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

661–670 of 670 posts

Re: Why Discord is switching from Go to Rust

#661

Post by wool_gather »

kllrnohj wrote: post #659
wool_gather wrote: post #658

Earlier quoted context omitted.

Ah, thanks for the link; I wasn't sure what it meant in the context of Java, since it's possible to get value semantics using a class. Sorry about the confusion. I meant for the quotes around "copy-only" to indicate that it wasn't really a standard term, but I marked "value types" the same way, so that didn't really work. By "copy-only" I meant something you couldn't have more than one reference to: every name (varia…

> By "copy-only" I meant something you couldn't have more than one reference to: every name (variable) to which you assign the data would have its own independent copy. That's not really a requirement of value types, no. C# has value types (structs) and you can have references to them as well (ref & out params). In general though yes it would be typically copied around, same as an 'int' is. Particularly if Java doesn…

I know, that's why I asked for clarification originally. :) Anyways, I appreciate the details.

Re: Why Discord is switching from Go to Rust

#662

Post by igouy »

kllrnohj wrote: post #523
squarefoot wrote: post #325

Earlier quoted context omitted.

3x might be a bit too much today, but it's definitely slower than C. Also to be considered is the VM overhead, not just the executed code. Here are some benchmarks; I'll leave to the experts out there to confirm or dismiss them. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

> 3x might be a bit too much today, but it's definitely slower than C. If anything the gap is increasing not shrinking. JVM is terrible at memory access patterns due to the design of the language, and designing for memory is increasingly critical for maximum performance on modern systems. All the clever JIT'ing in the world can't save you from the constant pointer chasing, poor cache locality, and poor prefetching. T…

> Almost no classes or allocations.

Plenty of `inner static classes`. Where's the up-to-date comparison showing that `static` makes a performance difference for those tiny programs?

Plenty of TreeNode allocations.

----

> The problem with …

The problem with saying "in any substantial project that performance drops off" is when we don't show any evidence.

Re: Why Discord is switching from Go to Rust

#663

Post by takeda »

Uristqwerty wrote: post #660
takeda wrote: post #648

Earlier quoted context omitted.

