Rust seems to be doing far better. Though it's also worth noting that Go never got the same adoption as Rust either. Wonder if someone more familiar with the story of all these languages at Meta can comment on why that is.
It is a pity that D never found its enterprise sponsor to push it no matter what.
Even the recently announced Carbon could probably have somehow built on top of it.
Re: Go, it's use cases overlap with the officially supported languages, so there's no broad need for it.
An off the cuff comment but all the same it made me think - how would you get data for an assertion like that. The usage of both D and Rust is notoriously low in the industry, a rounding error. That has to make it so hard to measure. Still, you'd expect D to be more popular because Rust's only been around 10-ish years or so.
If you click through the TIOBE rankings, it lists them right next to each other on page 3 of the results behind other languages i can't help but be sceptical of like SAS, Prolog, Scratch and Visual Fox Pro.
Indeed claims 5k job listings for "D Programming Language" (i call foul, that seems way too high) and 2k for rust.
The industry adopted Go as the cloud native language, not rust, i suspect the people doing the recomandation are ex-mozilla, or they literally HATE Go
(Normally I don't check author's names in hacker news comments. But I wanted to check if this is WalterBright posting here)
It is true that Nim has the same problem as D to a certain extent: the ecosystem is limited and the benefit it brings over C++ just doesn't overcome that. A great example of this is why I said "in theory" above, in practice interfacing with C++ in Nim just hasn't been done enough to be mature. Multiple teams in a FAANG aren't going to take a risk adopting that.
C++ and Rust are heavyweight and verbose, for ultimate control over execution. I have no Go experience but it seems to prefer simple over expressive.
I see that niche for Nim here: fast-ish, compiled, simple to use but also expressive.
With only a single or small group of evangelists for a language or platform, as soon as any of those aren't pushing it anymore, the entropy takes over.
It also rode on a sort of anti OO programming sentiment (or rather, pro interface anti class sentiment), which was my personnal reason. I mean, i know you can do everything rust traits do with interfaces, but it feel better, and it also feel better there won't be a exceedingly smart programmer who does exceedingly smart things with classes that someone will have to understand and write a documentation for (and fail).
It also was out at a good time, with a sort of "rivalry" with go, without the same uses case: the number of "Go vs Rust" thread that poped in with the response "they are not targeting the same problems" did help with popularizing the two languages.
And rust is simply a very good language.
> For specific use cases, we support other languages, including Java, Erlang, Haskell, and Go
Makes sense. Python because ML.
Rust because of performance.
C++ and Java because all-the-things.
Go because 75% of all cncf.io projects are Go.
Haskell because elitism.
Erlang because stability.
/s
I think the real story is that migrating off PHP was too hard, so Hack was started which required a substantial C++ employee pool which meant that Rust was the ideal replacement to all of this skipping the Java/Kotlin and Go ecosystems altogether.
So not just scale at play here, a cause-and-effect of past hiring decisions.
It started with their PHP to C++ compiler, then someone started a JIT compiler, and eventually the JIT proved to be a better outcome in tooling and performance, that they scraped the compiler and kept the JIT instead.
It had the side effect that proper PHP now enjoys a JIT as well.
Was there really a need for this comment? How about: for correctness and expressivity
Maybe because of WhatsApp acquisition ? Some services might still be running in Erlang. Last I heard, Erlang was being replaced by C++.
> Haskell because elitism.
Haxl used to be a project at FaceBook, not sure what Haskell is used for now there.
Thoughts as an outsider. I dont work [neither have worked] at Meta.
I wonder if they will make that mistake twice
Does anyone know if Simon Marlow is still at Meta and what he works on?
Ouch. True elitists always code in ML.
Hack is recognizable as a PHP derivative but the experience of writing Hack is very different from the experience of writing PHP.
When I left earlier this year, pretty much all of the internal storage systems (from MySQL to blob storage) were moving to requiring all access to be via a common Entity framework that encoded the above-mentioned things in a common way. That framework exists on the non-Hack side of the house, but it's much, much easier and in some ways more robust on the Hack side.
That almost sounds like an endorsement. I’ve been holding off learning Rust. However, it seems like Rust adoption is reaching a tipping point.
Rust is quite an easy language to learn and a pleasurable language to use, due to its modern ergonomics and internal consistency. Give it a try. The only trick is that Rust newcomers actually need to read up on Rust borrow checker and lifetime annotations first, as opposed to learning Rust only through hacking with it. Those two concepts are unique to Rust and need to be well understood beforehand to avoid frustration.
It's funny. I hear two different things, all the time. "Rust is easy to learn" and "Rust has a steep learning curve". Personally, I found it to be the latter, and that's as a serial dabbler/language polyglot. I had a bear of a time wrapping my head around lifetime annotations, and needed someone already familiar with them to sherpa me through that stage.
I think it does a disservice to say, "Rust is easy to learn modulo these two really challenging concepts, plus some other things you are likely unfamiliar with". Python is easy to learn. C++ is hard to learn. I'd rate rust as medium difficulty.
It sure is enjoyable though, I don't think that's ever in doubt.
For anyone coming from a GC language, Rust is a huge change.
https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
This needs to exist in Rust for it to get adopted, because forcing good developers to get explicit with code for memory safety when they are doing simple operations is going to result in them ignoring the language.
So eventually code bases are going to be exactly like C++ code bases - C++ has a standard library and smart pointers that eliminate a lot of errors with dangling pointers, and if people use those exclusively (or better yet, the language disallowed any C style pointers or arrays), the language would be dramatically more safe.
If you want to improve development, focus on smarter compilers/interpreters, not languages.
> [Rust] [will be] driven into a shit state. Specifically because of [unsafe Rust]
Using unsafe Rust is actually frowned upon in the Rust community, unless you specifically need it in order to interface with another programming language (e.g., Foreign Function Interface), work around some OS issue (e.g., memory pinning for Linux driver development) and so on. Otherwise, you are supposed to always write safe Rust code.
Way more than unsafe Rust, what worries me is the potential future, long-term language feature bloat. I wholeheartedly do hope that Rust core team will keep the language as simple and consistent as humanly possible.
> If you want to improve development, focus on smarter compilers/interpreters, not languages.
Well, in order to get a smarter compiler, you need new language features to be able to feed additional information about programmer's intent into that compiler - hence Rust's new language features, for example (memory reference) lifetime annotations that all newcomers have a problem with :).
You can't use smart pointers exclusively, because there is no "smart observational pointer", and there cannot be one, because that would be a reference type checked by a borrow checker, which is exactly what rust uses.
You can emulate it with shared pointers, but then you're left with basically a reference counted language. Why not using swift at this point? Also this creates a semantic impedance mismatch that tends to manifest with cycles.
Source: walked a codebase that would (ab)use shared pointers
That's...exactly what Rust is doing with their compiler, which checks ownership and lifetimes, so I don't understand your point here. Maybe they didn't need to write a whole new language, but why not add modern features like pattern matching along the way?
Yes! IMO building CLI tools is one of Rust's sweet spots for a few reasons:
- Rust is great at building small, fast, statically linked executables. Python and a lot of other languages are not.
- Rust has excellent cross-platform support. The stdlib and crate ecosystem do a remarkable job of building abstractions that work across *nix OSs and That Other OS. Go's Windows support is relatively mediocre IMO.
- The `clap` arg parser is great
Ultimately I think the proof is the large number of very high-quality CLI tools written in Rust (things like bat, ripgrep, fd, watchexec). They were kind of a gateway drug for me; I first got into Rust because so many of my favourite CLI tools were written in it, and I wanted to compile/tweak them.
> clap
Isn't clap kind of notoriously bad about executable bloat and compile times?
CLI - The folks who worked on the most popular command line argument parser (https://docs.rs/clap/latest/clap/#example) made a positive contribution that didn't detract from any other use case.
Web Services - Similarly, the folks working on improving Rust for web services will also make it better for systems programming. In a blog post published today (https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-ge...), they discuss keyword generics, a feature that will be equally helpful for `async` code (helpful for web services) and `const` functions evaluated at compile time (helpful for low level performance).
Low level programming - There is already some interoperability with C++ (http://cxx.rs) and ongoing research into automating this interoperability (https://github.com/google/autocxx, https://github.com/google/crubit).
Feels like there's enough effort in all areas.
I don't understand a request that says "drop everything else, focus on what I think is important". That's not how open source efforts work. People work on what they think is most impactful, what they enjoy working on. As long as they're not hurting any other use case, why stop them?
and clap is probably the best args parser available on the planet. no other language has an args parser that is so easy to use and still extremly fast with a low overhead than rust.
We all hate the resource hogging desktop apps that are just browsers (which in turn are just OS'es). That is a niche as wide and as open as the ocean. Cryptography and web frameworks are nice, but not where the action needs to be.
If UI is too complex for Rust, give up altogether on Rust. As C/C++ keeps the win since the nineties and we know the competition will not be held anymore.
C++/WinRT tooling is a shadow of C++/CX capabilities (which feels like Microsoft's C++ Builder), and while the same folks are having fun with Rust/WinRT, its tooling is even worse.
I doubt that in five years it will be any close to what C++/CX was already doing in 2015.
Specially since they outsource any graphic tooling responsabilities to the DevDiv folks.
But I don't see why that precludes Rust from being a good choice in other applications, CLI in particular.
I use Go a lot more than Rust. It's like the Java of that world.
I am disappointed when zig calls itself a general purpose language, and 10 years ago Go called itself a system language.
Given that the whole Go toolchain is bootstraped, it fulfills that role quite alright.
Maybe we need drivers and such to strenght the argument, well given the role of gVisor and Android GPU debugger, that seems a case for systems programming.
Maybe still not good enough, then I refer to the F-Secure TamaGo unkernel being shipped as firmware for the USB Armory security keys, or the TinyGo runtime which even ARM refers to on their IoT page.
Is that true at fb? That's quite interesting if so.
Why isn't Go in this list? It is very surprising since it feels like all off tech jumped on the Go bandwagon, though I won't complain. I can only guess at why, but it would be very interesting to see why.
Why is Rust in the list, other than "so many people started to use it internally that we were kind of forced to officially support it" (at least that's how I understand their article)? Similarly I won't complain, but it'd be great as to what real benefits they pull off. At least it's great to know that Rust is considered mature by Meta, which adds them to the list of Big Corp endorsing it (Amazon, Google, Microsoft, Apple, Mozilla, ...).
>How did we arrive at our list of supported languages?
Which I believe answers the question well, with bullet points, that aren't just reducible to developer adoption, so I am unclear about your frustration here.
No, it's there. I can explain.
They clearly mention that adding support for a new language is considerable effort - the language needs support for core libraries, security and privacy, developer experience etc. They also mention that a long tail of languages are "community supported", meaning the teams that use them support their own use cases.
Let's look at it from the perspective of an infra team - let's say the ones maintaining the privacy aware database abstraction. That team has limited bandwidth so they can't support every language. They start with Hack support, because that's the biggest language. Then they add C++ support and build Python support "for free" on top of the C++ code. That's it, they've done their job.
Now if a developer team on a niche language wants access to the database, they're on their own. They need to come up with bindings to access these core abstractions. They implement it on their own, or they try to wrap the existing C++ libraries.
This is the core philosophy - every team has the freedom to make their tech choices. Maybe in some cases the tech is compelling enough (like Haskell for a rule engine) that it's worth the investment to build those bindings. In other cases (like Go for networking tools), they might not need the bindings at all. But the important thing is that tech choices happen bottom up and not top down.
Which also explains why Rust is now supported at Meta. Rust has a couple of advantages. Like Python, Rust can access C++ libraries with the appropriate bindings (https://cxx.rs). This reduced the friction for teams around the company to adopt Rust - the libraries they needed were mostly supported. Secondly, Rust has some compelling advantages over other languages.
This organic adoption of Rust led to leadership eventually considering if it made sense to make it "officially supported". The implications of this change are spelled out in the article - all of the things necessary for developer productivity would be provided. Clearly, they felt that Rust provided something that the other 3 languages didn't. That explains their decision.
I hope that answered your question. The article isn't worthless. I would not criticise so harshly if I were you.
Further reading - A brief history of Rust at Facebook (https://engineering.fb.com/2021/04/29/developer-tools/rust/)
It did well in the infra community (probably starting with docker) but, among my clients in services, I can think only of one failed startup who bet on Go (and actually failed because they decided to rewrite from node to go).
Interesting. What did golang do so badly that they failed?
Perhaps a blind spot for Meta is they're spending time working away from PHP/Hack so as they reach for Rust (away from web-centric languages) they don't realize TypeScript has compelling reasons to choose it on the server-side:
* Vercel-driven / full-stack developer innovation
* ubiquity of JS/TS for tooling, innovation, etc.
* fast enough to run serverless
* rich ecosystem, though you do need to curate your dependencies yourself and not just let npm take you for a ride
* closer to customers; since closer to the web, but with types.
* no over-engineering re: borrow checker for 90% of use cases.
I cringe every time I need to deal with node powered software on the backend, including some famous build tools.
EDIT: thinking about it again, I guess the domain where nodejs is excel at has already being done in Hack, which already grow within FB.
> Meta’s primary supported server-side languages are Hack, C++, Rust, and Python.
As it should.
Beyond that though. How relevant even is Meta anymore? They are a dying company aren’t they? Facebook hasn’t been relevant in ages. Instagram is losing footing too.
Only way I can see them maintaining relevance is if one or more of the following happens:
- They turn out to be right in their bet on VR and Metaverse. Personally I doubt it, and I think VR and Metaverse is closer akin to a hellscape than much else. Or,
- TikTok is banned like some media is talking about happening. Then people might flock to Instagram. Or,
- They aquire another up and coming social network. Maybe they will buy BeReal?
The Facebook app itself is massive, it's the most used classifieds, basically replacing craigslist, still used for many groups and many local businesses use it solely, their ad business is still raking it in. Event coordination and connections are maintained on FB since most everyone has it.
Instagram isn't dying either, it's very popular for both advertisers and influencers, TikTok stole some but they are really two different services, one static images one short videos with some overlap to compete.
Your social circle may not use those apps but A LOT of people do.
I don't use any social media because I'm not social, but I have to use FB to see community updates, to coordinate with groups, to sell/buy things, to lookup businesses without websites, etc. I don't see TikTok or others having that moat or even attempting to dig it.
Facebook has the businesses, the users, and the developers. In no way are they dying.
The lies and the media reports of the so called death of the fastest company to reach $1 trillion dollars in the 21st century has been greatly exaggerated. Especially with having platforms with 1 billion+ users each.
Meta has plenty of cash and revenues to sail though this decade. And no. Your social circles and anecdotes is not evidence.
Edgelord devs are a weird group.
Growth isn't everything, and Meta isn't dying anymore than MS is.
I'm no expert in golang, so golang may in fact be better(?) by some metric of better, but as the author of a Rust CLI tool[0], I will say that Rust is extremely performant, and pretty fantastic at this very use case. It seems like a sweet spot to me.
I'd really love to get into Rust (and Go, tbh) but haven't needed the performance when I'm working on personal stuff and it's generally 1000x faster for me to jump in Python and write a quick script, using threading or asyncio when I need more perf and my program is IO-limited.
Many have left as a result. Weird hill to die on. :)
Personally I'm not a fan of Rust, but it is interesting to see how the language is growing as it hits mainstream. Lots of similarities with Go back when it was cool and hip.
> For specific use cases, we support other languages, including Java, Erlang, Haskell, and Go. These languages are currently not widely supported outside of specific use cases.
Except they say: “For data science, ML applications, and Instagram, Python continues to be the language of choice, and we continue to invest in the experience with this ecosystem.”
How would one go about building a rest service in C++? Do you have to write everything yourself or are there libraries and frameworks. I did some light looking into it after reading the article but I would love to hear from folks who actually do it and what the state of the art is for C++ web services.
Note that before Java adoption push we had stuff like ATLServer, and the first version of ASP were basically COM libraries being called from VBscript/JScript.
On our case, we were calling C code from TCL scripts, using plugins like mod_tcl.
Nowadays you have stuff like Boost ASIO and Wt.
However I wouldn't plug C or C++ directly into the Internet, rather call them from managed languages, as native libraries, reducing the risk of possible exploits.
I'd use https://github.com/drogonframework/drogon if the app needs to be pure C++ or Cutelyst (https://cutelyst.org/) if it's a Qt app which needs to expose an http server
At Meta, you wouldn't. Everything is Thrift. For WWW, you'll have more graphql.
Meta also has a shit ton of libs to make service development easier than exists publicly.
And the company would already have a build farm.
If you want an ML / C family hybrid language there's Ocaml, or if you just want a fast static-binary language there's Go.
1. https://engineering.fb.com/2015/06/26/security/fighting-spam...
2. https://engineering.fb.com/2014/06/10/web/open-sourcing-haxl...
- Java (with JOOQ): As a high level typed language (similar to Hack for Meta's use case. If Golang's generics help create a JOOQ equivalent in the future, then this would be Golang).
- C++/Carbon: As a systems/performance language. (We haven't tried Carbon yet, but this I feel would help beat Rust for this systems category)
- JS/TypeScript (Node or Deno or zx): As a scripting/tools language.
- Python: As a data processing and machine learning language (primarily thanks to the JIT computing and data libraries for Python). (This list ignores CUDA :))
Update update: Or reluctantly with Python instead, with a similar library such as PugSQL.
It's basically the same situation as Apple has with Swift. They'd never switch from Swift to C++, no matter what features were added to the language.
I would have expected Go even for CLI due to fast compilation and easy cross compilation out of the box
Their manager is either incompetent, or he is very opinionated, wich doesn't sound good for their stack
Pure python maybe, but the popular packages for these applications are all essentially python wrappers for highly optimized compiled code.
I'm curious though, what language(s) do you believe belong on that list?
> Rust is immature
I recuse myself due to fanboyism.
> C++ is intractable
Except to all the firms and people successfully using it.
> Python is fundamentally unusable at scale
Except to all the firms and people successfully using it.
Because it's a list of opinions on languages. No specifics provided, and stated in a way that appears to be trolling (deliberate or accidental on the author's part). Comments like that are a dime a dozen in programming language threads and add nothing to the overall conversation.
Whereas the OP simply reeled off a list of half-baked subjective opinions.
It’s bad no matter what single language you’re promoting.