>the one easier to use is going to get wider spread / adoption

Between Rust and C++, this is Rust. In C++ you need to a lot more memory safety verification in your head, there are thousands of footguns that you need to be aware of at all times, the template metaprogramming facilities are really hard to grok with their weird syntax.

Rust is strict, but for the kinds of applications that you would replace C++ in this makes it a lot easier to learn.

I think the sentiment that Rust is hard comes from people that come from managed languages (Python/Java/C#) that aren't used to manual memory management. From that perspective Rust is indeed hard.

Golang is not much more widely used comparing to rust? both are 17+ years old and they're around 2% of the market.

I largely agree with the "programming languages are a communication technology [thus critical mass is critical]" bit, we spend more time reading and explaining code than we do writing it. That's why I'm really hopeful for Rust web frameworks like Loco to get to mainstream-ish.

There are just _so goddamn many_ webdevs that a reasonably popular web framework can bootstrap a language out of the mid-popularity uncanny valley. On the flipside, a lot of webdevs are interested in Rust, but aren't really personally set up to do some embedded or systems stuff, so the activation energy for a given developer getting into it remains slightly higher than other languages.

Beta wasn't better. VHS matched broadcast quality for less money and substantially more runtime per tape.

Dvorak isn't particularly better because typing speed isn't worth optimizing for if you are good enough and the difference if any is small.

Lua isn't better than js if it needs to run in the browser natively.

>"Rust is a superior technology to C++....it disciplines you to do the things the right way."

It is not. The only thing it disciplines one to do is to bend them to confines of particular safety model. And Rust creators do not have the ultimate authority to say what is the right way anyways. No one does. There are multiple concepts fitting different situations. Rust ignores many. As a general language it looks way too opinionated to me.

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.

> 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.

    Now, a few defence roles are creeping in, presumably due to the US government distancing itself from unsafe languages. 

Why would staying on top of Rust put you out of a job?

> 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?

Where are these C++ jobs? I've only seen Rust jobs :D

maybe you can only fit one really complex language in your head at a time while watching out for footguns

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.

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?

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.

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.

> it quite literally is the worst language to make large scale updates beating even C++

Having worked in both C++ and Rust codebases professionally, my experience has been the complete opposite. I have to be extremely cautious when making changes to C++ codebases, (especially async ones) and it’s always a huge time sink trying to just get the damn thing and its tests compiled. Rust’s compiler and tooling, on the other hand, allow me to make high-pressure changes much more confidently. It’s not perfect, but I’ll take it over the average C++ project every time

I'm not sure what's happened on the Rust projects you've worked on professionally, but having used Rust for over nine years now personally and about five years professionally, every experience I've had trying to refactor large projects in Go, C++, Python, and Ruby at work has been strictly worse than even my worst experience having to do so in Rust. Following the compiler errors makes it super easy to follow a chain of cascading changes from needing to change something that gets used elsewhere, which combined with the usual strategy of using the test suite to detect regressions makes it as easy as I could ever imagine. I've often had the experience where I've done large refactors that touch dozens of files and thousands of lines of changes where the tests pass immediately after finishing the changes to get it to compile, and in the refactors at least that size (including ones larger than that where it isn't as cinnamon to where that doesn't happen as often), the remaining work to fix things beyond stuff the compiler can catch is still much smaller than I've had to deal with in other languages.

Obviously, some amount of this is due to my own level of comfort in Rust and not specific to the language, but even if I accepted your premise that Rust is horrendous for large changes, that still would mean that being comfortable with a language can easily make up for any inherent issues with refactoring due to the language itself. If you strongly dislike working on large Rust codebases, I agree that it's probably better to avoid trying to use it professionally, but my experience is so radically different from what you describe that I have trouble believing that this is due to Rust being objectively unfit for large refactors to the extent that you describe.

The disadvantage of doing a big refactor in Rust is that you can't do a partial refactor -- it won't compile until you've fixed everything.

The advantage of doing a big refactor in Rust is that you can't do a partial refactor -- it won't compile until you've fixed everything.

You hear this about refactoring a lot and I don't get it. I've done several multi-thousand line refactors of a 500k line rust codebase in the past few years, and it's absolutely fantastic for this task. The type system guides you along, and once the thing compiles, it almost always works exactly as you intended it to. the "quick prototyping" languages like say python are a nightmare to do large refactors in, in my experience. at least if you don't want type system timebombs lurking in infrequently executed corner cases.

My experience is the exact opposite. Rust is slow for the initial programming, but great for making changes in, because the type system holds your hand and makes sure your changes are sound.

Refactoring C++ is an absolute nightmare due to templates and overloading. If you rename a function for example, tools can't propagate that change through a template because there's no way to know if that template is only ever used to call that particular function, and not some other function that happens to share the same name (some overload).

Another way to think of it is that in C++, templates are dynamically typed, and so templates suffer from all of the same refactoring problems that dynamically typed languages do.

In Rust that problem doesn't exist, there is no function overloading and generics are "statically-typed" via traits, so you can factor code that resides within generics just as you would refactor any other code and it all just works.

Rust was specifically designed to be refactorable and in my experience it is. It was part of the dogfooding process of building Rust in Rust - lots of changes to the language, lots of changes to the compiler, lots of churn. Rust's strong type system means you can refactor and be confident that programs continue to work.

> you need to quickly prototype, refactor the code or make changes under a strict deadline, not good

How many projects like this shouldn't be written in C++ in the first place? C++ isn't automatically faster than Java, and with the level of care you're describing ("strict deadlines, just get it done") you're unlikely to realize the advantage of C++.

Rust is one of the easiest languages for code refactoring, in my experience: the compiler amd clippy tell me everything i forgot to do. Just literally doing what clippy suggests often gets it compiled.

I use Kotlin all day at work and still think it’s a wonderful language.

I never use Rust at work and also think it’s a wonderful language. Rust is really just a fun language to write apps in. Is it okay for us to admit that yet?

> 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.

Most regular hard-and-fast organizations outside of the SV bubble don't subscribe to this. They will rather tweak design around to match whatever labor pool is available (e.g. Java for most code farms in the past decades).

Before Rust, C was my preferred language. It's really hard to talk about Rust in a way that doesn't sound like talking trash about C, because Rust's main reason to exist is preventing safety issues that… people programming in C usually say are not C's fault, so there's nothing to fix there.

The other aspect is that Rust has been developed recently, and didn't have to deal with all the legacy constraints of C. The features that Rust has would be mostly boring compared to modern GC or scripting languages, but they're notable for being in a language that can be as low-level as C. Comparing them directly to C does like trashing C — namespaced modules instead of textual inclusion, macro preprocessor based on AST (do-while tricks not needed), no headers, no need for build scripts in most programs, package management that works on Windows and macOS too, etc. Many other languages have this stuff, but C doesn't, so they're an interesting upgrade from C just because C is so old.

> 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.

For me, one major weakness of English is having adjectives appearing before nouns. The more time passes, the more I hate that aspect of English. It messes up all sorts of things. Most other languages don't have this problem.

Consider that in programming, technical docs, even normal writing, it is almost always better to the most important aspect of a name come first. The adjective-noun order in English makes this awkward all the time.

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)

