Live data from Hacker News

Programming languages endorsed for server-side use at Meta

engineering.fb.com

201–210 of 302 posts

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

#201
post #196
post #142

Earlier quoted context omitted.

I believe you're thinking of Project Verona. https://www.microsoft.com/en-us/research/project/project-ver...

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. They used to have this great site were you could interact with them all: https://web.archive.org/web/20180130101736/https://www.rise4... Source: I'm a former member of RiSE

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.

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

#202

Earlier quoted context omitted.

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.

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

grep inner loops are coded straight in Assembly. So Rust would be a poor fit.

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

#203
post #56

Earlier quoted context omitted.

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

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.

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

#204

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 am surprised too. If your number one problem is short deadlines, using Go is simply more obvious for CLI.

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

#205

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…

If you have organizational backing, it is not hard to use C++ because the company would have already standardized on libraries like Boost and Folley.

And the company would already have a build farm.

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

#206
post #56

> 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

Haskell's runtime performance is unethical from a carbon perspective.

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

#207
post #202

Earlier quoted context omitted.

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

grep inner loops are coded straight in Assembly. So Rust would be a poor fit.

Yet ripgrep is extremely fast, often faster than grep. Practice beats theory.

(Rust can also do in-line assembly…)

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

#208

Earlier quoted context omitted.

Curius why people downvote this.. its a perfect valid argument.

Because it's not an argument, it's just lazily recycling language tropes. > Rust is immature I recuse myself due to fanboyism. > C++ is intractable Except to all the firms and people successfully using it. > Python is fundamentally unusable at scale Except to all the firms and people successfully using it.

> I recuse myself due to fanboyism.

No true fanboy would ever say that ;)

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

#209

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

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.

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

#210
post #198

Earlier quoted context omitted.

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…

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

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.

Post reply on HN