News for hackers. Stuff that matters.
Re:Why Discord is switching from Go to Rust by spullara on Tuesday February 04, 2020 @02:06PM (#22239638)
Heap caches that keep things longer than a GC cycle are terrible under GC unless you have a collector in the new style like ZGC, Azul or Shenandoah.
Re:Why Discord is switching from Go to Rust by sitkack on Tuesday February 04, 2020 @02:16PM (#22239748)
Systems with poor GC and the need to keep data for lifetimes greater than a request should have an easy to use off heap mechanism to prevent these problems.

Often something like Redis is used as a shared cache that is invisible to the garbage collector, there is a natural key with a weak reference (by name) into a KV store. One could embed a KV store into an application that the GC can't scan into.

Re:Why Discord is switching from Go to Rust by spullara on Tuesday February 04, 2020 @02:24PM (#22239850)
100%. In Java, you would often use OpenHFT's ChronicleMap for now and hopefully inline classes/records in Java 16 or so.
Re:Why Discord is switching from Go to Rust by cgh on Tuesday February 04, 2020 @02:59PM (#22240259)
Ehcache has an efficient off-heap store: https://github.com/Terracotta-OSS/offheap-store/

Doesn't Go have something like this available? It's an obvious thing for garbage-collected languages to have.

Re:Why Discord is switching from Go to Rust by mappu on Tuesday February 04, 2020 @06:27PM (#22242286)
You can usually resort to `import C` and using `C.malloc` to get an unsafe.Pointer.
Re:Why Discord is switching from Go to Rust by mappu on Tuesday February 04, 2020 @06:26PM (#22242282)
What feature of "the new style" makes them more suitable in this case?
Re:Why Discord is switching from Go to Rust by spullara on Wednesday February 05, 2020 @02:20PM (#22250114)
They have very short pause times even for very large heaps with lots of objects in them as they don't have to crawl the entire live tree when collecting.