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

351–360 of 670 posts

Re: Why Discord is switching from Go to Rust

#351

Post by zlynx »

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?

Re: Why Discord is switching from Go to Rust

#352

Post by heinrich5991 »

tensor wrote: post #306
hinkley wrote: post #224

Earlier quoted context omitted.

The common factor in most of my decisions to look for a new job has been realizing that I feel like a very highly compensated janitor instead of a developer. Once I spend even the plurality of my time cleaning up messes instead of doing something new (and there are ways to do both), then all the life is sucked out of me and I just have to escape. Telling me that I have to keep using a tool with known issues that we h…

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.

Re: Why Discord is switching from Go to Rust

#353

Post by martindevans »

danbolt wrote: post #248
erk__ wrote: post #222

Earlier quoted context omitted.

C# uses a generational gc iirc so it may be better suited for a system where you have a relativly stable collection that does not need to be fully garbage collected all the time and have a smaller and more volitile set of objects that will be gc'ed more often. I don't think the current garbage collector in go does anything similar to that.

This might have changed with more recent updates, but I was under the impression that the Mono garbage collector in Unity was a bit dated and not as up-to-date as a C# one today.

Unity has recently added the "incremental GC" [1] which spreads the work of the GC over multiple frames. As I understand it this has a lower overall throughput, but _much_ better worst case latency.

[1] https://blogs.unity3d.com/2018/11/26/feature-preview-increme...

Re: Why Discord is switching from Go to Rust

#354

Post by lllr_finger »

romaniitedomum wrote: post #332

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

Re: Why Discord is switching from Go to Rust

#355

Post by rattray »

Polyisoprene wrote: post #339
efaref wrote: 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.

> 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

Re: Why Discord is switching from Go to Rust

#357

Post by cesarb »

mypalmike wrote: post #329
steveklabnik wrote: post #244

Earlier quoted context omitted.

Yeah so I was vaguely wondering about some sort of double indirection; the structure keeps track of "this is a pointer I've handed out", those pointers point into that, which then points into the main structure. I have no idea if this actually a good idea, seems like you get rid of a lot of the cache locality advantages.

This sounds a lot like classic MacOS (pre-Darwin) memory allocation. You were allocated a handle, which you called Lock on to get a real pointer. After accessing the memory, you called Unlock to release it. There was definitely a performance hit for that indirection.

It's the same on classic Windows (pre-Windows 95) memory allocation. GlobalAlloc with GMEM_MOVEABLE or LocalAlloc with LMEM_MOVEABLE returned a handle, which you called GlobalLock or LocalLock on to get a real pointer. After accessing the memory, you called GlobalUnlock or LocalUnlock to release it. Of course, this being Microsoft, you can still call these functions inherited from 16-bit Windows even on today's 64-bit Windows. (See Raymond Chen's "A history of GlobalLock" at https://devblogs.microsoft.com/oldnewthing/20041104-00/?p=37...).

Re: Why Discord is switching from Go to Rust

#358

Post by reificator »

Nullabillity wrote: post #175
heinrich5991 wrote: post #107

Earlier quoted context omitted.

There are a couple of hosting services hardcoded in Go. I believe it was about splitting the URL into the actual URL and the branch name.

https://github.com/golang/go/blob/e6ebbe0d20fe877b111cf4ccf8... Ouch, Go never ceases to amaze. The Bitbucket case[0] is even more crazy, calling out to the Bitbucket API to figure out which VCS to use. It has a special case for private repositories, but seems to hard-code cloning over HTTPS. If only we had some kind of universal way to identify resources, that told you how to access it... [0]: https://github.com/gol…

Thanks for the reference to prove me wrong.

Wow, that's sad. I'm glad it works seamlessly, don't get me wrong, but I was assuming I could chalk it up to defacto standards between the various vendors here.

Re: Why Discord is switching from Go to Rust

#359

Post by Polyisoprene »

ericflo wrote: post #56
erik_seaberg wrote: post #39

Earlier quoted context omitted.

Anyone who pushes the limits of a machine needs tuning options. If you can't turn knobs you have to keep rewriting code until you happen to get the same effect.

There's definitely a happy medium. One setting may indeed be too few, but JVM's many options ends in mass cargo-cult copypasta, often leading to really bad configurations.

Haven’t really seen anyone trying to use JVM options to get performance benefits without benchmarks for their specific use case the last 10 years or so.

Re: Why Discord is switching from Go to Rust

#360

Post by bcrosby95 »

marcosdumay wrote: post #328
georgebarnett wrote: post #303

Earlier quoted context omitted.

Could you please provide a source for this? Java is very fast and 3X slower is a pretty wild claim.

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.
Post reply on HN