Why Discord is switching from Go to Rust • Hacker News Board

Re: Why Discord is switching from Go to Rust

#541

Post by nnq » Wed, Feb 05, 2020, 7:18 AM UTC

corford wrote: post #439

tormeh wrote: post #416

Earlier quoted context omitted.

D, Nim and Crystal all do very well on all metrics. Author finds Rust pretty close but not as maintainable. Interesting that the top 3 (performance close to C++, but more maintainable) all are niche languages that haven't really broken into the mainstream.

I really wish Intel or MS or someone would fund D so it could give Go and Rust a run for their money. It's as fast (or faster), expressive, powerful and, subjectively, easier to pick up and code in than Rust. It just needs some backers with muscle.

You probably have Swift in the same niche... and more elegant, not completely ignoring the last few decades of language research etc. If you want something more minimalistic there's Zig. D is just "C++ + hindsight", nothing special, only extra fragmentation of dev ecosystem by bringing in another language.

Ofc, Apple is not MS, so Swift developer experience and docs kind of suck (if you're not in the "iOS bubble" where it's nice and friendly), and multiplatform dev experience especially sucks even worse...

And "easier to pick up and code in" might not necessarily be an advantage for a systems language - better start slowly putting the puzzle together in your head, and start banging up code others need to see only after you've internalized the language and its advanced features and when (not) to use them! It helps everyone in the long run. This is one reason why I'd bet on Rust!

Re: Why Discord is switching from Go to Rust

#542

Post by dodobirdlord » Wed, Feb 05, 2020, 7:25 AM UTC

estebank wrote: post #526

dodobirdlord wrote: post #503

Earlier quoted context omitted.

This reminds me of the ongoing saga of RUSTC_BOOTSTRAP[0][1] The stable compiler is permitted to use unstable features in stable builds, but only for compiling the compiler. In essence, there are some Rust features that are supported by the compiler but only permitted to be used by the compiler. Unsurprisingly, various non-compiler users of Rust have decided that they want those features and begun setting the RUSTC_B…

This is not entirely correct. These things that "can only be used by the compiler" are nightly features that haven't been stabilized yet . Some of them might never be stabilized, but you could always use them in a nightly conpiler, stability assurances just fly out the window then. This is also why using that environment variable is highly discouraged: it breaks the stability guarantees of the language and you're eff…

I don't see what is incorrect? Perhaps I was insufficiently clear that when I said "the compiler" I meant "the stable compiler" as opposed to more generally all possible versions of rustc. The stable compiler is permitted to use unstable features for its own bootstrap, example being the limited use of const generics to compile parts of the standard library.

Re: Why Discord is switching from Go to Rust

#543

Post by cft » Wed, Feb 05, 2020, 7:27 AM UTC

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

Re: Why Discord is switching from Go to Rust

#544

Post by adev_ » Wed, Feb 05, 2020, 7:31 AM UTC

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…

> The JVM world tends to solve this problem by using off-heap caches. See Apache Ignite [0] or Ehcache [1].

Yeah, but I really do not bite your argument.

When you are reduced to do manual memory management and fight the GC of your language, maybe you should simply not use a language with GC in the first place.

They are right to use rust ( or C/C++) for that. It's not for nothing that redis (C) is so successful in the LRU domain.

> It's worth mentioning that Apache Cassandra itself uses an off-heap cache.

And still ScyllaDB (C++) is able to completely destroy Cassandra in term of AVG latency [0]

[0]: https://www.scylladb.com/product/benchmarks/

Re: Why Discord is switching from Go to Rust

#545

Post by raverbashing » Wed, Feb 05, 2020, 7:32 AM UTC

> but because the garbage collector needed to scan the entire LRU cache in order to determine if the memory was truly free from references

Yeah please tell me again how GC is a superior solution to reference counting in cases when you know exactly when you don't need the object anymore.

(Hint: RC is not GC if the object is dealocating itself)

Re: Why Discord is switching from Go to Rust

#546

Post by mrjn » Wed, Feb 05, 2020, 7:35 AM UTC

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…

