Hacker News Reader

Comment by jhgg | Hacker News Reader

This blog post perhaps is a bit "after the fact" we had made the switch over mid 2019, and wanted to try out rust as well for services like this, due to adoption elsewhere in the company. Also, after upgrading between 4 golang versions on this service and noticing it didn't materially change performance, we decided to just spend our time on the rewrite (for fun, and latency) and to get a head start into the asynchronous rust ecosystem.

This blog post kinda internally matches our upgrade to std::futures and tokio 0.2, away from futures 0.1.

View on HN

Do you have any load tests or synthetic benchmarks that are still capable of producing this?

It would be interesting to see what a more modern Go would do given there have been a bunch of tail latency GC improvements since your older 1.9 Go version... and in an ideal world, it would be nice to file an issue on the tracker if you were still seeing this.

(Maybe that ends up later helping another one of your Go services, or maybe it just helps the community, or maybe it’s a topic for another interesting blog...).

In any event, thanks for taking the time to write up and share this one.

This comment doesn’t make sense. Didn’t rust not have async back then?

The timelines don’t appear to fit

Tokio and Futures have existed since 2016. I worked on the initial loqui implementation that powers rpc at Discord in raw Futures/Tokio in late 2018. async/await was also on nightly back then. Jesse finished it and migrated it to async/await and later used that as the basis for Read States. The timelines make perfect sense.

Alright. I stand corrected. I used Go back when it was beta, but it never stuck with me. I still like it for small script like tasks. I also happen to think Rust is amazing. The learning curve kept me away for a while.

It would still be interesting to see them post how go > 1.12 would do since it no longer has stop the world garbage collection.

Out of curiosity, why didn't you choose Kotlin? It can reuse the Java ecosystem which allow you to save tons of money, and give you advanced features and scalability. It is a sexier and more ergonomic language too. And with e.g ZGC, you can have a GC that is fine tunable, and that has very low latency.

By choosing rust you will suffer a great deal of the limitations of it's poor, not production ready, ecosystem. I'm not even talking about the immaturity of the async await support.

More people at our company know Rust than Kotlin. It's used across multiple teams (from our game SDK, native encoder/capture pipeline, chat infra team for Erlang rust NIFs.) where as Kotlin is only used by our android team.

We are willing to adopt early technologies we think are promising, and contribute to or fund projects to continue to advance the ecosystem. Yes, this means the path less traveled, but in the case of rust (and in the past Elixir, and even React Native) we think the trade offs are worth it.

Also the tokio team uses Discord for their chat stuff, so it's nice to pop in to be able to ask for and offer help.

> By choosing rust you will suffer a great deal of the limitations of it's poor, not production ready, ecosystem.

Why do you think that? Seems like Rust is a great choice for this type of high performance work.

Rust does best when the number of lines of code that must be parsed in an edit-compile-test loop is small. When the sources that must be parsed get large, coders suffer.

It is doubtful that this will improve, much, without breaking changes to the language. The range of code over which type inference operates, or at least programmers' reliance on it, would need to contract by quite a lot. There would be Complaints.

Type inference only operates within function bodies. It's also not the thing that causes compilation to be slow.

Ecosystem is a real problem, but motivated engineers will make it work no matter what. I mean, banks run on COBOL.

Besides, I am willing to bet idiomatic rust is 2x-10x faster than idiomatic kotlin.

Then that motivation should be applicable to Go as well.

> you can have a GC

But can I not have it?

Yes. You can have a no-op collector

> I'm not even talking about the immaturity of the async await support.

The one that is 100% more mature than the Java async/await support?

Kotlin has coroutines, actors, lazy and reactive programming.

Reply on news.ycombinator.com