Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Discord is switching from Go to Rust

blog.discordapp.com

Post reply on HN
Print view View original

381–390 of 670 posts

Re: Why Discord is switching from Go to Rust

#381

Post by sreque »

stingraycharles wrote: post #275
the-alchemist wrote: post #96

Looks like the big challenge is managing a large, LRU cache, which tends to be a difficult problem for GC runtimes. I bet the JVM, with its myriad tunable GC algorithms, would perform better, especially Shenandoah and, of course, the Azul C4. The JVM world tends to solve this problem by using off-heap caches. See Apache Ignite [0] or Ehcache [1]. I can't speak for how their Rust cache manages memory, but the thing to…

> The JVM world tends to solve this problem by using off-heap caches. See Apache Ignite [0] or Ehcache [1]. For those who care, I was interested how off-heap caching works in Java and I did some quick searching around the Apache Ignite code. The meat is here: - GridUnsafeMemory, an implementation of access to entries allocated off-heap. This appears to implement some common Ignite interface, and invokes calls to a “G…

Unsafe lets you manipulate memory without any JNI overhead other than when allocating or de-allocating memory, and that is usually done in larger chunks and pooled to avoid the overhead at steady state. Netty also takes advantage of Unsafe to move a lot of memory operations off the java heap.

Unsafe was one of the cooler aspects to Java that Oracle is actively killing for, well, no good reason at least.

Re: Why Discord is switching from Go to Rust

#382

Post by archi42 »

Uhm, I'd suppose the service runs on one or more dedicated nodes - so there should be no competition for RAM (or if a node runs multiple services, the I'd expect a fixed memory amount to be available). In such an environment, each fixed size LRU cache could just allocate a huge chunk of RAM for data + indices (index size is bound by data size). That's nothing to do with the ownership model, it's just manually managed memory.

Yes, reality is more complex since they probably have multi socket servers/NUMA, which might add memory access latencies and atomic updates to the LRU might require a locking scheme, which also isn't trivial (and where async Rust might be useful).

Re: Why Discord is switching from Go to Rust

#383

Post by Polyisoprene »

rattray wrote: post #355
Polyisoprene wrote: post #339

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.

> Trolling is fun and all This isn't in keeping with HN's guidelines[0], eg: > Be kind. Don't be snarky. Of course, you may be expressing an unpopular opinion, so your comment may receive downvotes regardless. You may wish to delete and repost without the first clause to more accurately gauge community response. https://news.ycombinator.com/newsguidelines.html

Sure, just reflecting on the “There also tends to be way less of the `EnterpriseJavaBeanFactory`-style code in idiomatic Rust.”

Re: Why Discord is switching from Go to Rust

#384

Post by The_rationalist »

jen20 wrote: post #349
The_rationalist wrote: post #95

Earlier quoted context omitted.

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…

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

Re: Why Discord is switching from Go to Rust

#385

Post by mcguire »

masklinn wrote: post #276
falcolas wrote: post #260

Earlier quoted context omitted.

While Rust does not have a discrete runtime GC process, it does utilize reference counting for dynamic memory cleanup. So you could argue that they are still going to suffer some of the downsides of a GC'ed memory allocation. Some potential issues include non-deterministic object lifespan, and ensuring that any unsafe code they write which interacts with the cache does the "right thing" with the reference counts (pot…

> While Rust does not have a discrete runtime GC process, it does utilize reference counting for dynamic memory cleanup. That's so misleading as to essentially be a lie. Rust uses reference counting if and only if you opt into it via reference-counted pointers . Using Rc or Arc is not the normal or default course of action, and I'm not aware of any situation where it is ubiquitous. > So you could argue [nonsense] No,…

On the other hand, Rust's RAII management model behaves similarly to a reference counting system where the counts are limited to 0 and 1 (well, for a loose approximation of the 0 state), right?

Re: Why Discord is switching from Go to Rust

#386

Post by nottorp »

zlynx wrote: post #351
nottorp wrote: post #301

Can someone wake me up when they switch from javascript to something native in the client ? I just checked and as usually, I have an entry labeled "Discord Helper (Not Responding)" in my process list. I don't think i've ever seen it in a normal state.

That is kind of bad Windows programming but easy to do when writing an app that doesn't need to handle Windows event messages. It probably sits in a loop waiting on socket events and doesn't care if you sent it a WM_QUIT or not. It would be easy to pump the message loop and ignore all, but why bother?

Lol it's a javascript thing that instantiates a copy of Chrome, not a Windows program. I doubt they know what a WM_QUIT is...

Re: Why Discord is switching from Go to Rust

#387

Post by Polyisoprene »

roca wrote: post #371
Polyisoprene wrote: post #339

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…

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

Re: Why Discord is switching from Go to Rust

#388

Post by steveklabnik »

mcguire wrote: post #385
masklinn wrote: post #276

Earlier quoted context omitted.

> While Rust does not have a discrete runtime GC process, it does utilize reference counting for dynamic memory cleanup. That's so misleading as to essentially be a lie. Rust uses reference counting if and only if you opt into it via reference-counted pointers . Using Rc or Arc is not the normal or default course of action, and I'm not aware of any situation where it is ubiquitous. > So you could argue [nonsense] No,…

On the other hand, Rust's RAII management model behaves similarly to a reference counting system where the counts are limited to 0 and 1 (well, for a loose approximation of the 0 state), right?

Some people say this, but I think it's misleading; refcounting can make things live longer, but the borrow checker cannot.

Re: Why Discord is switching from Go to Rust

#389

Post by h2odragon »

staticassertion wrote: post #45
h2odragon wrote: post #37

Excellent write up, and effective argument for Rust in this application and others. My cynical side sums it up as: "Go sucked for us because we refused to own our tooling and make a special allocator for this service. Switching to Rust forced us to do that, and life got better"

I'm confused. Build a special allocator for Go you mean? That feels like going well beyond typical "own your tooling".

I'm outdated. I used to have 4 different python interpreter builds, for different purposes, where the modern world would be using lua as a glue language. I had nothing like the scale, staff, or budget of Discord; all I had was need and tools that could bend to fill it.

I think this is a great write up of why they chose a different tool. I don't say it was the wrong decision, they make that argument pretty well too. I'm still surprised that either Go isn't malleable enough to have bent around the need, or they didn't feel it worth more effort than parameter tweaking to bend it so.

Re: Why Discord is switching from Go to Rust

#390

Post by steveklabnik »

fatbird wrote: post #368
brylie wrote: post #363

What are some recommended resources for a gentle introduction to Rust?

I read the Rust Programming Language book over Christmas and it's a very good introduction to it, probably one of the best I've seen for any language. It's got a good voice, and it's very good about putting enough context around Rust design decisions to understand the why as well as the how. But's it's not so long that it feels like a slog.

Thank you!
Post reply on HN