> Its compilation is slow. I mean SLOW. Slower than C++.
No way. Maybe Rust 1.0, but it's steadily improved and it's definitely faster than C++ now.
> It’s complex. Just as complex as C++.
True, but the problem with C++'s complexity is that you have to memorise all of it or you'll accidentally invoke UB. It's so complex that is basically impossible.
Rust is complex but most of the time the compiler will tell you if you got it wrong. There are exceptions of course (lots of async footguns) but it's still night and day.
> Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing
Not sure I really need to counter this...
> When handling lots of mutable shared state (GUI, DB, stateful services, OS/hardware), the performance of native Rust memory model is subpar, and non-native unsafes just leave you with slow compilation, high complexity, and no memory safety in the end — which makes Rust practically meaningless for heavy mutable state jobs.
Not totally clear what he's getting at here. Maybe the ergonomics of GUI style programming which are still being figured out? Hardly a deal breaker though is it? There are plenty of C/C++ GUI libraries with terrible ergonomics and the only one that is actually great (Qt) had to use a custom language extension for decades to achieve that.
> So, is the Rust bad or good? It’s neither. It’s a mediocre programming language with thousands of man-month put into its development
I would love to hear what he thinks a good programming language is, because I can easily pick more holes in any other language than he has.
He hates on C++ pretty much the same as he does on Rust. Your argument seems to be that Rust is better than C++, which is akin to trying to make the case that Cholera is better than Smallpox.
Language wars are boring and pointless, they all have areas of suckage. The right approach is to pick whichever one is the least worst for the job at hand.
Python? Jesus. One of the worst languages. Half of the community doesn't use static types, `import` is hilariously bonkers. Until very recently (uv) the tooling was absolutely atrocious (they still haven't fixed that dependency confusion issue). Insanely slow.
> I would love to hear what he thinks a good programming language is
Also, not the OP, but I bet it is Python.
- No compile time.
- Not as complex as C++.
- Memory Safety, while they don't care about this apparently, but nice to have.
- Plenty of ergonomic GUI style programming, like PySide (Qt for python).
Of course, I know there are many downsides to python. Such as interpreted languages, especially ones that are duck typed are very slow to run... but that's not one of the OP's complaints.
The article complained that a Rust program can crash when you call `unwrap`—in fact, the author says that's their strongest critique. Python crashes when you call `sys.exit`, so it's no better.
Unfortunately I don't think their critique is really coherent—this is an absurd standard.
Other languages have some kind of exception mechanism so the crashing unwrap gets caught and handled, preferably sanely. Erlang in fact is written around the idea of expecting stuff to crash, and restarting the crashed thing when it happens.
This crash gets caught and handled too: the process exits, the kubernetes pod fails, and the deployment recreates it from scratch. Panicking like this is a request for the infrastructure to turn the whole service off and on again, which is sometimes the correct way to deal with transient failures. The problem here is that the infrastructure was restarting the service with the same bad config every time, causing a crashloop. It's a system design bug.
I have never once seen someone try to catch a NoneType error in Python or an abort()/assert() in C, at least outside of things like HTTP handlers that try to catch everything - which you can also do in Rust!
>I would love to hear what he thinks a good programming language is, because I can easily pick more holes in any other language than he has.
I have a working theory that the classic programming is basically dying out:
https://bykozy.me/blog/llm-s-are-not-smart-rather-programmin...
You just cannot write fast and reliable program neither with C++ nor with Rust, because the fundamental model is broken and nobody's really bothered fixing it.
> Its compilation is slow. I mean SLOW. Slower than C++.
No way. Maybe Rust 1.0, but it's steadily improved and it's definitely faster than C++ now.
> It’s complex. Just as complex as C++.
True, but the problem with C++'s complexity is that you have to memorise all of it or you'll accidentally invoke UB. It's so complex that is basically impossible.
Rust is complex but most of the time the compiler will tell you if you got it wrong. There are exceptions of course (lots of async footguns) but it's still night and day.
> Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing
Not sure I really need to counter this...
> When handling lots of mutable shared state (GUI, DB, stateful services, OS/hardware), the performance of native Rust memory model is subpar, and non-native unsafes just leave you with slow compilation, high complexity, and no memory safety in the end — which makes Rust practically meaningless for heavy mutable state jobs.
Not totally clear what he's getting at here. Maybe the ergonomics of GUI style programming which are still being figured out? Hardly a deal breaker though is it? There are plenty of C/C++ GUI libraries with terrible ergonomics and the only one that is actually great (Qt) had to use a custom language extension for decades to achieve that.
> So, is the Rust bad or good? It’s neither. It’s a mediocre programming language with thousands of man-month put into its development
I would love to hear what he thinks a good programming language is, because I can easily pick more holes in any other language than he has.
This anti-Rust zealotry is super tedious.