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

161–170 of 302 posts

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

#161

Post by pessimizer »

01acheru wrote: post #42
Xeoncross wrote: post #17

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

Probably Erlang because of Whatsapp, IIRC it's backend was written in Erlang.

And they actually moved to Erlang for chat before Whatsapp, around when they hired https://yarivsblog.blogspot.com/

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

#162

Post by rich_sasha »

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

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 .

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

#163

Post by pjmlp »

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…

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.

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

#164

Post by packetslave »

antholeole wrote: post #50
Xeoncross wrote: post #17

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

Hack because?

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.

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

#165

Post by rich_sasha »

vaylian wrote: post #145
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…

Interesting to hear this from a Nim developer. Do you think Nim would be a good fit for what facebook needs? (Normally I don't check author's names in hacker news comments. But I wanted to check if this is WalterBright posting here)

That's what crossed my mind too.

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.

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

#166

Post by Xeoncross »

louthy wrote: post #56
Xeoncross wrote: post #17

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

> Haskell because elitism Was there really a need for this comment? How about: for correctness and expressivity

True, I was going to write something else for Haskell but realized it didn't matter what I put as I'd be called out and corrected regardless.

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

#167

Post by uaksom »

meitros wrote: post #154
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

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

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

#168

Post by int_19h »

ActorNightly wrote: post #80
melling wrote: post #30

“Since we began our journey with Rust, the number of projects using Rust inside Meta has increased at an accelerated rate” That almost sounds like an endorsement. I’ve been holding off learning Rust. However, it seems like Rust adoption is reaching a tipping point.

Yep, and its pretty much going to become the next C++ - i.e widely adopted at first, and driven into a shit state. Specifically because of this 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 ev…

This needs to exist in order for the Rust standard library to be written in Rust.

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

#169

Post by ayewo »

hunterb123 wrote: post #113
AtNightWeCode wrote: post #110

Earlier quoted context omitted.

They have changed the algo. Several pro photographers and photograph artists have confirmed this.

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.

> … but the habits of people have changed.

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?

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

#170

Post by nindalf »

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

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

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?

Post reply on HN