Hacker News Reader

Comment by sportanova | Hacker News Reader

A little late, but why not Rust? Not the right libraries? I would think no gc would be one of the biggest factors

CockroachDB engineer here. Rust would definitely be a contender if we were starting the project today (we have several rust fans on the team), but when the project was started in early 2014 it wasn't ready yet. The language was still changing too much to make such an investment in (they hadn't even removed the @ and ~ pointer syntax from the language yet).

Longtime Rust developer here. You definitely made the right choice, it would have been a pretty big risk to bet a startup on rust back in 2014 if you didn't have the freedom to keep up to date with the breaking changes. Crazy people like me had a lot fun seeing the language evolve in realtime, but it certainly would have been stress-inducing if I was betting my livelihood on it.

Now that we're stable, please let us know if you plan on experimenting with Rust. We'd love to hear how it goes (I run the SF meetups and am always looking for speakers), and what we can do to help. One of our short/medium term goals is to make some high quality bindings to other languages, so that projects like yours could slowly introduce Rust where it makes sense.

They started the project long before Rust was stable and even today the Rust ecosystem is still lacking some libraries (understandably).

The performance potential is real but not free as the productivity isn't as good.

I've often read stories about fast refactors from Python or PHP to Go. I wonder if that would translate to a reasonably fast refactor to Rust later on, if that should become necessary or desirable.

My experience is that refactoring from a garbage-collected language to a non-garbage-collected language are slow.

Rust is different enough as non-GC'ed languages go that I'd be interested in someone's experience, whenever they have it. I could easily see it being easier or harder than trying to convert to a "conventional" language. Heck, I could even see it sort of being both, where the conversion takes longer because the compiler keeps complaining but the final outcome is solid almost instantly.

I've done a port of a small amount of code (not a full project) from lisp to Rust; it really doesn't work, as Rust's ownership semantics and circular references are somewhat orthogonal.

Also lisp is in an odd position where it has influence from functional style, but at the same time expects to have mutability always available, while Rust wants mutability to be constrained to known dynamic extents.

Using Go is a Google acquihire hedge. :)

I think that someone building a product on Rust is taking a very long view and has to make an investment in the development of the language or they are at the mercy of the changes and lack of libraries.

But seriously, why not Nim?

At the time it would suffer from the same problems as Golang (GC) and Rust (not stable, few libraries around).

Reply on news.ycombinator.com