BatmanAoD

Unless you work for the committee or for ISO somehow, then I don't think that really follows. C++ and JavaScript were both used in production for decades before they had standards, and the dissolution of the standards committee wouldn't cause compiler vendors to stop developing compilers.

Wait, which one leaves you unemployed?

In addition to not actually being correct, I don't think the information you've provided is particularly helpful in answering OP's question.

The first part is confusing what "middleware" means. Rather than "duplicating" functionality, it connects libraries (I'm guessing this is what you meant). But that has nothing to do with a language being compiled versus "directly executed", because compilation doesn't connect different services or libraries; it just transforms a higher-level description of execution into an executable binary. You could argue that an interpreter or managed runtime is a form of "middleware" between interpreted code and the operating system, but middleware typically doesn't describe anything so critical to a piece of software that the software can't run without it, so even that isn't really a correct use of the term.

The second part is just...completely wrong. Lisp, Fortran, and other high-level languages predate terminal shells; C obviously predates the shell because most shells are written in C. "Most original code" is in an actual systems language like C.

(As a side note, Python wasn't the first scripting language, and it didn't become popular very quickly. Perl and Tcl preceded it; Lua, php, and R were invented later but grew in popularity much earlier.)

Pretty much all languages are middleware, and most of the original code was shell/bash.

What? I genuinely do not know what you mean by this.

Yeah, I was particularly glad to see the change in loop variable semantics become a stable part of the language. That was a terrible footgun.

There are other things I dislike about Go, but I do think it's improving while maintaining its better qualities, which is no small feat.

It is similar to old error codes, but I feel that this makes one always have to be mindful of error handling and the non happy path

Technically you need a separate linter (errcheck) to ensure you don't just ignore errors. This is...not great. (That should have been a compiler error.)

I agree that it's a "cop-out", but the issue it mitigates is not an individual one but a systemic one. We've made it very, very difficult for apps not to rely on environmental conditions that are effectively impossible to control without VMs or containerization. That's bad, but it's not fixable by asking all app developers to make their apps work in every platform and environment, because that's a Herculean task even for a single program. (Just look at all the compatibility work in a codebase that really does work everywhere, such as vim.)

Oh, I see, so you don't exercise your muscle memory but you at least see the "raw" commands more often.

Looks like this was suggested in nushell, and someone came up with a way to emulate the behavior manually: https://github.com/nushell/nushell/issues/5552#issuecomment-2113935091

Edit: there's another issue for this: https://github.com/nushell/nushell/issues/5597

Hopefully nu will decide to implement it properly in the future.

Hm, I'm not sure what you're looking for, then.

How are fish abbreviations different from nushell aliases for working on temporary machines? Surely your Windows sandboxes don't have fish installed?

I think it really depends how much time you actuall spend working on these temporary systems, and what mechanisms are available for automatically configuring those systems, even temporarily. You can generally assume that some version of bash is available on all systems, so if you have a bashrc that you like, you could use sshrc or kyrat to at least bring over some functions and aliases (I used sshrc long ago but haven't tried kyrat): https://github.com/cdown/sshrc, https://github.com/fsquillace/kyrat

If you do want to use nushell on remote systems, possibly xxh would enable that; I haven't used it personally, but it looks promising: https://github.com/xxh/xxh

If you're not using ssh, then it really depends what you are doing.