5 ms·

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

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, ...).

rwbhn 4y ago
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.
- disgruntledphd2 4y ago
  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.
beepbooptheory 4y ago
There is a subheading in the article that reads: >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.
kaba0 4y ago
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.
nicolashahn 4y ago
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.
beiller 4y ago
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!
jokethrowaway 4y ago
I can't say Go had the adoption I was hoping for. 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).
- al_mandi 4y ago
  > and actually failed because they decided to rewrite from node to go Interesting. What did golang do so badly that they failed?
  - jokethrowaway 4y ago
    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.
nindalf 4y ago
> 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 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/ https://engineering.fb.com/2021/04/29/developer-tools/rust/)

rwbhn 4y ago

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.

disgruntledphd2 4y ago
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.

beepbooptheory 4y ago

There is a subheading in the article that reads: >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.

kaba0 4y ago

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.

nicolashahn 4y ago

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.

beiller 4y ago

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!

jokethrowaway 4y ago

I can't say Go had the adoption I was hoping for. 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).

al_mandi 4y ago
> and actually failed because they decided to rewrite from node to go Interesting. What did golang do so badly that they failed?
- jokethrowaway 4y ago
  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.

nindalf 4y ago

> 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 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/ https://engineering.fb.com/2021/04/29/developer-tools/rust/)