So you are the person that ruins it for everyone (are you emacs user by any chance?). Tabs are more versatile, you can even use proportional fonts with them. Projects end up using tabs because many people end up mixing them together (unknowingly or in your case knowingly using configuration that is unavailable in many IDEs). BTW when you mix spaces with tabs you eliminate all benefits that tabs give (for example you…

If I were an emacs user, I'd figure out how to write a plugin to display tab-indented code to my preferences. No, I used to be a notepad user (on personal projects, not shared work) (you can kinda see it in the use of indentation to help convey information that IDEs would use font or colour to emphasize), and these days use tabs but longingly wish Eclipse, etc. had more options in their already-massive formatting con…

The reason I asked is that I believe this behavior is what Emacs does by default (actually don't know if by default, but saw this from code produced by Emacs users) e.g.

(inserts 4 spaces)(replaces 4 spaces into a tab that is 8 columns)(adds 4 spaces after the tab)(replaces with two tabs and so on)

Unless I misunderstood what formatting you were using.

Re: Why Discord is switching from Go to Rust

#664

Post by to11mtm »

jayd16 wrote: post #539
sreque wrote: post #381

Earlier quoted context omitted.

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.

C# seems to have a neat middle ground for this kind of stuff with their Span api.

True, but we had our own version of unsafe for a much longer time. MS was just pragmatic enough to allow it across the ecosystem.

I'm guessing at least some of that was a side effect of wanting to support C++; not having pointers as an option would have killed C++/CLI from the get go.

Re: Why Discord is switching from Go to Rust

#665

Post by to11mtm »

erk__ wrote: post #222
wongarsu wrote: post #77

Earlier quoted context omitted.

Games written in the Unity engine are (predominately) written in C#, a garbage collected language. Keeping large amounts of data around isn't that unusual since reading from disk is often prohibitively slow, and it's normal to minimize memory allocation/garbage generation (using object pools, caches etc), and manually trigger the GC in loading screens and in other opportune places (as easy as calling System.GC.Collec…

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.

Yeah, that's the ideal pattern in C#. You have to be smart-ish about it, but writing low GC pressure code can be easier than you think. Keep your call stacks shallow, avoid certain language constructs (i.e. LINQ) or at least know when they really make sense for the cost (async).

IDK if this is true for earlier versions, but as of today C# has pretty clear rules: 16MB in desktop or 64MB in server (which type is used can be set via config) will trigger a full GC [1]. Note that less than that may trigger a lower level GC, but those are usually not the ones that are noticed. I'm guessing at least some of that is because of memory locality as well as the small sizes.

On the other hand, in a lot of the Unity related C# posts I see on forums/etc, passing structs around is considered the 'performant' way to do things to minimize GC pressure.

[1] https://docs.microsoft.com/en-us/dotnet/standard/garbage-col... [2] https://blog.golang.org/ismmkeynote

Re: Why Discord is switching from Go to Rust

#666

Post by [deleted] »

cft wrote: post #543
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…

> From a purely architectural perspective, I would try to put cacheable material in something like memcache or redis You cannot use a caching server at that scale with those latency requirements. It has to be embedded

[deleted]

Re: Why Discord is switching from Go to Rust

#667

Post by ignoramous »

singron wrote: post #644
ignoramous wrote: post #170

Earlier quoted context omitted.

> ...all instances might OOM near the same time. CloudFront, for this reason, allocates heterogeneous fleets in its PoPs which have diff RAM sizes and CPUs [0], and even different software versions [1]. > When they all restart with cold caches, they might hammer the database again and cause the issue to repeat. Reminds me of the DynamoDB outage of 2015 that essentially took out us-east-1 [2]. Also, ELB had a similar…

Google's SRE book covers some of this (if you aren't cheekily referring to that). E.g. chapters 21 and 22 are "Handling Overload" and "Addressing Cascading Failures". The SRE book also covers mitigation by operators (e.g. manually setting traffic to 0 at load balancer and ramping back up, manually increasing capacity), but it also talks about engineering the service in the first place. This is definitely a familiar p…

Your comment reminds me of this excellent ACM article by Facebook on the topic: https://queue.acm.org/detail.cfm?id=2839461

I've read the first SRE book but having worked on large-scale systems it is impossible to relate to the book or internalise the advice/process outlined in it unless you've been burned by scale.

I must note that there are two Google SRE books in-circulation, now: https://landing.google.com/sre/books/

Re: Why Discord is switching from Go to Rust

#668

Post by Cthulhu_ »

RcouF1uZ4gsC wrote: post #25

> Changing to a BTreeMap instead of a HashMap in the LRU cache to optimize memory usage. Collections are one of the big areas where Go's lack of generics really hurts it. In Go, if one of the built in collections does not meet your needs, you are going to take a safety and ergonomic hit going to a custom collection. In Rust, if one of the standard collections does not meet your needs, you (or someone else) can create…

I like to think it's a tradeoff; limit the language and standard library and you limit the amount of things you have to consider. That is, 99% of applications probably won't need a BTree.

(anecdotal: in Java I've never needed anything else than a HashMap or an ArrayList)

Re: Why Discord is switching from Go to Rust

#670

Post by ascv »

topspin wrote: post #517
ascv wrote: post #465

Earlier quoted context omitted.

Actually it turns out that they DID test the latest version which at the time was 1.10 (see my edit). I guess you should be surprised now? :D

Since I actually cited 1.10 as one they tested I'm not surprised at all.

Except that you literally said it wasn't surprising b/c gc sucks. You were "not surprised" in response to the assumption that they DIDN'T test the latest version. However this was just a mis-understanding and you're re-casting your comment to make it seem like you were right all along. If you knew they tested the latest version all along then you couldn't have been surprised or not surprised to something that didn't happen.

It seems like my comment was just an entry point for you to shit on gc which, ironically, I mostly agree with in this context.

Post reply on HN