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.

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.

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.

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.

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.

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.

Seems a bit clickbaity to me. It’s a flaw in Windows/cmd.exe, not Rust. Rust is just called out because it tries to emulated proper argument passing on Windows (and didn’t get it perfectly right). All languages are affected by this but most of them just throw their hands in the air and say “you’re on your own”:

• Erlang (documentation update)
• Go (documentation update)
• Haskell (patch available)
• Java (won’t fix)
• Node.js (patch will be available)
• PHP (patch will be available)
• Python (documentation update)
• Ruby (documentation update)

It’s also extremely unlikely that you’d be running a bat script with untrusted arguments on Windows.

Maybe all of the stars, forks, and discussions on the GitHub page are from fake accounts

All 9k stars, 10k PRs, 400 forks & professional web site are fake? Come on this is about the most obviously not fake project I’ve seen!

How do you know when a product like this can be trusted?

The same way you tell if anything can be trusted - you look at the signals and see if they are suss. In this case:

• Lots of stars
• Lots of real code in the repo
• Professional looking website with commercial pricing
• Lots of issues
• Good English

The amount of effort it would take to fake this for very little benefit is enormous.

Maybe I’m just being paranoid.

Yeah just a little!