Right, but their endorsement is still likely to do more harm than good in terms of public perception of the law, I think.

Kingdom of Heaven, I believe

Nah, this is society if we move past needing so many passwords. Passkeys, federated logins, and one-time login codes are all preferable.

But how does the alternative solutions compare with regards to maintainability?

Which alternative solutions are you thinking of, and have you tried them?

Rust has been mentioned several times in the thread already, but Go also prohibits "standard" OOP in the sense that structs don't have inheritance. So have you used either Rust or Go on a large project?

It's not a strawman, though, because Martin's actual example code in the book is like this, including a full module he rewrites toward the end.

There is nothing specific in the rust port that makes fish more available for servers or LTS distros.

Being written in Rust does improve availability, because by default Rust statically links against everything except libc, and you can opt out of that if necessary. So there is inherently no need to build separate dependency packages for each distro, unless you use a Rust crate that specifically links to a C or C++ library.

I mean to be fair, that's a pretty useful tool.

BEAMScript!

git checkout ma<tab>

If you don't have autocomplete set up for your shell, get it working. If someone has a different branch named ma..., ask if you can delete it, and get your team to adopt a decent branch naming convention.

I very much understand thinking that Rust has too much hype, but the differences between C and Rust are so fundamental that "switching between" them just to "keep your interest fresh" seems ill-advised to me. To be honest, your statements about both C and Rust so far seem pretty superficial; have you actually used Rust for anything nontrivial?

C syntax is simple, yes, but C semantics are not; there have been numerous attempts to quantify what percentage of C and C++ software bugs and/or security vulnerabilities are due to the lack of memory safety in these languages, and although the results have varied widely, the most conservative estimate (this blog post about curl; see the section "C is unsafe and always will be") ended up with an estimate of 40%, or 50% if you only count critical bugs. If I recall correctly, Microsoft did a similar study on one of their projects and declared a rate closer to 70%.

This means that the choice of language is not just about personal preference. Bugs aren't just extra work for software developers; they affect all users of software, which means they affect pretty much everyone. And, crucially, they're not just annoyances; cyberattacks of various kinds are extremely prevalent and can have a huge impact on people. So if 50% or more of critical software vulnerabilities are due to the choice of language, then that is a very good reason to pick a safer language.

Rust is not the only choice for memory-safe languages. If you like the simplicity of C, you should definitely learn Go (it's explicitly designed to be as simple as possible to learn). But I would also strongly recommend looking into Zig, which hews much closer to C than Rust does; in fact, it has probably the best interoperability with C of any modern language.

This is probably the most well-researched piece of writing on the matter: https://www.hillelwayne.com/post/are-we-really-engineers/

It's pretty nice. I've been following its progress essentially since the beginning and would like to adopt it as my primary shell eventually, but it's had some blockers that prevent me from switching completely, most of which have been resolved by now. The one I'm currently waiting for is the ability to suspend and resume processes: https://github.com/nushell/nushell/issues/247