5 ms·

Not a chance. We are going hard on rust in 2021 after some very successful projects in 2019 and 2020. our engineers have ramped up on the language - and we have

by jhgg 6y ago

Not a chance. We are going hard on rust in 2021 after some very successful projects in 2019 and 2020. our engineers have ramped up on the language - and we have good support internally (both in terms of tools, but also knowledge) to see its success. Once you've passed the learning curve - imo, rust is far easier and more productive to write than go - especially if you know how to leverage the type system to build idiomatic code and apis that are very hard to use incorrectly. Every piece of rust code we have shipped to production so far has gone perfectly thanks to the really powerful compile time checks and guarantees of the language. I can't say the same for our experiences with go. Our reasons go well beyond "oh the gc in go has given us problems" but more like "go as a language has willingly ignored and has rejected advances in programming languages". You can pry those algebraic data types, enums, borrow checker, and compile time memory management/safety, etc... from my cold dead hands. And for network programming - I've been incredibly delighted with the power and flexibility of rusts futures combined with tokio. The fact that you can just drop a future to cancel it, as opposed to having to thread around a ctx which may or may not work has been amazing.

Thaxll 6y ago
So there is also no point keep using Elixir then.
- jhgg 6y ago
  We will continue to use beam/otp where it makes sense. In fact some rust runs in BEAM now thanks to Rustler. We wrote a blog about this! https://blog.discord.com/using-rust-to-scale-elixir-for-11-million-concurrent-users-c6f19fc029d3 https://blog.discord.com/using-rust-to-scale-elixir-for-11-m...
  - Thaxll 6y ago
    You said that Go doesn't have: algebraic data types, enums, borrow checker, and compile time memory management/safety which Erlang / Elixir is even worse in some of those because it's a dynamic typed language so it's a bit confusing.
    - jhgg 6y ago
      I think you're missing the point. We use Elixir to solve one class of problems which its excellent in doing (notably: real time distributed systems.) In this area, there is nothing even remotely close in terms of capability. So, we choose the runtime over the language (elixir is a pretty cool dynamic language though!). Also, due to the unique nature of Erlang/Elixir, a lot of problems that exist in C/C++/Rust/Go don't exist in that language. Of course this has meant writing a lot more tests to test things that a typechecker should be able to catch. But it is what it is. We're following Gleam though to see where that ends up. BTW, here's some places I've spoken about Discord's Elixir usage: - a podcast: https://smartlogic.io/podcast/elixir-wizards/s5e8-nowack-heinz/ https://smartlogic.io/podcast/elixir-wizards/s5e8-nowack-hei... - interview with José Valim (elixir's creator): https://elixir-lang.org/blog/2020/10/08/real-time-communication-at-scale-with-elixir-at-discord/ https://elixir-lang.org/blog/2020/10/08/real-time-communicat...
      - jaytaylor 6y ago
        Gleam looks like a very promising language! I hadn't seen it before. https://gleam.run/book/tour/try.html https://gleam.run/book/tour/try.html It also looks like there are currently some serious limitations: https://github.com/gleam-lang/otp https://github.com/gleam-lang/otp
    - c-cube 6y ago
      I think a difference is that Elixir is deliberately dynamically typed, so you don't expect type safety. You write the happy path and rely on "fail fast" and the actor hierarchies to write robust code. Besides, Elixir/Erlang has the best dynamically-typed equivalent of algebraic types (tuples + atoms + pattern matching) :-)
aaomidi 6y ago
I agree, rust is so much easier once you've passed that learning curve. Not having to worry if this random reference you're using has been overwritten somewhere else in the code is absolutely refreshing. It allows me to bring back the mental map of my code and the variables to the exact scope I'm writing in. This is an underrated feature of rust. Especially for newer devs who do not have that mental map of the code yet, and are worried that any small change they make might cause cascading failures. That's just something you don't think about in Rust.
tschellenbach 6y ago
Those reasons make much more sense than the GC focus of the blogpost. Definitely a lot of nice features in Rust.
- phabora 6y ago
  The GC was apparently the reason behind rewriting that particular service. No wonder there are more reasons when you look at all the services across the company. But you couldn’t help yourself even after being corrected by someone who knows what they’re talking about.
