An an ex-Apple engineer I can assure almost every programming language you can think of is probably used by one team or another. The idea that a team rewrote a service in Rust means Apple is "all-in" in Rust is ridiculous.
Every large company I've worked at has had many, many internal services using all sorts of different languages/frameworks.
Agreed. It's the same for the other bigger companies (Microsoft, Amazon, etc).
However people with less experience often assume those big companies have strategic directions for tech stacks, and that one teaming using something must be really important and implies bigger usage. I might even have assumed the same when being fresh out of university.
Therefore any news about "X is using Rust" seem to get a lot of traction.
For example, my team at one of the big software companies has code in Rust, Python, C++, Go, Elixir, C#, Scala (Spark), and probably another that I don't remember right now.
The bigger the company is, the less it means that somebody there is trying out Rust.
Corollary is that the greater the fraction of reports of Rust usage that we see are about somebody in a big company, the lower the actual usage is.
Similarly, the greater the fraction of articles about Rust usage that carry on about how great it is, vs articles complaining about it, the less actual usage there is. Engineers are always limited by our tools, and we deeply resent those limitations. People complain a great deal about C++; the more useful it has turned out to be, the more complaints they have about it, and they are generally not shy about telling you them.
Agree. I think this is typical 'small guy landing big punch attitude'. I see this is common for languages which have not yet achieved (real or perceived) popularity.
Not every company, but some companies, Apple included, like to experiment for the simple reasons that some of the experiments pan out and it pays for ones that don't.
This makes more sense for tech companies. I work mostly for large banks and there definitely is less experimentation but there still is more experimentation than one would think (I have couple large Clojure projects very close in my org).
It's not because of experimentation–it's because Apple for the most part lets their team's choose what they feel is best for what they are trying to accomplish. It is trust. If there was a concern about a technology choice, it was discussed and pros/cons weighed, but there wasn't some standardization of language under the guise of "developer productivity".
That is experimentation. This is organization say it lets people to make mistakes because of potential payoff.
If the organization did not believe in potential of value from these ventures there would just be a small limited amount of languages to choose from because it is more economical when you consider support system. This is starkly visible in banks where there is huge need for development support system but no belief in value from ventures into obscure languages. The end result being that everything is written in Java and maybe couple other JVM languages (just because it is easy when you are already invested in JVM).
I guess I don't see a choice as an experiment. It's about using the right tool for the job. There could be multiple languages used by a team and a choice be made to use one over another. There are pros and cons depending on what is most important (speed, safety, hiring, etc.), but that doesn't cause those choices to be experiments.
Chris Lattner has stated his goal with Swift was for it to be able to “scale up” and “scale down” for high level and low level tasks as needed but not that it is necessary always the best tool for these use cases, just that it can do it when you need it. It’s sweet spot is somewhere in the middle. Swift is also reference counted which might not work well for low level networking, linux support is also lacking.
> We interface directly to low-level Linux kernel interfaces, using asynchronous I/O and threads to distribute workload. Following a very successful first foray into Rust we are migrating an established codebase from C to Rust, and building new functionality primarily in Rust.
However, the team specifically works on the cloud services:
> We develop and deploy software which forms the foundation for some of Apple's most important services, including iCloud, Maps, iTunes, and more.
So no rust-based software is going into MacOS or iOS quite yet.
So I am reading this as more like Apple is funding ( so to speak ) some work on Linux Networking using Rust? Which seems reasonable given Linux Kernel recently shared their intention to accept Rust code.
And I was thinking why did they make Swift for low level usage if they were going to use Rust.
> And I was thinking why did they make Swift for low level usage if they were going to use Rust.
Swift is great for application programming, but for low-level performance-critical systems programming it’s currently a huge pain in the rear. Swift’s philosophy is basically “give everything a Python-like level of dynamism, and then heavily inline/optimize out when statically possible.” For instance:
- Swift’s memory management is based on reference counting. It’s usually convenient and efficient (and lets you do cool things like copy-on-write), but when you know more about your object lifetimes than the compiler, the unnecessary retain/release traffic gets really annoying and is not easy to avoid.
- Swift’s generics are dynamic by default, which involves wrapping up every object into a possibly-heap-allocated container and using dynamic dispatch for everything. Usually the compiler will inline/specialize generics, but there’s no guarantee, especially when calling generics across module boundaries (due to ABI stability restrictions). Rust/C++ exclusively uses compile-time template instantiation, which is a little less flexible and doesn’t guarantee ABI stability but it always guarantees unimpaired performance. See [0] for a more detailed comparison.
- No stack-allocated arrays in Swift; all collections are reference-counted and stored on the heap.
- Still no async/await (or any real concurrency model at all) in Swift; it’s planned to be available in the next year or two. This could be a big deal for a networking team.
> - Swift’s generics are dynamic by default, which involves wrapping up every object into a possibly-heap-allocated container and using dynamic dispatch for everything.
You're right about the dynamic dispatch, but both specialized and unspecialized generics use the same memory layout. While unspecialized generics have to compute the layout dynamically if needed, there's no boxing required. If this were not the case, specialized and unspecialized code would not be able to interoperate (and as you said, this is a requirement because of ABI boundaries).
> - No stack-allocated arrays in Swift; all collections are reference-counted and stored on the heap.
There's a compiler optimization pass which stack-allocates reference counted objects with a known lifetime (which includes the backing storage for arrays). However, just as with generic specialization, this is a best-effort optimization and is not guaranteed to actually take place.
Swift is 6 years old, Rust might have been popular among programming language connoisseurs at the time, but it wouldn't have been that silly to expect it to be a fad.
Another factor here is that Chris Lattner, creator of Swift, used to work for Apple, with a high-ranking job, he was directing a whole department. He's since left Apple a few years ago. No longer having the creator of Swift championing its use at Apple opens the door to alternatives. I haven't used Rust myself, but it looks like a solid language for systems development.
That tweet really blowing things out of proportion. Migrating one project, out of presumably many thousands, is not “going all in”. It’s still interesting though.
That's how you build hype though. I like Rust (haven't used it in years though) but the marketing hype-train is one of the most effective I've seen - perhaps other than Java in the olden days.
Most large companies typically have a bunch of primary languages/frameworks, so IMO there's never really such a thing as going all in. Unless you're FB and you're stuck with PHP/Hack.
From speaking with friends who work at AWS, Amazon sounds pretty “all in” on Java. i.e. their server side code is very dominantly Java. I believe Netflix’s backend is pretty dominantly Java too, other than their edge API.
IMO, having one dominant server side language (with of course some small bits written in other languages) is about as common at a large tech company as being truly polyglot, where you can’t point to a single language used in the vast majority of the BE.
That said, I think it's safe to say - this tweet is a sign that Rust is gaining traction at Apple. It might end up influencing others at Apple to consider Rust as an option and evangelize it within.
Yeah I've definitely found it's much easier to persuade a team to use some new technology if you can point to another team that is already using it. Nobody can say "we can't use Rust in Apple because X" because you can just say "but team Y is already doing it so that can't be true".
The difference here is that Apple is the originator and primary influence for a language that it markets as being applicable to the same use cases as Rust.
That said, as has been pointed out, this seems to be one team making a technical decision for their own work.
I also think we should understand someone was probably quite excited to see something they liked taken seriously by a company they respect. Maybe in their excitement and rush they user hyperbole.
One project/team out of how many? Any of the FAANG companies will already have code in dozens of languages. Rust has probably been in the mix for years, as has Go, as has Erlang, as has Haskell, and so on. It's great that there are job postings for this, but not sure if it's really news.
> Companies don’t let you use production code in any language you choose.
You might be surprised. At most companies I've worked at (over a dozen) that's largely true. Three jobs ago I was product architect for the entire company and spent a significant part of my time fighting just this kind of language proliferation. However, it's a very different story at a large company. Google seems to try pretty hard to keep this under control. OTOH, Facebook (where I work) prides itself on a "bottom up" "engineer driven" culture in which any such top-down prescriptivism doesn't fly. Don't know where the others fit in along that spectrum. The situation gets even murkier when code is inherited via acquisition or imported from open source. So such code often exists, whether it's "supposed to" or not.
Interesting that you mention Facebook. A team at Facebook can choose whatever language they want, but they're on the hook for creating and maintaining libraries that talk to internal services (config, database etc). There's a tendency to choose one of the existing popular languages (C++, Python, Java) so you get those libraries for free.
Therefore in practice, giving engineers the freedom to make their choices doesn't lead to an explosion in the number of languages used in production.
An engineering team that can get started with a new, esoteric language without having to first build internal libraries is much more likely to try that new language.
It’s not just libraries though. All software needs to build when invoked with “buck build” and it’s dependencies need to be specified in buck’s configuration format. Scala’s build is different enough that it can’t piggyback off Java here.
This requirement is a stumbling block for many languages. For example when compiling Rust, no one actually calls rustc directly, everyone uses cargo. Effectively this meant someone had to reimplement cargo within buck.
Parent mentioned FAANG and to my knowledge of FB, Google and Apple, they all let their teams choose whatever is the best tool for the job, including new languages (including developing new languages, for example Reason).
I was at FB from 2011-2018, and things may have changed since, but at that time it required serious buy-in to do anything that wasn’t in Hack, C++, Python, Java, or one of the mainstream mobile languages (JS/Swift/etc.) There were pilots of various things that made it into prod (Haskell had a modest niche and I spent a year on that team).
When you think about the dizzying array of touch points (logging, metrics/monitoring, service publishing and discovery, and on and on) that even the smallest component needs, the absurd wealth of libraries better than anything in open source, the standards-committee level expertise an email away that you have in one of the mainstream languages it becomes clear that you’d need more than a large incremental improvement in the language itself to break even.
The thing that might get Rust over the threshold isn’t memory safety (modern C++ with hardcore warnings-as-errors static analysis and automated ASAN/TSAN/UBSAN runs is rather solid), it’s build times.
Build times are the thing that will kill C++ unless they can come up with a modules solution that is cheaper to migrate than rewriting everything. At some point you just can’t fucking build the thing no matter how many boxes you throw at it. Rust may have a window of opportunity before C++ finds an answer on that.
> When you think about the dizzying array of touch points
Thrift generators and/or a decent FFI can resolve a lot of those. Yes, other teams might try to make noise and threaten not to support you, but I've yet to see one go so far as to blacklist a service because they disagreed with its implementation choices (including language).
> libraries better than anything in open source
Only in their authors' minds, in most cases. NIH at its worst.
> Build times are the thing that will kill C++
Certainly up there, and I wish more people realized this. Every test/deploy pipeline is an order of magnitude slower than it should be because of this, and perpetuating it is part of why I think those libraries aren't really better. In fact many of them make it worse, because they're the most aggressive users of features that increase compilation time.
There was a time when F14 and Swiss were internally available and not in open source. You think there aren’t other things that aren’t open source yet that those guys have?
folly/absl/gtest/glog/tf/pytorch/etc/etc aren’t perfect, but they have stuff that no one else has, and they had it before Github did.
“The guy who wrote the book” so to speak often works at one of these places, and while some of the stuff makes it into open source some of the time, some of it doesn’t.
Google gets Borg, OSS gets k8s.
Citing NIH is kinda flamey as an alternative to citing examples IMHO.
The "g" in "gtest" and "glog" doesn't stand for Facebook, so I don't even know why you include those. Folly is open source. PyTorch is open source. You can't be "better than anything" in a category that you're in yourself. Yes, there's stuff in folly that's available internally before it's open sourced. Yes, some of it's good stuff. Some of it's so Facebook-specific that it's only useful inside, or it's just plain junk that the rest of the world is spared.
After eight years working solely on open source at Red Hat, I've seen nothing particularly exceptional about the quality of Facebook's proprietary code. People who have no experience beyond school see something new, they think it's the bees' knees, surely they think they must be blessed to work at a place where such things are created ... but they're not uniquely blessed. There are people all over this industry pushing the state of the art. Facebook engineers think that Facebook hires the best people in the world, but people at Google think that they do, and people at Apple think that they do, and people at random startups think that they do. Not without reason in any case, but still incorrectly. It's a common kind of sampling error. The reality is that there's good and bad code everywhere, and the larger a company is the more it tends to regress toward the mean.
I mention Swiss/glog/gtest/tf because I was always talking about FANG companies, high finance (Renaissance, Jump, etc.) and to a lesser extent some of the unicorns. You know, the elite places with boundless budgets and counter-productively high technical hiring bars. Hence “these places”. When it comes to “who hires the best?” it gets a bit fuzzy and anecdotal, but roughly RenTech hires the best. Google hires the best on average in the valley, though FB has made multiple deep cuts through their top quartile with money, which is why so much Facebook stuff seems like “close but not quite” Google stuff. Other massively resourced companies also get quite good people, and there are plenty of little pockets of genius at various universities and think tanks (INRIA comes to mind).
I don’t know exactly why a tangent about having F14FastMap or MPMCQueue (and proprietary friends) before the rest of the world has evoked such a strong reaction in a point about C++ making sense at MegaCorp du jour, but calling people who think the cutting-edge internal stuff at the elite companies is a plus for C++ new grads is where I step off this train. I share your frustration with the consolidation of power, money, and talent at a small number of elite institutions to some degree, but you can take it out on someone else.
Personal attacks and flamewar comments like this will get you banned on HN. We've had to ask you about this kind of thing more than once before.
If you're involved in a tit-for-tat exchange that's activating to this degree, please just step away for a while. The internet does it to all of us, but the purpose of this site is to practice something different together.
You’ve taken a comment that adds something to the conversation (a conclusion about build times that you agree with), grabbed a tangential aside about good libraries and spun off a flamey side-thread by going after internal library authors as being delusional, done that god awful cherry-pick “>” citation thing, made repeated appeals to authority about your extensive experience, cited zero examples of OSS libraries to make a substantial counter point (which can be done), ratcheted up the temperature first with NIH, second with disparaging remarks about new grads, and finally with a bizarre contention that I must be angry that I can’t get a job at a place I got a job. All the while I’ve made all my points under my own name, and you’re safe behind an alias.
Your profile lists you as a moderator. Why are you throwing fuel on this instead of steering it back to the technology as I’ve repeatedly tried to do by bringing up actual examples of actual code? In spite of a 12 year tenure as a site member I comment pretty rarely because there are only a few topics where my perspective is all that unique, I don’t care about karma points, and the odds that someone is going to pick a fight make it easier to just get back to work and not risk it 99/100 times. You’ve succeeded in sending me back to the orange bar for however long, so mission accomplished: someone is still wrong on the internet but you’ve driven them off their cookie.
LoL. As if rust build times are much better than C++.
The rust compiler / internals section has very few experts. The compiler produces poor LLVM IR and compile times are as poor as C++ __Despite having modules__. Basic performance improvements like ```TrustedLen``` took a lot of time to surface despite everyone touting "zero cost abstractions".
Given the hype rust is getting by ruby/js hipsters learning it, you would think they would have a better, faster compiler backend instead of depending on LLVM cruft which can't even utilize rust's Mutable Xor Shared guarantees.
C++ code, CAN be in theory rewritten to compile fast. Small, trivial C++ code compiles blazingly fast even on very old hardware. I have an old Sandy Bridge Celeron, and a 5000 lines of C++ compiles in 5 seconds, with optimization on. Even 100 lines of Rust takes longer than that to compile.
I promise you the antibodies that prevent people from using one of the approved languages don't have permissions or disclosures at Apple to actually implement any language bans.
Yes, it is slower than we'd like. Comparisons to C++ are really complex though, with some people thinking they're better, and some thinking they're worse. There's a lot of details here, and we'll also see how the Rust work shakes out, as well as C++20 modules.
I haven’t done enough with Rust to speak conclusively to that, I imagine this comment will get a sibling from someone better informed.
Rust can at least in principle do better than “recursive textual substitution of massive amounts of redundant code into translation units” and I imagine the Rust leadership is probably sharp enough to know that this is the chink in the armor of an otherwise rapidly improving safety and usability story for a deeply entrenched incumbent.
That's not really what I hear from friends at Google.
Lumping Apple together with software companies illustrates well why using this acronym out of context is silly. Apple is incredibly silo'ed in comparison. Teams have a lot more freedom since they don't need to reuse internal infrastructure so much.
I work for a large communications company. We had this top-down approach for a really long time. It doesn't work too well. Essentially you're blocked from using something until its a "standard" at the company and the larger the development team the longer they take to converge on a "standard". The standards still exist now, but they're more guidelines. If you use the standards (Python/Java) you have a lot of existing tooling that you can utilize to get your project off the ground (e.g. APM tooling, docker build templates, SDK for internal apps, etc.). You can use other languages if you want to but you're going to have to do the tooling yourself. So, although Go isn't a "standard" for app development it is used to create k8s operators, etc.
I wish Rust's non-x86 support was a bit better. I wish I had time to jump in and help on the MIPs target. I wish I could figure out how to cross-compile to ARM/ARM64+uClibC. I wish I had a pony, too.
Very exciting to see a language tuned toward reliability taking off like this.
Do you mean Tier 1 support? There are just so many rust arm targets that it is difficult to make guarantees. Here is the official list if anyone is interested:
Limited experience here but seems like fairly large binaries for embedded as well. Though have not spent much time investigating how to make them smaller.
no_std is the result of that. The panic/backtrace machinery turns out to be remarkably expensive. formatting machinery turns out to be expensive. etc.
The fundamental problem is that Rust relies REALLY hard on LLVM optimizing stuff away after code generation. That's not a good way to deal with embedded. It has issues even on Desktop, too (for example, the difference in speed between debug and release modes is enormous--often to the point that if you have performance code you can't realistically run a debug build to actually ... you know ... debug).
There are changes afoot because of MIR, but they will take a while to land.
People forget how many companies created weird and wacky compilers for C on 8-bit targets because C code was "too large/too slow/etc." And how many years those companies persisted.
Optimization for embedded takes time, and the amount of resources available for it is orders of magnitude smaller than general development.
There's a ton of stuff you can do. If you don't care about binary size, they can blow up easily, but if you do, you can make it work. 145 bytes is the smallest binary rustc ever produced.
This is so exciting. They just opened the 2020 State of Rust Survey[1], and I would imagine that I’m not the only one who noted that I hoped more companies would start writing software in Rust, so that hopefully I can use it as a primary language at my next job. Apple using Rust for new low-level functionality definitely is a step in the right direction!
> Apple using Rust for all new low-level functionality definitely is a step in the right direction!
Nowhere in the job posting did it indicate or intimate that. It looks like one team doing network infrastructure (for backend services, not Apple platforms) is writing Rust code.
It's interesting because I spent time learning C++/Rust a year or so back and I stupidly didn't look into the job market before devoting time to it only to get the sober realization in my city of 6 million that very few companies were looking for it. I ended up learning Javascript not because I truly loved it but because there are/were significantly more positions available.
It's only a stupid decision if you learned nothing. The things you learn writing code in one language are often transferable to others (just avoid being the type who can "write Fortran in any language"). Rust and C++ have different OO models than each other and Javascript. Rust has a different type system than C++ and both have different type systems than Javascript. Take the things you've seen/learned from the first two languages and you'll be able to see things about JS that those who've only learned it won't see, or you'll see patterns that you can apply to your JS code that are non-obvious without extra-JS experience.
Additionally, having experience with static type systems, the statically typed languages that are transpiled to JS shouldn't be as big a learning curve for you.
The use cases for C++/Rust and JavaScript are generally very, very different. One might have better luck concentrating on learning a technology stack as opposed to a language.
Yes. In fact, the Linux kernel has been talking about allowing drivers to be written in Rust. (There are other examples of stuff in this space too, but that's the biggest deal so far.)
The kernel devs have said that that is not a blocker. (This is because what's being discussed are drivers, not the kernel itself, though they would be in the kernel tree.)
And, there's been some interest towards getting gcc to be able to compile Rust too, so that may happen regardless of its need or not.
Rust is a very clean language with several use cases. It gives a lot of power to the programmer and it's super easier to be productive compared. Rust will win over Go much like React.js won over Angular. I'd predict that the Rust language will dominate and become a must-know in a couple years time.
Rust is the new systems language with a good safety story (which implies some cognitive overhead, but that's fine for low level programming where you don't want a GC), gives C++-like performance by virtue of being close-to-the metal, and a zealot crowd around it with many kinds of political bullshit and ruby / Javascript hipsters learning it and thinking they have understood computer science because they understood difference between stack and heap.
Rust is a fringe language and it won't get a lot of traction, because of more-noise-than-signal more-politics-than-technical-talent surrounding it.
People's negative reaction to this comment believe is that new languages can only solve so many problems. Doesn't matter how great Rust is. So the idea of pushing a new languages too much gets bad reactions.
Every large company I've worked at has had many, many internal services using all sorts of different languages/frameworks.