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.)

My point is that the claim in the comic and in other comments that this corrupts your repo or loses work simply isn’t true.

It’s not even actually that bad, at least not since January of 2020: https://stackoverflow.com/a/59687740/1858225

Huh. I had forgotten that git does actually create a file with the branch name. But it doesn’t actually screw up the .git folder or lose your data when you try to do a rename like this; it just rejects the rename unless you also use the “force” option. This has been the case since at least January of 2020. But apparently it actually doesn’t always use a local file for branch names, so sometimes there’s a problem and sometimes there isn’t, which I guess is arguably worse than just having consistently-surprising behavior.

I honestly don’t even understand the joke. Case-insensitive file names cause problems, but what does that have to do with version control branch names?

Yeah, consistency is good, which is why it’s good to follow the spec. I’m saying that the decision to make errors be flat strings in the spec was a bad one. A better design would be what you have, where code is nested one level below error, plus permitting extra implementation-defined fields in that object.

The spec requires errors to be a single string, and also mandates using the space character as a separator? I’m not a fan of deviating from spec, but those are…bad choices in the spec.

For anyone else wondering, here’s the text of the actual email cited as the CoC violation:

Michal, if you think crashing processes is an acceptable alternative to error handling you have no business writing kernel code.

You have been stridently arguing for one bad idea after another, and it’s an insult to those of us who do give a shit about writing reliable software.

You’re arguing against basic precepts of kernel programming.

Get your head examined. And get the fuck out of here with this shit.

I agree, but if you look at the specific email linked, it very clearly crosses the line into direct abuse, whereas most of Linus’s rants do exist in a slightly greyer area (even if they’d be grounds for a discussion with HR at an actual company).

Understandable; no time to check details when your fuse is that short

The second button is actually a pretty major change!

It means both.

It had a reasonably clear warning, though; a screenshot is included in this response from the devs. But note that the response also links to another issue where some bikeshedding on the warning occurred and the warning was ultimately improved.

In reality, that was added four and a half years after this issue was opened.

Yes, the dialog was changed, as part of this linked issue (and maybe again after that; this whole incident is very old). After reading some of the comments on that issue, I agree with the reasoning with some of the commenters that it would be less surprising for that menu option to behave like git reset --hard and not delete tracked files.