ngrilly 6y ago
> rust is far easier That's an unusual claim :) Could you elaborate? How is the learning curve, especially for fresh graduates who have been trained only on languages like C, Java and Python? > The fact that you can just drop a future to cancel it, as opposed to having to thread around a ctx which may or may not work has been amazing. Agreed. I like Go, but that's big drawback of goroutines and threads.
- chayleaf 6y ago
  In my experience, Rust puts many costs upfront, which makes it harder to do stuff when you aren't used to doing it the Rust way, but makes it easier to get it right if you are used to Rust. It basically gives you a relatively strong guarantee that if your code compiles and has no warnings, it's mostly collect - yes, that includes logic errors to some extent thanks to the type system. That also makes refactoring easier - chances are, the bugs you possibly added by refactoring will get caught by the compiler. Obviously, that's not a complete replacement for testing, but it does reduce the amount of tests you need to write to ensure correctness. Frankly, I don't consider myself a particularly good programmer - but when I use Rust, I feel confident because of being backed by the compiler. That's something I can't say about any other language, and I only have less than a year of Rust experience compared to 5 years of total experience programming. Imo Rust is easier to master than other languages, but it's definitely harder to do basic stuff in it because of the upfront costs I mentioned.
- marcosdumay 6y ago
  A language being easy to write has no relation at all with it being easy to learn.
- xiphias2 6y ago
  How would a fresh graduate be able to write safe C code when even experienced people are unable to? I have worked with multi-threaded C++ code long enough to see that it's impossible to work in a team while keeping the code safe. Usually servers crash and canaries catch it in production, but if we have type system improvements that solve these problem, why not take advantage of it?
- 6y ago
deleted 6y ago
[deleted]
jimbokun 6y ago
When I read descriptions like yours, Rust sounds like the language delivering on the promises of Haskell in the Real World.
- marcosdumay 6y ago
  Some promises of Haskell. Rust is still a very low level language, but if you like Haskell, you won't go into anything else when writing some low level program.
  - xiphias2 6y ago
    Haskell overpromised a lot. When I looked at it, the favourite quicksort example was so elegant, I wanted to learn the language. Then after I started looking at the run time (after wasting a lot of time going through learning Haskell), I realized that it was all a lie, ant that sort wasn't quick at all. I don't see the same overpromising problems with Rust: you usually get the performance that you think you will get when you're writing the code.
    - travv0 6y ago
      So let me get this straight: You don't like Haskell because someone used it to write an inefficient quicksort example online?
      - xiphias2 6y ago
        Not somebody, it was on the home page as a use case of how much better Haskell is than other languages. The default libraries are extremely inefficient. Generally if I use Python/Ruby I can get a 50x slow down that is accepted, but with Haskell it can be more, as it's very hard to think about what the compiler does (memory usage can blow up easily).
        reddit_clone 6y ago
        To be fair, that code is to illustrate the beauty of the language rather than efficiency. (Also the fibonacci sequence using 'zip'. Blew my mind.) Haskell folks are fairly upfront about possible performance issues. Lazy evaluation comes with its own set of tradeoffs. You can write very inefficient code in C++ if your algorithm isn't efficient.

by jhgg 6y ago

Thaxll 6y ago

So there is also no point keep using Elixir then.

jhgg 6y ago
We will continue to use beam/otp where it makes sense. In fact some rust runs in BEAM now thanks to Rustler. We wrote a blog about this! https://blog.discord.com/using-rust-to-scale-elixir-for-11-million-concurrent-users-c6f19fc029d3 https://blog.discord.com/using-rust-to-scale-elixir-for-11-m...
- Thaxll 6y ago
  You said that Go doesn't have: algebraic data types, enums, borrow checker, and compile time memory management/safety which Erlang / Elixir is even worse in some of those because it's a dynamic typed language so it's a bit confusing.
  - jhgg 6y ago
    I think you're missing the point. We use Elixir to solve one class of problems which its excellent in doing (notably: real time distributed systems.) In this area, there is nothing even remotely close in terms of capability. So, we choose the runtime over the language (elixir is a pretty cool dynamic language though!). Also, due to the unique nature of Erlang/Elixir, a lot of problems that exist in C/C++/Rust/Go don't exist in that language. Of course this has meant writing a lot more tests to test things that a typechecker should be able to catch. But it is what it is. We're following Gleam though to see where that ends up. BTW, here's some places I've spoken about Discord's Elixir usage: - a podcast: https://smartlogic.io/podcast/elixir-wizards/s5e8-nowack-heinz/ https://smartlogic.io/podcast/elixir-wizards/s5e8-nowack-hei... - interview with José Valim (elixir's creator): https://elixir-lang.org/blog/2020/10/08/real-time-communication-at-scale-with-elixir-at-discord/ https://elixir-lang.org/blog/2020/10/08/real-time-communicat...
    - jaytaylor 6y ago
      Gleam looks like a very promising language! I hadn't seen it before. https://gleam.run/book/tour/try.html https://gleam.run/book/tour/try.html It also looks like there are currently some serious limitations: https://github.com/gleam-lang/otp https://github.com/gleam-lang/otp
  - c-cube 6y ago
    I think a difference is that Elixir is deliberately dynamically typed, so you don't expect type safety. You write the happy path and rely on "fail fast" and the actor hierarchies to write robust code. Besides, Elixir/Erlang has the best dynamically-typed equivalent of algebraic types (tuples + atoms + pattern matching) :-)

