"Criticizing the Rust Language, and Why C/C++ Will Never Die"
https://www.viva64.com/en/b/0324/
Not sure why certain members of the Rust community aren't happy with just having a neat language. Making one false claim after another isn't doing them any favors. It's just aggravating, especially when people who should know better start to believe the hype.
FAKE NEWS!
Fortunately the overwhelming majority of the community isn't afraid to call this post out, judging by the comments at https://www.reddit.com/r/rust/comments/63ijkw/rust_optimizat... :) I've never seen the author engage with the Rust community in any great capacity (they're not a regular in any forum that I frequent, and I can't name any libraries that they've written), so I wish he'd take the time to learn Rust more before blogging about it.
There is an opportunity to do some very cool things with Rust and I think most people would love to see a "better together" mindset being shared.
Saying this isn't going to do my karma any good, but it's almost certainly because they're feeling competitive pressure from the even more numerous Go developers doing the exact same thing with their language. A lot of people feel like it's time to move on from C and C++, especially to something with better memory-safety properties. (This is for low-level infrastructure code, mostly. Other kinds of code have been better written in higher-level languages for a long time.) Rust developers/advocates feel that it has the best current answer to that need. They might even be right. Then they see the total deluge of Go propaganda, encouraging people to adopt what they feel is a less-good approach. They know that "just having a neat language" won't be enough to overcome that. Therefore, out of a completely laudable desire to help others avoid a mistake, they ratchet up their own rhetoric to match. Some get a bit carried away.
If the goal is to discourage overly ardent advocacy for Rust, we also need to discourage the same for other languages as well - not just Go but also Swift, Erlang/Elixir, *ML, and so on. The pattern of people becoming tiresome about their choice of programming language (or paradigm) has existed for a long time.
> Rust is safe indeed but, unfortunately, far from fast.
Today's version of that graph: http://benchmarksgame.alioth.debian.org/u64q/which-programs-...
Rust appears second, after C and before C++.
> And what actually makes Rust safe, by the way?
Yes, a company that makes static analysis tooling is going to claim that their static analysis tools give you the same degree of safety. They don't, generally, due to language semantics. If this was truly a viable path, we wouldn't have created (okay this is a bad word, I mean "Mozilla probably wouldn't be looking to create Servo and instead would have gotten the guarantees for Firefox by using those tools rather than sponsoring Rust's development) Rust in the first place; we would have just used them. (That doesn't mean they're bad of course, but they can't do what rustc can.)
> Even apart from that speed/safety compromise issue, I'm also skeptical about the language's design as such. In particular as regards to the five types of pointers used in it.
This was already outdated information when the article was originally created; that all went away half a year earlier than the post. Doesn't give much confidence that the author actually spent any significant time with Rust.
> Macros used as a crutch to make up for the excessive verbosity caused by the absence of normal exceptions.
This is not what macros are for. One of these macros did exist, and today is a language feature (?). But there are lots of reasons why exceptions aren't used, including by many C++ programs.
> People are idiots and cargo actively encourages downloading packages directly from git repositories, bypassing Crates.io.
I can't speak to this problem at that time, I don't remember it being a thing, but maybe it could have been. Included for completeness :p
> I can generally understand why it doesn't have a decent inheritance and exceptions, but the fact itself that someone is making decisions for me regarding things like that makes me feel somewhat displeased. C++ doesn't restrict programmers regarding what they can or cannot use.
C++ includes or doesn't include lots of language features, this feels like a real stretch.
> Now, since we have taken the path of simplification, why not throw away all those language extensions? The current state of things resembles the Haskell world where every programmer is coding in their own dialect.
I _think_ this is referring to the stability markers, as we have nothing like Haskell's language extensions. If so, well, they exist due to the way the release process works, and so did and were steadily going away when this was written.
> Smart pointers, for you to know, are far not free of charge and do not ensure a fixed time of garbage collection.
"smart pointer" is not synonymous with "reference counting". The answer to this problem is "use an arena", which you can use in Rust just like C++.
> Has anyone seen a strict description of Rust's semantics? Does it have a memory model at least?
This is true, with lots of ongoing work, including millions of Euro of grants to academics working on it. Not quite there yet though. C and C++ had over a decade before they had their respective standards, so we've still got eight years, by that measure.
> I can't but remind you for one more time that the source of troubles is usually in humans, not technology.
This is just straight-up opinion and so isn't really refutable.
Anyway, just saying. In the moment, that article wasn't very good, but today, it's pretty much entirely irrelevant.
In context: "You can see that the order would be different if it was based on the median scores instead of the [pdf] geometric mean scores."
http://benchmarksgame.alioth.debian.org/u64q/which-programs-...