2017 Rust Roadmap

Post by igouy » Sat, Oct 22, 2016, 4:37 PM UTC

steveklabnik wrote: post #130

fbender wrote: post #126

Earlier quoted context omitted.

Source? First Google result for "Rust vs Go speed": https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... Rust seems to perform significantly better on some workloads while Go outperforms it marginally in other ones (except reverse-complement where Go is almost 50% faster than Rust). Edit: As for the other points you make – they are often subjective and I've read the opposite to your statement at least as o…

The ones where Go outperforms us currently are the ones with heavy SIMD use; explicit SIMD is still unstable in Rust, so you're at the whims of LLVM generating it. We'll get there...

Post by steveklabnik » Sat, Oct 22, 2016, 4:50 PM UTC

igouy wrote: post #151

steveklabnik wrote: post #130

Earlier quoted context omitted.

The ones where Go outperforms us currently are the ones with heavy SIMD use; explicit SIMD is still unstable in Rust, so you're at the whims of LLVM generating it. We'll get there...

Do those Go programs use explicit SIMD ? http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

Post by pcwalton » Sat, Oct 22, 2016, 5:02 PM UTC

dysfunctor wrote: post #121

pcwalton wrote: post #10

Earlier quoted context omitted.

It's important to note that Go and C have very different design goals from Rust. Go was never designed to have zero-cost abstractions (garbage collection being the most obvious outcome of this, but there are many others), and it has a runtime. C was never designed for safety and security, memory safety or otherwise. In short, Go sacrifices performance and C sacrifices safety, while Rust's goal is to sacrifice neither…

Go outperforms rust on all kinds of benchmarks, has a larger community, better documentation, more third party libraries, and significantly better tooling. What's the value proposition for using rust over go?

Post by pcwalton » Sat, Oct 22, 2016, 5:13 PM UTC

shadowmint wrote: post #112

bluejekyll wrote: post #46

Earlier quoted context omitted.

Honestly, the more you program in rust, the more you get used to its mannerisms. I don't at this point find that I'm less productive in it than in Go, and with gennerics I'm generally able to reuse code more often meaning that I usually write less code. Similarly in C I lose time on screwing up basic things that I have to debug in testing, whereas in Rust I don't have to even worry about that. I'm actually not buying…

Claiming that it is less productive when you barely know it isn't fair... I'm really quite familiar with both go and rust, and I can say straight out that go is more productive than rust. ...but because rust is in any way a worse or less productive language (that remains to be seen), but because it has an immature ecosystem with few high quality crates and virtually no tooling. Go has a lot of very polished tooling (…

Post by pcwalton » Sat, Oct 22, 2016, 5:18 PM UTC

naasking wrote: post #123

pcwalton wrote: post #70

Earlier quoted context omitted.

> Sometimes ref-counting (Rc in Rust) is fine, although that's more expensive than GC. To nitpick: The jury's still out on that one, because Rc in Rust isn't thread-safe reference counting. I believe that non-thread-safe reference counting is quite competitive with global, cross-thread tracing GC. When people (rightly) talk about how much slower reference counting is than tracing GC, they're almost always talking abo…

> When people (rightly) talk about how much slower reference counting is than tracing GC, they're almost always talking about either thread-safe tracing GC vs. thread-safe reference counting or single-threaded tracing GC vs. single-threaded reference counting. Reference counting has always been slower, even in single-threaded cases. This should be obvious because pure reference counting requires modifying counts when…