2017 Rust Roadmap • Hacker News Board

Re: 2017 Rust Roadmap

#121

Post by dysfunctor » Sat, Oct 22, 2016, 10:49 AM UTC

pcwalton wrote: post #10

fixxer wrote: post #6

Awesome to see the learning curve addressed with such high priority. I like Rust and I'd like to use it more, but I generally lean on Go or C for writing anything that needs performance. I can't quite get past the awkward, fumbling stage with Rust. Go, on the other hand, was really easy to get acquainted with and not too substantial of an effort to get to strong expertise. I've been able to teach Go to junior devs wi…

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?

Re: 2017 Rust Roadmap

#122

Post by erlend_sh » Sat, Oct 22, 2016, 11:03 AM UTC

tatterdemalion wrote: post #88

berntb wrote: post #75

Earlier quoted context omitted.

Are you saying that Rust, a system programming language, can compete with the scripting languages in speed of developing features?! Or are you saying that it is a pleasure to use, so you'll use it for smaller backends where development speed isn't that critical? (Asking, not flaming. :-) )

> Are you saying that Rust, a system programming language, can compete with the scripting languages in speed of developing features?! I'll say it. At work, the backend is Rails, and I am a Rust contributor in my freetime. I am in the early stages of working on a framework for web apps in Rust & I believe it will be comparatively productive to Rails. Only your code will be faster and many bugs will be caught at compil…

Have you heard about Helix? - http://blog.skylight.io/introducing-helix/

I think this is a great way to introduce large existing Ruby codebases to Rust in increments, much like Sentry demonstrated recently, but for Python: https://blog.sentry.io/2016/10/19/fixing-python-performance-...

Re: 2017 Rust Roadmap

#123

Post by naasking » Sat, Oct 22, 2016, 12:03 PM UTC

pcwalton wrote: post #70

jdf wrote: post #53

Earlier quoted context omitted.

I forgot to add - I partially agree with you about the productivity of GC. For non-performance sensitive code, GC simplifies a lot. Otherwise, I find Go much nicer to reason about than Java since it has real arrays (value types!). But I find it a mixed bag of whether the naive Go version of something that shares memory by GC is simpler than the naive Rust version of something that shares memory. Sometimes ref-countin…

> 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 whenever locals are assigned, which happen orders of magnitude more often than main memory updates, and now each local assignment requires touching main memory too.

As soon as you defer these updates somehow to recover that cost, you've introduced partial tracing. You can find papers from way back acknowledging this overhead, and suggesting optimizations [1].

[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.25.9...

Re: 2017 Rust Roadmap

#124

Post by agentgt » Sat, Oct 22, 2016, 12:08 PM UTC

For what it's worth I hope serde or whatever default serializers are improved. I had some serious issues trying to combine libraries because of serde changing too much. Albeit this was about a year ago so it probably is fixed.

Second it would be nice to see some best practices not just for libraries but application development. What to do and what not to do. Maybe a cookbook or even... design patterns. I had a hard time trying to figure out if I should embrace closures or go traits (at the time closures were not working as well so maybe this is not an issue either).

Re: 2017 Rust Roadmap

#125

Post by agentgt » Sat, Oct 22, 2016, 12:16 PM UTC

joshmarlow wrote: post #13

I would love to see Rust with a REPL. I use Python professionally a lot and have done a fair amount of OCaml in my spare time and both have excellent REPls in the form of `ipython` and `coretop`. Quick experiments with auto-complete is incredibly helpful for exploring a language. That's the only thing I really miss from those languages; when I want to wrap my head around a bit of syntax or a library feature in Rust,…

For languages that do not have REPLs I usually just write unit tests.

This works particularly well for Java as the Eclipse compiler iteratively compiles and most IDEs will let you run a single method.

I imagine a similar stopgap could be used for Rust. I know its not the same but in some ways I have sort of disliked REPLs because its is very easy to accidentally delete or loose what you have type and you might as well make your playing around a test (just my 2 cents).

Re: 2017 Rust Roadmap

#126

Post by fbender » Sat, Oct 22, 2016, 12:25 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?

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

Re: 2017 Rust Roadmap

#127

Post by mythz » Sat, Oct 22, 2016, 12:26 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?

Where are these benchmarks showing Go outperforming Rust? I've only seen the opposite with Rust convincingly out performing Go, it would also have more predictable performance thanks to the lack of a GC.

At a language-level Rust has generics, a better Type system and is better suited to functional programming.

Seems Systems-level programming, High-performance computing and resource-constrained embedded devices are areas where Rust would shine over Go.

Re: 2017 Rust Roadmap

#128

Post by mythz » Sat, Oct 22, 2016, 12:33 PM UTC

kjksf wrote: post #32

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…

It's also important to note that Go was designed for programmer productivity and Rust wasn't. GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management. Compile times in Go are a fraction of Rust compile times, which is another productivity boost. Go gives you one good way to do concurrency, Rust believes in tyranny of choice. Without mentioning that you don't pai…

> GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management.

Swift is a recent high-level productive language without a GC.

Re: 2017 Rust Roadmap

#129

Post by steveklabnik » Sat, Oct 22, 2016, 12:52 PM UTC

agentgt wrote: post #124

For what it's worth I hope serde or whatever default serializers are improved. I had some serious issues trying to combine libraries because of serde changing too much. Albeit this was about a year ago so it probably is fixed. Second it would be nice to see some best practices not just for libraries but application development. What to do and what not to do. Maybe a cookbook or even... design patterns. I had a hard t…

We have already landed the underlying things Serde needs to be better in nightly Rust, and it should be stable soon.

I would love to see such a thing as well; I wonder if we're not quite old enough to have said patterns really gel yet. We'll see if someone comes up with something.

Re: 2017 Rust Roadmap

#130

Post by steveklabnik » Sat, Oct 22, 2016, 12:53 PM UTC

fbender wrote: post #126

dysfunctor wrote: post #121

Earlier quoted context omitted.

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?

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