I left a comment on Reddit that I'll adapt here. It's really intended at the Rust community specifically, but I think the message is still worthwhile anyway:
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.
I've been programming for 35 years, and I remember when object-oriented programming advocates seemed cult-like. As it turned out, O-O is a very useful tool, but it is not the ultimate programming paradigm. Time has shown that the early adopters of O-O were mostly justified in their enthusiasm, but tended to overstate the benefits of the technology. The O-O naysayers had concerns about performance, which is an issue in some O-O languages, but one that C++ solved. They also had concerns that O-O was hard to understand, but that is something that has been mostly solved through education. These days, the expectation is that a good programmer understands O-O.
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.
> Today, I see similar reactions to leading edge technologies and languages that are difficult to understand, whether they be FP, Rust, or Haskell.
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 C/C++ will never die. Not everyone loves them, but they're both good languages and they both have their place. Part of that place is due to mere tradition, mere established-ness, but part of it is real merit in terms of speed and directness.
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).
As someone who is gung-ho and hopeful about Rust, but an outsider, I would also like to see that measured, well-argued article.
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)
It doesn't help that the only language they could think of to compare Rust to is D.
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.
>OK, but doesn't it imply that I do not need Rust at all because I could write 90% of my code in Go and the rest 10% in C? Only silver bullet seekers and airy-fairy (t)he(o)retics will use Rust just for the sake of feeling contented about having 100% of a program written in seemingly one language.
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.
Actually, in the CHICKEN Scheme community, this is done quite often, though you don't see it nearly as much because of how transparent it ends up being. Mostly stuff is written in Scheme / R5RS when possible, and C bindings to a faster library or implementation are exported using the bind egg when speed is of critical importance.
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.
It also means they know what they're talking about.
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.
They know only 1 part of the bridge, but without second part is not the bridge, but shameful biased grunt "oh oh, will we still make money on C++ or we need to learn something new to keep our income?". And question is answered before they company existed. They even dare enough to recommend others don't learn Rust in favor of C++ - so biased recommendation makes whole grunt even more pointless.
Don't get me wrong, I understand difference between constructive criticism and biased grunt of grumpy C++ programmer.
I have made my living as a C++ programmer for 20 years.... C++ is not going away any time soon, but Rust looks pretty cool... I see no reason to bash it.
I note that there are no arguments that C/C++ is better than Rust, except that it has been used for longer (and thus has more tools & knowhow around it).
That C/C++ have a formal standard and have an entire tool ecosystem is a huge advantage over Rust for mission critical and safety critical areas (not that Rust would be used for SC applications).
> "is a huge advantage over Rust for mission critical and safety critical areas"
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.
> There's no C/C++. They are entirely different languages (even if C is supposed to be a subset).
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.
> There's no C/C++. They are entirely different languages (even if C is supposed to be a subset).
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.
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.
You are right, they have diverged. However my initial statement was/is true, as C++ started as a subset of C (even though the two are totally incompatible for all non-trivial programs today).
A formal standard that has undefined behavior and is apparently difficult to implement a compiler for. It seems C++ is popular for mission critical software despite its standards.
Basically, avoid using C++, except for <insert list of features here>.
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.
This is incorrect. Any language with a well-defined semantics (such as a compiler or interpreter) can be validated formally. It may just be too time-consuming for people to bother. For example the operational semantics of C has been implemented formally, e.g. [1]. The same could be done with C++.
My day job is currently writing embedded high availability code to a slightly modified version of the JSF coding standard (which is itself a modified version of MISRA for C++). There's a lot of safety that Rust would give us on top of C++ with the coding standard's rules, and we're waiting for Rust to simply mature a little.
To me, it seems like in the future Rust could occupy the same niche as Java + RTSJ does presently. I'm just not clear on how or why Rust would be sufficiently better to overcome the track record of Java + RTSJ.
There's a real point hiding in the article, and not quite stated explicitly: If a language (call it X) exists and is widely used, because it's really useful for certain things, and another language (Y, say) comes along, then for Y to replace X, Y has to be significantly better than X at the things that X is good at. Otherwise Y gets viewed as "kind of interesting, but not worth the investment to make the jump", and languishes in obscurity.
Regarding speed, I am not sure it really is the bee's knees.
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.
It's a little silly to quibble about speed when the language is still being designed. There is plenty of time to optimize the language; there's not much technical barrier to matching the speed of c/c++, especially when allowing unsafe code.
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.
This is an interesting question, but I'm not convinced it is the case. Many people have argued that Java, Ruby, (insert favorite language here) will one day match the speed of C, it just requires more advanced tooling, but that promise has never been fulfilled. Many abstractions come with a cost, just look at the jump between C and C++. Perhaps Rust will match the speed of C, but I don't think it is certain.
> Many people have argued that Java, Ruby, (insert favorite language here) will one day match the speed of C, it just requires more advanced tooling, but that promise has never been fulfilled.
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.
So, it's functionally equivalent to a "restrict" keyword in unsafe mode? (i.e. you can alias without the compiler being able to prove it as if you weren't aliasing.)
We're already faster than C in some benchmarks, (and slower in others, of course) and since we use LLVM on the backend, we can take advantage of all of the performance work that's put into Clang and friends as well.
I also forsee a significant speedup in complex applications caused by programmers being more free to do pointer gymnastics because they know that there won't be use after free or anything (as compared to using refcounting everywhere or a GC).
Java/Go use a GC and have certain design principles which place an upper bound on the speed unless you want to break backwards compatibility.
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)
It is for the tasks that Rust is designed for. Rust is supposed to be a systems language; it is supposed to be the language used for writing web browsers etc, really performance critical stuff.
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.
What did everybody make of the benchmarks cited in the article? I couldn't really understand what they actually represented, or if I should put much stock in them. I was surprised that Rust didn't come out better in those.
A bunch of changes landed right before the beta release some weeks back, and a bunch of examples broke. We also haven't invested much time in making sure that the examples have kept up lately. We used to beat C++ in several of them, but who knows what's happened since.
I get that this is a translation but it's very poorly written even considering that. lots of repetitive conclusion jumping in what I can only assume is an attempt to baffle the reader into uncritically accepting what appears to be a largely unsupported opinion.
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.
Correction: a set of microbenchmarks whose own documentation emphatically states the difficulty of drawing any conclusions from those results.
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?
Technically Rust will be 1.0 by the end of the week; but that won't magically make it faster.
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!)
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...