Earlier quoted context omitted.
There are tradeoffs with all languages. C++ avoids the GC, but you then have to make sure you know how to avoid the common pitfalls of that language. We use C++ at Scylla (saw that we got a shout-out in the blog! Woot!) but it's not like there isn't a whole industry about writing blogs avoiding C++ pitfalls. C++ pitfalls through the years... • https://www.horstmann.com/cpp/pitfalls.html (1997) • https://stackoverflow…
(Discord infra person here.) Actually we didn't update the reference to Cassandra in the article -- the read states workload is now on Scylla too, as of last week. ;) We'll be writing up a blog post on our migration with Scylla at some point in the next few months, but we've been super happy with it. I replaced our TokuMX cluster with it and it's faster, more reliable, _and_ cheaper (including the support contract).…
Why Discord is switching from Go to Rust
601–610 of 670 posts
Re: Why Discord is switching from Go to Rust
#602Earlier quoted context omitted.
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
#603Re: Why Discord is switching from Go to Rust
#604Re: Why Discord is switching from Go to Rust
#605Earlier quoted context omitted.
Landing in a shop that uses N programming languages for N microservices would be a pretty miserable experience.
I've seen quite a few environments, and usually there's only a limited current set of tech the devs are allowed to use, and if that's not the case, I try to enforce this, but this set should evolve depending on the needs. The main issue however is manpower. At my current client, one of the technologies still actively being used for this reason is PHP (which is a horrible fit for microservices for a lot of reasons), b…
Re: Why Discord is switching from Go to Rust
#606Really interesting post, however they're using a 2+years old runtime, Go 1.9.2 was released 2017/10/25 why did they not even try Go 1.13? For me the interesting part is that their new implementation in Rust with a new data structure is less than 2x faster than an implementation in Go using a 2+years old runtime. It shows how fast Go is vs an very optimized language + new data structure with no GC. Overall I'm pretty…
The graphs were in different units. The final Rust version was over 100x faster.
Re: Why Discord is switching from Go to Rust
#607Earlier quoted context omitted.
One the one hand, yes. On the other hand, all of this sounds much more complex and fragile. This seems like an important point to me: "Remarkably, we had only put very basic thought into optimization as the Rust version was written. Even with just basic optimization, Rust was able to outperform the hyper hand-tuned Go version."
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!
If one goes with reference counting as GC implementation, then one should take the effort to use hazardous pointers and related optimizations.
Re: Why Discord is switching from Go to Rust
#608Earlier quoted context omitted.
> Swift doesn't have a GC slowing things down This Apple marketing meme needs to die. Reference counting incurs arguably more cost than GC, or at least the cost is spread through-out processing.
It incurs some cost, but whether it is higher is very debatable. This is very much workload dependent. A smart compiler can elide most reference updates.
Re: Why Discord is switching from Go to Rust
#609Earlier 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.
So I doubt they would sponsor D.
Re: Why Discord is switching from Go to Rust
#610Earlier quoted context omitted.
> The JVM world tends to solve this problem by using off-heap caches. See Apache Ignite [0] or Ehcache [1]. For those who care, I was interested how off-heap caching works in Java and I did some quick searching around the Apache Ignite code. The meat is here: - GridUnsafeMemory, an implementation of access to entries allocated off-heap. This appears to implement some common Ignite interface, and invokes calls to a “G…
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.
Project Panama is what is driving that effort.