Live data from Hacker News

Why Discord is switching from Go to Rust

blog.discordapp.com

401–410 of 670 posts

Re: Why Discord is switching from Go to Rust

#401

Tokio author here (mentioned in blog post). It is really great to see these success stories. I also think it is great that Discord is using the right tool for the job. It isn't often that you need the performance gains that Rust & Tokio so pick what works best to get the job done and iterate.

No offense to Tokio and Rust, I really like Rust, but having someone rewriting their app because of performance limitations in their previous language choice, isn’t really someone picking the right tool for the job necessary. I’m not so sure they would have done the rewrite if the Go GC was performing better, and the choice of Rust seems primarily based on prior experience at the company writing performance sensitive…

Correct. They wouldn't have considered Rust if the GC was performing better. They also wouldn't have even adopted Go if Elixir was sufficient. This team seems to have an incredible talent pool who is willing to push further for the sake of, as you say, delivering business value. Improving UX, investing in capabilities for growth, are valid business reasons why they're iterating over so many solutions. It's really impressive to see what they're accomplishing.

Re: Why Discord is switching from Go to Rust

#402
post #109

Earlier quoted context omitted.

Think replacing elixir with Rust would ever be a consideration? Rust isn't there yet, but if you are NIF'ing a bunch of stuff, seems like it could make sense at some point?

I Googled around, but couldn't find the answer. What is "NIF"?

https://erlang.org/doc/man/erl_nif.html

Short: ffi for erlang.

Re: Why Discord is switching from Go to Rust

#403
post #203

Earlier quoted context omitted.

Because many services eventually become performance bottlenecked either via accumulation of users or accumulation of features. In either case eventually performance becomes very critical.

Sure, but that doesn't make Go unsuitable for those tasks on a fundamental basis. Go is very high performance. Whether Go or another language is the best match very much depends on the problem at hand and the especial requirements. Even in the described case they might have tweaked the GC to fit their bill.

GC pauses aside can Go match the performance of Rust when coded properly? Would sorting an array of structs in Go be in the same ballpark as sorting the same sized array of structures in Rust? I don't know a whole lot about how Go manages the heap under the covers.

Re: Why Discord is switching from Go to Rust

#404
post #298

Earlier quoted context omitted.

Keeping LRU cache that large with these performance requirements is not a "most people's problem". Go is actually great to solve most people's problem with web servers, while Rust is better for edge cases.

> Keeping LRU cache that large with these performance requirements is not a "most people's problem". Sure, but that's not what I said. Any program of sufficient complexity will run into at least one critical problem that isn't a "most people's problem". A well-written general-purpose language implementation will have been written in such a way that that problem isn't totally intractable. > Go is actually great to sol…

> Give it a few years and similar toolsets will be invented for Go, I'm sure.

Go 1.0 is nearly 8 years old at this point, and these toolsets have existed for years.

Re: Why Discord is switching from Go to Rust

#405
post #398

Earlier quoted context omitted.

No offense to Tokio and Rust, I really like Rust, but having someone rewriting their app because of performance limitations in their previous language choice, isn’t really someone picking the right tool for the job necessary. I’m not so sure they would have done the rewrite if the Go GC was performing better, and the choice of Rust seems primarily based on prior experience at the company writing performance sensitive…

too much focus on "business value" often ends-up with codebase in a state that makes delivery of that business value pretty impossible. Boeing was delivering a lot of business value with MAX ...

[deleted]

Re: Why Discord is switching from Go to Rust

#406
post #371

Earlier quoted context omitted.

Rust's type system is definitely much more powerful, even ignoring borrowing. Rust's affine (ownership) types add a lot of power. They make it possible for APIs to take ownership of a passed-in object and guarantee no other references to it exist. For example this lets you manually deallocate resources (e.g. close a File), while preserving the invariant that if you have a reference to a File, then it is open. Also, R…

Sure, but generics are available in Java as well and compared to Haskell and similar language I rate Rust as closer to Java.

Rust's generics are much more powerful. You can do type level programming, e.g. : https://docs.rs/peano/1.0.2/peano/

There's an interesting comparison of Rust and Haskell's type system here: https://www.reddit.com/r/rust/comments/4jh8hv/question_about... I guess it's just a matter of opinion about what sorts of differences you think are significant vs not.

Re: Why Discord is switching from Go to Rust

#407
post #371

Earlier quoted context omitted.

Rust's type system is definitely much more powerful, even ignoring borrowing. Rust's affine (ownership) types add a lot of power. They make it possible for APIs to take ownership of a passed-in object and guarantee no other references to it exist. For example this lets you manually deallocate resources (e.g. close a File), while preserving the invariant that if you have a reference to a File, then it is open. Also, R…

Sure, but generics are available in Java as well and compared to Haskell and similar language I rate Rust as closer to Java.

I think most people would rate Rust as being closer to Haskell than Java at the type level.

Rust traits are very much like Haskell type classes. Java gives you classic OOP, but neither Rust nor Haskell do.

Rust generics are much more like Haskell generics than Java generics. Rust and Haskell both have associated types, Java doesn't. Java generics are crippled due to type erasure; Rust and Haskell don't have those limitations.

Rust and Haskell generics support a lot of type-level computation; Java doesn't.

Rust and Haskell don't have ubiquitous nullable-by-default values; Java does.

Rust and Haskell have discriminated sum types; Java doesn't.

The only way I think Rust is more like Java than Haskell at the type level is that Haskell has higher-kinded types and Rust/Java don't. There are plans to fix this in Rust though.

Re: Why Discord is switching from Go to Rust

#409

Earlier quoted context omitted.

> Since the whole point of the region is that the GC doesn't scan it, nothing in the region will be able to keep anything outside the region alive. You can treat external references as GC roots.

How do you know that they exist, if you're not scanning that memory?

The data structure code can take care of this by registering GC roots with the garbage collector (and de-registering them if an external reference changes). It's no different in principle than any other smart pointer.

Re: Why Discord is switching from Go to Rust

#410
post #375

Earlier quoted context omitted.

>Referring to these people as "janitors" is pretty damn demeaning, "Referring to the term of "janitors" as demeaning is pretty demeaning and says more about you than your judgement of the parent." I don't like this rhetoric device you just used. Also, I think that janitors do important work as well.

Let's not fool ourselves. The demeaning of janitors was introduced by GP by describing it as something they would rather not do. No mental gymnastics required.

He said he felt like a janitor, next guy said he demeaned others as janitors, and now you are saying he demeaned janitors. There is a level of gymnastics going on.
Post reply on HN