8 ms·

Why would they switch to rust, rather than upgrading from 3 years old version?

jhgg 7y ago
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.
- The_rationalist 7y ago
  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.
  - therockhead 7y ago
    > 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.
    - ncmncm 7y ago
      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.
      - steveklabnik 7y ago
        Type inference only operates within function bodies. It's also not the thing that causes compilation to be slow.
  - jhgg 7y ago
    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.
  - mping 7y ago
    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.
    - codehalo 7y ago
      Then that motivation should be applicable to Go as well.
  - kaoD 7y ago
    > you can have a GC But can I not have it?
    - qw 7y ago
      Yes. You can have a no-op collector
  - jen20 7y ago
    > 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?
    - The_rationalist 7y ago
      Kotlin has coroutines, actors, lazy and reactive programming.
- graphememes 7y ago
  Shiny toy syndrome, basically.
- The_rationalist 7y ago
  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 So you basically don't read release changelogs of the slow iterating language like go, yet have the double standard of keeping up with rust nightly? Because Go 1.12 explicitly mention performance improvements to it's GC. You just wanted to do it "for fun" (but is rust and it' s immature ecosystem with all it's issues that fun?). This blog is dishonest and show amateurism at discord. BTW it's not too late, prove us right or wrong by benchmarcking latest Go GC vs rust.
- crystaldev 7y ago
  > to get a head start into the asynchronous rust ecosystem. Sounds resume-driven.
- typical182 7y ago
  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.
- jamra 7y ago
  This comment doesn’t make sense. Didn’t rust not have async back then? The timelines don’t appear to fit
  - gmjosack 7y ago
    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.
    - jamra 7y ago
      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.

jhgg 7y ago

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.

The_rationalist 7y ago
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.
- therockhead 7y ago
  > 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.
  - ncmncm 7y ago
    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.
    - steveklabnik 7y ago
      Type inference only operates within function bodies. It's also not the thing that causes compilation to be slow.
- jhgg 7y ago
  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.
- mping 7y ago
  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.
  - codehalo 7y ago
    Then that motivation should be applicable to Go as well.
- kaoD 7y ago
  > you can have a GC But can I not have it?
  - qw 7y ago
    Yes. You can have a no-op collector
- jen20 7y ago
  > 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?
  - The_rationalist 7y ago
    Kotlin has coroutines, actors, lazy and reactive programming.
graphememes 7y ago
Shiny toy syndrome, basically.
The_rationalist 7y ago
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 So you basically don't read release changelogs of the slow iterating language like go, yet have the double standard of keeping up with rust nightly? Because Go 1.12 explicitly mention performance improvements to it's GC. You just wanted to do it "for fun" (but is rust and it' s immature ecosystem with all it's issues that fun?). This blog is dishonest and show amateurism at discord. BTW it's not too late, prove us right or wrong by benchmarcking latest Go GC vs rust.
crystaldev 7y ago
> to get a head start into the asynchronous rust ecosystem. Sounds resume-driven.
typical182 7y ago
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.
jamra 7y ago
This comment doesn’t make sense. Didn’t rust not have async back then? The timelines don’t appear to fit
- gmjosack 7y ago
  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.
  - jamra 7y ago
    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.