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

211–220 of 670 posts

Re: Why Discord is switching from Go to Rust

#211

Post by masklinn »

steveklabnik wrote: post #155
tasty_freeze wrote: post #135

Earlier quoted context omitted.

Please explain to me how this works for the case I outlineed, eg: some_function(arg1, arg2, arg3, arg4, arg5, arg6); For the sake of argument, say tabstop=4. If the first line starts with two tabs, will the second line also have two tabs and then a bunch of spaces, or will it start with five tabs and a couple spaces?

You wouldn't use an alignment-based style, but a block-based one instead: some_function( arg1, arg2, arg3, arg4, arg5, arg6, ); (I don't know what Go idiom says here, this is just a more general solution.)

Checking the original code on the playground, Go just reindents everything using one tab per level. So if the funcall is indented by 2 (tabs), the line-broken arguments are indented by 3 (not aligned with the open paren).

rustfmt looks to try and be "smarter" as it will move the argslist and add linebreaks to it go not go beyond whatever limit is configured on the playground, gofmt apparently doesn't insert breaks in arglists.

Re: Why Discord is switching from Go to Rust

#212

Post by _ph_ »

correct_horse wrote: post #12

I've heard lots of hot takes on "what Go really is". Here's mine. Go is what would have happened if Bell Labs wrote Java.

Interesting comment, as 2 of the main Go creators (Ken Thompson and Rob Pike) did work at the Bell Labs. So while I doubt they tried to write Java, Go in a sense was written by the Bell Labs :).

(And Kernighan was their floor-mate too, that must have been a stunningly great environment)

Re: Why Discord is switching from Go to Rust

#213

Post by hombre_fatal »

tomc1985 wrote: post #73
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.

YeAh BuT wE dOnT wAnT tO hAvE tO tEsT eVeRy oPtIoN!!! - lazy devs and product managers, everywhere

This was the first time I've seen that annoying cAsE meme on HN and I pray it's the last. It is a lazy way to make your point, hoping your meme-case does all the work for you so that you don't have to say anything substantial.

Or do you think it adds to the discussion?

Re: Why Discord is switching from Go to Rust

#214

Post by jasondclinton »

rvcdbn wrote: post #157

Seems like you were hitting: runtime: Large maps cause significant GC pauses #9477 [0] Looks like this issue was resolved for maps that don't contain pointers by [1]. From the article, sounds like the map keys were strings (which do contain pointers, so the map would need to be scanned by the GC). If pointers in the map keys and values could be avoided, it would have (if my understanding is correct) removed the need…

Finding out if that does resolve the author's issue would be interesting but I'm not sure that that would be particularly supportive data in favor of Go. If anything it would reinforce the downsides of Go's GC implementation: prone sudden pitfalls only avoidable with obtuse, error-prone fiddling that makes the code more complex.

After spending weeks fighting with Java's GC tuning for a similar production service tail latency problem, I wouldn't want to be caught having to do that again.

Re: Why Discord is switching from Go to Rust

#215

Post by chc »

deweller wrote: post #179
chc wrote: post #140

Earlier quoted context omitted.

Why would you want to bring up the Actix author's drama? That doesn't seem like something that should reflect on a language one way or the other.

As an outsider to both the Go and Rust cultures, I read the Actix news and walked away with the impression that the Rust ecosystem is less mature.

I actually agree that there are many parts of Rust's ecosystem that are relatively immature — I just don't see how the Actix situation reflects on that. It's not like Actix was a core part of the Rust ecosystem. It was a framework that was most notable for doing very well on the Techempower benchmarks. People get hurt feelings and have flameouts in the C, Java, JavaScript, etc. ecosystems too.

Re: Why Discord is switching from Go to Rust

#216

Post by kikimora »

kerkeslager wrote: post #158
_bxg1 wrote: post #41

It's always good to see a case-study/anecdote, but nothing in here is surprising. It also doesn't really invalidate Go in any way. Rust is faster than Go. People use Go, like any other technology, when the tradeoffs between developer iteration/throughput/latency/etc. make sense. When those cease to make sense, a hot path gets converted down to something more efficient. This is the natural way of things.

> It's always good to see a case-study/anecdote, but nothing in here is surprising. It also doesn't really invalidate Go in any way. Well, sure, because categorizing languages as "valid/invalid" doesn't make any sense. But it does show yet another example of how designing a language to solve Google's fairly-unique problems doesn't result in a general-purpose language suitable for solving most people's problems.

Long GC pauses caused by large collections/caches are decade long problem with no real wide spread solution so far. With Java and .NET you can resort to off-heap data. Not sure if this is possible with Go.

Re: Why Discord is switching from Go to Rust

#217

Post by masklinn »

jasondclinton wrote: post #214
rvcdbn wrote: post #157

Seems like you were hitting: runtime: Large maps cause significant GC pauses #9477 [0] Looks like this issue was resolved for maps that don't contain pointers by [1]. From the article, sounds like the map keys were strings (which do contain pointers, so the map would need to be scanned by the GC). If pointers in the map keys and values could be avoided, it would have (if my understanding is correct) removed the need…

Finding out if that does resolve the author's issue would be interesting but I'm not sure that that would be particularly supportive data in favor of Go. If anything it would reinforce the downsides of Go's GC implementation: prone sudden pitfalls only avoidable with obtuse, error-prone fiddling that makes the code more complex. After spending weeks fighting with Java's GC tuning for a similar production service tail…

The good news are that Go's GC has basically no tunables, so you wouldn't have spent weeks on that. The bad news is that it has basically no tunables so if it's a tuning issue you're either fucked or have to put "tuning" hacks right into the code if you find any that works (e.g. twitch's "memory ballast" to avoid overly aggressive GC runs: https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...)

Re: Why Discord is switching from Go to Rust

#218

Post by tick_tock_tick »

firethief wrote: post #191
mrpotato wrote: post #88

Earlier quoted context omitted.

Interesting, they went a totally different route. > The ballast in our application is a large allocation of memory that provides stability to the heap. > As noted earlier, the GC will trigger every time the heap size doubles. The heap size is the total size of allocations on the heap. Therefore, if a ballast of 10 GiB is allocated, the next GC will only trigger when the heap size grows to 20 GiB. At that point, there…

Wow, that puts Discord's "absurd hack" into perspective! I feel like the moral here is a corollary to that law where people will depend on any observable behavior of the implementation: people will use any available means to tune important performance parameters; so you might as well expose an API directly, because doing so actually results in less dependence on your implementation details than if people resort to ce…

I mean if you read Twitch's hack they intentionally did it in code so they didn't need to tune the GC parameter. They wanted to avoid all environment config.

Re: Why Discord is switching from Go to Rust

#219

Post by tsimionescu »

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?

It doesn't. You could start and stop the GC occasionally, maybe?

Re: Why Discord is switching from Go to Rust

#220

Post by KMag »

_ph_ wrote: post #72

If you have a problem at hand which does not really benefit from the presence of a garbage collector, switching to an implementation without a garbage collector has quite a potential to be at least somewhat faster. I remember myself to run onto this time trigger for garbage collection long in the past - though I don't remember why and mostly forgot about ever since until I read this article. As also written in the ar…

Not only is there good potential for a speed improvement, but languages built around the assumption of pervasive garbage collection tend not to have good language constructs to support manual memory management.

To be fair, most languages without GCs also don't have good language constructs to support manual memory management. If you're going to make wide use of manual memory management, you should think very carefully about how the language and ecosystem you're using help or hinder your manual memory management.

Post reply on HN