Hacker News new | ask | show | jobs
by putzdown 4054 days ago
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).

3 comments

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.

I'd love to too.

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)

Or documentation.