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

Re: Why Discord is switching from Go to Rust

#621

Post by koffiezet » Wed, Feb 05, 2020, 4:09 PM UTC

qaq wrote: post #605

koffiezet wrote: post #584

Earlier quoted context omitted.

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…

I can buy this for Rust but if people have issues picking up Go quickly ...

Well, picking up the language itself is one thing (and I agree, that's quite easy with Go), but getting familiar with the ecosystem, best practices and avoiding habits from other languages? That's an entirely different thing.

And that's also how management usually sees it, and if they're smart they also realise that the first project using an unfamiliar technology is usually one to throw away.

Re: Why Discord is switching from Go to Rust

#622

Post by wool_gather » Wed, Feb 05, 2020, 4:38 PM UTC

nnq wrote: post #541

corford wrote: post #439

Earlier quoted context omitted.

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" whe…

"completely ignoring the last few decades"

Well, for fairness, D is quite a bit older than Swift. (It's nearly as much older than Swift as it is younger than C++!) But what do you think pushes Swift out of the "C++ with hindsight" basket?

Re: Why Discord is switching from Go to Rust

#623

Post by scott_s » Wed, Feb 05, 2020, 4:41 PM UTC

thu2111 wrote: post #561

the_duke wrote: post #442

Earlier quoted context omitted.

VMs with JIT like the JVM are only ever really fast/competitive with C in small numerical micro-benchmarks where the code can be hyper-optimized. Most code will be considerably slower due to a lot of factors. Java in particular is a very pointer-heavy language, made up of pointers to pointers to pointers everywhere, which is really bad for our modern systems that often are much more memory latency than CPU constraine…

This stuff is really hard to pin down though. I've been reading these sorts of debates forever. It's true that pointer chasing really hurts in some sorts of program and benchmark. For sure. No argument. That's why Project Valhalla exists. But it's also my view that modern C++ programming gets away with a lot of slow behaviours that people don't really investigate or talk about because they're smeared over the program…

> We know malloc is very slow because people so frequently roll their own allocators that the STL supports this behaviour out of the box. But malloc/new is also completely endemic all over C++ codebases. Custom allocators are rare and restricted to very hot paths in very well optimised programs. On the JVM allocation is always so fast it's nearly free, and if you're not actually saturating every core on the machine 100% of the time, allocation effectively is free because all the work is pushed to the spare cores doing GC.

Allocation in a C++ program is going to be about the same speed as in a Java program. Modern mallocs are doing basically the same thing on the hot-path: bumping the index on a local slab allocator.

Re: Why Discord is switching from Go to Rust

#624

Post by wool_gather » Wed, Feb 05, 2020, 4:43 PM UTC

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…

When you say "value types" in this context, you mean "copy-only types"?

Re: Why Discord is switching from Go to Rust

#625

Post by wool_gather » Wed, Feb 05, 2020, 4:47 PM UTC

iainmerrick wrote: post #568

robocat wrote: post #367

Earlier quoted context omitted.

However the memory usage difference is astonishing for some of those benchmarks - using 1000x more memory is only acceptable for some situations.

This may be overly cynical, but don’t you have it backwards? 1000x greater memory usage is acceptable for most applications. There are only a few applications for which it isn’t acceptable. Just look at all the massive apps built on Electron. People wouldn’t do that if it wasn’t effective.

Wouldn't you say there's a difference between "effective" and "getting away with it"? If non-technical users see that their daily computing lives are made more complicated (because of lowered performance) by having n Electron apps running at the same time, they may not understand the reasons, but they will certainly choose a different solution that has the features they need, where available.

Re: Why Discord is switching from Go to Rust

#626

Post by igouy » Wed, Feb 05, 2020, 5:04 PM UTC

bcrosby95 wrote: post #360

marcosdumay wrote: post #328

Earlier quoted context omitted.

Those people have a really good claim to have the most optimized choice on each language. They've found Java to be 2 to 3 times slower than C and Rust (with much slower outliers). https://benchmarksgame-team.pages.debian.net/benchmarksgame/... On the real world, you won't get things as optimized in higher level languages, because optimized code looks completely unidiomatic. A 3x speedup from Java is a pretty normal c…

Speaking of, I wish there were an "idiomatic code benchmarks game". Some of us want to compare language speed for common use cases vs trying to squeeze every last piece of performance from it.

>> I wish there were an "idiomatic code benchmarks game"

Help make one:

— contribute programs that you consider to be "idiomatic"

https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...

— use those measurement and web scripts to publish your own "common use cases" "idiomatic code" benchmarks game

----

>> compare language speed for common use cases vs trying to squeeze every last piece of performance

— please be clear about why you wish to compare the speed of programs written as if speed did not matter

----

??? What do you think is not "idiomatic" about programs such as:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Why Discord is switching from Go to Rust

#627

Post by kllrnohj » Wed, Feb 05, 2020, 5:05 PM UTC

wool_gather wrote: post #624

kllrnohj wrote: post #523

Earlier quoted context omitted.

> 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…

When you say "value types" in this context, you mean "copy-only types"?

I mean "value types" https://www.jesperdj.com/2015/10/04/project-valhalla-value-t... & http://cr.openjdk.java.net/~jrose/values/values-0.html

I don't know what you mean by "copy-only types." I'm not finding any reference to that terminology in the context of language design.

Re: Why Discord is switching from Go to Rust

#628

Post by igouy » Wed, Feb 05, 2020, 5:17 PM UTC

totalperspectiv wrote: post #399

bcrosby95 wrote: post #360

Earlier quoted context omitted.

Speaking of, I wish there were an "idiomatic code benchmarks game". Some of us want to compare language speed for common use cases vs trying to squeeze every last piece of performance from it.

Check out this: https://github.com/frol/completely-unscientific-benchmarks

— Expressiveness "keep in mind that this is a subjective metric based on the author's experience!"

— Maintenance Complexity "keep in mind that this is a subjective metric based on the author's experience!"

Re: Why Discord is switching from Go to Rust

#629

Post by marcosdumay » Wed, Feb 05, 2020, 5:30 PM UTC

pjmlp wrote: post #609

corford wrote: post #439

Earlier quoted context omitted.

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.

That is what MS is doing with C#/F# and .NET Native/Xamarin AOT/CoreRT, with the experience taken from Midori. So I doubt they would sponsor D.

C# is an attempt of making Java good, F# is an attempt of making a subset of Haskell popular. .Net Native/Xamarin/CoreRT are UI frameworks. There is nothing there that would compete with C++.

I don't think MS has any interest in improving C++ (look at their compiler). But that's not because of competing activities.

Re: Why Discord is switching from Go to Rust

#630

Post by igouy » Wed, Feb 05, 2020, 5:34 PM UTC

robocat wrote: post #367

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

However the memory usage difference is astonishing for some of those benchmarks - using 1000x more memory is only acceptable for some situations.

— default JVM allocation ~35 MB looks astonishing for tiny programs that don't allocate memory

— memory usage is less different for tiny programs that do allocate memory: reverse-complement, k-nucleotide, binary-trees, mandelbrot, regex-redux