Hacker News Reader

Comment by 0xCMP | Hacker News Reader

Oh, I thought Dropbox was using Rust instead of Go for a lot of things, but maybe they ended up using both. I can see why they'd have wanted to be just moving to either Rust or Go since from what I understand they used to be mostly Python for everything.

Cool that they use Go a lot.

View on HN

Last I checked, server-side Rust usage at Dropbox is reserved for the very bottom of the stack, for the bits that are performance-sensitive enough that the alternative would have demanded they be written in C++. Apparently there's a significant amount of Rust in Dropbox's Windows client as well, though I don't know the story there...

We're making a pretty big bet on Rust in the client (if you'd call it a bet, I don't see a scenario where we walk this back). The majority of new Sync code in the client (read: not UI) is being written in Rust and it's been a blast so far, not to mention much easier to reason about correctness which is really what we care about.

(something something we're hiring)

So does this means that the talks at CppCon are now invalidated and future uses of Djini will see Rust support?

Here is a talk by Jamie Turner of Dropbox about where Rust is used: https://air.mozilla.org/rust-meetup-may-2017/

(I work at Dropbox)

Easier to go from python to go than to rust.

How so? You can extend Python with Rust but you can't with Go. Go requires a complete rewrite or independent service.

You can write go with the same loose nature of Python. Conceptually you can write programs the same and get some speed boost + type checking while you're at it.

It's like a more intense form of adding annotations in theory.

So while it requires a rewrite, a cost which you should not write off either, it can feel similar to Python but more verbose. Where Rust feels like Haskell and C++ had a child together and can be more jarring to switch to (in my experience as primarily Python/Django who uses Go in many side projects and tried Rust up-to and around 1.0).

Thanks for commenting. I think I took the statement too literally. If I understand you correctly, the transition from Python to Go is easier because learning/using Go requires less cognitive overhead than what is required of Python to Rust.

Go and Rust are not competing for same space. They are different language for different purposes.

Rust is multi-purpose, and with improved tooling and a little more maturity (Rust 2.0) I can see it getting all the (network/server) systems and command line stuff Go does.

(But not vice versa: Go wont be able to handle the no-GC close-to-the-metal use cases).

Rust is great, but to be honest, Rust's learning curve is way steeper than GO's. And this may slow down the Rust's domination.

I think the things Rust has had to sacrifice on the altar of zero-cost abstraction (mostly, garbage collection) mean that it will always be harder to use than Go.

The orthogonal fact that it's a much richer language also means that it will always be harder to learn, so Go has advantage in the niche of beginners' language, or second language, particularly for people who mainly work in an untyped language, and so don't already have type system instincts to lean on.

Sure they can be. Rust just isn't able to compete in some areas where Go is objectively easier and better, but they're areas which can be fixed with improved documentation, training, and libraries.

YMMV, but I think people just want something fast, productive, and safe by default. Normally you had to pick just two, but Go gives you 2.5 (Not as safe as it "could be") and Rust only gives you 2 right now (Not as productive, libraries too immature), but it is on it's way to giving all 3 as soon as libraries gain maturity.

Reply on news.ycombinator.com