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

391–400 of 670 posts

Re: Why Discord is switching from Go to Rust

#391

Post by lostcolony »

marrs wrote: post #103
ptrincr wrote: post #24

Earlier quoted context omitted.

You are able to disable GC with: GOGC=off As someone mentions below. More details here: https://golang.org/pkg/runtime/

How does Go allow you to manage memory manually? Malloc/free or something more sophisticated?

So other comments didn't mention this, per se, but Go gives you tools to see what memory escapes the stack and ends up being heap allocated. If you work to ensure things stay stack allocated, it gets freed when the stack frees, and the GC never touches it.

But, per other comments, there isn't any direct malloc/free behavior. It just provides tools to help you enable the compiler to determine that GC is not needed for some.

Re: Why Discord is switching from Go to Rust

#392

Post by Polyisoprene »

gameswithgo wrote: post #345
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.

So, being able to have a value or a reference vs everything always being a reference is a pretty massive difference. Option types instead of nulls is also a pretty large difference. Generics being better from a performance perspective is a large difference too. As well, traits are quite a bit different than classes, but not always in a good way!

Hopefully Java will support proper values regarding inlining and on-stack allocation for non-primitive types soon, but yes option types are a benefit in Rust as long as you’re not using any more advanced reference libraries.

Re: Why Discord is switching from Go to Rust

#393

Post by meowface »

onebot wrote: post #109
jhgg wrote: post #27

Earlier quoted context omitted.

This is one of multiple, we did not blog about this one, but switching a Python http service for analytics ingest that was purely CPU bound to rust resulted in a 90% reduction in compute required to power it. However, that's not too interesting because it's known that Python is slow haha. We have 2 golang services left, one of them has a rewrite in rust in PR as of last week (as a fun side project an engineer wanted…

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"?

Re: Why Discord is switching from Go to Rust

#395

Post by lostcolony »

kerkeslager wrote: post #169
dilyevsky wrote: post #105

Earlier quoted context omitted.

LOL that should’ve been at the top. The improvement in gc between 1.9 and 1.12 is absolutely massive. They could’ve just upgraded go toolchain.

The GC changes in 1.12 supposedly target large heaps, which is not Discord's situation.

Really? My take was that it was. They mention a bunch of cached data, that rarely got ejected (so not generating a lot of garbage), but that took a long time to traverse (so when GC DID occur, it took a long time), which implies it being large.

Re: Why Discord is switching from Go to Rust

#396

Post by jodrellblank »

snazz wrote: post #83
okgood288 wrote: post #62

Earlier quoted context omitted.

Well sure when it’s a micro service that probably has more lines of infra config than biz logic LOC. This isn’t exactly “Linux kernel: now in Rust!” Glad you’re making tech for you all better. We get to take up the externalized runtime costs of the mess that is the Electron app. Engineers are super efficient at offloading the last mile of effort.

Let's not start the Electron debate again. That's been argued to death already.

Maybe if we keep at it, we can argue it until Electron's death?

Re: Why Discord is switching from Go to Rust

#397

Post by tene »

Polyisoprene wrote: post #392
gameswithgo wrote: post #345

Earlier quoted context omitted.

So, being able to have a value or a reference vs everything always being a reference is a pretty massive difference. Option types instead of nulls is also a pretty large difference. Generics being better from a performance perspective is a large difference too. As well, traits are quite a bit different than classes, but not always in a good way!

Hopefully Java will support proper values regarding inlining and on-stack allocation for non-primitive types soon, but yes option types are a benefit in Rust as long as you’re not using any more advanced reference libraries.

Can you explain more about "advanced reference libraries", and how they interfere with the benefits of option types?

Re: Why Discord is switching from Go to Rust

#398

Post by qaq »

Polyisoprene wrote: post #350
carllerche wrote: post #4

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…

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

Re: Why Discord is switching from Go to Rust

#399

Post by totalperspectiv »

bcrosby95 wrote: post #360
marcosdumay wrote: post #328

Earlier quoted context omitted.

Those people have a really good claim to have the most optimized choice on each language. They've found Java to be 2 to 3 times slower than C and Rust (with much slower outliers). https://benchmarksgame-team.pages.debian.net/benchmarksgame/... On the real world, you won't get things as optimized in higher level languages, because optimized code looks completely unidiomatic. A 3x speedup from Java is a pretty normal c…

Speaking of, I wish there were an "idiomatic code benchmarks game". Some of us want to compare language speed for common use cases vs trying to squeeze every last piece of performance from it.

Check out this: https://github.com/frol/completely-unscientific-benchmarks

Re: Why Discord is switching from Go to Rust

#400

Post by ta20200202 »

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?

RAII for references (pointers) is a no-op. If the cache returns references to the data in its own array there is no overhead.
Post reply on HN