Phoronix has notoriously dumb commenters. I don't know why exactly but it's really notable.

Hackaday too. Again, not sure why. They're both significantly worse than Reddit, HN, Ars or here. Maybe even worse than YouTube comments...

Yeah... This doesn't sound promising. Refusing to acknowledge the obvious fact that AI and hostile mods have driven away 99% (not an exaggeration!) of their audience. A visual makeover before the change anything. Trying to sell the Q/A database for AI despite the fact that you can download it for free. They even talk up their job advertising product that they inexplicably cancelled a few years ago (btw I found levels.fyi has a pretty good job database if anyone is looking).

If it were me I would:

1. Use AI to improve question quality - if people post obviously bad questions get AI to improve it via a conversation.
2. Make it waaaaay harder to close questions. Like, require 10 votes and allow the asker to reopen it for free once.
3. Make it so questions can't go below 0 points.
4. Make it impossible to close as duplicate. You should be able to mark questions as possible duplicates (and the asker can say "yes it is") but if they don't it should stay open.
5. Maybe even make it impossible to close questions at all. What actual purpose does it solve apart from driving people away?

Apart from the AI that's all stuff they should have done 10 years ago.

It's probably too late anyway.

I don't think that's a surprise to anyone that has actually used them for more than a few seconds.

Rust for now, by a wide margin. But I'm following other languages that I think have the potential to surpass it, including Vale (promises way more than it delivers currently), Koka, Hylo, maybe Lobster.

...for people who refuse to use static types.

Definitely agree with tech debt. Seems like nobody except me cares about improving things, which is surprising given this survey!

Also definitely agree about reliability of tools/systems, but again it feels like it's just me that cares about robustness - everyone else is very happy to churn out hacky Bash scripts, dynamically typed Python and regexes with abandon.

Either you're all a bunch of hypocrites or the SO survey is quite a biased sample!

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.

Yeah except it's named after the play so it's definitely pronounced God-oh. I think people just mispronounce it Go-dot if they haven't heard of the play. Looking at you Mr Linus Tips.

It's because

1. They're old and they don't want to have to spend time learning something new.
2. They spent a lot of time learning C and getting moderately good at it. They don't want that knowledge to become obsolete.
3. They currently don't know Rust, and don't want to feel like the thing they do know is no longer the best option.
4. They aren't the ones with the idea to use Rust, and they don't want to lose face by accepting that someone other than them had a good idea. Especially not some young upstarts.
5. Supporting Rust is extra work for them and they don't care about memory safety or strong types etc.

In order to avoid losing face they'll come up with endless plausible technical reasons why you can't use Rust in order to hide the real reasons. They may not even realise they're doing it.

Some of the reasons might even be genuinely good reasons, but they'll come up with them as an "aha! So that's why it's impossible" rather than a "hmm that's an issue we'll have to solve".

It's not just Rust Vs C. This naysaying happens wherever there's a new thing that's better than the established old thing. It's a basic human tendancy.

Fortunately not everyone is like that. Linus seems in favour of Rust which is a very good sign.

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

Honestly those things just don't sound like common enough actions to be worth shaving 0.5 seconds off. How often do you know exactly how many lines to move a line by? And how often do you even need to move a line that far?

I still don't buy it.