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

331–340 of 670 posts

Re: Why Discord is switching from Go to Rust

#331

Post by gameswithgo »

marta_morena wrote: post #323
pkolaczk wrote: post #311

This is consistent with my observations of porting Java code to Rust. Much simpler and nicer to read safe Rust code (no unsafe tricks) compiles to programs that outperform carefully tuned Java code.

Sorry, but `Much simpler and nicer` is something that I highly doubt when you talk about Java to Rust. Unless the people writing the Java code were C programmers, lol, in which case I feel for you.

Remember that the comparison is a hand performance tuned Java program, vs a naive Rust implementation. When you are trying to extract performance out of Java, things can get pretty messy.

Re: Why Discord is switching from Go to Rust

#332

Post by romaniitedomum »

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.

Re: Why Discord is switching from Go to Rust

#333

Post by gameswithgo »

georgebarnett wrote: post #303
novok wrote: post #290

Earlier quoted context omitted.

A C app will tend to outperform a Java or Golang app by 3x, so it isn't too surprising.

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

It depends greatly on the problem domain. The difference might be near zero, or you might be able to get ~16x better performance (using say, AVX-512 intrinsics). Then again, is intrinsics really C? Not really, but you can do it. What if you have to abandon using classes when you want to, in order to get the memory layout you want in Java, are you still using Java?

Re: Why Discord is switching from Go to Rust

#334

Post by [deleted] »

The_rationalist wrote: post #159
thedance wrote: post #40

These kinds of posts would be much more interesting if they discussed alternatives considered and rejected. For example why did they choose Rust over C++?

The most pressing undiscussed alternative is: why didn't they update their 3 years old Go version yet had the double standard of using rust nightly... This blog post is a scam and their only reason to use rust should be assumed: it's because they wanted to.

[deleted]

Re: Why Discord is switching from Go to Rust

#335

Post by kerkeslager »

vogre wrote: post #319
kerkeslager wrote: post #112

Go is not a general-purpose language. It's a Google language designed to solve Google's problems. If you aren't Google, you probably have different problems, which Go isn't intended to solve. EDIT: Currently at -4 downvotes. Would downvoters care to discuss their votes?

I am not downvoter, but you should learn the history of the language. Most of the concepts in the language were first implemented long before Google even existed, for systems that were very different from modern ones. It was made by people who had been designing languages for about 40 years now. While some design choices seem weird, they usually have very strong argumentation and solid experience behind them. Also if…

> I am not downvoter, but you should learn the history of the language.

What makes you think I haven't been following Go since its inception?

> Most of the concepts in the language were first implemented long before Google even existed, for systems that were very different from modern ones.

Yes, some of the languages which created those concepts are languages which I've used and which I feel did it better, which is why I am particularly frustrated that Go has gained such popularity with so little substance.

> It was made by people who had been designing languages for about 40 years now. While some design choices seem weird, they usually have very strong argumentation and solid experience behind them.

Yes. Most of the strong argumentation is Google specific.

> Also if you read the list of problems tha Go is intended to solve, you will be surprised how common they are in software development.

Such as?

Re: Why Discord is switching from Go to Rust

#336

Post by wvenable »

graphememes wrote: post #324
wvenable wrote: post #279

Earlier quoted context omitted.

You're telling me Discord is patching itself on every single launch and this somehow a valid excuse for slow startup performance? Almost every single app I run auto-updates itself in some form.

In the case of Discord, yes. That's a valid argument, whether or not it's truly important, I'm not sure. It certainly is a waste of time to invest improving when their current system works perfectly fine.

They're investing in server-side project that are also perfectly fine. In this case, re-writing an entire module in a different language to eek out a tiny bit more performance!

But on the client side, it's arguably the slowest to launch application I have installed even among other Electron apps. Perfectly fine.

This completely re-enforces my original statement: "Desktop development is a total wasteland these days -- there isn't nearly as much effort put into optimization as server side" Desktop having horrible startup performance is "fine" but a little GC jitter on the server requires a complete re-write from the ground up.

Re: Why Discord is switching from Go to Rust

#337

Post by penagwin »

jhgg wrote: post #254
penagwin wrote: post #137

Earlier quoted context omitted.

I feel that it's not really fair to expect them to natively implement their app on every platform and put tons of resources into it's client performance - anecdotally discord is a very responsive app - see [0]. But think of it this way, all the effort they put into their desktop app works on all major OSes without a problem. They even get to reuse most of the code for access from the browser, with no installation req…

A lot of the startup cost right now is in our really ancient update checker. There are plans to rewrite all of this, now that we understand why it's bad, and have some solid ideas as to what we can do better. I do think it's reasonable to get the startup time of Discord to be near what VS Code's startup times are. If we remove the updater, it actually starts pretty fast (chromium boot -> JS loaded from cache) is The…

When you guys do address it could I pretty please request you do a blog article about it?

Electron startup time as well as v8 snapshots have been a hot topic for a looooong time. I actually started a pull request for it in 2015 [0]. My pull request was focusing on source code protection, but ANY information on how you use v8 snapshots, etc. would be awesome!

[0] https://github.com/electron/electron/issues/3041

Re: Why Discord is switching from Go to Rust

#338

Post by kerkeslager »

cmrdporcupine wrote: post #282
kerkeslager wrote: post #112

Go is not a general-purpose language. It's a Google language designed to solve Google's problems. If you aren't Google, you probably have different problems, which Go isn't intended to solve. EDIT: Currently at -4 downvotes. Would downvoters care to discuss their votes?

As a Googler, I don't consider this accurate. I've been here 8 years and have yet to work on a Go code base. Yes, there are projects in Go. Certainly not a majority, nor even a significant minority, honestly. No, I wouldn't say Go is specific to Google's problems, though I'm sure some of the engineers had them in mind. I see Go used far more outside of Google than in.

Well, that's pretty interesting.

I don't know if that disproves that Go was intended to solve Google's problems, though. I think from the early writings of the authors of the language in its infancy, it was pretty clear that they intended it to solve problems they were having at Google (i.e. the single-pass compilation design was intended to help with the compilation of their gigantic codebase). If it hasn't gained traction at Google, that only proves that it failed to solve a lot of Google's problems.

That's still not to say it's a failure in an absolute sense: it may have solved the problems it was intended to solve.

Re: Why Discord is switching from Go to Rust

#339

Post by Polyisoprene »

efaref wrote: post #326
marta_morena wrote: post #323

Earlier quoted context omitted.

Sorry, but `Much simpler and nicer` is something that I highly doubt when you talk about Java to Rust. Unless the people writing the Java code were C programmers, lol, in which case I feel for you.

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.

Re: Why Discord is switching from Go to Rust

#340

Post by _fbpt »

oconnor663 wrote: post #6
johnmc408 wrote: post #2

Non programmer here, but would it make sense to add a keyword (or flag) to Go to manually allocate a piece of memory (ie not use GC). That way, for some use cases, you could use avoid GC for the critical path. Then when GC happened, it could be very fast as there would be far less to pause-and-scan (in this use case example). Obviously this would have to be optional and discouraged...but there seems to be no way to w…

There are two things you'd have to do at the same time that make this complicated: - You'd have to ensure that your large data structure gets allocated entirely within the special region. That's simple enough if all you have is a big array, but it gets more complicated if you've got something like a map of strings. Each map cell and each string would need to get allocated in the special region, and all of the types i…

Both of these requirements kinda remind me of Microsoft's Verona language.
Post reply on HN