Rust is already a mainstream language, unless you have a weirdly restrictive definition of mainstream.
Type "Rust" into a job search engine and see what comes up, it's mostly blockchainy stuff. Or a few shops that are "looking into" doing Rust for new projects (which is encouraging, but hard to say how that will shake out).
I personally won't touch anything "crypto", so I feel somewhat lucky to be getting paid to work in Rust right now for something that isn't. But I fully expect that once this gig finishes, it'll probably be back to C++ for me.
I would characterize the amount of Rust being done at Google as ... insignifant.
That could change, but apart from Fuchsia and maybe some kernel driver work I struggle to picture where it would fit in the language pantheon there.
I am in contact with some people in the Android team at Google that are also using Rust (and that want to use Miri :D ).
But I'm sure it's growing. But it won't be in the core Google3-on-Borg parts of Google, which are on the whole in either C++ or (increasingly) Go. Switching to a standardized garbage collected Google supported language makes sense in that domain. The "Carbon" stuff recently announced sounds interesting as well.
The long term looks good for Rust. But actual production code is still thin on the ground still everywhere.
FWIW, to the best of my memory as of a year ago I counted ~1.1 MLoC of Rust code in our open source tree, with an additional ~1.3 MLoC in things we've vendored from crates.io.
There was a bit more C++ when I did the analysis, but it was the same order of magnitude.
Other than that... Fuchsia was the thing that was rewriting all my work from scratch and killing everything I worked on (Chromecast on Home Hub, etc), so... :-)
Rust usage at these companies isn't yet 'large' in the sense of KLoC or anything, especially compared to existing legacy codebases, but it's getting put in at some really critical infrastructure levels that are unlikely to do anything but grow imo.
That's kind of the thing about rust though. That's where it's got the most power to improve things, so its introduction to a workspace is kind of subtle.
Is there any public source for Apple using Rust?
And yeah those are exactly the domains Rust is designed for, and even if it doesn't mean huge codebases, that kind of usage at a whole bunch of huge companies hopefully means Rust is more likely to survive beyond the initial hype. :)
But a) it's Apple, a stressy, workaholic company to work for [at least that's how it seemed when my wife worked there] and b) I'd never convince the wife and kids to move right now.
It's a surprising location and the story behind it existing is fun but also not mine to tell, but if you applied and interviewed you'd almost certainly get to hear it. The stuff that team does is much more important than its location would suggest and the software they build was mostly originally in C (not c++), which is also kind of surprising for the services side of apple. We were involved in porting swift to Linux in the hopes it would meet our needs but that didn't work out for various silly reasons.
At any rate it's not the only part of apple using rust, but it is probably the earliest adopter and also the most mission critical user there.
> But a) it's Apple, a stressy, workaholic company to work for [at least that's how it seemed when my wife worked there] and b) I'd never convince the wife and kids to move right now.
Fwiw this team isn't really any of those things, it's very unusual in a lot of ways. Very good work life balance, especially now that the office isn't an hour from a real city.
I didn't leave on bad terms at all, I just needed a change of scenery and the one big downside to that office is you can't really go to any other teams because Apple is so dead set against remote or distributed teams without a shared office space, so you're just kinda stuck. Also I ran out my patience for not being able to work on open source unrelated to my job (though at least it got easier to work on open source related to my job over the time I did work there).
Do a search on Upwork for Rust gigs. Almost all crypto.
LinkedIn jobs, very similar. Putting "Rust" in my profile there has also led to a lot of recruiters pinging me about web3-ish jobs that I have no interest in.
The Rust PL group I'm on, also on LinkedIn, has a steady stream of 'smart contract' etc discussions. And people advertising themselves for crypto jobs. Or crypto jobs advertising looking for people.
That's not to say there isn't plenty of other Rust stuff out there, but it seems like this is where a lot of the use is right now and I really hope the language as a whole doesn't get typecast this way.
My overall thought is that programming language popularity is a lagging indicator; people might be hiring Java engineers even if they wish they didn't write their codebase in Java. Changing that is risky; getting one more employee can stop the bleeding. Meanwhile newly-formed companies use the newest tools, and thus among newly-formed companies, you're going to see many more requests for engineers with experience with the newer tools. (It's one of those secret advantages for startups; your competitor might be slowed down by all the legacy and thus resources given to your new startup might get more value than if given to the incumbent.)
Those are just the loudest people. Web3 companies depend on hype so they shout all over the web about anything they can, including how they're using the hot new language for blah blah blah and you can come and write it with us! (As long as you're willing to be paid in worthless tokens.)
In normal companies there is plenty of Rust use but you don't hear about it as much because it tends to be initiated internally by people who weren't hired as Rust programmers, and it's used for new projects that take a long time to get to the point of needing new employees. I know in my company it was at least 2 years between when we started using Rust and when we wrote "Rust" on a job advert.
by dictionary definition, rust is not mainstream. it's not normal (common, typical, customary) for an engineer to interact with rust
It's only 3 times less popular than C. As I said, very weird definition of mainstream.
It will come. It's not there yet.
I still argue it's not the language best suited for what a lot of people are trying to use it for. It has a niche, one that I like, but I fail to understand why it's being deployed for web services type applications. IMHO it's not a good fit.
But none of this is unique to Rust. And I'm not convinced on the WASM stuff at all for writing web front ends, though I'm enamoured of it as a generic backend managed VM, but that's another story.
And I think adopting Rust in many shops with a mix of developer seniority levels will be a productivity killer. I think most places doing this kind of thing would probably be better off with TypeScript, or Kotlin. Or if they want to go more functional and exotic, F#, Scala, OCaml, or Erlang/Elixir, etc.
But for places where we've been doing C++ for years and setting off footguns all over the place? Rust is great! Love it.
It's pretty tricky to do that in an untyped language. But TypeScript could have this, or maybe even already does?
AFAIK TypeScript doesn't have ML-style pattern matching, but its type system is fairly expressive and you can do something "like" it https://dev.to/gvergnaud/bringing-pattern-matching-to-typesc...
If I just say "algebraic data types" or "sum types" I fear many people won't know what I mean...
If you mean dynamically typed, then Elixir has it:
https://elixir-lang.org/getting-started/case-cond-and-if.htm...
What I was referring to is things like `match x { Some(y) => ..., None => ... }`, where there is data that is available only in some variants of the type (like `y`). Without a type, even naming these variants becomes an interesting problem. (Not unsolvable, mind you. But not obvious either, and you lose some of the benefits that algebraic data types have in typed languages.)
There are plenty of reasons why it's a good fit for web services. It's fast, has great tooling, a great library ecosystem, and perhaps most importantly the strong type system and borrow checker mean you write far fewer bugs than in most other languages (C++, Java, Typescript, Go etc; maybe not Haskell).
The only reason I wouldn't use it in web services is because the whole ecosystem seems to have decided that everything has to be async despite that adding a ton of complexity and almost nobody needing it.
How is that not mainstream by even your own definition? It’s consistently a part of the current zeitgeist.