Live data from Hacker News

Why Discord is switching from Go to Rust

blog.discordapp.com

371–380 of 670 posts

Re: Why Discord is switching from Go to Rust

#371
post #326

Earlier quoted context omitted.

Rust's type system is more expressive than Java's so you can end up with much nicer to read code with stricter and more obvious invariants. There also tends to be way less of the `EnterpriseJavaBeanFactory`-style code in idiomatic Rust.

Trolling is fun and all, but I wouldn’t say Rust’s type system that much more advanced than Java’s. The borrow checker definitely helps to catch errors, but I would rate them at basically the same level.

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, Rust traits and generics are a lot more powerful than anything Java has. For example Rust generics support associated types. E.g. the Iterator trait has an associated type Item:

trait Iterator { type Item; ... }

You can now write code that's generic over Iterator, and refers to its Item type:

fn first(iter: I) -> I::Item { iter.next().unwrap() }

Toy example, but associated types are really important.

Rust traits and generics are more powerful in other ways too. E.g. in Rust you can do anything with a generic type, unlike Java where type erasure means you can't write 'new T' etc.

Re: Why Discord is switching from Go to Rust

#372

Earlier quoted context omitted.

Rust has it's lot of weird hacks too. E.g array can take traits impls only if they have less than 32 elements... https://doc.rust-lang.org/std/array/trait.LengthAtMost32.htm...

That's… not that at all. You can absolutely implement traits for arrays of more than 32 elements[0]. It is rather that due to a lack of genericity (namely const generics) you can't implement traits for [T;N], you have to implement them for each size individually. So there has to be an upper bound somehow[1], and the stdlib developers arbitrarily picked 32 for stdlib traits on arrays. A not entirely dissimilar limit t…

Also worth noting that Rust's const generics support has progressed to the point that the stdlib is already using them to implement the standard traits on arrays; the 32-element issue still technically exists, but only because the stdlib is manually restricting the trait implementation so as to not accidentally expose const generics to stable Rust before const generics is officially stabilized.

Re: Why Discord is switching from Go to Rust

#373
post #299

I chose Rust over Go after weighing the pros and cons. It was an easy decision. I wouldn't consider using a high level language that lacks generics. The entire point of using a high level language is writing less code.

The syntax looks pedantic to me. Going to require some adjusting.

Re: Why Discord is switching from Go to Rust

#374

You're switching to Rust because Go is too slow? Colour me sceptical, but this seems more like an excuse to adopt a trendy language than a considered technical decision. Rust is designed first and foremost for memory safety, and it sacrifices a lot of developer time to achieve this, so if memory safety isn't high in your list of concerns Rust is probably not going to bring many benefits.

The goals of Rust are stated boldly right on the official website - "Performance" is one of them. In Discord's case, the hit in productivity was worth avoiding the GC issues in Go. I read the article and didn't come to the same conclusion, so I'm curious which passages led you to believe this was done to "adopt a trendy language"?

Performance is not the core raison d'etre of Rust, and there are no shortage of testimonials to the difficulty new developers have with it, not to mention the slowness of its compiler. Given that, it's too much of a leap for me to get from "GC is too slow in Go" to "rewrite in Rust", at least when considered as a purely technical decision. There is no mention, for instance, of what other languages were considered. My guess is none were considered. Finally, the author states that Discord pride themselves in embracing new things, and cites having to work with the nightly build of the compiler to get async. All of this tells me that they chose Rust for non-technical reasons and were prepared to jump through all kinds of hoops to make it work. Which is fine, it's their business to run however they want, but I find the premise that Rust is an obvious choice for speed entirely unpersuasive. In most businesses, introducing unstable nightly builds of compilers to build production services would be a major red flag.

Re: Why Discord is switching from Go to Rust

#375
post #306

Earlier quoted context omitted.

Most development jobs on products that matter involve working on large established code bases. Many people get satisfaction from knowing that their work matters to end users, even if it's not writing new things in the new shiny language or framework. Referring to these people as "janitors" is pretty damn demeaning, and says more about you than the actual job. Rewrites are rarely the right call, and doing simply to en…

>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.

Re: Why Discord is switching from Go to Rust

#376
post #32

Earlier quoted context omitted.

It does sound like Discord's case was fairly extraordinary in terms of the degree of the spike: > We kept digging and learned the spikes were huge not because of a massive amount of ready-to-free memory, but because the garbage collector needed to scan the entire LRU cache in order to determine if the memory was truly free from references. So maybe this is one of those things that just doesn't come up in most cases?…

Heap caches that keep things longer than a GC cycle are terrible under GC unless you have a collector in the new style like ZGC, Azul or Shenandoah.

What feature of "the new style" makes them more suitable in this case?

Re: Why Discord is switching from Go to Rust

#377
post #177

Earlier quoted context omitted.

100%. In Java, you would often use OpenHFT's ChronicleMap for now and hopefully inline classes/records in Java 16 or so.

Ehcache has an efficient off-heap store: https://github.com/Terracotta-OSS/offheap-store/ Doesn't Go have something like this available? It's an obvious thing for garbage-collected languages to have.

You can usually resort to `import C` and using `C.malloc` to get an unsafe.Pointer.

Re: Why Discord is switching from Go to Rust

#378

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…

Right tool for the job should also take into account the experience of the devs you have at your disposal. For an omniscient Dev, is Rust the best tool for the job? Unsure. But for them with already significant rust experience? Sounds like it.

Re: Why Discord is switching from Go to Rust

#379
post #371

Earlier quoted context omitted.

Trolling is fun and all, but I wouldn’t say Rust’s type system that much more advanced than Java’s. The borrow checker definitely helps to catch errors, but I would rate them at basically the same level.

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…

BTW I'm not knocking Java here. Java's simpler type system is actually great for the applications I think Java is good for --- business logic and simple mobile apps, the COBOL of the 21st century.

Well, except that Java went ahead and gratuitously complicated their type system with wildcards. That was crazy.

Re: Why Discord is switching from Go to Rust

#380

Earlier quoted context omitted.

Everything I've read indicates that RAM caches work poorly in a GC environment. The problem is that garbage collectors are optimized for applications that mostly have short-lived objects, and a small amount of long-lived objects. Things like large in-RAM LRU are basically the slowest thing for a garbage collector to do, because the mark-and-sweep phase always has to go through the entire cache, and because you're con…

A high number of short lived allocations is also a bad thing in a compacting GC environment, because every allocation gets you a reference to a memory region touched very long time ago and it is likely a cache miss. You would like to do an object pool to avoid this but then you run into a pitfall with long living objects, so there is really no good way out.

???

The allocation is going to be close to the last allocation, which was touched recently, no? The first allocation after a compaction wii be far from recent allocations, but close to the compacted objects?

Post reply on HN