aaomidi 6y ago

I agree, rust is so much easier once you've passed that learning curve. Not having to worry if this random reference you're using has been overwritten somewhere else in the code is absolutely refreshing. It allows me to bring back the mental map of my code and the variables to the exact scope I'm writing in. This is an underrated feature of rust. Especially for newer devs who do not have that mental map of the code yet, and are worried that any small change they make might cause cascading failures. That's just something you don't think about in Rust.

tschellenbach 6y ago

Those reasons make much more sense than the GC focus of the blogpost. Definitely a lot of nice features in Rust.

phabora 6y ago
The GC was apparently the reason behind rewriting that particular service. No wonder there are more reasons when you look at all the services across the company. But you couldn’t help yourself even after being corrected by someone who knows what they’re talking about.

ngrilly 6y ago

> rust is far easier That's an unusual claim :) Could you elaborate? How is the learning curve, especially for fresh graduates who have been trained only on languages like C, Java and Python? > The fact that you can just drop a future to cancel it, as opposed to having to thread around a ctx which may or may not work has been amazing. Agreed. I like Go, but that's big drawback of goroutines and threads.

chayleaf 6y ago
In my experience, Rust puts many costs upfront, which makes it harder to do stuff when you aren't used to doing it the Rust way, but makes it easier to get it right if you are used to Rust. It basically gives you a relatively strong guarantee that if your code compiles and has no warnings, it's mostly collect - yes, that includes logic errors to some extent thanks to the type system. That also makes refactoring easier - chances are, the bugs you possibly added by refactoring will get caught by the compiler. Obviously, that's not a complete replacement for testing, but it does reduce the amount of tests you need to write to ensure correctness. Frankly, I don't consider myself a particularly good programmer - but when I use Rust, I feel confident because of being backed by the compiler. That's something I can't say about any other language, and I only have less than a year of Rust experience compared to 5 years of total experience programming. Imo Rust is easier to master than other languages, but it's definitely harder to do basic stuff in it because of the upfront costs I mentioned.
marcosdumay 6y ago
A language being easy to write has no relation at all with it being easy to learn.
xiphias2 6y ago
How would a fresh graduate be able to write safe C code when even experienced people are unable to? I have worked with multi-threaded C++ code long enough to see that it's impossible to work in a team while keeping the code safe. Usually servers crash and canaries catch it in production, but if we have type system improvements that solve these problem, why not take advantage of it?
6y ago

deleted 6y ago

[deleted]

jimbokun 6y ago

When I read descriptions like yours, Rust sounds like the language delivering on the promises of Haskell in the Real World.

marcosdumay 6y ago
Some promises of Haskell. Rust is still a very low level language, but if you like Haskell, you won't go into anything else when writing some low level program.
- xiphias2 6y ago
  Haskell overpromised a lot. When I looked at it, the favourite quicksort example was so elegant, I wanted to learn the language. Then after I started looking at the run time (after wasting a lot of time going through learning Haskell), I realized that it was all a lie, ant that sort wasn't quick at all. I don't see the same overpromising problems with Rust: you usually get the performance that you think you will get when you're writing the code.
  - travv0 6y ago
    So let me get this straight: You don't like Haskell because someone used it to write an inefficient quicksort example online?
    - xiphias2 6y ago
      Not somebody, it was on the home page as a use case of how much better Haskell is than other languages. The default libraries are extremely inefficient. Generally if I use Python/Ruby I can get a 50x slow down that is accepted, but with Haskell it can be more, as it's very hard to think about what the compiler does (memory usage can blow up easily).
      - reddit_clone 6y ago
        To be fair, that code is to illustrate the beauty of the language rather than efficiency. (Also the fibonacci sequence using 'zip'. Blew my mind.) Haskell folks are fairly upfront about possible performance issues. Lazy evaluation comes with its own set of tradeoffs. You can write very inefficient code in C++ if your algorithm isn't efficient.