Live data from Hacker News

Programming languages endorsed for server-side use at Meta

engineering.fb.com

191–200 of 302 posts

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

#191
post #69
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.

Not that you need to be a fan, but what are your reasons for not liking Rust? As a Rust developer, I'm always curious.

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.

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

#192
post #175

Earlier quoted context omitted.

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.

You can have a look at its issues, https://github.com/microsoft/windows-rs Note the lack of of safe wrappers for Windows APIs, and still no good way to create the Windows Runtime objects necessary to interoperate with XAML. Also the basic examples with very little UI code on what is supposed to be a projection for a Windows UI framework.

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.

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

#193
post #157

Earlier quoted context omitted.

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.

That would be pretty close to OCaml.

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

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

> I’ve been holding off learning Rust. 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 un…

> Rust is quite an easy language to learn

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.

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

#196
post #142

Earlier quoted context omitted.

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

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

#197
post #67
post #20

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

Does it make sense to adopt hack outside of FB? I never even heard of it before.

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

#198
post #106

Earlier quoted context omitted.

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

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

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

#199

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

> Erlang because stability. Maybe because of WhatsApp acquisition ? Some services might still be running in Erlang. Last I heard, Erlang was being replaced by C++. > Haskell because elitism. Haxl used to be a project at FaceBook, not sure what Haskell is used for now there. Thoughts as an outsider. I dont work [neither have worked] at Meta.

> Haskell because elitism.

Does anyone know if Simon Marlow is still at Meta and what he works on?

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

#200

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

Hack is a facebook project. Hack was born out of need to improve speed of PHP performance and add a typing discipline.
Post reply on HN