I’ve heard it as a word, “Rustles”. Not sure how canonical that is though.

This could be done almost trivially using the typestate pattern: https://zerotomastery.io/blog/rust-typestate-patterns/.

• big oil, for the last 70 years, fully aware of the consequences of their greed.

I mean, the simple proof is that Rust has been growing by leaps and bounds in the embedded world, which is the closest to bare metal you get. It’s also being used in the Linux kernel and Windows, and there are several projects building new kernels in pure Rust. So yeah, it’s safe to say that it’s as close to the metal as C.

Also, the comparison to Java is understandable if you’ve only been exposed to Rust by the memes, but it doesn’t hold up in practice. Rust has a lot more syntax than C (although that’s not saying much), but it’s one of the most expressive languages on the market today.

It’s satire, pointing the cognitive dissonance that allows people to recognize that fumes are deadly but never question the fact that our entire “modern” concept of city planning is built around constantly being in and around the machines that produce these fumes 24/7.

My preferred variation of this is to make it an open question that leaves them in the position of authority, and assumes that they made a deliberate decision.

For example, instead of “Why aren’t you using StandardLib that does 90% of this?”, I would try “Could this be achieved with StandardLib? Seems like it would cover 90% of this”.

As with all things, there’s a trade off: how much do you value the [convenience/ecosystem/insert other thing that proprietary system offers you] compared to the ongoing cost - monetarily but also in terms of privacy, market manipulation, environmental impact, etc. of supporting and relying on the proprietary system.

You can’t do your work without connecting to Exchange because Microsoft has leveraged decades of monopolistic gains to make Outlook the default option for any “serious” business, and has invested even further in making inconvenient (or soon impossible) to connect to Exchange from outside their sanctioned walled gardens. Demanding that Linux solve that for you is akin to demanding that the person commuting on bike undo a century of automotive-centric urban expansion in the US so that they don’t interrupt your commute. It’s not their fault they can’t solve the problem and it doesn’t help anyone to get mad at them for doing their best to behave rationally in a system stacked to only serve the 1%’s corporate interests.

The most obvious cost of detached homes is the completely unsustainable amounts of infrastructure required to maintain them. Roads, sewage, electric, etc.

It’s a well documented fact that suburbs of sprawling suburban homes are bankrupting towns/cities all across America and only the densely built downtown cores are keeping these cities afloat because the tax revenue of dense mixed-use areas is substantially higher than the cost of maintaining the infrastructure for these places. Check out Strong Towns if you’d like to know more and see the studies showing all this.

I switched from Zsh to Nushell almost two years ago and I have never looked back. If you need POSIX compliance, Nushell is a no go. But it sounds like your real problem was just that Zsh was familiar whereas fish was not. Nushell strikes the perfect balance of offering the commands you’re used to but letting everything just make intuitive sense. Plus, its help command is so far above and beyond other shells. I rarely need to open the Nushell docs (even though they’re really good), and I never have to go the community (even though it’s awesome), because I can figure pretty much everything out just from interacting help within the terminal.

For anyone interested in learning more about bloom filters, this is a technical but extremely accessible and easy to follow introduction to them, including some excellent interactive visualizations: https://samwho.dev/bloom-filters/

More specifically, he argued (and the recent and upcoming releases of most major frameworks agree) that rendering most content on the server with islands of client-side interactivity is the future.

That’s not necessarily a huge revelation, but the big difference from what people have been doing with PHP for decades is the level of integration and simplicity in mixing server-side and client-side code seamlessly so that a dev can choose the appropriate thing in each context and not have to go through a lot of effort when requirements change or scaling becomes an issue. I would say that this represents a new level of maturity in the “modern” web frameworks where devs can choose the right technology for every problem to serve their users best.

I think you would be pleasantly surprised by the direction web dev is moving if you gave it a chance.

For example, I suspect that you think one of the ways the web has gotten shittier is because sites are too bloated and JavaScript frameworks are too heavy and slow.

One of the key takeaways is that, across almost all frameworks and stacks, web dev is moving back to doing as much work on the server-side as possible, while retaining the minimum necessary interactivity via Islands of Interactivity with much lighter JavaScript than what was pushed for the last decade.

The major car manufacturers have literally been collaborating for the better part of a century, along with oil companies, to keep Americans dependent on cars. It’s a well-documented fact. Even long before Citizebs United made corporate bribery legal, they’ve been using the state’s power to quell protests, destroy non-car infrastructure, and outlaw use of our streets for anything except cars.

Have you tried developing a GUI app for Windows in the last 5 years? All the official first-party frameworks are either mostly deprecated (WPF, WinForms), or half-baked and despised by every developer I’ve talked to about them (MAUI).

I’ll stick with nushell for terminal-first data interactions.

I think the point is that they don’t want to have to use a full JS framework (which is what HTMX is) for this behavior.

And this is where HTMX fits in. It’s an elegant and powerful solution to the front-end/back-end split, allowing more of the control logic to operate on the back-end while dynamically loading HTML into their respective places on the front-end.

But for a tech-luddite like me, this was still a bit too much. All I really want to do is swap page fragments using something like AJAX while sticking to semantically correct HTML.

EDIT: Put another way, if you look at HTMX’s "motivation"s:

motivation

• Why should only <a> & <form> be able to make HTTP requests?
• Why should only click & submit events trigger them?
• Why should only GET & POST methods be available?
• Why should you only be able to replace the entire screen?

By removing these constraints, htmx completes HTML as a hypertext

It seems the author only cares about the final bullet, and thinks the first three are reasonable/acceptable limitations.

If you dig the structured output of powershell, you might want to check out Nushell. It’s a cross-platform shell that builds on powershell’s structured data approach but is much less verbose and, in my opinion, more intuitive than both powershell and Posix shells.

I mean yes, but also the idea is that the user of serverless doesn’t have to configure, provision, maintain, etc. any server. You as the user just provide the code, and their platform handles running it on a server when needed.

This misses the fact that even the experts have been using “AI” to refer to whatever technology used to seem impossible, until it becomes commonplace. Before LLMs there were heuristic algorithms, and then expert systems, and then intelligent agents and then deep learning. As the boundaries of what is deemed achievable expand, the definition of AI moves to just beyond the frontier.

There are several things I disagree with in this article, although I see where the author is coming from. I will never be onboard with “I’ll take my segfaults and buffer overflows.”, and I fundamentally disagree about concurrency. I also think that cargo is fantastic, and a lack of standard build tools is one thing that holds rust’s predecessors back.

However, a majority of the authors points can be boiled down to “C is more mature”, which doesn’t tell us much about the long-term viability and value of these languages. For example, in the author’s metric of stability and complexity, they use C99 as the baseline, but C99 is the state of a language that had already had almost 3 decades of development, whereas Rust has been stable for less than a decade. Talking about superior portability, stability, and even spec, implementations, and ABI is in some real sense just saying “C is older”.

That’s not to say those things aren’t valuable, but rather they aren’t immutable characteristics of either language. And given that safety is playing an ever more important role in software, especially systems software, I think Rust will catch up in all the ways that are meaningful for real projects more quickly than most of us realize. I certainly don’t think it’s going anywhere anytime soon.