What's always been interesting about the languages Meta uses is the story of the rise and fall of the D programming language at Meta. I wasn't around at the time when Andrei was working there and advocating for its adoption, but it seemed like he hit a wall at some point. By the time I joined all D services were being deprecated or rewritten.
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.
D always struck me as not sufficiently better than C++ to justify the litany of downsides to using a relatively obscure language. To find a niche, it basically needed to be what Carbon now promises to be - something that can seamlessly integrate with existing C++ code.
Yeah, it sad to think we have 100 f*cking think tanks endowed by billionaires that serve mainly to drive wedges into our democracies, yet nothing like that for PL geniuses that I'm aware of.
>> Rust is far more widely used than D in the industry
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 usage of both D and Rust is notoriously low in the industry
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...
Rusts usage in industry absolutely is notoriously low when in comparison to C++ though (as is D’s) That’s changing of course but HN’s bubble is just that, a bubble.
My issue was with lumping in Rust with D when saying they both have "notoriously low usage" when Rust has, conservatively, probably >10x the usage of D.
You've said many wrong things on this thread, but the most egregious is quoting TIOBE like is has any meaning whatsoever. It's exclusively meant for managers who have no technical chops.
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.
Rust has been adopted by Mozilla (of course), Microsoft, Meta, Google/Acrobat, Amazon, and even Apple for key infrastructure, among tons of others major big players.
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).
>Mozilla is a c++ and javascript shop. What do they ship in Rust? How much of Firefox is written in rust for example?
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."
Yep, I also just left Meta/Facebook after 4 years working there. I did spend some of my time trying to see where Nim could fit (together with a few other folks that liked Nim at FB), the best area we could come up with was CLI tools that interfaced with many internal C++ libraries. Nim would be a great replacement for Python here (it's fast and typed) and its ability to compile to C++ makes interfacing with C++ super simple (at least in theory).
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.
I added Nim support to an edge platform for that reason. I think it fits in with the others. Crucially it boils down to machine code and can be debugged with GDB.
Same reason we’re using Nim for our IoT sensor platforms firmware: it just boils down to C, so we don’t have to give up driver support or rewrite ESP-IDF from scratch.
Most of the other "Better C" languages never got the inertia to overcome C++ so that's not really a unique case. Go and Rust both had key organizational buy-in from large and culturally important orgs early on which is why they seem to have gotten roots down versus most others, and even Go took a fairly long time to see adoption outside of Google at least to my view of things.
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.
Rust was sufficiently different from C++ and C in a lot of use cases, while maintaining a similar syntax.
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.
> Meta’s primary supported server-side languages are Hack, C++, Rust, and Python.
> 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.
I believe the chat backend was implemented in Erlang too. When I was much younger, the web based instant messaging seemed like magic to me so I looked into it and turned out they used Erlang.
Why would you have been called out for saying “correctness and expressivity”? That’s accurate, though also probably legacy now that Rust can satisfy most or all of those use cases.
In practice they're always (?!) about the userbase.
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.
> 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. :)
An elite is a subset that was drawn out of a pool. The set of very rich people is a small subset: an elite. The group of prisoners chosen for execution today is also an elite.
I can't see how those statements in any way define any sort of population subset.
The elite is associated with accuracy, cleanliness of execution, precision, correctness, an ability to be flexible and expressive while maintaining refined control and precision.
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.
Iirc the story was fb messenger was written in Erlang, then they rewrote in c++ because of no trust in erlang (I think that was around when fb messenger started sucking with everyone complaining about bugs -- it was better last I used it 4 yrs ago) then ironically they re-acquired Erlang via WhatsApp.
I think Sigma (FB's spam filtering system) is still written in Haskell, but I may be wrong (basing this around internet rumours since I don't work at Meta).
Back in the 2010s pre-Rust era Facebook hired and acqui-hired some big names in the Haskell and functional programming world. Probably still have some of them, and their codebases. But Rust can probably now satisfy most of those use cases.
Basically, all the front-end code on the server side is written in Hack, because it was originally written in PHP. My understanding is that general application logic, like permissions, is handled by libraries written in Hack. Also stuff like templates (for HTML or other UIs, including CSS), etc.
Hack is recognizable as a PHP derivative but the experience of writing Hack is very different from the experience of writing PHP.
There's a LOT of infrastructure that already exists in the Hack ecosystem at Meta. Especially around things like data access control, privacy, auditing, data deletion, etc.
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.
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.
Yes, good point, a switch from a GC-based language to a memory ownership -based language is definitely non-trivial, but you can always just forget Rust references altogether for the time-being and start hacking with Rust with its reference-counted smart pointers, effectively learning Rust as if it were Go. (You will have to switch back to Rust ownership/references later on to get back the performance and the respect of other Rustaceans 8) .)
I don't think Rust is easy to learn, it's has a kind of famously steep learning curve. The tooling is great which helps, but it's not easy for new-ish systems programmers.
Well, you will probably think I'm crazy, but for me personally, having a couple of decades of C++ experience, learning Rust turned out to be much easier than learning... Swift. Yes, that famed, ultra-modern, great-as-your-first-programming-language Swift. Except for lifetime annotations and the borrow checker, Rust turned out to be much easier for my brain to parse and memorize than Swift, perhaps due to Rust's consistency and predictability and Swift's horrible language construct bloat.
Going from C++ to Rust is pretty much the easiest path, since most of the "hard" parts of Rust are just automating stuff you do by hand in C++ anyway. For other languages where people regularly get tripped up on "what's the stack vs the heap?" coming to Rust it's a bit of a different story, ime.
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.
I came to rust from the other direction, as it were: from Haskell.
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).
The thing is that mutability is a useful and common property used by most programmers. It takes a bit of buy in to be convinced immutability is a good thing that solves bugs. For example:
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)
Here's that in Rust.
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);
}
}
}
This will not compile, at all. You need to do a lot of work to restructure the data structures in Rust to get that reasonable program to run soundly. Now that's a good thing, because this would be invalid in C/C++ too due to iterator invalidation and lifetime issues, but it's the kind of thing that people who haven't seen a block of code segfault due to a `push_back` before would be confused by.
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.
TBH I'm surprised that even works in Python – modifying a collection you're in the middle of iterating seems like a bad habit to get into in any language.
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.
Agreed, python may be a contrived example here. It is possible to pull this off in a few languages where object relocation isn't a problem and mutating a collection during iteration is natural.
I don't disagree but that says to me that a lot of the "Rust is hard" narrative is actually "low-level systems programming is hard", eg) domain complexity is being misattributed to the language.
Yeah, I have to agree with this. I tried to get my team at my previous work to adopt Rust, and they all pretty much failed to really pick it up. Granted they weren't the most talented group I've worked with.
It's really frustrating to write, until it isn't. The language lets you be extremely expressive with about the same level of mental overhead as a garbage collected language. Once it "clicks," it's a joy to work with.
The borrow checker and lifetime annotations. It's always the borrow checker and lifetime annotations - otherwise Rust is, IMHO, as readable as (the excellent) Golang.
I've often wondered what it would be like having a variant of Rust that was essentially the same underlying language, but with a garbage collector of some kind instead of a borrow checker and lifetime annotations.
You can approximate this already: forget Rust references (borrow checking + lifetimes; in other words, raw pointers) and start hacking with Rust using its shared ownership (reference-counted) smart pointers, immutable Rc<T>[1], mutable RefCell<T>[2] and the combination of the two[3]. The syntax will, overall, get considerably more dense than Go, but otherwise analogous to Go. Instead of GC cycles, memory will be freed incrementally, immediately when no longer in use.
I've tried learning Rust after learning Go, never really got into it. I also know C, C++, Java, Python, PHP, JS, and a couple others (Perl, anyone?) I find Rust syntax too complex, similar to C++ which I also avoid now.
That's true, but it doesn't mean C++ is harder to learn. Rust has a broader and more novel conceptual surface area than C++. This is what influences difficulty, not memory safety guarantees.
I postulate that a lot of folks confuse ‘easier to learn’ with ‘easier to get code to compile’ and I disagree that the two are the same. Rust makes it more obvious sooner that you have soooo much to learn.
Rust presents a programmatic model to its users that is exceptionally broad. That model is not objectively more correct, or better, or whatever else, than the model presented by other languages. It provides different guarantees, and extracts different costs, and lifts different concerns into the domain of its users, compared to alternatives. Those particular costs and benefits make sense for certain use cases, and don't make sense for others.
Rust adoption very much seems to be ramping up within the really big companies. Google talking about it both for Android and Chrome, FB with a ton of things, Apple had uses for it I think but I'm blanking on what, Amazon is using it for at least some new AWS infrastucture...
Note that on Android it is only endorsed for system code by Google itself and OEMs, officially there are no plans to support it on the NDK, or Android Studio.
Nothing prevents Google to eventually change their mind in regards to its support on userspace, however given how the NDK has been managed all these years (as a kind of side project at least from the outside), I pretty much doubt it.
Yeah. They are both writing code in Rust and also dabbling in creating a language of their own to see how that goes, not necessarily with the intent of releasing it, but at least exploring the space from first principles instead of being incumbered by Rust's decisions. I think the name started with V but I cannot find it right now with quick Googling.
I wouldn't put much stock in MSR languages until they get usage in other orgs. There's at least a dozen research languages in flight at a given point in time.
Verona is less interesting in the language that I expect to make it into the world sense and more they may learn things while exploring safety that can be applied by someone else. Rust does a lot of good with exploring the safety space, but I hope we don't simply let that be the end of any exploration of building safety into the language at a deep level.
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.
Being "explicit with code for memory safety [even for] simple operations" is the whole point of Rust. Otherwise, sooner or later, as a codebase grows, you make mistakes that your compiler cannot catch (e.g., you give an immutable reference to a component and later on unexpectedly mutate that same referenced memory from under that component).
> [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 :).
Rust community can't control what happens in enterprise, and enterprise has a nasty habit of prioritizing delivery times over robustness.
>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.
> C++ has a standard library and smart pointers that eliminate a lot of errors with dangling pointers, and if people use those exclusively
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
The point is you can still write memory safe code and avoid all the double free and user after free bugs if you just use smart pointers correctly and standard namespace constructs. You can be extra safe and use unique pointers and transfer ownership.
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.
> focus on smarter compilers/interpreters, not languages
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?
The primary use case for Rust being CLI is somewhat strange and speaks to non-technical considerations. Does anyone really think there is an advantage Rust brings here over everything else -- Golang, Python etc. Rust community seems to go after "hot" areas in hopes of getting traction, fully understandable. Writing web services is another area Rust people jumped into looking at the popularity of Golang. Most recent "hot" area being crypto. The reality is none of these areas is a sweet spot for Rust and will remain niche (in comparison to other languages). The sweet spot is low level systems programming and displacing C++ (of which there is a real and desperate need). If the community can focus on interoperability with C++ (at the gnarly level), would be make a big difference to adoption.
> Does anyone really think there is an advantage Rust brings here over everything else -- Golang, Python etc.
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.
Depends on your definition of "small". Clap will add significantly to the compile time, but your binary won't be too much larger. Rust binaries tend to fall in the range of 2–30MB, depending on lots of things.
But that's still relatively small compared to Go, or even Python if you consider needing to bundle the interpreter for "fully statically linked".
clap adds about 300kb with my usual release mode profile (lto = true, opt-level = 'z', panic = 'abort', strip = true). Bigger than I would like but for most projects I'm OK taking the binary size hit for nicer ergonomics and more features than argh.
The areas you mentioned (CLI, web services, low level systems programming) are not mutually exclusive. Doing a good job on one doesn't mean something else is affected.
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).
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?
actually creating a cli with rust is really one of the best ways to use it.
it is extremly fast and has a low footprint and if your cli does only one thing well it's probably easy to write opinionated rust.
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.
It is not beyond some base-line which golang cobra, python argparse, rust clap all hit. But it's so nice to use I thought there would have to be a trade-off and there wasn't.
well depending on the language an argsparser can trash quite a lot of memory and become slower than necessary when there is a big argument list.
as others said if this cli is also used as a component than it might be important that it is fast.
and since claps is so easy to use and has basically no downsides it's stupid to even not at least try it.
as said compared to other tools it's really really simple
re CLI, the author of esbuild had an interesting comment about writing it in both Go and Rust and the Go version being faster out of the box https://news.ycombinator.com/item?id=22336284
GC gives you a nice cushion, because it makes allocations fast. However, with a little bit of thought put into memory allocation (such as using arenas with bump allocation), you'd easily beat Go with Rust. The author of SWC did exactly that https://swc.rs/docs/benchmarks
The time to start up a Python interpreter and do meaningful imports is quite painful for a CLI app. If you have Python code and want add a CLI you can live with it, but you wouldn't pick it ahead of time .
This is exactly why. It's also not just the interpreter, it's also one-time costs involved in unpacking PAR files, but deploys are frequent enough that you might hit those delays many times per day.
If I can have a XAML/WinForms like UI dev experience with Rust on Linux, I am sold. Even just a usable rich UI framework on Linux. Cross-platform is a bonus, but since I believe Linux is the future I can live without other platform targets.
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.
You cannot even get it with Rust/WinRT straight out of Redmond, let alone having hopes to get it on Linux.
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.
That's sad. I would love to tinker with UI programming on Linux, but it seems like to get anything decent you will have to use QT, which brings C++ as a requirement.
Thanks. I did not mean XAML literally though, something like that would be super nice for Linux. The project you linked brings Windows RT as a requirement.
But just something with the richness of QT + Rust on Linux would be welcome. I am hearing the rust bindings for QT are just a pain and incomplete. I was hoping for Rust to really offer an alternative for C++ here.
Thank you, still early indeed but the project looks promising. I am really hoping for the Return of the Desktop in which episode Rust defeats C++ and we all have a sane, safe, free and memory abiding computing experience.
Well, isn´t that a bit damning though? I am not an expert on Rust, so please enlighten me. If it is meant to replace C++, I would expect it to dethrone on the areas where it is king. I am looking at a crap ton of programs with an UI. Your IDE, your text editor, your spreadsheet program, your graphics editor, etc. Most of the modern programs just give up and ship as a full blown bloated memory eating web browser.
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.
For CLI apps, performance may be important, and Rust offers a performance profile similar to C++. This is exactly the niche where relying on an automatic GC may be undesirable.
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).
«But also, I feel that it's generally incorrect to position Rust's safety model as the opposite of automatic GC.»
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.
The question, rather, is why one would want to use C++ rather than something higher-level (e.g. C#, Java, Swift) for a GUI app in 2022. We're long past the point where performance benefits were worth writing the whole thing that way. Most apps can get away without anything C-like at all, and for the few that need that perf boost, it's easier to implement the corresponding part as a C++ library called from higher-level GUI code. In such an architecture, Rust can transparently replace C++.
I see your point, but that also means data marshalling between the higher level language and the rust components. Also, I think GUI is a place where speed plays a significant role. It is no wonder that most GUI's are written in C/C++.
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.
So does ripgrep... Which is written in Rust. So how exactly is Rust a poor fit?
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.
Back in my days, systems programming evolved writing compilers, linkers, os drivers and kernels.
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’ve seen comments from you several times that echo this point. But it always seems to end conversations, which I find disheartening, because I’d really like to see others at least discuss your point, even if they never adopt a similar view. Your premise seems to be that most devs are overlooking the applicability of ‘managed’ languages in the area of ‘systems programming.’ I think your listing of systems programming topics above is a fairly representative sample and I never see much push back, or any concrete examples, for why a managed language is not capable of being used in the general case.
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.
It is hard to have such conversations, because they tend to be more ideologic than technical.
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.
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.
I indeed agree that Go can be used for many systems and adjacent purposes, and is used for many DB engines and network stack stuff pretty well.
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?
While this is cool to see "how the big guys do it", this article is worthless. Specifically, it lacks one fundamental thing: why.
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.
Given the deliberate shortness of the list, I would rather ask why would they add it? It is not more performant than rust or c++, nor is it more productive than php or python. It is a high level language with not many interesting qualities over the litany of other GC-d languages that could equally well be added.
Go is mentioned and supported in specific use cases, just not as widely used as the other languages. It fits in a niche that overlaps with the supported languages, so there's no broad need for it.
> Specifically, it lacks one fundamental thing: why.
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.
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).
Not a fault of Go, the rewrite just burnt all the time they should have spent improving the product.
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.
The article does a good job of explaining why the list is small - and in my opinion quite useful in that regard. Agree that it would be interesting to know what perceived costs/benefits of various options considered were. I suspect accidents of history, before the need for a list like this was recognized, play a large part.
When I started there in 2013 the philosophy was that they'd help you build your service in any language. Funny the difference a decade makes, I suppose.
Isn't Go at least partially contributed and controlled by Google? My knowledge may be out of date. If it is it may make it a strategic move to not fully embrace it. Rust solves some of the problems Go attempts to solve at least and it is more community driven from what I understand. Please correct me!
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'm biased but I see no fundamental reason why everything doesn't converge on TypeScript in the future. C : C++/Rust (context: systems development) as JS : TS (context: all programming).
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?
React/RN is the largest web & native cross-platform framework, Jest is one of the main testing tools as well.
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.
My wife's feed mainly shows images as that's mostly what her followers post.
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.
I'm sure they are always changing the alg like all social media companies, but the habits of people have changed. They are most likely adjusting to it.
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?
Certainly. The habit changes are just my anecdote. The anecdotes of others such as the mentioned photographers. They are two different perspective (consumer and creator) so I'm sure there are different experiences.
The consumer notices changes of their friends, who is posting what.
The creator notices changes in their impressions, how many is viewing what.
> 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.
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.
The absolute dumpster fire that is their pivot to VR however.. go look at this and the replies and then remember this is what they are betting the company on at a time when they have never had less user trust, goodwill or greater potential for government oversight.
This is hopefully the beginning of the end for them.
For folks at Meta, is Thrift still the main communication protocol for service-to-service communication? Curious to see if that's still how most of these server-side applications talk with each other.
I’m surprised they said Rust is their new language of choice for CLI tools. I’m no expert but always saw Go as the better choice for CLI tooling where performance is important, Rust more of a low level language for highly performant libraries and tools, and Python a good choice for scripting or plumbing that needs to work and be easily maintainable, without special performance concerns (Python is my primary language, I’ve only dabbled in Go and Rust).
> I’m no expert but always saw Go as the better choice for CLI tooling where performance is important
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.
Sure, I wasn't really implying that Go is more performant than Rust, but that Go is a better choice where performance is important, but not so important that you'd forgo the simplicity of Go for Rust's more complex development style (borrow checker, etc?).
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.
> Go is a better choice where performance is important, but not so important that you'd forgo the simplicity of Go for Rust's more complex development style (borrow checker, etc?).
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].
Go is the go-to for many teams, especially CLIs. Unfortunately there are strong opinions held by high influence on Rust vs. Go instead of Rust + Go. To the point of finger pointing any chance they could with "see??"
Many have left as a result. Weird hill to die on. :)
There's a lot more Python which is somehow not considered "server-side use" even though it's absolutely essential for standing up a new service. You can't do configuration or alerting without at least a little bit of it, for example, and those are mandatory. There's also some Ruby, because chef, but TBH in 3.5 years there I never had to touch more than a couple of tiny bits personally.
I work at Meta and I use tools written in bash, C, Java, Go, TypeScript, Kotlin and Dart daily. I've definitely noticed that some C++ tools are moving to Rust. I would have preferred to see D in its place, but it is what it is.
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 think its killer feature is the memory safety guarantees, but other than that, I just don't find it as readable as other modern languages, mainly because it's symbol heavy.
All the notes about supported languages are very superficial, it reads more about “we adopted Rust” than anything else. Someone clearly felt the need to say it out loud.
I remember interviewing there in 2009 and I stopped counting the number of languages I was told were being used on the SRO / backend side. I'm sure it wasn't, but it seemed like it was basically "everything" :-)
Most big companies use "everything" in some capacity, which is why "X uses Y" type statements are meaningless. The question is what's primary, what's supported, what's common in practice.
I assume there's still a big difference between big companies that have a monorepo and extremely centralized and vertical build infrastructure, and the ones that don't, especially if they're very siloed. From what I see from friends at Apple for instance, starting a project in an uncommon language is not a problem at all for most teams.
It's curious not to see any JVM language there. Scala isn't even mentioned. Probably the data size is so high that the only way to survive there is to write everything in low level C++ or Rust.
> 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.
> Probably the data size is so high that the only way to survive there is to write everything in low level C++ or Rust.
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.”
For research you use Python or whatever. For production you compile your models to whatever their proprietary equivalent to TorchScript and ONNX is, which is surely executed by hyperoptimized C++/Rust/Cuda code.
I'm very surprised that C++ is one of the recommended languages for backend services. I occasionally am interested in learning C++ but with my context as a web developer I find it doesn't really fit any of my use cases.
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.
This is what I had considered to be the state of things. The phrasing on initial read suggested to me that C++ & Rust were the default now for performance critical services (with Rust being a new add) and Hack was used where it made sense but not necessarily by default anymore. I think I may have discounted Hack's role too much.
Clearly one can write web services in C++. Meta does not really, though. It is Hack code that talks to most web clients (and python for Instagram). The C++ code sits behind that. All of the databases, the caches, the indexing services, the ads ranking and selection are written in C++ and talk Thrift to each other and to the Hack code.
"backend" does not necessarily means the part that receives the HTTP request from the client. It could be a microservice that speaks some other protocol, a load-balancer that sits in front of the web workers, and task runner, etc.
I’d bet they use e.g. Python to receive the HTTP calls and do basic logic at that level, but use C++ libs to chew through lots of multimedia, ML/AI, etc.
I'm surprised by the use of Rust in domains where a GC is perfectly fine, like much of CLI tooling. Manual memory management is one of the most time consuming issues to deal with and I don't understand why people are burdening themselves with it in domains where it's not strictly necessary.
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.
Rust memory is not manually managed though. At least not in the sense where you have to remember to free things or not use dangling pointers. The amount of memory management in (non unsafe) Rust code, at least in my experience, is minimal.
I don’t work there, but from talks I’ve gone to I believe their Scaled Abuse team uses (or at least used to use) Haskell[1] along with the library Haxl[2]
It also powers the backend of Wit.ai which FB owns. Wit's open-source entity parser, duckling, is written entirely in Haskell. https://github.com/facebook/duckling
My guess is that most people using Haskell (and OCaml and Standard ML) are using it for internal tool such as program verification/analysis/transformation. It's not that Haskell/OCaml/Standard ML should not be used for backend services (i.e. APIs in a hot spot [at faceboook's scale anyway]). It's just that (in my experience) they're most commonly used for out-of-band analysis or developer lifecycle systems.
In a pre-AST project 2 world, I've found the following 4 languages work well for programming (non-frontend) use cases, based on my startup experience:
- 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: This list can be brought down to 3, if Java is substituted with TypeScript(/WASM-target for the future?), with a type-safe SQL codegen library such as: https://github.com/adelsz/pgtyped
Update update: Or reluctantly with Python instead, with a similar library such as PugSQL.
Not surprised at the list. Hack stands out as unique to facebook. Is hack being used in other large companies? I wonder if they will ever move back to php now that many issues facebook had have been resolved in later versions.
Hack has become essentially a domain-specific language for the frameworks used at Meta. They evolve together. There's no going back to PHP because there's no reason to rewrite the frameworks and give up on the flexibility afforded by being able to tweak the language to fit the framework.
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'm surprised at the list. Rust is fundamentally immature, C++ is fundamentally intractable, Python is fundamentally unusable at scale, and Hack is, well, no discussion needed. Strong negative signal for potential candidates.
I can't speak to the other three, but the comment about python is not accurate. Or at least not given the way that python is used for the mentioned applications "For data science, ML applications, and Instagram, Python continues to be the language of choice".
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?
Instagram is a huge Django app and unlike all the ML libraries, Django isn't highly optimized low-level code wrapped in Python, at least not by default. That's why Facebook are putting so much work into running a more performant fork of CPython - https://github.com/facebookincubator/cinder
> Curius why people downvote this.. its a perfect valid argument.
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.
I’d hazard a guess that Meta put a fair amount of effort into coming up with that list, applying business context to their specific technology problems.
Whereas the OP simply reeled off a list of half-baked subjective opinions.
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.