Having worked with Lua and JS professionally for years, Lua is far, far worse than JS.

> Esperanto is certainly not better than English

Agreed. Until Esperanto starts having actual native-speaking communities, I will look at it the same way I look at Klingon or Elvish.

I think the answer to “why” here is (and will always be) familiarity: Rust bears syntactic and semantic resemblance to already popular languages. Ada doesn’t to the same degree.

(This could be framed as a fashion choice, but I think the more neutral framing is precedence: Rust achieves desirable language-level properties without exhausting the novelty budget for people writing non-government software.)

> cite some mission critical software that has been running for a decade written in Rust besides a browser

This will be hard for anyone to do, given that Rust 1.0 was in 2015, so 9 years ago.

However, if you want examples of Rust running in mature, critical environments: my understanding is that Firecracker has been a key part of AWS’s serverless control plane for years now. Similarly, my understanding is that Windows has been shipping Rust in the NT kernel for the last year.

> 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.

C++ is really long in the tooth from a language design and tooling perspective. In that sense its due for disruption. So yes, it seems like C++ is on the way out.

On the other hand, Rust is not a strict upgrade. In game dev, runtime performance and iteration time are priorities. Safety is secondary. Rust isn't gaining that much ground in games because Rust appears to be unnecessarily burdensome. Async is especially useful for UI and game-thread style programming and that seems to be a weak spot of Rust as well.

There's still room for something besides Rust to steal C++ market share.

"Few decades".

Im thinking more like at least a century.

At first I thought you were serious, but I can appreciate a good attitude with sarcasm.

C++ is a lot of fun, and there exist many compelling subsets, but the language as a whole is a minefield that you need years of experience to navigate, and probably can never master.

