Not sure I'd go that far. I am getting paid to work full-time in Rust right now, but... My experience is the # of companies doing this that aren't "web3" companies is pretty small. Insignificant as a % of the total industry. Rust forums on LinkedIn are dominated by chatter about Solana etc. When recruiters reach out to me about Rust, it's almost always some blockchainy thing. I wouldn't characterize that as 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.
Also Apple, fwiw. I just left a job doing rust there a few months ago (for another job doing rust at another FAANG). But if you have an iphone and use icloud, rust code has probably been involved in some part of your daily life (just not on the phone itself) for the last couple of years.
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.
Oh that's interesting, I kept saying Apple is the only "big tech" company not using Rust. (Huawei should probably also be considered "big tech", but they are also using Rust.) But with Apple being as closed as they are, I guess it's not too surprising that one doesn't hear much about it...
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. :)
That particular posting has been up in some form forever. I'm always tempted to apply, since I'm from Edmonton area originally, and my whole family is there, and I do Rust. I've always found it curious that that posting exists, since Apple has no other presence 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.
It's the team I worked on. Apple has had an office in the Edmonton area for about 9 years now, originally in camrose (which if you're from here you'll probably think is hilarious), now in downtown Edmonton (the move was during COVID lockdown). It's generally been about a 10 person team, give or take, but recently split into two teams that are both doing rust in different areas.
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).
I looked around for work in Rust inside Google a year or so before I left and it was only some small parts of Fuchsia and not anything hiring at my site.
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.
(disclaimer: I work on Fuchsia, not speaking on behalf of my employer, feel free to clone the source repo and make your own analysis)
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.
Good to hear. A few years ago, there was a team advertising on grow/ for Fuchsia & Rust (for networking stuff I think), and they advertised in Waterloo but when I inquired, the posting went away and I was told they weren't actually hiring at my site. shrug Maybe it was my bad breath.
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... :-)
> My experience is the # of companies doing this that aren't "web3" companies is pretty small.
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.
It really would be, and we need to fight that. It's definitely a trend I've been seeing and it worries me.
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.
I got the same impression looking for Go a few years ago. I guess in a world without legacy code because it's too new for legacy code, you're going to use the newest programming languages. That was also the kind of startup that was getting funded back then. I haven't paid much attention but maybe the hype has died down over the last few months.
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.)
> belonging to or characteristic of the ideas, attitudes, or activities that are regarded as normal or conventional, or the dominant trend in opinion, fashion, or the arts
by dictionary definition, rust is not mainstream. it's not normal (common, typical, customary) for an engineer to interact with rust
I would consider it perfectly normal to discover something in my company or on Github was written in Rust. It's the 12th most popular language on Github by PRs according to this: https://madnight.github.io/githut/#/pull_requests/2022/1 (Shell and Nix don't count).
It's only 3 times less popular than C. As I said, very weird definition of mainstream.
The measure of "mainstream" should not be "projects on github" but: code deployed (or actively deploying) in production. GitHub is full of personal interest and research and unfinished projects.
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.
> I fail to understand why it's being deployed for web services type applications. IMHO it's not a good fit.
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.
I think people are seduced by some of the modern language features (like pattern matching, etc) by some of the third party libraries, by async [careful!], and primarily also by the WASM story that seems to be kind of going along with Rust. And by the novelty. And by promise of vaguely defined "performance."
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.
If Rust leads to more languages for more domains adopting Rust-style enums and pattern matching (algebraic data types / sum types -- this idea predates Rust by decades, so "modern" is an interesting term to use), I'd call that a big win for everyone. :)
It's pretty tricky to do that in an untyped language. But TypeScript could have this, or maybe even already does?
I mean, sure, why are we calling it "Rust-style"; it comes from ML and its descendants and Rust is obviously very influenced by them. When I say "modern" I really mean... finally learned from what "we" were "all" reading about on Lambda The Ultimate 20 years ago about languages designed 40 years ago that were not part of the mainstream until about 5-10 years ago :-)
I used "Rust-style enums" because if I just say "enum" then people think I mean something else. ;) And then I added the clarification to make sure nobody thinks I would claim that Rust invented Rust-style enums.
If I just say "algebraic data types" or "sum types" I fear many people won't know what I mean...
I think "discriminated union" is a useful bridge term here, even if it does confuse C programmers due to the conflated meanings of both enum and union in that language. It better represents the concept at an implementation level, and maps it to the C structure that enums more closely resemble in practice.
From a quick scroll, that seems to be just C-style `select` with `if` guards?
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.)
That’s not a metric I would start for defining mainstreamness. There are at least 2 orders of magnitude more program written in C that is not open-source, but part of a critical infrastructure.
Yet here you are on a discussion about it, of many rust discussions. Many companies use it enough that most of the MANGA companies have openings for it.
How is that not mainstream by even your own definition? It’s consistently a part of the current zeitgeist.
I hear this "luck" thing a lot but not sure that's the case. It's probably more originality + quality. So few undiscovered gems out there, thousands of average things though.
In no other industry/medium do you see nearly as much survivorship bias as in discussion around videogames.
I’ve always liked to think of it as a lottery, but where there are a ton of things you can do to buy yourself more tickets.
Doing the bare minimum is unlikely to bring you success, but it does happen… on the other hand sometimes a game will have a lot of things going for it and still perform poorly.
Also of all the things that are likely to bring a game success, originality is quite far down the list. That’s one of those areas where survivorship bias has a huge influence. (source: I’ve been a self-sustaining indie game dev for 12 years)
I don't want to sound dismissive, but saying "a game will have a lot of things going for it" to me sounds like about average. I mean it can still work out, but it does raise a flag.
> I’ve been a self-sustaining indie game dev for 12 years.
The quality of that 'average' has absolutely skyrocketed in the last decade or so, as ever-more-powerful tools have become available for ever-lower prices. But at the same time, we're also seeing 'indie' games with larger budgets than ever, either funded by publishers and or previous successes.
But games have been massively devalued over the last decade or so, when you've got AAA games practically given away (Game Pass, PS Plus, Steam sales), and indie games bundled up and sold for pennies, alongside the rise of F2P.
So now starting an indie game team is like starting an indie band. If you've got a bit of talent and put the effort in, you now have access to inexpensive high-end tools to unleash your creativity. But if you want to actually make money from your endeavours, it's getting ever-harder. And with the relative easy of porting games build with Unity/Unreal, even brand new platforms have completely oversaturated stores more or less by launch day, too.
International industrial spies doesn't seem to be needed today, USA gladly gave away most of their technology to China for free. Now the highest end silicon is made and developed in Asia, why would they spy on USA?
Not mainstream language 'fine', but fine.