>Rust is a superior technology to C++....it disciplines you to do the things the right way.<p>>But Rust is better in the same way that Betamax was better than VHS, Mastodon is better than Twitter, Dvorak keyboards are better than QWERTY, Esperanto is better than English and Lua is better than Javascript: in communication technologies, adoption and critical mass are 90% of the game and the other 10% are bikeshedding, at best. And programming languages are a communication technology, they're means to communicate ideas to other programmers.<p>Love this. May be I should repost this every time there is an argument about Rust. And to expand on that, in communication technology, the one easier to use is going to get wider spread / adoption. And while there were never much hype around Go, I think it is a very good example.<p>But a lot of Rust [1] ideas are now being polished and used elsewhere like Swift. I am sure we will continue to be experimented in other languages and real world to test whether the trade off is worthwhile.<p>[1] ( ok may be Cyclone or something earlier in case someone wants to nitpick )
This maps to my own experience in the UK. Every time I search for a C++ job, I inevitably end up discussing my fondness of Rust but inability to use it at work. The interviewer will typically reply mentioning discussions of using it for greenfield projects - but I know it won't result in me writing anything of substance.<p>2 years ago, seeing a somewhat applicable Rust job-description made me 90% certain it was about cryptocurrency fintech. Now, a few defence roles are creeping in, presumably due to the US government distancing itself from unsafe languages. Neither are fields I really want to work in. And what a shame it would be if such a great language was relegated to being an Ada alternative.<p>I try to keep on top of Rust, - it's the most likely candidate to put me out of a job - but it will be a long time before there are no more legacy C++ codebases. Being the COBOL guy of the future doesn't sound too bad.
This is kind of silly to me. You don't have to break up with Rust to use C++.<p>Look for opportunities to adopt Rust, especially greenfield projects. We don't have to eliminate all C++ codebases first.
I wonder how much of this love of Rust stems from the fact that he actually didn't have a full time job programming in Rust. When one starts off doing hobby projects in Rust the experience can be very pleasant thanks to cargo (btw, it is a bit puzzling that vcpkg is not adopted more broadly in C++ land since the gap from cargo is not that bad).<p>However, once you get a job writing programs and find out you need to quickly prototype, refactor the code or make changes under a strict deadline, not good, it quite literally is the worst language to make large scale updates beating even C++. This is not counting the other memory safe languages (golang, C#, Java, Kotlin, etc..) which is where you should first target.
I like C. I learned it a long time ago, it was one of my favorite languages to learn, and I'm comfortable using it.<p>I'm open to learning new languages, but learning new languages from people who talking nothing but trash about C does not inspire confidence. Nobody who loves unix says "you need to try Windows." At the same time, Windows lovers trash Unix. So the two schools remain separate.<p>if you want to sell Rust, find people who like C who will recommend Rust and shut everybody else up, then people who like C will listen.<p>edit: thought of one, the soles of shoes
IMO choice of language is a design decision. Weighing the pros and cons of a particular language without specifying the use case and project requirements seems ass backwards to me.<p>To illustrate, consider if we rewrite the title: “Goodbye, Phillips head screwdrivers, I wish you success, but I’m back to flat heads”. Seems silly, doesn’t it?<p>To be fair though, I imagine this article is written as a reaction to Rust proponents making similar arguments.
> But Rust is better in the same way that Betamax was better than VHS, Mastodon is better than Twitter, Dvorak keyboards are better than QWERTY, Esperanto is better than English and Lua is better than Javascript<p>Esperanto is certainly not better than English; and I really doubt Lua is better than Javascript.
I like the Betamax vs. VHS, X vs. Mastodon bit, because technically if you want a safe, high-integrity programming language today, you would choose SPARK2014, the Ada language that has a legacy of mission-critical real-world software projects for decades, proven verification tools and and it is easy to read and write. Rust gained favor with the tech crowd, while SPARK was being used in avionics, aerospace, and other high-assurance software. Why would you choose Rust a relatively new, unproven language (cite some mission critical software that has been running for a decade written in Rust besides a browser) for crypto, aerospace, AWS, and other critical areas? Programming language adoption is just as much about fashion as it is about a true pros/cons in tech.
Am I the only one who loves writing C++? I've used some newer languages like Kotlin, and that's good too, but I always come back to C++. I think a lot of the criticism is from the old way it was written, before C++11/17.
C and C++ are languages of an era. C++ will be unseated eventually but it will take another decade at the minimum for a new generation of programmers who have used the 'modern' languages from day one to overthrow the incumbents. Then another few decades to rewrite everything.
The root issue I have with this and many other articles is the false dichotomy around this vs that programming language.<p>I would feel comfortable interviewing for a Rust, C++, job, and probably a C, Pytbon position as well, just because the industry I'm in might require it.
For me, Rust has a size issue, its std lib after strip is at least 3x as to libstdc++, and Rust is default to statically link to that lib! When you have a few Rust binaries, the storage space adds up quickly, not a good fit for embedded boards where storage is limited(same problems for Go, by the way).<p>Why can't Rust have a mode to do what c/c++/etc doing, that is, a reasonably sized standard library to link to? Yes I'm aware of 'how to minimize rust size' and 'prefer-dynamic', still comparing to c/c++, it is so much worse when storage size is a concern.
"Popularity is the only thing that matters, and Rust is not popular enough."<p>What a fundamentally narrow and depressing point of view.<p>"Nobody gets fired for IBM" should not be an aspirational sentiment!<p>And the top comments take the first part axiomatically and only disagree on how (un)popular Rust is.<p>Lots of ideas and technologies can be useful and successful without becoming massively popular. There's a reason we don't all eat McDonalds and listen to Pop music.<p>So why shouldn't we expect the same from different ways of thinking about and practicing programming? It's clearly possible to be productive and effective in "unpopular" languages—I've seen it first-hand with OCaml and Haskell teams, and secondhand with lots of other tech—so why not <i>encourage</i> that? I'd rather have an industry that values good taste than slavish trend-following, thank you very much.
For personal projects, I use C because it is fun and brings me joy without getting in my way, while Rust brings me pain, and (when i must seek help) derision from the community. Here, I choose fun and joy.<p>For work I use C because that is what all existing non-toy kernels are written in and will continue to be written in until long after i've retired, been buried, and decomposed. Here, i choose what employers want and will pay for.
Rust is slow to develop and prototype in. It's good if you're a big company not the average Joe.<p>We need a better C++ ("systems") base language that could have an optional borrow checker or bounded model checker enabled.
You can make a pointer-based graph structure with cycles in C++ without a fuss. You can decide how the memory managed and implement exactly that with minimal barriers in your way.
Another commenter mentioned the NSA and safe languages, which is what prompted our move...<p>...and I have to say, Rust is fantastic. I was reading the O'Reilly book when I was doing some gnarly three-star C work and I kept thinking that it would likely be far easier and safer in Rust.<p>We're now at the point where all new work is Rust and that gnarly, performant AF piece of C that just flies will be replaced with a simpler, safer Rust version.<p>Another commenter mentioned speed of prototyping. That was a concern for me, too, but so far real life has shown me the opposite: prototyping is only slightly slower, mostly because I am having to learn various Crates instead of using system calls and their libc variants I've known for years, but incremental debelopment from proto to poc to mvp to product is faster because there is far less dumb at each step: if it built, it is safe(r) to extend.<p>Maybe it is because so much of what we do is low level high performance system programming, I dunno, but, after 37 years, I may soon have invoked a C compiler for the last time.
About the only remaining issues I personally face is the suspicious lack of plotting libraries, and bit of an insufficiency in maths libraries, especially for higher level operations than just linear algebra.<p>There's no scipy, numpy and matplotlib equivalent yet. Both C and C++ do better in this particular area...<p>Peroxide is a good start, but it cheats much like scipy by calling into Fortran, while having some very pecuilar APIs thanks to that.
I don't think the goal of Rust has to be to unseat C++, just like the goal of Macs is no longer to unseat Windows. Here are some nobler goals:<p>* be a language that users and non-users believe is better<p>* be a language that people learn things in before entering the industry<p>* be a language for solving important problems, if not every problem<p>* if a billionaire buys C++ and makes it terrible, be an alternative<p>Edit: unrelated— I <i>really</i> struggle with writing lists on HN. :-(
> The majority of the Rust programming jobs asks primarily for deep knowledge in specialized technologies: cryptocurrencies/blockchain, finance trading, machine learning/data analysis, obscure network protocols, cybersecurity, etc.<p>I agree, but that's a lot of fields and C and C++ jobs ask for the same: finance trading, videogames, machine learning, electronics, legacy protocols, etc. So I don't see how this is unique to Rust but doesn't apply to C++.<p>Yeah I see very few and far between job offers for Rust but I can say the same for C or C++, and new companies are using Rust not the former languages. Maybe it's easier in the USA.
Usually C or C++ jobs ask for embedded knowledge, whereas Rust ones don't.
Meh, I'll take his closing advice.
If this were written in 2018 i might agree. Rust is currently exploding, however.
C++ is footgun central, which is the opposite of typesafe.
Go doesn't care about typesafety, and had it's heydey already.
Rust is eating everything in 2024.
People have begun to appreciate an approach to maintaining comprehensive typesafety from the db to user input.
Rust is capable of holding much info about what it specifies, and is basically lossless as a specification.
Rust is already eating the world, it just took a couple of decades of committee bikeshedding to achieve it.
People are starting to understand why typesafety matters, as they flail around in bug soup.
"There is an huge junkyard of technologies that failed to gain broad acceptance, many of them far more revolutionary than Rust (e.g.: Lisp, Smalltalk). I don't see why those technologies' story can be avoided."<p>Yeah, but I think more importantly much of the value that Rust brings would have been available 30 years ago if language development/selection wasn't so siloed, full of biases, and driven by (often undeserved) popularity.
> And the problem with Rust is that it just doesn't have critical mass and, frankly, I don't think it will ever have.<p>Isn't this premature? Rust is still pretty new.
> the problem with Rust is that it just doesn't have critical mass and, frankly, I don't think it will ever have<p>Let’s check back in a couple of years!
"Dvorak keyboards are better than QWERTY,"<p>As I understand it, the advantage of Dvorak was that in the study that promoted it, the Dvorak people got retraining and the qwerty people were taken as is.<p>Once both sets were sent through training, the Dvorak advantage disappeared