Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming languages endorsed for server-side use at Meta

engineering.fb.com

Post reply on HN
Print view View original

151–160 of 302 posts

Re: Programming languages endorsed for server-side use at Meta

#151

Post by renewiltord »

sigmonsays wrote: post #148
merb wrote: post #143

Earlier quoted context omitted.

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.

in what world is the arg parser performance critical?

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.

Re: Programming languages endorsed for server-side use at Meta

#152

Post by 10x-dev »

zascrash wrote: post #108
10x-dev wrote: post #63

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.

Are your use of Dart related to flutter?

Yeap, our team has a few quick-and-dirty GUI tools in Flutter

Re: Programming languages endorsed for server-side use at Meta

#153

Post by reincarnate0x14 »

dom96 wrote: post #51

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 ne…

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.

Re: Programming languages endorsed for server-side use at Meta

#154

Post by meitros »

npalli wrote: post #135

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 "…

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

Re: Programming languages endorsed for server-side use at Meta

#155

Post by kristopolous »

TillE wrote: post #91
kristopolous wrote: post #74

Earlier quoted context omitted.

What you offered up is pretty close to the meaning of elite.

"Elite" and "elitism" are totally different concepts. Disparaging jokes about programming languages are really tired and uninteresting, I was glad to see that the Carbon discord explicitly bans them.

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.

Re: Programming languages endorsed for server-side use at Meta

#156

Post by nindalf »

tuetuopay wrote: post #57

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…

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

Further reading - A brief history of Rust at Facebook (https://engineering.fb.com/2021/04/29/developer-tools/rust/)

Re: Programming languages endorsed for server-side use at Meta

#157

Post by dvlsg »

gary17the wrote: post #92
DoesntMatter22 wrote: post #82

Earlier quoted context omitted.

Every video I've watched on youtube of Rust vs Go makes me think Rust is not a whole lot of fun to write.

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.

Re: Programming languages endorsed for server-side use at Meta

#158

Post by hhjinks »

DoesntMatter22 wrote: post #82
duped wrote: post #68

Earlier quoted context omitted.

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.

Every video I've watched on youtube of Rust vs Go makes me think Rust is not a whole lot of fun to write.

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.

Re: Programming languages endorsed for server-side use at Meta

#159

Post by pjmlp »

TillE wrote: post #95
pjmlp wrote: post #70

Earlier quoted context omitted.

Andrei is now at NVidia, and I bet most likely for his C++ skills. 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.

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.

They actually started down that path, https://dlang.org/spec/cpp_interface.html, hence my remark.

Re: Programming languages endorsed for server-side use at Meta

#160

Post by int_19h »

exceptione wrote: post #149
npalli wrote: post #135

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 "…

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 framewo…

UI is a poor fit for Rust, IMO, because the natural way to model UI widget hierarchies is rather painful with ownership tracking in the picture.

But I don't see why that precludes Rust from being a good choice in other applications, CLI in particular.

Post reply on HN