>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.
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.
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.
[1] ( ok may be Cyclone or something earlier in case someone wants to nitpick )
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.
You don't need to be aware of 1000s of foot guns for every block of non rust code. But you do have to remember dozens of pedantic rules, or stdlib wrappers just to trick rust into allowing you to compile your simple/demo code.
Rust will probably replace C++ in some areas where it is a legacy app (or part of the app) that is not changed frequently anymore.
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.
Excluding CLI, Go's use cases virtually did not exist when Go was created. So Go was "the right language at the right time" to grow up with it's niches (decent performance, easy to learn, easy to reuse library code, easy to deploy, easy concurrency). It is virtually non-existent anywhere else.
On the other hand, Rust competes in exactly the same high-performance/low-overhead space that C++ dominates. Because of Rust's complexity, it is very unlikely that it can compete anywhere else. Rust must displace C++, or at least be a viable alternative to it.
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.
Is Dvorak even quicker? I tried learning it and found some quirks, for example, lots of English words end in "ght" (thought, bought, draught, taught, etc...) which is extremely awkward to type on a Dvorak layout (you need to strike all three with one finger whereas on QWERTY it's split between both hands so you can alternate).
I agree with your point though. I type 80+ WPM on QWERTY with no maintenance and honestly, I type way faster than I can even think about what to type (especially for programming). Now that my college essay days are way behind me, I don't think it even matters.
Languages like Golang, can make a good argument of being the VHS to Betamax, because it is among the easier to learn memory safe languages. Golang is much more strongly positioned to take over C#, Java, and even Python spaces. Not just technically, as a language, but because of the large corporate machinery and jobs behind it, that is the result of being a Google product.
As for Rust's main claim to fame, memory safety, lots of other lesser known languages are hard at work to become direct viable alternatives to Rust. Some of them are: Hylo, Vale, Lobster, etc... Vlang, while not quite trying to aim as high as the others (on memory safety), uses an optional GC (like Nim and Dlang), and is among the safer languages. It then becomes a question of how much the extra burden of Rust is needed, for the project in question.
Which frustrates me in many respects. Especially in a specialization like tech where the audience should be used to picking up new tools to make for the best project. But I know most projects are made with business constraints in mind (i.e money and time) and cheapest almost always wins.
This is somewhat of an anthropocentric point of view. (In particular, assembler is as far as it gets from this.)
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.
I'd like to see some actual examples of this, and I assume many Rust devs would react the same way. In practice, most proposed "safety models" that Rust complains about don't really work when considering that code must be enabled to interact not just within a single module but rather across modules. This is where Rust nudges developers to make the right choices for successful programming "in the large", while still providing the "unsafe" featureset for safety assurances within a single, self-contained context.
If you feel that way, you are free to take the reigns and put unsafe blocks everywhere. Languages by design need to be opinionated (even stuff like machine language), and most of them do not let you say "it's cool, I know what I am doing here" to begin with.
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.
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.
Again, sorry. :( But I am not getting any networking opportunities lately and couldn't resist replying to your message.
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.
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.
Well, I am interested. Got any names?
Look for opportunities to adopt Rust, especially greenfield projects. We don't have to eliminate all C++ codebases first.
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.
Google trends only go back to 2004, but it's older than that.
Rejoice! You are one of today's Lucky 10,000[0]!
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 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.
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.
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've got a massive multi-binary monorepo and it's so easy to make sweeping refactors to core libraries that impact all build targets.
I can't fathom doing this in C++, or worse, a dynamic language.
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 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 always need to figure out how much you're going to bite off with each refactor. It's usually possible to do things incrementally.
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.
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++.
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?
Come to think of it, the 21st century/mutable by default is a nice group also: groovy, C#, golang, TS, Dart and Bright's D.
https://elizarov.medium.com/immutability-we-can-afford-10c0d...
blurred scan: https://www.joyk.com/dig/detail/1595957460688776
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.
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.
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 loath 1-based indexes though. Just odd.
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.
A lot of languages have this property: Germanic languages (incl. English), Slavic languages, Indian languages, most Chinese languages.
Source: https://wals.info/feature/87A#7/18.104/263.320
There are strictly _more_ languages with the opposite order (nouns before adjectives), at least in this dataset, but that seems to be an artifact of the huge number of distinct languages with relatively few speakers documented in Southeast Asia, Papua New Guinea and Africa.
I suspect that weighted by number of speakers, adjective-noun is the most common order globally.
Agreed. Until Esperanto starts having actual native-speaking communities, I will look at it the same way I look at Klingon or Elvish.
that was the point of the OOP, yes. No one cares about quality, but popularity. And OOP feels the same.
We need a better C++ ("systems") base language that could have an optional borrow checker or bounded model checker enabled.
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)
But large codebases in C are tedious to work with and slow to refactor.
Maybe if you’ve already got the toolchain set up and boilerplate templates etc.
That being said, keep an eye on Carbon.
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.
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)
C++ and Rust are a different thing.
Are you describing Rust?
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.
People are happy in Ivory towers, and often ignore better high-level llvm compiler options. =3
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.
> 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
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.
All the CVEs found in the last several years would like a word with you.
Apple is a rare exception, even if their incentives are perverse.
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.
Im thinking more like at least a century.
What a fundamentally narrow and depressing point of view.
"Nobody gets fired for IBM" should not be an aspirational sentiment!
And the top comments take the first part axiomatically and only disagree on how (un)popular Rust is.
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.
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 encourage that? I'd rather have an industry that values good taste than slavish trend-following, thank you very much.
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.
ironic to call someone's POV narrow just becasue it disagrees with your worldview.
>I don't subscribe to this philosophy. People will repeat it in certain contexts to avoid sounding out of touch and incurring social bullying but I have genuine doubts that their beliefs can be so easily manipulated.
We had an entire election where a state was bought with votes, admitted it was a scam, and is using the courts as a cost of doing business. Beliefs can in fact be manupulated more easily than you expect for the common people.
If lots of articles are written saying that popularity is all that matters, then people will start believing it, and it becomes a self-fulfilling prophecy. That's the narrowness.
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.
I concur. Lots of folks here and elsewhere will make claims about how Rust isn't a good fit for this space because _it's a systems language_ or because the iteration cycle is too slow and it isn't meant to replace Python/JavaScript/whatever, anyways. To that, I call BS. It's (objectively) a general purpose programming language and can be used to do whatever you need it to.
To your point, I've also found it extremely productive for web development. Even if it does require more work up front, that's (usually) work you're not doing on the back-end chasing and squashing bugs or trying to cover corner cases which you hadn't accounted for -- but the Rust compiler would have.
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.
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.
I'm not surprised to see this mentality because this is also ultimately a place to foster entrepreneurs, who revolve around money. But it's still saddening to see curiosity be mocked.
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.
Been safer is far from enough to replace the incumbent, you also need win in simplicity, speed, size, ecosystem,etc. Size at the moment is the most obvious problem as far as I can tell.
We hit this issue too, and our solution was to go busybox-style with binaries. One binary that then gets linked to with different names. Solved the problem for us.
when stdlib is needed then size becomes a big issue, yes busybox approach helps,but.
Add to the potion, binary libraries and extern templates for the common types.
I love golang and it is my language of choice but the type system still lets you shoot your foot off sometimes.
The vast majority of c++ I encounter is simple orthodox c++.
No one I know cares about new features in c++ and bemoans having to ever write a template.
No one really cares about bulletproofing types, ie: copy/move constructors and all that stuff.
I'm sure it's different at big companies but the vast vast majority of c++ is just simple procedural code.
(lots of reasons to like it, too)
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.
No need to school me on how that isn't true, I'm just describing my feeling and why I love C++.
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.
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.
you could just as easily say "goodbye allen, but i'm going to torx" or any <insert-things-here> pair. it's only silly if both of the interlocutors happen to agree on the relative merits and that the difference is large enough to be called "silly".
the problem is responses like that amplify the vibes of "well, it's clear that everyone agrees that rust/phillips is just objectively better in all ways". i don't think this discussion would be occurring if that were true.
the right thing is to drill down into the specific trades, and i'm scratching the surface.
oh, you have a greenfield project where manual memory management in C or C++ is burdensome and error prone and it's kicking your butt. perhaps rust might be a good fit?
or perhaps you have a problem where you need to maximize the code interchange with a few million lines of existing code and a large set of existing experienced developers? well, maybe not then...
It was even simpler in that they aren't confident of mass adoption. I'm unsure if that's Rust's fault (and honestly, finding any job in this market is a small miracle), but it's a valid factor to not want to be stuck to something forever niche.
Isn't this premature? Rust is still pretty new.
The old lady said both those things to me this week. In two different conversations.
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.
with the US mandate away from unsafe languages, that may change faster than you think. Unless you are already quite close to retiring.
* 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. :-(
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.
No I won't!!
Sorry.
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.
Smalltalk I believe was designed to run on computers that wouldn't be around until the 90s and and when the 90s arrived it didn't have a big company pouring gobs of money into marketing it unlike Java. There are other factors that also contributed it's unpopularity. Like who wants to distribute a whole system for each smalltalk program they sell?
I think also Lisp and APL weren't designed to run on the weak PCs in their day. You needed to use a timesharing system to program in them.
IBM not big enough? :-)
But of course IBM's consulting group were technology neutral and pivoted from Smalltalk to Java when the wind changed.
> Like who wants to distribute a whole system for each smalltalk program they sell?
Smalltalk was marketed to corporations as a 4GL replacement for green screen systems. So enterprise wide client-server apps for insurance/reinsurance, call center outsourcing, assembly line control, options/derivatives/reconciliation, ERP CRM TLA TLA, etc etc
I don't claim to have been in "The Room Where It Happens" meetings, so I'll just say that from my lowly perspective during that period Allen Wirfs-Brock's comment ring true.
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.
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.
edit: thought of one, the soles of shoes
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.
(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.
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.
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.
Let’s check back in a couple of years!
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.
...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.
There's no scipy, numpy and matplotlib equivalent yet. Both C and C++ do better in this particular area...
Peroxide is a good start, but it cheats much like scipy by calling into Fortran, while having some very pecuilar APIs thanks to that.
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.
Once both sets were sent through training, the Dvorak advantage disappeared