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.
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.
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.
Being in the uk, we were fortunate enough to choose rust as a main language with my co-founder about two years ago. We chose it after trying it out for some toy projects, and with no real experience with it (but both of us having heavy experience of C++, C#, Python, Ruby, and having tested many others).
We chose it because it felt "right", giving us c++ performance, productivity when writing, and a feeling of cleanliness from its type system I had not experienced since ... Ocaml.
But what we did not expect was how great it was from a talent perspective. We started hiring at a time where lots of rust developers were being laid off crypto, and the caliber of candidates is just ... amazing. Rust devs enjoy working with the language, and you get a type of developer who likes producing good code, and is usually quite passionate about coding.
So, I understand rust jobs are not easy to get by, but being on the other side of the table, it's a wonderful talent magnet for our team, allowing us to hire great developers.
Apologies for the off-topic but I am currently in a job search. I'd rate myself below the guys and girls you hired but I am very enthusiastic working with Rust. You hiring?
Again, sorry. :( But I am not getting any networking opportunities lately and couldn't resist replying to your message.
The crypto bit is an interesting filter. Wether the developers you found are true believers, grifters in on the scam, or just mercenaries for hire welding crates, they can't not have an opinion on cryptocurrency so my question to you is how much of that do they bring to work? Are there coffee chats about Ayn Rand and politics or do they steer clear of any of that.
> Being the COBOL guy of the future doesn't sound too bad.
This is where I arrived for different reasons. It seems that Rust might become an important language, career-wise, so I learned it to the level of basic competency. In the course of doing that, I learned that I really hate Rust. Not on technical grounds, but I find the language itself unpleasant, and I dislike much of the tooling around the language (crates, etc.)
Rust wouldn't be the first language I've learned and dislike, but this time, I decided to just take a pass. Even if Rust becomes the predominant language, there will always be work in other languages. I'll be content with that.
This is also true where I am in Australia. There are very few Rust jobs.
However, from the first two comments on the article :
"We use Rust at AWS (in my org) for every new project that would have previously been written in c++.
[–]rigmaroler 104 points 23 hours ago
Microsoft is the same. All new services running on VM-hosting nodes (i.e. domains where C# is explicitly not allowed) have to use Rust now. It's a top-down mandate.
There's also AI investment in converting C/C++ services to Rust, but I have a negative opinion on that investment"
So there is clearly a substantial amount of Rust being written in some places.
That's a kind of tier of employer that wouldn't even invite me to interview but you are right and I expect it will trickle down to my level in the long-run.
Now, a few defence roles are creeping in, presumably due to the US government distancing itself from unsafe languages.
I know a few contractor teams that have moved to Rust not because of any federal pressure, but simply because they're small and hierarchical enough that 1-2 people who understand the benefits are able to set the development language.
> 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.
They're saying they stay up to date with Rust, because it's the most likely to do away with C++ (their job), making sure they have relevant skills for if that happens.
> 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
Esperanto is certainly not better than English; and I really doubt Lua is better than Javascript.
I caught a different meaning from this entire sentence. I think the author was alluding to the fact that even if you replace a technology with something "better", at the end it doesn't matter, because Most People will keep using Twitter, Most People will keep using QWERTY layout, count all of your acquaintances, I doubt any of them speak Esperanto.
Well at least the idea comes through, but I don't think it makes sense to argue whether Lua is actually better than JavaScript or not.
Indeed. If one primarily values certain technical aspects, Beta was "better" than VHS. But if one primarily values popularity, profitability or practicality, then VHS was "better". And so on with the other examples.
So when we go back to this:
> Esperanto is certainly not better than English; and I really doubt Lua is better than Javascript
All I get from it is "I personally have a strong opinion about what makes a language 'better'". Nothing wrong with that, but it's independent from the argument made by TFA. Perhaps I misinterpreted.
I think maybe they meant it is a better lingua franca than English, which I'm a little more likely to agree with (Esperanto is by no means perfect for this)
Aside: I've been programming for... 35 years or so by my reckoning, but I can't recall ever hearing the term "greenfield project" before this year, and now it's seemingly everywhere. What's up with that? What happened to just... making new things?
Exactly. VSCode and Chrome already have Rust code, although only a very small part. But if giant, complex projects like these can find places where Rust fits, most other projects can as well.
This and also what people don't realize is that because right now Rust is a passion project for most people almost everything in it is of very high quality.
Jobs will come soon because stability and speed is good for business. And then we will have a bunch of lower quality stuff but more jobs. So enjoy the good things at each stage.
I agree with your take and want to add that Rust has stellar tooling and code analysis of it also looks either easier or just more people are doing it so I think linting and semi-automatically applying better practices will be easier compared to, say, Python.
Ime you kind of do, at least did. I learned rust twice I think. First time it had a lot of time hype so I sat down and learned it. Then kind of like this rant never used it so it forgot it.
Then it came up at work and the language changed enough that I had to learn it again. Features were added, the "community approved" libraries changed, tools changed, coding conventions changed.
I never had that feeling with any other language I've used in similar ways. Javascript, ruby, python go I always felt like I could learn, stop using and come back to use pretty easily.
I have difficulty picking Rust again for semi-different reasons than yours: it simply has a huge surface, not only the core language but also the libraries; the amount of those you really must know to be able to call yourself a commercial Rust programmer seems to grow with time. (You mentioned this last point, hence the "semi-different reasons" expression.)
I know Rust quite fine as a language but put me in a commercial project and I'll definitely need a few weeks to learn what should be used for i.e. error handling, logging, OpenTelemetry, and such.
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.
This will never going to happen for obvious reasons; if it ain't broken, don't fix it!
Create interoperability with other languages, like what Swift is currently attempting to do, yes; but to completely rewrite an entire project that consists of millions of lines, I don't think so.
Rewriting existing code in another language might be one thing LLMs can actually get good at. I wouldn't doubt if they could convert complex projects someday, without too much error or hassle.
All code has a lifespan, either because it rots or it becomes irrelevant/unneeded. Existing C++ code will gradually expire and the most important pieces will indeed be rewritten, accelerated by shrinking expertise.
This may be technically true on a long enough timeline, but COBOL is still the backbone of the financial sector even though companies have dumped millions into attempting to convert it to something new with limited success.
For sure, we can debate the timeline, we can debate what language will replace C++. The way I read stefanos82's reply is that they don't believe C++ code will ever be rewritten, which is obviously not true.
COBOL running the financial sector is a myth in my opinion. There are still companies running aspects of their business on it, but calling it the 'backbone' is an overstatement. If you tallied up lines of code by language in the sector, I would wager COBOL makes up less than 1%.
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.
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?
To be fair though, I imagine this article is written as a reaction to Rust proponents making similar arguments.
TRACTOR seems like a helluva Hail Mary. The C and C++ abstract machine had so many sharp pointy bits that need to be reified exactly that I find it hard to translate to Rust.
Whoever wins it (not sure if they’ve announced it yet?) will be doing God’s work but it feels like an enormous undertaking. And I sometimes like these DARPA-hard projects.
Another commenter mentioned the NSA and safe languages, which is what prompted our move...
...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.
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.
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.
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.
Develop? Debatable. At a certain scale of project, all the static guarantees become quite helpful. And a "prototype" written in Rust is often much closer to production-ready than you might think. Rust makes it easier to see which corners you've been cutting than most languages.
Is C++ easier to prototype in? Of course there's the borrow checker, but I feel like Rust at least shows up with some expressiveness niceties that gets you some productivity wins in the prototyping stage.
Though really I suppose "comfort with a language " is such a big factor, seeing people really belt out stuff in C is always a bit impressive to me (yeah yeah, bug filled etc)
C forces me to do the barest minimum and avoid prematurely astronaut architect everything. That often makes it faster to prototype in. Not because I can do more. But because I have to reframe the problem so it fits.
But large codebases in C are tedious to work with and slow to refactor.
Safe programs extend beyond those that Rust's borrow checker accepts though. There is more than one way to make a program safe, not all of them would be valid Rust.
If you remove "develop" from the OP and stick to "prototype", it's a totally valid criticism, and you come across as a condescending jerk if you suggest that software can't be "working" unless it's bug-free.
I can't count the number of times I've wanted to try out some library and whipped up a quick prototype app in an hour or two to play around with it. I don't give a damn if that app is memory safe, handles signals safely, satisfies arcane aliasing rules or deals with any of the other million footguns in C/C++. I'm happy if it compiles and does what I want it to. I deal with that stuff when I inevitably rewrite it from scratch the next day and have an actual design in mind.
FWIW, I'm comfortable enough with Rust that I would personally choose it over C or C++ for most stuff like this these days since the standard library makes a lot of boilerplate prototyping stuff (e.g. setting up a project, pulling in dependencies, handling files and I/O) much more pleasant. But suggesting that anyone who writes unsafe C/C++ in any context doesn't know what they're doing is ridiculous.
Working software doesn’t always have to be correct or safe. This is highly use case dependent. Rust’s guarantees aren’t free, it comes with a handful of tradeoffs, such as learning curve, implementation speed, (this one is personally annoying) compilation speed, and portability. I’m a huge proponent of using the right language for the job. Sometimes rust is the obvious choice, sometimes it’s Python, Go, Lua, Java, Prolog, C, brainfuck etc.
> Working software doesn’t always have to be correct or safe.
I feel like I am missing some very obvious point of yours because that statement in isolation I cannot agree with (I've read the rest of your comment and still can't find the extra context). Can you clarify?
Apple is positioning Swift as this (and are also moving it from Apple's space on Github etc. into its own and gradually trying to build more of a community), so I wonder if it will catch on more. If people are already using it in the app space, it might be able to branch out into other areas.
Over the last year and a bit they've also been working on strong C++ interop to be able to start using it in their own projects without having to do rewrites, and also better cross-platform and static linking support on Linux which could all make it a lot more attractive.
(For context, like Rust, Swift is both memory safe and data-race safe)
Swift uses garbage collection (I know, arc, but that's still garbage collection), so it more or less is in the same category as Go. And I don't see people choosing Swift over Go any time soon.
Isn't that just D? No one uses D not because it's a bad language, but because the actual language isn't nearly as important for adoption as the community behind it.
> I don't think the goal of Rust has to be to unseat C++
Agreed, but it's also true at the same time that projects you would choose C++ for are also very legitimate candidates for Rust. So they are competing, even if that's not the goal of both communities.
> be a language that users and non-users believe is better
Well, lately one person that contributes Rust to the Linux kernel got attacked with ridiculous screaming like "you will never force us to use Rust!" -- and he never did that. So he (or was he somebody else? can't remember now) basically stepped down because it turned out that nobody could challenge his technical work so they started attacking him on every other platform. Inevitably, you get enough of this and want to be left alone. Sad... but that's humans apparently.
As for non-users, even more difficult. But having studies like those of Microsoft and Google that clearly demonstrate that between 60% to 75% of all CVEs are due to memory unsafety, helps a lot.
> be a language that people learn things in before entering the industry
That one is needlessly difficult because a lot of professors are stuck in the early 2000s. Read: they only know Python or JS or Java or C# and they will never learn anything else. Young minds are impressionable so these fossils only perpetuate the problem of indoctrinating people and preventing them from utilizing the innovations in the PL area.
> be a language for solving important problems, if not every problem
Too generic to work, I am afraid. :/
You'll find people on HN arguing that you can solve every problem in the CS area just fine with Brainfuck and that we are all brainless lemmings for not seeing the light. Now replace that language with literally every other and you'll still find people saying the exact same thing...
> if a billionaire buys C++ and makes it terrible, be an alternative
That one is not so bad IMO, be it Rust or any other language really. If this happens the community will still push to do things like they want to, ultimately resulting in a fork if the buyer is stubborn enough.
No money in the world can make people suddenly write terrible code if they are passionate about doing the opposite.
The language seems to be heavily branding itself as "data-oriented", mentioning it front and center on the website and repo, but never mentions in the docs what makes it data-oriented, or what it even means by that. Is it data-oriented in the Clojure sense, in contrast to "place-oriented"? Or is it data-oriented as in programming with tables of rows, or something else?
I have written no less than 20 hobby mini-projects with Go but it's hardly an alternative to Rust. They serve fairly different purposes. Sure you can write almost any project X with either language but most of the time Go or Rust would be a bad fit for project X and a near-perfect fit for project Y.
I love Go, but they are not really interchangeable. If you do systems programming and you need a very low-level language, Go is not a good alternative. Though if we are talking about more high-level applications like web servers, then I totally agree.
> 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.
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++.
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.
What country are you looking in? Everything I’ve seen (US) is like the linked post describes. There’s a fair amount of C or C++ jobs, while the Rust ones are all either crypto startups or extremely specialized (5 years professional rust experience plus 10 years professional Linux kernel development experience, or 4 years professional rust experience plus 8 years compiler development experience, stuff like that).
(1) You need to either hire or train someone to write in Rust, and neither is trivial amount of effort. And at the end of the day, you need to push features out. Let's be real: you can find someone to write JavaScript to do full stack development, anywhere in the world, for a cheap price. Rust? The code may be more robust and easier to maintain in the long run, but it's hard to do that unless you already set up a team for that.
(2) Most software companies don't actually care that much about the language they use, the tech stack, or their infrastructure in general. Remember there are lots and lots of software companies that are not Google/Meta etc, and they are not at the bleeding edge of have state-of-the-art infrastructure. Saying that as someone working at a company with thousands of developers, and there are millions of old, ugly, almost unmaintainable Perl code in our core infrastructure running right now. From outside, it all looks fine.
How many wildly successful finance firms are running COBOL somewhere on the backend? How many successful healthcare systems are running MUMPS? Bad languages don't seem to kill companies, just make disgruntled developers and bad products.
There's a huge amount of legacy code that cannot be replaced overnight. There's thousands of person-hours invested in such codebases and they need to be maintained. There's also a much greater number of experienced C++ programmers available versus Rust programmers with the same level of experience (especially working experience, not just the language itself), so that's another factor.
So companies with lots of earning potential in greenfield projects might indeed have a competitive advantage, while it's more difficult for those with products that have a large existing C++ codebase.
Funny enough, there's a bunch of Javascript tooling for which being written in rust, as opposed to thee one they are replacing written in js itself, is their competitive advantage.
Not necessarily. To me the actual advantage is that they are times, if not tens of times, faster than the semi-equivalent JS tool.
People love to downplay long startup times or longer runtimes ("Who cares if it takes 1s to start?" and "It takes 17s vs. 1s, big deal, you are overreacting!") but it does add up with time and makes people dissociate and stop caring. I've seen it (and it happened to me as well).
Maybe. The writer notes other technologies that were superior (on some axis) and won second place:
> 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
If I created the perfect language tomorrow the very first problem that absolutely nobody would have any experience in it.
It would also have no other ecosystem. No books. No tutorials. No mentors. No libraries. No frameworks.
And even as it got those things, they would remain immature and incomplete for a long time when compared to the ecosystem around languages that are decades old.
I could also make an operating system that was superior in every way and it would fail because there would be no apps for it.
What is your comment directed at? If it's the article, I don't see hate. OP professed their love for Rust, but explained why they're moving on to C++. Mainly skepticism that it'll ever cross the chasm into mainstream.
At the risk of dating myself, I suspect the author of that self-described rant either has forgotten how long it took for C++ to mostly dethrone plain C, and perhaps practically more relevantly, how painfully long it took for new versions of C++ to be widespread enough that people dared to rely on them. This stuff isn't easy at scale; adoption is slow.
Doesn't mean rust will ever grow like that, but merely slow adoption doesn't sound like a death knell by itself to me.
100% this. It's still absurd to me how codebases in some industries are still basically C++98 and haven't even begun to transition to at least C++17 (which forces new code that adds or changes features to be written C++98-style as well).
Hard to imagine those companies switching to a different language anytime soon. Maybe the new US government push towards "memory safe" languages will help with that.
I think Go thrives in a much more popular field (web services, etc.) and it's also designed to be easy to pick up so I'm not surprised this was the case.
1.0 was in May of 2015, but that was closer to an MVP with stability guarantees than the full language. It wasn't until 2018 that Rust was as usable for most tasks. Everything you might have learned back then is still available, just a lot of restrictions have been removed, and there are more to come.
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.
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.
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.
Being in the uk, we were fortunate enough to choose rust as a main language with my co-founder about two years ago. We chose it after trying it out for some toy projects, and with no real experience with it (but both of us having heavy experience of C++, C#, Python, Ruby, and having tested many others).
We chose it because it felt "right", giving us c++ performance, productivity when writing, and a feeling of cleanliness from its type system I had not experienced since ... Ocaml.
But what we did not expect was how great it was from a talent perspective. We started hiring at a time where lots of rust developers were being laid off crypto, and the caliber of candidates is just ... amazing. Rust devs enjoy working with the language, and you get a type of developer who likes producing good code, and is usually quite passionate about coding.
So, I understand rust jobs are not easy to get by, but being on the other side of the table, it's a wonderful talent magnet for our team, allowing us to hire great developers.
Apologies for the off-topic but I am currently in a job search. I'd rate myself below the guys and girls you hired but I am very enthusiastic working with Rust. You hiring?
Again, sorry. :( But I am not getting any networking opportunities lately and couldn't resist replying to your message.
There's a hiring thread: you might find that useful. https://news.ycombinator.com/submitted?id=whoishiring The next one's coming out in a few days.
Already did, thank you, I am simply trying my luck at a direct connection. Sanctioned HR processes are a meat grinder.
The crypto bit is an interesting filter. Wether the developers you found are true believers, grifters in on the scam, or just mercenaries for hire welding crates, they can't not have an opinion on cryptocurrency so my question to you is how much of that do they bring to work? Are there coffee chats about Ayn Rand and politics or do they steer clear of any of that.
> Being the COBOL guy of the future doesn't sound too bad.
This is where I arrived for different reasons. It seems that Rust might become an important language, career-wise, so I learned it to the level of basic competency. In the course of doing that, I learned that I really hate Rust. Not on technical grounds, but I find the language itself unpleasant, and I dislike much of the tooling around the language (crates, etc.)
Rust wouldn't be the first language I've learned and dislike, but this time, I decided to just take a pass. Even if Rust becomes the predominant language, there will always be work in other languages. I'll be content with that.
This is also true where I am in Australia. There are very few Rust jobs.
However, from the first two comments on the article :
"We use Rust at AWS (in my org) for every new project that would have previously been written in c++.
[–]rigmaroler 104 points 23 hours ago
Microsoft is the same. All new services running on VM-hosting nodes (i.e. domains where C# is explicitly not allowed) have to use Rust now. It's a top-down mandate.
There's also AI investment in converting C/C++ services to Rust, but I have a negative opinion on that investment"
So there is clearly a substantial amount of Rust being written in some places.
That's a kind of tier of employer that wouldn't even invite me to interview but you are right and I expect it will trickle down to my level in the long-run.
> 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.
Well, I am interested. Got any names?
Why would staying on top of Rust put you out of a job?
They're saying they stay up to date with Rust, because it's the most likely to do away with C++ (their job), making sure they have relevant skills for if that happens.
The Rust language is what he's saying will put him out of a job, over tim as it replaces C (the language I'm guessing they work with professionally).
Where are these C++ jobs? I've only seen Rust jobs :D
> 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
Esperanto is certainly not better than English; and I really doubt Lua is better than Javascript.
> Esperanto is certainly not better than English; and I really doubt Lua is better than Javascript
Doesn't that depend on how one decides to "score" a language? And I think that's what the author is getting at, too.
I caught a different meaning from this entire sentence. I think the author was alluding to the fact that even if you replace a technology with something "better", at the end it doesn't matter, because Most People will keep using Twitter, Most People will keep using QWERTY layout, count all of your acquaintances, I doubt any of them speak Esperanto.
Well at least the idea comes through, but I don't think it makes sense to argue whether Lua is actually better than JavaScript or not.
Indeed. If one primarily values certain technical aspects, Beta was "better" than VHS. But if one primarily values popularity, profitability or practicality, then VHS was "better". And so on with the other examples.
So when we go back to this:
> Esperanto is certainly not better than English; and I really doubt Lua is better than Javascript
All I get from it is "I personally have a strong opinion about what makes a language 'better'". Nothing wrong with that, but it's independent from the argument made by TFA. Perhaps I misinterpreted.
>Doesn't that depend on how one decides to "score" a language?
Not as much, because not all ways of scoring a language are as good either, and in the ways of scoring that matter, English is better than Esperanto.
I think maybe they meant it is a better lingua franca than English, which I'm a little more likely to agree with (Esperanto is by no means perfect for this)
This is kind of silly to me. You don't have to break up with Rust to use C++.
Look for opportunities to adopt Rust, especially greenfield projects. We don't have to eliminate all C++ codebases first.
maybe you can only fit one really complex language in your head at a time while watching out for footguns
Aside: I've been programming for... 35 years or so by my reckoning, but I can't recall ever hearing the term "greenfield project" before this year, and now it's seemingly everywhere. What's up with that? What happened to just... making new things?
It's probably the circles you are around. The term has been around for a long time.
Exactly. VSCode and Chrome already have Rust code, although only a very small part. But if giant, complex projects like these can find places where Rust fits, most other projects can as well.
Android, Windows, Discord, Dropbox, Cloudflare, AWS
This and also what people don't realize is that because right now Rust is a passion project for most people almost everything in it is of very high quality.
Jobs will come soon because stability and speed is good for business. And then we will have a bunch of lower quality stuff but more jobs. So enjoy the good things at each stage.
I agree with your take and want to add that Rust has stellar tooling and code analysis of it also looks either easier or just more people are doing it so I think linting and semi-automatically applying better practices will be easier compared to, say, Python.
Ime you kind of do, at least did. I learned rust twice I think. First time it had a lot of time hype so I sat down and learned it. Then kind of like this rant never used it so it forgot it.
Then it came up at work and the language changed enough that I had to learn it again. Features were added, the "community approved" libraries changed, tools changed, coding conventions changed.
I never had that feeling with any other language I've used in similar ways. Javascript, ruby, python go I always felt like I could learn, stop using and come back to use pretty easily.
I have difficulty picking Rust again for semi-different reasons than yours: it simply has a huge surface, not only the core language but also the libraries; the amount of those you really must know to be able to call yourself a commercial Rust programmer seems to grow with time. (You mentioned this last point, hence the "semi-different reasons" expression.)
I know Rust quite fine as a language but put me in a commercial project and I'll definitely need a few weeks to learn what should be used for i.e. error handling, logging, OpenTelemetry, and such.
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.
> Then another few decades to rewrite everything.
This will never going to happen for obvious reasons; if it ain't broken, don't fix it!
Create interoperability with other languages, like what Swift is currently attempting to do, yes; but to completely rewrite an entire project that consists of millions of lines, I don't think so.
> if it ain't broken, don't fix it!
All the CVEs found in the last several years would like a word with you.
Rewriting existing code in another language might be one thing LLMs can actually get good at. I wouldn't doubt if they could convert complex projects someday, without too much error or hassle.
All code has a lifespan, either because it rots or it becomes irrelevant/unneeded. Existing C++ code will gradually expire and the most important pieces will indeed be rewritten, accelerated by shrinking expertise.
This may be technically true on a long enough timeline, but COBOL is still the backbone of the financial sector even though companies have dumped millions into attempting to convert it to something new with limited success.
For sure, we can debate the timeline, we can debate what language will replace C++. The way I read stefanos82's reply is that they don't believe C++ code will ever be rewritten, which is obviously not true.
COBOL running the financial sector is a myth in my opinion. There are still companies running aspects of their business on it, but calling it the 'backbone' is an overstatement. If you tallied up lines of code by language in the sector, I would wager COBOL makes up less than 1%.
The backbone is a minority of the bones in the body too, but without it you're screwed.
My previous job was at one of the largest investment companies in the world, if the COBOL went away the company would collapse.
At first I thought you were serious, but I can appreciate a good attitude with sarcasm.
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.
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?
To be fair though, I imagine this article is written as a reaction to Rust proponents making similar arguments.
> Weighing the pros and cons of a particular language without specifying the use case and project requirements seems ass backwards to me.
Practically every company I talked with about Rust positions named very good reasons to move to it.
N=1 and all, yup, but your opinion is N=1 as well.
There are several very engineering-sound reasons to choose Rust and people are aware of them and are appealing to them when considering it.
I deeply appreciate the mood, but when the NSA started pushing memory safety and TRACTOR launched, I doubled down.
TRACTOR seems like a helluva Hail Mary. The C and C++ abstract machine had so many sharp pointy bits that need to be reified exactly that I find it hard to translate to Rust.
Whoever wins it (not sure if they’ve announced it yet?) will be doing God’s work but it feels like an enormous undertaking. And I sometimes like these DARPA-hard projects.
Another commenter mentioned the NSA and safe languages, which is what prompted our move...
...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.
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.
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.
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.
Rust is slow to develop and prototype in. It's good if you're a big company not the average Joe.
We need a better C++ ("systems") base language that could have an optional borrow checker or bounded model checker enabled.
Prototype, sure.
Develop? Debatable. At a certain scale of project, all the static guarantees become quite helpful. And a "prototype" written in Rust is often much closer to production-ready than you might think. Rust makes it easier to see which corners you've been cutting than most languages.
Is C++ easier to prototype in? Of course there's the borrow checker, but I feel like Rust at least shows up with some expressiveness niceties that gets you some productivity wins in the prototyping stage.
Though really I suppose "comfort with a language " is such a big factor, seeing people really belt out stuff in C is always a bit impressive to me (yeah yeah, bug filled etc)
C forces me to do the barest minimum and avoid prematurely astronaut architect everything. That often makes it faster to prototype in. Not because I can do more. But because I have to reframe the problem so it fits.
But large codebases in C are tedious to work with and slow to refactor.
> Is C++ easier to prototype in?
Maybe if you’ve already got the toolchain set up and boilerplate templates etc.
If the borrow checker slows you down, the C++ you write instead would just be buggy
Safe programs extend beyond those that Rust's borrow checker accepts though. There is more than one way to make a program safe, not all of them would be valid Rust.
Most Rust criticisms boil down to "I don't understand how to write working software".
If you remove "develop" from the OP and stick to "prototype", it's a totally valid criticism, and you come across as a condescending jerk if you suggest that software can't be "working" unless it's bug-free.
I can't count the number of times I've wanted to try out some library and whipped up a quick prototype app in an hour or two to play around with it. I don't give a damn if that app is memory safe, handles signals safely, satisfies arcane aliasing rules or deals with any of the other million footguns in C/C++. I'm happy if it compiles and does what I want it to. I deal with that stuff when I inevitably rewrite it from scratch the next day and have an actual design in mind.
FWIW, I'm comfortable enough with Rust that I would personally choose it over C or C++ for most stuff like this these days since the standard library makes a lot of boilerplate prototyping stuff (e.g. setting up a project, pulling in dependencies, handling files and I/O) much more pleasant. But suggesting that anyone who writes unsafe C/C++ in any context doesn't know what they're doing is ridiculous.
What trade-offs are you typically evaluating with the prototype?
Have you ever found that decision harder to make because of shortcuts etc taken during prototype?
Working software doesn’t always have to be correct or safe. This is highly use case dependent. Rust’s guarantees aren’t free, it comes with a handful of tradeoffs, such as learning curve, implementation speed, (this one is personally annoying) compilation speed, and portability. I’m a huge proponent of using the right language for the job. Sometimes rust is the obvious choice, sometimes it’s Python, Go, Lua, Java, Prolog, C, brainfuck etc.
> Working software doesn’t always have to be correct or safe.
I feel like I am missing some very obvious point of yours because that statement in isolation I cannot agree with (I've read the rest of your comment and still can't find the extra context). Can you clarify?
"Software doesn't always have to be correct" is cope for people too dumb write working software.
You are really being a jerk in this entire thread. Here is an 18,000+ word article on one domain where Rust is not a great fit.
https://loglog.games/blog/leaving-rust-gamedev/
Apple is positioning Swift as this (and are also moving it from Apple's space on Github etc. into its own and gradually trying to build more of a community), so I wonder if it will catch on more. If people are already using it in the app space, it might be able to branch out into other areas.
Over the last year and a bit they've also been working on strong C++ interop to be able to start using it in their own projects without having to do rewrites, and also better cross-platform and static linking support on Linux which could all make it a lot more attractive.
(For context, like Rust, Swift is both memory safe and data-race safe)
Swift uses garbage collection (I know, arc, but that's still garbage collection), so it more or less is in the same category as Go. And I don't see people choosing Swift over Go any time soon.
C++ and Rust are a different thing.
Rust isn’t too bad if you throw clones everywhere. Otherwise, you might as well use a garbage collected language.
Isn't that just D? No one uses D not because it's a bad language, but because the actual language isn't nearly as important for adoption as the community behind it.
If it's optional, people are unlikely to use it, and we'll be back at square one again regarding pervasive memory safety issues.
That being said, keep an eye on Carbon.
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:
* be a language that users and non-users believe is better
* be a language that people learn things in before entering the industry
* be a language for solving important problems, if not every problem
* if a billionaire buys C++ and makes it terrible, be an alternative
Edit: unrelated— I really struggle with writing lists on HN. :-(
> I don't think the goal of Rust has to be to unseat C++
Agreed, but it's also true at the same time that projects you would choose C++ for are also very legitimate candidates for Rust. So they are competing, even if that's not the goal of both communities.
> be a language that users and non-users believe is better
Well, lately one person that contributes Rust to the Linux kernel got attacked with ridiculous screaming like "you will never force us to use Rust!" -- and he never did that. So he (or was he somebody else? can't remember now) basically stepped down because it turned out that nobody could challenge his technical work so they started attacking him on every other platform. Inevitably, you get enough of this and want to be left alone. Sad... but that's humans apparently.
As for non-users, even more difficult. But having studies like those of Microsoft and Google that clearly demonstrate that between 60% to 75% of all CVEs are due to memory unsafety, helps a lot.
> be a language that people learn things in before entering the industry
That one is needlessly difficult because a lot of professors are stuck in the early 2000s. Read: they only know Python or JS or Java or C# and they will never learn anything else. Young minds are impressionable so these fossils only perpetuate the problem of indoctrinating people and preventing them from utilizing the innovations in the PL area.
> be a language for solving important problems, if not every problem
Too generic to work, I am afraid. :/
You'll find people on HN arguing that you can solve every problem in the CS area just fine with Brainfuck and that we are all brainless lemmings for not seeing the light. Now replace that language with literally every other and you'll still find people saying the exact same thing...
> if a billionaire buys C++ and makes it terrible, be an alternative
That one is not so bad IMO, be it Rust or any other language really. If this happens the community will still push to do things like they want to, ultimately resulting in a fork if the buyer is stubborn enough.
No money in the world can make people suddenly write terrible code if they are passionate about doing the opposite.
Just give me a modern C++ like language with fast compilation, easy to pull in packages, and build tooling. Basically Go with no GC.
Check Odin.
The language seems to be heavily branding itself as "data-oriented", mentioning it front and center on the website and repo, but never mentions in the docs what makes it data-oriented, or what it even means by that. Is it data-oriented in the Clojure sense, in contrast to "place-oriented"? Or is it data-oriented as in programming with tables of rows, or something else?
https://en.wikipedia.org/wiki/Data-oriented_design
come to the land of no drama, no changes and always productive Go :)
I have written no less than 20 hobby mini-projects with Go but it's hardly an alternative to Rust. They serve fairly different purposes. Sure you can write almost any project X with either language but most of the time Go or Rust would be a bad fit for project X and a near-perfect fit for project Y.
I love Go, but they are not really interchangeable. If you do systems programming and you need a very low-level language, Go is not a good alternative. Though if we are talking about more high-level applications like web servers, then I totally agree.
> 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.
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++.
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.
What country are you looking in? Everything I’ve seen (US) is like the linked post describes. There’s a fair amount of C or C++ jobs, while the Rust ones are all either crypto startups or extremely specialized (5 years professional rust experience plus 10 years professional Linux kernel development experience, or 4 years professional rust experience plus 8 years compiler development experience, stuff like that).
goodbye raku, it’s back to perl
If Rust was really that superior, would companies using it not have a competitive advantage in the market?
> have a competitive advantage in the market
In theory, yes, but there are two problems:
(1) You need to either hire or train someone to write in Rust, and neither is trivial amount of effort. And at the end of the day, you need to push features out. Let's be real: you can find someone to write JavaScript to do full stack development, anywhere in the world, for a cheap price. Rust? The code may be more robust and easier to maintain in the long run, but it's hard to do that unless you already set up a team for that.
(2) Most software companies don't actually care that much about the language they use, the tech stack, or their infrastructure in general. Remember there are lots and lots of software companies that are not Google/Meta etc, and they are not at the bleeding edge of have state-of-the-art infrastructure. Saying that as someone working at a company with thousands of developers, and there are millions of old, ugly, almost unmaintainable Perl code in our core infrastructure running right now. From outside, it all looks fine.
Languages are fungible at most scales
Most languages exhibit Isomorphism, and necessarily so...
People are happy in Ivory towers, and often ignore better high-level llvm compiler options. =3
How many wildly successful finance firms are running COBOL somewhere on the backend? How many successful healthcare systems are running MUMPS? Bad languages don't seem to kill companies, just make disgruntled developers and bad products.
So I should clarify - I was referring to new code. If the old code already works it might not be worth rewriting it.
Old code need maintenance, bugfixes and new features. One does not rewrite their stack from scratch.
But many companies are definitely writing new projects in rust rather than C++, including Big Tech.
There's a huge amount of legacy code that cannot be replaced overnight. There's thousands of person-hours invested in such codebases and they need to be maintained. There's also a much greater number of experienced C++ programmers available versus Rust programmers with the same level of experience (especially working experience, not just the language itself), so that's another factor.
So companies with lots of earning potential in greenfield projects might indeed have a competitive advantage, while it's more difficult for those with products that have a large existing C++ codebase.
Funny enough, there's a bunch of Javascript tooling for which being written in rust, as opposed to thee one they are replacing written in js itself, is their competitive advantage.
Don't you think their actual advantage is that they are compiled to native code?
Not necessarily. To me the actual advantage is that they are times, if not tens of times, faster than the semi-equivalent JS tool.
People love to downplay long startup times or longer runtimes ("Who cares if it takes 1s to start?" and "It takes 17s vs. 1s, big deal, you are overreacting!") but it does add up with time and makes people dissociate and stop caring. I've seen it (and it happened to me as well).
Maybe. The writer notes other technologies that were superior (on some axis) and won second place:
> 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
That is, unfortunately, not how anything works.
Tell me more.. there's a X lange and it's superior in every aspect. Wouldn't new apps be written in that language? Why?
If I created the perfect language tomorrow the very first problem that absolutely nobody would have any experience in it.
It would also have no other ecosystem. No books. No tutorials. No mentors. No libraries. No frameworks.
And even as it got those things, they would remain immature and incomplete for a long time when compared to the ecosystem around languages that are decades old.
I could also make an operating system that was superior in every way and it would fail because there would be no apps for it.
always this trend of hating popular things
What is your comment directed at? If it's the article, I don't see hate. OP professed their love for Rust, but explained why they're moving on to C++. Mainly skepticism that it'll ever cross the chasm into mainstream.
TL;DR: “Rust isn’t popular enough”
> And the problem with Rust is that it just doesn't have critical mass and, frankly, I don't think it will ever have.
Isn't this premature? Rust is still pretty new.
It is premature. And furthermore, adoption will mostly be driven by new projects written in Rust, not conversion of C/C++. That takes time.
At the risk of dating myself, I suspect the author of that self-described rant either has forgotten how long it took for C++ to mostly dethrone plain C, and perhaps practically more relevantly, how painfully long it took for new versions of C++ to be widespread enough that people dared to rely on them. This stuff isn't easy at scale; adoption is slow.
Doesn't mean rust will ever grow like that, but merely slow adoption doesn't sound like a death knell by itself to me.
100% this. It's still absurd to me how codebases in some industries are still basically C++98 and haven't even begun to transition to at least C++17 (which forces new code that adds or changes features to be written C++98-style as well).
Hard to imagine those companies switching to a different language anytime soon. Maybe the new US government push towards "memory safe" languages will help with that.
It's not that new; nearly 10 years old now I think. Go's adoption was faster
I think Go thrives in a much more popular field (web services, etc.) and it's also designed to be easy to pick up so I'm not surprised this was the case.
Isnt the first stable language version from 2018?
1.0 was in May of 2015, but that was closer to an MVP with stability guarantees than the full language. It wasn't until 2018 that Rust was as usable for most tasks. Everything you might have learned back then is still available, just a lot of restrictions have been removed, and there are more to come.
May 2015.
> Isn't this premature? Rust is still pretty new.
The old lady said both those things to me this week. In two different conversations.