Criticizing the Rust Language, and Why C/C++ Will Never Die
viva64.com
viva64.com
Not everyone is going to like Rust. That's totally okay.
I've seen language communities, especially newer ones where people are particularly passionate, essentially turn into... this is a bit strong, but mini-cults. Where if you don't like the language, you're obviously an illliterate pleb who needs to learn how to code. This ends up creating an insular, backwards, dangerous culture. I'd prefer a culture of "we're doing cool stuff, I hope you like it, but reasonable people may not, and that's okay."
I'm not really speaking about any particular language here, please don't try to 'figure out who I'm talking about' or something.
While it's true that the author may have only breifly tried Rust, and not tried to understand design choices, this is going to be the first of many, many blog posts like this as we grow after 1.0. The vast, vast majority of programmers haven't even tried Rust yet. Flamebait blog post titles are a standby of today's programmer culture. We shouldn't get too hung up on it, and instead, focus on doing cool stuff with the people who do get it.
http://www.reddit.com/r/rust/comments/35pn5a/criticizing_the...
Today, I see similar reactions to leading edge technologies and languages that are difficult to understand, whether they be FP, Rust, or Haskell. Time will tell whether these things break into the mainstream as did O-O, C++, and Java. I personally think that Rust is onto something, but it is too early to know how much impact it will have on the mainstream. Who knows, 10 years from now, we may see a dominant OS and application ecosystem written completely in Rust that has a level of quality seldom seen today. Or maybe we will see some of the ideas in Rust incorporated into a future version of C++. Or maybe Rust and its ideas will prove to be too impractical and will fade away.
I hope to have the time to learn and use Rust soon, but I certainly understand those who prefer to wait and see. What I don't care for is a knee-jerk reaction against something because it is unfamiliar.
I wouldn't lump all three together just because they may happen to be somewhat difficult to understand. I see your point regarding FP (and Haskell happens to be an FP language). However, Rust is a multi-paradigm language, just the way C++ is. Time and time again in my day job, I see issues in our code that Rust would have prevented at compile time (and we're not using C++).
It's true that Rust aficionados tend to come across as religious zealots. Most "up and coming" language advocates do. This is a case where zealotry is understandable and maybe necessary. When you've got a good thing that's an underdog in a world ruled by the familiar, the status quo, zealotry is the only way to break through the complacency.
It's also true that between awkward English, poor structure, and a lack of rigor in argumentation, this article comes across as drum-banging rather than thoughtful. I'd like to see an article that respects Rust, respects C/C++, and offers a measured, well-argued case for how they compare and what their prospects are in the long term when "establishedness" becomes less relevant (i.e. when Rust, through becoming more widespread, becomes less hampered by not having a large community or job base).
I thought this article had some truth in it, but in general I'm always frustrated by the implication (which pops up from time to time) that languages with similar goals are mutually exclusive and newer ones must kill the older ones or themselves die. C++ is a great language which has been on a tear of improvement for the past decade or so, and suggesting that something will, or even should, kill it is silly. But it's just as silly to suggest that it is pointless to target the same goals as C++ while attempting to improve on some of its weaknesses.
I think it is likely that Rust will not be the rocket-ship of growth that Go has been, because while Go has attacked a niche by largely upending its ground rules, Rust merely provides some (arguably) better trade-offs within a fundamentally similar paradigm. A better comparison will perhaps be Scala and Java, and that's something to aspire to – Java isn't going anywhere, but there are lots of great things written in Scala and plenty of opportunities to use it professionally.
Certainly, it will be interesting to see where or if Rust finds its place in the types of large and enduring projects that it takes to really get a language off the ground. I think a particularly interesting area could be the ever-expanding database sector. It's clear (perhaps to the chagrin of many) that there is room for many different database products attacking different trade-offs, and they are often written in C++ (or C) for performance reasons, but have high bars for robustness and concurrency for which Rust really may be a boon.
I do think a lot of Rust's adoption will hinge on its performance story, and that was the argument in this article, and others along these lines, that is the most compelling. To be in the running for projects that would otherwise be written in C++ (like the database projects I mentioned), Rust will need to have credible and competitive benchmarks. I think it has made many good choices about the fundamental trade-offs that have a huge impact on efficiency (like defaulting to value types), but that it remains to be seen if pervasive safety comes at too large a cost.
One way to do this would be to get a Rust aficionado who has written a significant amount of Rust code and knows all the nooks and crannies to work with a C++ counterpart on such an article. If both parties are mature enough (zealotry allowed on both sides, but constructive zealotry :P), we can get a decent post which addresses either side and has all the points and counterpoints that might come up in a discussion.
I'm not exactly a seasoned Rustacean, but I'd be more than happy to try this out with someone. (might take some time for me to get to it though, intern just started and I have some other Rust blog posts I want to get done first)
While D is alright it was never really slated to be the "next systems language" in the way Rust is being positioned.
The other part of the argument that comes across as really weak is criticism of Cargo. That would make sense if the alternative had better tooling. However if you have ever tried to assemble libraries and a decent build process for them in a large C++ project you would know that Cargo is almost like a gift from god.
Claiming that Rust is "simple" because it doesn't have inheritance is also a straw-man. Inheritance is far from the only means of polymorphism and it's presence has little bearing on the overall power of the language. In fact I would argue Rust's trait system is actually the more powerful of the two, but that is just my opinion.
Overall the author comes across as trying to find reasons to dislike Rust for the sake of disliking it, as if they feel threatened by it's very existence.
Have you actually tried to do that or understand what Rust unsafe code means ? Interfacing between different run-times and memory management systems is complicated (and often slow), rust unsafe is simply giving up on compiler verification.
He misses the point on premature optimization entirely.
>For Android, it's also hardly probable, but for a different reason: there is way more than one architecture there, so JVM will do much better
And yet people write C++ code for Android, or is he arguing that Rust won't replace Java on Android (that's a pretty big straw man)
>I can't but remind you for one more time that the source of troubles is usually in humans, not technology . If your C++ code is not good enough or Java code is painfully slow, it's not because the technology is bad - it's because you haven't learned how to use it right. That way, you won't be satisfied with Rust either, but just for some other reasons. Isn't it easier to learn how to use more popular tools and start liking them?
Different tools require different amounts of effort to get things "right" and it's not simply a matter of "learning things" - humans have limited brain power - there's only so many things you can be aware of at any time - good tools reduce the number of those things required to get the job done - C++ is bad at this.
I agree with some of his points about the ergonomics and the implementation/tooling but I also feel like those are just growing pains - now is the time you start working on Rust for your weekend github project and start paving the way for actual real world use by early adopters which is at least a year off from this point.
This is obviously not the norm, as the bind egg is very good, but it's definitely out there. Makes me wish that there were other languages which offered something similar to bind, but alas CHICKEN is the only one I know of thus far.
This might be the case of conflict of interest and/or heavy bias.
Many of the points are valid, but it's important to remember Rust is not even released. Java 1, Ruby 1, Perl 1, Python 1 were all pretty terrible compared to their current manifestations.
Don't get me wrong, I understand difference between constructive criticism and biased grunt of grumpy C++ programmer.
There's no C/C++. They are entirely different languages (even if C is supposed to be a subset).
Not exactly suitable for mission critical systems. The fact that they are used for that is more due to the fact that they can interface with hardware at a fairly low level and the amount of engineers with C (and nowadays, C++) knowledge.
The 'formal' standard doesn't help you much when there's so much undefined behavior.
Tool availability is a fair point.
I think the OP is trying to say that both C and C++ have international standards.
> Not exactly suitable for mission critical systems. The fact that they are used for that is more due to the fact that they can interface with hardware at a fairly low level and the amount of engineers with C (and nowadays, C++) knowledge.
And highly deterministic behaviors, crucial in real time systems. But I think Rust is trying to provide those guarantees too.
If Rust had a formal standard, and had the tool ecosystem, then I could see it being an interesting possibility for critical systems, certainly for the same places that Java + RTSJ would be appropriate. I won't be the first one to try and push a Rust-powered device through regulatory approval though.
Forgot about that, a very good point.
C++ is a subset of C, not the other way around.
> the fact that they can interface with hardware at a fairly low level
That's certainly one reason. Others include raw performance (think real-time safety-critical applications), no funny abstractions, tighter memory footprint, more flexibility, etc.
> and the amount of engineers with C (and nowadays, C++)
While I believe there are a number of C++ engineers out there, I'd wager that the number of competent C language engineers has dwindled over the years. Sure, everyone learns some C, but to know it well enough to write embedded real-time safety-critical systems is a whole different game. (not to mention the number of Java engineers has greatly outpaced even C++ engineers, thanks to University teaching Java, Android's dominance, and the lower barrier to entry).
> The 'formal' standard doesn't help you much when there's so much undefined behavior.
The formal standard defines what is undefined. Your safety-critical code shouldn't rely on some compiler-specific quirks or some magical code, but rather it should stay within the bounds of well-defined behavior.
This is not true, the two languages have diverged: http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B
I can't see how this statement could possibly be true.
> no funny abstractions
Really? Maybe I suck at C++, but I can't meaningfully reason about template-heavy code. Not about the run-time performance, nor resource consumption. STL and Boost are beyond funny if you ask me.
> The formal standard defines what is undefined. Your safety-critical code shouldn't rely on some compiler-specific quirks or some magical code, but rather it should stay within the bounds of well-defined behavior.
Agreed. But take a look at the specification and you'll be amazed on just how much stuff is left for the actual implementation to figure out.
Which is why the coding standard for a critical project will disallow the use of things that can lead to undefined behavior.
The way Qt does is actually quite pleasant to work with, but they avoid most language features and roll their own (QObject, I'm looking at you), even including their own preprocessor.
It's sad they don't teach C++ properly any more. The stuff I see leaking out onto Stack Overflow from courses is shamefully bad.
Rust inherently guarantees static memory safety in many situations, on the other hand.
Honestly I see Rust as (potentially, down the road) being a better, less verbose Ada than a better C++ or Java. You tend to write Rust code much like you would an Ada or VHDL program.
I ask because I'm in the process of spec'ing out a safety critical medical device, and JamaicaVM is the lead candidate at the moment.
C++ is impossible to validate formally.
[1] http://fsl.cs.illinois.edu/index.php/An_Executable_Formal_Se...
No shit. C++ has been around for 30 years now.
And this is exactly the reason why Rust even exists. I find it amusing to see the author use it to defend the C++'s side.
Like OpenSSL...
The existence of LLVM and the likes, the fact that Javascript got a HUGE speedup in the past 5 years seems to be an indication that it is by essence a factor that can be tuned eventually. I doubt a "slow" language will ever get to be C in that regard, but I also doubt C will ever provide the kind of ease of mind that a more inherently modern and secure language like Rust offers out of the box thanks to its memory management model. And at the end of the day, in a web-centric world, the latter might well be what programmers and users alike happen to care more about.
However, something I've noticed from the land of C++ is some peoples' issue with the idea that thread safety is difficult. In fact, they appear to downright bristle at the idea that they might not write perfect code and that they might lose the ability to run with fast-but-not-correct code. I don't think this is a conscious reaction, but it seems similar to what's going on in the article.
(http://manishearth.github.io/blog/2015/05/03/where-rust-real... has an example for others reading this thread)
The primary block to this is memory management. Rust allows a superset of C/C++ memory management techniques, so there is literally no technical reason you shouldn't be able to port a c program to the equivalent rust program. Unlike java, go, etc., this doesn't break new ground in terms of optimization but rather verification of existing systems programming techniques.
To put this another way, you could write a rust -> c++ compiler and "automagically" get the speed of c++, but the same could not be said of Java.
The one area of which I'm unaware is pointer aliasing (in unsafe code, obviously). I am not entirely sure how well rust can restrict the types to optimize exclusive access to a memory region ala the c `restrict` keyword. But there's always inline assembly if that fails.
> Note that this definition of noalias is intentionally similar to the
> definition of restrict in C99 for function arguments.
If you alias, you might break, as optimizations will assume otherwise.
Oh, and `&mut` pointers are safe to use, not unsafe.
Rust does not. The main issue with Rust is that we haven't gotten around to optimizing the IR properly. It's something which can be done backwards compatibly without changing the actual language at all.
The only design component I can think of which leads to bad perf is the drop flag. And that's something that should go away soon (Rust doesn't guarantee that destructors will run using this model only, so it can be changed)
That was the whole big deal about Rust; that it's possible to get all of the nice functional stuff, the type safety etc yet still get fantastic performance.
You're meant to write your optimising Javascript VM in Rust, basically, your SSL library etc.
I'm not saying that Rust's performance is bad, or won't be good - and certainly that article convinces me of nothing. Nevertheless, if Rust were to be found to be only a little faster than Java for tight loops etc, that'd be disappointing.
This should be "Rebar"
the only evidence the post seems to offer is that rust is slow because it showed up 5th in a set of microbenchmarks. everything else is rhetorical garbage, frankly.
Come back when it's cooked :)
The real point to be made here is that Rust can be optimized without dropping any design principles. It's a solvable problem. On the other hand, Java and Go's design puts a limit on the optimization you can use.
(Also, those benchmarks are a year old IIRC, Rust might actually have sped up in that time!)
[1] http://benchmarksgame.alioth.debian.org/u64/which-programs-a...
Why didn't you check the commit age in the repo?
Comparing different programming languages is notoriously difficult, particularly since the metric is underdefined. The best programmers might write faster code in language A compared to language B, but if average programmers write code that is no faster, does that mean language A is better than language B?
The difficulty of drawing general conclusions from program performance measurements -- not just "those results".