Don't know enough about Rust, but I think Go would benefit immensely by allowing its users to disable GC and allow de-allocating memory by hand. GC is great for simpler applications, but more complex projects end up fighting so much with memory and GC in Go that all the benefits of automatic de-allocations are negated. Love every other aspect of Go.

Re: Why Discord is switching from Go to Rust

#547

Post by pkolaczk » Wed, Feb 05, 2020, 7:36 AM UTC

anarazel wrote: post #440

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

Really depends on the domain. There's some things that are a lot easier to make scale up in a language with a great concurrent gc, because that makes writing some lock free data structures quite fundamentally easier (no complicated memory reclamation logic, trivial to avoid ABA problems).

GC makes it easier to write, but not necessarily better. Modern state-of-the-art Java GCs operate a global heap, so you often pay for what you do not use. In languages like Rust or C++ your can build small locally GCed heaps, where you can limit GC overhead to just a few particular structures that need GC, not everything. Therefore other structures like caches don't affect GC pause times.

And the "hardness" of writing lockless structures is strongly offset by libraries, so unless you're doing something very exotic, it is rarely a real problem.

Re: Why Discord is switching from Go to Rust

#548

Post by Jweb_Guru » Wed, Feb 05, 2020, 7:46 AM UTC

steveklabnik wrote: post #230

ithkuil wrote: post #221

Earlier quoted context omitted.

Perhaps such a library could help you record the location of the variables that contain pointers to the strings and keep that pointer up to data as the ownership of the string moves from variable to variable? I'm other words, doing some of the work a moving compacting collector would do during compaction but continuously during normal program execution.

There's no way to hook into the move, so I don't see how it would be possible, or at least, not with techniques similar to compacting GCs.

It would be possible (and not that hard) for Copy types, but you'd need some custom derive traits if you had any pointers to managed objects.

Re: Why Discord is switching from Go to Rust

#549

Post by Jweb_Guru » Wed, Feb 05, 2020, 7:48 AM UTC

steveklabnik wrote: post #388

mcguire wrote: post #385

Earlier quoted context omitted.

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?

Some people say this, but I think it's misleading; refcounting can make things live longer, but the borrow checker cannot.

Well, with ownership, a move can make things "live" longer, I guess.

Re: Why Discord is switching from Go to Rust

#550

Post by 1propionyl » Wed, Feb 05, 2020, 7:48 AM UTC

dgellow wrote: post #320

chubs wrote: post #307

Earlier quoted context omitted.

I found similarly when I ported an image resizing algorithm from Swift to Rust: I'm experienced in swift thus was able to write in an idiomatic way, and have little Rust experience thus I wrote it in a naive way; yet still the rust algorithm was twice(!) as fast. And swift doesn't even have a GC slowing things down!

ARC, used by Swift, has its own cost.

True, but it's generally better than most full GC solutions (for processes running for relatively short times without the benefit of profile-guided optimization), and worse than languages with fully statically analyzable memory usage.

Note: that parenthetical is a very big caveat, because properly profile-optimized JVM executables can often achieve exceptional performance/development cost tradeoffs.

In addition however, ARC admits a substantial amount of memory-usage optimization given bytecode, which is now what developers provide to Apple on iOS. Not to mention potential optimizations by allowing Apple to serve last-minute compiled microarchitecture optimized binaries for each device (family).

To satiate the pedants... ARC is more of less GC where calls into the GC mechanism are compiled in statically and where there are at worst deterministic bounds on potential "stop the world" conditions.

While this may not be presently optimal because profile-guided approaches can deliver better performance by tuning allocation pool and collection time parameters, it's arguably a more consistent and statically analyzable approach that with improvement in compilers may yield better overall performance. It also provides tight bounds on "stop the world" situations, which also exist far less frequently on mobile platforms than in long running sever applications.

Beyond those theoretical bounds, it's certainly much easier to handle when you have an OS that is loading and unloading applications according to some policy. This is extremely relevant as most sensible apps are not actually long running.