Programming languages endorsed for server-side use at Meta
engineering.fb.com
engineering.fb.com
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.
And yet in 2022 we still have to beg employers and donors to keep those projects running.
If one PL doesn’t do the job, another will.
If we don’t get fusion, we die. That’s what the Princeton IAS is for.
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.
Rust usage is not "notoriously low" (don't know how you came to believe that) and it's growing very rapidly. The fact that it's a major supported language at Meta is evidence enough to the contrary, not to mention the plethora of post titles on HN that end with "in Rust", or are about rewriting in Rust (some of these are personal projects but many are company blog posts). I haven't seen any for D. Also just looked at the 2022 June Who's Hiring thread and ctrl-f "rust" found 23 matches, though admittedly that doesn't mean there are 23 jobs using Rust there.
I wouldn't trust Indeed, personally I've found it to be pretty bad for programming jobs, and definitely not representative of the industry (especially estimated salary, it's been wildly off for every company I've been at).
I just tried searching for a few language popularity studies, any that I found did not even include D. The StackOverflow 2022 dev survey says that Rust is both the most loved and wanted language: https://survey.stackoverflow.co/2022/#most-loved-dreaded-and...
Hardly any job postings. No large projects on github. No halo project (does servo count? It’s not gone anywhere yet, is it still alive?).
There’s an echo chamber around the language.
Job postings that mention using Rust from July 2022 Who's Hiring thread alone: https://news.ycombinator.com/item?id=31948363 https://news.ycombinator.com/item?id=32070322 https://news.ycombinator.com/item?id=31949373 https://news.ycombinator.com/item?id=31947931 https://news.ycombinator.com/item?id=32015077 https://news.ycombinator.com/item?id=31947359 https://news.ycombinator.com/item?id=31969755 https://news.ycombinator.com/item?id=31949096
> No large projects on github. No halo project
Take your pick: https://github.com/search?l=Rust&o=desc&q=rust&s=stars&type=... Deno has 84k stars.
That's practically all of FAANG and more.
D never had that.
Mozilla is a c++ and javascript shop. What do they ship in Rust? How much of Firefox is written in rust for example?
>> Microsoft, Meta, Google/Acrobat, Amazon
Large firms have lots of devs and consequently lots of toy projects. Is their usage of rust more significant than their use of D? I mean Meta was churning out projects in D a while back (warp, flint, etc) and looked like it might be going all in at one point (they even hired one of the leads on D lang).
>> That's practically all of FAANG
Who were we missing? Netflix, they’ve dabbled with D too: https://github.com/Netflix/vectorflow
Don’t misunderstand my point - it’s not that D is more popular than rust, it’s that rust is not used for real work in any significant capacity yet.
Where’s the big project written in rust? Servo and the rust compiler are the only two large rust projects on github.
About 20%, if you compare it directly against C and C++ and exclude Javascript, CSS, HTML, Java, etc.
https://www.openhub.net/p/firefox/analyses/latest/languages_...
Mozilla created the Rust project and funded the language's creation and several years of maturity. They replaced a large chunk of the layout engine with a Rust version.
>Large firms have lots of devs and consequently lots of toy projects.
Yes. But they don't tout the languages they use in those toy projects in their official communications, help create the language foundation, support the language with devs, or build their critical infrastructure or new in-house mobile OS in those toy languages.
Here's an example from Amazon:
"At AWS, Rust has quickly become critical to building infrastructure at scale. Firecracker is an open source virtualization technology that powers AWS Lambda and other serverless offerings. It launched publicly in 2018 as our first notable product implemented in Rust. We use Rust to deliver services such as Amazon Simple Storage Service (Amazon S3), Amazon Elastic Compute Cloud (Amazon EC2), Amazon CloudFront, and more. In 2020, we launched Bottlerocket, a Linux-based container operating system written in Rust, and our Amazon EC2 team uses Rust as the language of choice for new AWS Nitro System components, including sensitive applications, such as Nitro Enclaves.
At AWS, we believe leaders create more than they consume and always leave things better than they found them. In 2019, AWS was proud to become a sponsor of the Rust project. In 2020, we started hiring Rust maintainers and contributors, and we partnered with Google, Huawei, Microsoft, and Mozilla to create the Rust Foundation with a mission to support Rust. AWS is investing in the sustainability of Rust, a language we believe should be used to build sustainable and secure solutions."
And here are more:
https://cloudblogs.microsoft.com/opensource/2021/02/08/micro...
https://opensource.googleblog.com/2021/02/google-joins-rust-...
https://docs.microsoft.com/en-us/windows/dev-environment/rus...
https://fuchsia.googlesource.com/docs/+/d4f9b980f18fc6722b06...
https://aws.amazon.com/blogs/opensource/why-aws-loves-rust-a...
https://aws.amazon.com/blogs/opensource/sustainability-with-...
https://thenewstack.io/microsoft-rust-is-the-industrys-best-...
>Where’s the big project written in rust? Servo and the rust compiler are the only two large rust projects on github.
I don't think you'll find Google, Amazon, Dropbox, etc backend code in GitHub, if that's your metric.
Do you even know what TIOBE measures? Not usage, not sentiment, not search trends. It measures the number of search results that a term returns. So any change to Google's algorithm changes the ranking of a programming language. If Google starts returning coffee results for "Java" that will boost it's TIOBE ranking.
Let me give you a few examples of how dumb TIOBE is.
1. You know what's the most popular language by any metric - jobs, Github repos/PRs, stackoverflow stars, survey results? Yeah, JavaScript. You know what TIOBE ranks higher than JS? Visual Basic.
2. Next, you know the entire iOS ecosystem that supports tens of thousands of devs and the billions of dollars in app revenue? All of it is written in Swift and Obj-C. You know what's ranked higher than those two? Assembly Language.
3. You know what almost all new web frontend codebases are written in now? TypeScript. In a few years it'll be the #1 language in the world once it supplants JS. You know it's TIOBE rank? #37, below Scratch, Prolog, Object Pascal.
But no, perhaps your confident assertion that Mozilla doesn't use Rust beats this TIOBE nonsense.
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)
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.
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.
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.
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.
Only a semi troll comment, IRL Facebook recently said they were genuinely unable to audit where personal information was ending up across their systems which is a terrifying thing to think about and another reason I genuinely hope their pivot to VR kills them as a company.
Was there really a need for this comment? How about: for correctness and expressivity
Disparaging jokes about programming languages are really tired and uninteresting, I was glad to see that the Carbon discord explicitly bans them.
Everything's got exceptions but it's usually a punch by proxy. This would be really obvious if it was anything else.
If someone started making fun of say basketball, keeping it not about the people who play and are fans would be quite a precipice to navigate.
You could certainly complain about the technicals of the rules but you're no longer in the world of jokes.
Given that, Haskell, unless you're a mathematician, is still one of the least accessible language outside of purely academic, esoteric or intentionally obfuscated ones.
Tiny nitpick: Haskell the language and runtime is just another ML. You could technically write a ground-up Haskell program that doesn't do any maths stuff — in about the same way that you can write a ground-up Erlang program that doesn't use OTP.
Haskell just has a standard library and language-package ecosystem that's full of stuff only mathematicians were previously expected to understand. :)
I can't see how those statements in any way define any sort of population subset.
Take olympic athletes or orchestral musicians for instance.
If say a violinist said they only used a particular violin because it was that which was correct and expressive, that's much closer to elitist than say egalitarianism.
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.
Ouch. True elitists always code in ML.
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?
That almost sounds like an endorsement. I’ve been holding off learning Rust. However, it seems like Rust adoption is reaching a tipping point.
https://www.microsoft.com/en-us/research/project/project-ver...
They used to have this great site were you could interact with them all: https://web.archive.org/web/20180130101736/https://www.rise4...
Source: I'm a former member of RiSE
It is also where F# started, although they seem not yet to know where to push it, or if it was a good idea to actually box it in VS 2010.
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.
[1] - https://doc.rust-lang.org/book/ch15-04-rc.html
[2] - https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...
[3] - https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...
Talking about which object "owns" another that a pointer "outlives" what it points to are totally normal parlance for C++ developers and completely foreign to a lot of other folks.
There are a lot of similarities! The type systems are similar, with some name changes (sum types -> enums, typeclasses -> traits). Pattern matching is basically the same. Haskell uses (lazy) lists mostly the same way rust uses iterators. Ownership is new, but imposes some of the same requirements that immutability does (no cycles without shenanigans[0]). Rust requires that values are aliasable XOR mutable: Haskell does too (they're always aliasable and never mutable).
But someone who understands Haskell, may still find some memory stuff clumsy.
Here's a reasonable program to write in Python (wave hands here, my python is rusty)
queue = [root]
for node in queue:
if !node.visited:
# ... visit the node ...
node.visited = True
for child in node.children:
queue.insert(child)
let mut queue = VecDeque::new();
queue.push_back(root);
for node in &mut queue {
if !node.visited {
// ... visit the node ...
node.visited = true;
for child in &mut node.children {
queue.push_back(child);
}
}
}
It's rather rare for a programmer to need to learn about memory safety when compilers in managed languages just solve it for you, and in other systems languages they assume you already know it (or don't care that you can write unsafe programs).
There's just that additional conceptual burden when learning Rust and why programs that seem syntactically correct and safe are forbidden.
edit: in fact, if you specifically use a deque in Python the way you are in Rust, Python will throw a "RuntimeError: deque mutated during iteration". This is just a bad approach in any language, honestly.
For anyone coming from a GC language, Rust is a huge change.
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.
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 :).
>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
Yes and no. There are some things you want to specify for compiler to check, but a lot of behavior can be inferred from the code. Think about some backend server functionality for a website that has to do processing on some json data. You could take that code in python and write absolutely safe C code, and the process to translate it wouldn't be that hard.
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
Sure, there are some things that Rust makes nice, like compile time checking for errors, however with C++ codebases, they will just result in runtime errors rather than usable exploits.
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?
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.
I agree that examples of drivers, and possibly kernels (outside of Oberon), that utilize managed languages may be needed to really start the conversation, but there really should be a conversation. So, off hand, can you think of any books, technical reports, papers, videos, whatever on this general topic that can point me deeper? At my core as a developer, I am concerned first and foremost with performance (along many metrics, not just wall-clock speed), but outside of hard or soft real-time systems (and soft may have more leeway than is commonly claimed) I really think there are some big wins possible in multiple areas by switching the default definition of ‘systems programming language’.
PS. Sorry for going super OT and for dragging up an almost day old comment.
Most of the systems that we had in such directions, like Xerox PARC and ETHZ endevours, Inferno, Microsoft research, usually failed not because of technical issues (which they had), but because management decided to spend money elsewhere.
As proven by stuff like Android, JavaScript JIT and similar projects, it isn't a MVP product, rather something that you really need to be willing to spend years putting money into to prove a point, and the large majority isn't into it.
Regarding information, the now abandoned Android Things replaced the original Brillo project, whereas Brillo was Android without Java everything C++, Android Things became a subset of Android, where for security reasons drivers would have to be written in Java.
https://developer.android.com/reference/com/google/android/t...
Since Project Treble, Android allows for writing Treble drivers in Java,
https://source.android.com/devices/architecture/hidl
Apple's continuous push for Swift (they even made the point at WWDC 2022 that Objective-C is done and thank him for all the fish) is another example, so anything coming from them. Yes, Swift does count as managed language, as RC is a GC algorithm.
But it's relatively more abstract and gives less control than C++/zig/rust. I was just comparing and contrasting the marketing.
Go was once marketed as systems language even if the authors intended it more for systems adjacent stuff. Now everyone advertises their language can write web services it seems. I mean why is it out of fashion to just admit a language is mainly intended for low level stuff?
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.
But I don't see why that precludes Rust from being a good choice in other applications, CLI in particular.
There is a gap between the nineties and now, and it is still void.
If you have to constrain it to CLI apps the average developer here on HN needs to write, I don´t see a reason to use such a complex beast as Rust. If you mean operating systems, I can see a spot for Rust. Also database systems or a web server implementation. But that is fairly niche.
For userland cli-apps I am not sure if the added complexity pays of in terms of sufficient performance gains in practice. If you want to write a new implementation of grep, sure. But how niche is that?
So in those cases where you need both type strictness (which I agree should be the default requirement) and cannot have an automatic garbage collector, I can see the value of Rust.
But for what audience is an automatic GC really a problem? Personally I would use Haskell, Java, F# for CLI-apps, but I know there are tons of other options there.
(Rust can also do in-line assembly…)
However, by the same token, we might as well count any assembly in the kernel that gets executed due to some syscall from grep.
In any case, I'd still like to see a grep whose inner loop is written in Assembly. :-)
That won't be considered 'inner loop'
https://github.com/Genivia/ugrep/blob/a3acf863803a755ff8da8c...
And that isn't Assembly.
So I guess what you said earlier, "grep inner loops are coded straight in Assembly," was a misrepresentation. And that "Rust was a poor fit" is just empirically wrong.
But also, I feel that it's generally incorrect to position Rust's safety model as the opposite of automatic GC. It kinda makes sense if you only focus on management of memory as a resource, but it ignores the whole race condition angle (which very much still exists in GC'd languages like Go or Java).
Agree, that is not what I meant. Rust provides type safety and allows you to without a GC, all while offering top speed. Being able to do without a GC is somewhat of a niche requirement I think. In those cases it is an requirement, Rust would be a top choice.
My point is: there are tons of GUI applications written in C++. And to this day there are still new projects that pick C++ because it needs a GUI. I consider that a bad thing for Rust. Thinking Rust should be at the CLI-apps competition is just a way to avoid C++. It is the wrong contest, and I am not sure if Rust is even able to win that contest because what Rust has to offer (no GC) isn´t of interest for most CLI apps. I think cli apps like kubectl would not be hurt by being GC'ed.
I think that the Rust leadership should identify that GUI is the first city they need to liberate from C++ if they ever dream to replace C++. I just learned some original work has started by various projects, so I keep my fingers crossed.
Unless you mean that the lower level GUI code should be rewritten in Rust, so that other languages can provide a higher level interface on top of that. That might indeed sort of work. But the vast amount of work is going to be in Rust. And you still pay some penalty, depending on the mismatch of the higher level language and rust. You will need to have a frictionless integration as between C# and WinForms.
The hard work is on that lower level. A simple text input control takes a lot of engineering. You will still end up with something like QT in Rust.
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.
https://github.com/microsoft/windows-rs
Note the lack of of safe wrappers for Windows APIs, and still no good way to create the Windows Runtime objects necessary to interoperate with XAML.
Also the basic examples with very little UI code on what is supposed to be a projection for a Windows UI framework.
Check their online demos.
I use Go a lot more than Rust. It's like the Java of that world.
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?
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?
But that's still relatively small compared to Go, or even Python if you consider needing to bundle the interpreter for "fully statically linked".
Is that true at fb? That's quite interesting if so.
Spite is a great design decision.
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.
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?
They had a working node server and decided to reimplement it from scratch. They started missing demos and weren't able to raise more from existing or new investors before they run out of money. I suspect the CTO did it on purpose and was just CV building.
Often times the tech choice is not that important, you just need to get something out the door.
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/)
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.
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.
I cringe every time I need to deal with node powered software on the backend, including some famous build tools.
> 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.
People's habits have been switching to use videos (the bubbles) as they disappear. They are using it like SnapChat. It's not the algo that changed.
Your feed is just what your followers have recently posted. When you go to a profile the bubbles (videos) are at the top and the images / perm videos are in their gallery.
But the main thing that effects your app experience is who you follow, what they post, and how you browse. Personally I've always gone straight to the profiles and view from there, but I view IG more as a photo gallery than anything else.
Surely, it could be both: the algorithm changes people’s habits and people change their posting habits based on the activity they think the algorithm is rewarding?
The consumer notices changes of their friends, who is posting what.
The creator notices changes in their impressions, how many is viewing what.
I haven't read any recent earnings statement, but curious how bad Apple's new privacy policies were for FB.
Regardless of the expected loss, that overall increase and total billions in profit is not "dying" by any means.
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.
This is hopefully the beginning of the end for them.
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.
I understand why someone might feel this way, but I think it may misunderstand/misinterpret a few things.
First, a more complex development style is not a chronic condition, because you become proficient in the language you work in. For instance re: the borrow checker, you begin to understand what it wants you to do, and why. Rust may be harder to pick up, but, once you do, it's just as easy to build a CLI tool in Rust.
Second, obviously, it depends on the type of CLI tool you're writing. Maybe the CLI tools Meta are writing look less like Python scripts, and more like Valgrind or tcpdump.
Third, not to disparage golang in any way, but golang's simplicity is something of an illusion. Because all "simplicity" is an illusion. It breaks down quickly at the edges. As someone else noted, you should take a look at "I want off Mr. Golang's Wild Ride"[0] but also perhaps "Simple Made Easy"[1].
[0]: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... [1]: https://www.youtube.com/watch?v=SxdOUGdseq4
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.
I prefer to make my life harder by pursuing the perfect solution. It has bitten me in the behind multiple times in the past :)
> 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.
And the company would already have a build farm.
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.
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
But Meta is in the advertising business and Google is a competitor.
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?
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.
half-assed gestures to lazy forum-warrior tropes, would be a more accurate description.
> 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.
No true fanboy would ever say that ;)