I love it too, it tends to bend to my will, for better or worse. It feels like it doesn't stand in my way, and that further translates to feeling like there is nothing between my program and the hardware it runs on.

No need to school me on how that isn't true, I'm just describing my feeling and why I love C++.

I love C++, it was my next language after Turbo Pascal, there was a small stint with C, but already in 1992 it felt outdated.

However, during the last decade C++ culture suffered, probably it has taken too many C refugees.

What you call old way, it is still how many folks write C++ in big corporations, I tend to complain that I only see Modern C++ in conference slides, and my own hobby coding.

Tooling is a pain, packages are a pain, compiles are slow, the language is inconsistent, header files why..., the list goes on and on and its not outdated complaints.

(lots of reasons to like it, too)

Did you try https://github.com/johnthagen/min-sized-rust ?

Maybe it can. Why don't you propose[0] a list of features that would fit your requirements? You never know!

[0] https://lang-team.rust-lang.org/how_to/nominate.html

> What a fundamentally narrow and depressing point of view.

I want to get work done. Not be a part of some "software taste revolution." If you can't help me get my work done you're not on the list.

It's your point of view that is narrow. If popularity is not material then the loss of a single developer will have no impact and Rust will be the same as it ever was. Otherwise popularity matters and you should endeavor to observe and catalogs Rusts shortcomings so they can be addressed.

> "Popularity is the only thing that matters, and Rust is not popular enough."

This is unfair to the article, when the actual focus is on finding a job and paying the bills.

It doesn't have any of moral bankrupcy of the "Nobody gets fired for IBM" situation, where we'd be enabling corrupt companies because everyone else is also turning a blind eye.

> What a fundamentally narrow and depressing point of view.

Maybe not for you HN patricians, but most regular people in the world want stability and have other immediate priorities far above becoming a programming language revolutionary.

Rust is extremely popular and is only getting bigger with every passing year. It's got incredible velocity and is about to break into the TIOBE top ten.

The Rust critics can't stop other people from using and enjoying it. It's unstoppable at this point.

> For higher level stuff (e.g.: web backends) Go offers faster iteration cycles than Rust

Rust is excelling in this space and in so many other use cases it was never originally imaged for. Have you seen the Actix/Axum adoption? It's insanely popular, and it's such a nice and low defect rate language to write web endpoints in. It's actually highly productive in this use case.

> Yes, Rust adoption is rising but competing technologies are also getting better

Other languages are not "catching up" on competing with Rust. Adding sum types is great, but that won't deliver the same benefits. Rust features make it fit into a truly unique space.

> a big push in advancing programming languages was the support of big corporations

No big companies using Rust? All of the big companies are using it!

> the first rule of Rust jobs is that no one talks about Rust jobs

There are Rust jobs! I'm hiring Rust devs.

True... but whether the ability to so is a superpowers strength or a debilitating weakness depends on both your values and point of view!

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.

Check Odin.

How is fast compilation possible with C++-like templates? That seems impossible.

Swift

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)

If the borrow checker slows you down, the C++ you write instead would just be buggy

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.

Rust isn’t too bad if you throw clones everywhere. Otherwise, you might as well use a garbage collected language.

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.

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.

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)

> We need a better C++ ("systems") base language that could have an optional borrow checker or bounded model checker enabled.

Are you describing Rust?

I can tell you that the website for a very large company with billions in revenue has gone down several times due to nil pointer errors in golang.

I love golang and it is my language of choice but the type system still lets you shoot your foot off sometimes.

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.

Besides few areas, Go is a backwards language. I'd rather use F# or Kotlin. And for performance with GC escape hatch it's borderline impossible to beat C#.

> 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.

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).

I think it already has. It just isn't very visible to us. Rust becomes easy (especially the borrow checker) once you know how the hardware works. This is unfortunately true for even non-system programming in Rust. However, those who deal with hardware - OS devs, web engine devs, DB engine devs, etc - can see the problem and appreciate what Rust offers. That's why we see big companies like Microsoft, Google, Amazon and even Apple adopt Rust quickly. It's just not visible to us on the surface.

It is premature. And furthermore, adoption will mostly be driven by new projects written in Rust, not conversion of C/C++. That takes time.

It's not that new; nearly 10 years old now I think. Go's adoption was faster

> Isn't this premature? Rust is still pretty new.

The old lady said both those things to me this week. In two different conversations.

> 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

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.

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.

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.

That is, unfortunately, not how anything works.

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