You missed the point. He understands all these things you tried to explain. The point is that your definition of the word "concurrency" is objectively wrong.

You:

you seem to be doing multiple things at the same time. In reality they are run little by little one after another

The actual meaning of the word "concurrency":

The property or an instance of being concurrent; something that happens at the same time as something else.

Wiktionary actually even disagrees with your pedantic definition even in computing!

(computer science, by extension) A property of systems where several processes execute at the same time.

I suspect that concurrency and parallelism were actually used interchangeably until multicore became common, and then someone noticed the distinction (which is usually irrelevant) and said "aha! I'm going to decide that the words have this precise meaning" and nerds love pedantic "ackshewally"s so it became popular.

def foo(x):
  return x.whatevr

No linter is going to catch that.

I think I disagree with everything here.

Exceptions Are Much Easier to Work With

Well, they're "easier" in the same way that dynamic typing is easier. It's obviously less work initially just to say "screw it; any error gets caught in main()". But that's short term easiness. In the long term its much more painful because:

1. You don't know which functions might produce errors, and therefore you don't know where you should be even trying to handle errors. (Checked exceptions are the answer here but they are relatively rarely used in practice.)
2. Actually handling errors properly often involves responding to errors from individual function calls - at least adding human readable context to them. That is stupidly tedious with exceptions. Every line turns into 5. Sometime it makes the code extremely awkward:

try {
   int& foo = bar();
} catch (...) {
   std::cout << "bar failed, try ...\n";
   return nullopt;
}
foo = 5;

(It actually gets worse than that but I can't think of a good example.)

Over 100× less code! [fewer exception catching in their C++ database than error handling in a Go database]

Well... I'm guessing your codebase is a lot smaller than the other one for a start, and you're comparing with Go which is kind of worst case... But anyway this kind of proves my point! You only actually have proper error handling in 140 places - apparently mostly in tests. In other words you just throw all exceptions to main().

System errors [he's mainly talking about OOM, stack overflow & arithmetic errors like integer overflow]

Kind of a fair point I guess. I dunno how you can reasonably stack overflows without exceptions. But guess what - Rust does have panic!() for that, and you can catch panics. I'd say that's one of the few reasonable cases to use catch_unwind.

Exceptions Lead to Better Error Messages

Hahahahahaha. I dunno if a bare stack trace with NullPointerException counts as a "better error message". Ridiculous.

Exceptions Are More Performant

Sure maybe in error handling microbenchmarks, or particularly extreme examples. In real world code it clearly makes little difference. Certainly not enough to choose an inferior error handling system.

I would say one real reason to prefer exceptions over Result<>s is they are a fair bit easier to debug because you can just break on throw. That's tricky with Result<> because creating a Err is not necessarily an error. At least I have not found a way to "break on Err". You can break on unwrap() but that is usually after the stack has been unwound quite a bit and you lose all context.

They're being diplomatic. From Wikipedia:

The name "Godot" was chosen due to its relation to Samuel Beckett's play Waiting for Godot, as it represents the never-ending wish of adding new features in the engine, which would get it closer to an exhaustive product, but never will.

Rust is the obvious answer, though I dunno how suitable it really is for games - the most popular game engine is Bevy and I'm not sure I like it too much. Also there seems to be much more focus on game technology than making actual games.

Don't worry about it being "functional" though. It did support lots of FP features but the typical style is much more like imperative C++ than Haskell.

I would also look into Zig though.

I would say because a) there are zero alternatives, and b) it's pretty powerful; you can generally do pretty much any layout even if it requires hacks, c) switching to something else is clearly infeasible so it's not worth even asking for.

Just have to live with it (on the web at least).

I don't think VSCode's mantra is that it "just works". It's definitely a "platform" IDE like Eclipse was.

I disagree. People run Bash scripts they haven't read all the time.

Hell some installers are technically Bash scripts with a zip embedded in them.

The reason systemd absorbs other services is because it's trying to make a proper integrated OS userland. Having a load of separate components that don't really know anything about each other kiiind of works, but it's super janky.

For example Windows has supported a secure attention key sequence (ctrl-alt-del) for literal decades. Linux still doesn't support this very basic - and critical for shared computing environments like schools - feature, because it requires coordinating X11 and logind and the kernel and god knows what else and they simply aren't properly integrated.

The systemd hatred strongly reminds me of when Xorg started automating the config and you no longer needed xfree86config. You didn't need to manually write mode lines and tell X that your mouse had 3 buttons, and some people did not like that.

Yes it sounds completely insane that people wouldn't like this obvious improvement where things used to require tedious manual configuration and now they worked automatically but some people really didn't I promise! My theory is that it's because a) it made their hard won knowledge obsolete, making them less smart relatively, and b) they resented the fact that they had to go through the pain but new people wouldn't and that isn't fair.

Seems similar with systemd. I would like my laptop to sleep properly please.

Also I have actually read some of the sudo source code. There's absolutely no way that code should be SUID. Insane.

Yeah... Usually if you join a company with bad practices it's because the people who already work there don't want to do things properly. They tend to not react well to the new guy telling them what they're doing wrong.

Only really feasible if you're the boss, or you have an unreasonable amount of patience.

Neat FP style. Pretty verbose though. Someone should invent a terser syntax so you don't need to write do_two_things everywhere. It's a common operation so maybe it could even be a single character.

This is a misconception that's common among beginner C programmers. They think C is high level assembly and don't understand the kinds of optimisations modern compilers make. And they think they're hardcore and don't make mistakes.

Hope you figure it out eventually.