Fearless concurrency with Rust • Hacker News Board

Re: Fearless concurrency with Rust

#51

Post by ajross » Fri, Apr 10, 2015, 7:21 PM UTC

chimeracoder wrote: post #29

Animats wrote: post #12

Rust's ownership model, and the borrow checker that enforces it, are a major breakthrough in language design. It's so simple, yet it solves so many problems. This is what Go should have done. Then Go's "share by communicating, not by sharing" would be real, not PR. Go code often passes references over channels, which results in shared memory between two threads with no locking. In Rust, when you do that, you pass own…

First, please don't compare Go and Rust. They are completely different languages with completely different target use cases. Go has very different design goals than Rust, so very little that Rust does would actually be possible in Go, and vice versa. > Go code often passes references over channels, which results in shared memory between two threads with no locking Having a complex type system would cut into compile t…

> First, please don't compare Go and Rust. They are completely different languages with completely different target use cases.

Then why does everyone insist on comparing Rust and C++? Objectively Rust is much closer to Go than to C++.

That's just dumb. Rust and Go were, in fact, contemporarily designed to similar constraints and with similar goals. That they made significantly different design choices is an interesting point that should be discussed and not swept under the rug just to win internet points.

Re: Fearless concurrency with Rust

#52

Post by detrino » Fri, Apr 10, 2015, 7:24 PM UTC

chimeracoder wrote: post #29

Animats wrote: post #12

Rust's ownership model, and the borrow checker that enforces it, are a major breakthrough in language design. It's so simple, yet it solves so many problems. This is what Go should have done. Then Go's "share by communicating, not by sharing" would be real, not PR. Go code often passes references over channels, which results in shared memory between two threads with no locking. In Rust, when you do that, you pass own…

First, please don't compare Go and Rust. They are completely different languages with completely different target use cases. Go has very different design goals than Rust, so very little that Rust does would actually be possible in Go, and vice versa. > Go code often passes references over channels, which results in shared memory between two threads with no locking Having a complex type system would cut into compile t…

> First, please don't compare Go and Rust. They are completely different languages with completely different target use cases. Go has very different design goals than Rust, so very little that Rust does would actually be possible in Go, and vice versa.

It's perfectly reasonable to compare any two programming languages, especially where their use cases overlap.

> As for the code you're referring to, Go is not designed to be a language which prevents you from shooting yourself in the foot with provable code. It's designed to be a language which makes it reasonably easy to be sure you haven't, as long as you follow the general idioms and best practices. What you're describing here is definitely not one - I can think of a few instances in which pointers might be reasonably passed over a channel, but they're few and far between.

Absolutely sure is better than reasonable sure.

Re: Fearless concurrency with Rust

#53

Post by Jweb_Guru » Fri, Apr 10, 2015, 7:32 PM UTC

ajross wrote: post #51

chimeracoder wrote: post #29

Earlier quoted context omitted.

First, please don't compare Go and Rust. They are completely different languages with completely different target use cases. Go has very different design goals than Rust, so very little that Rust does would actually be possible in Go, and vice versa. > Go code often passes references over channels, which results in shared memory between two threads with no locking Having a complex type system would cut into compile t…

> First, please don't compare Go and Rust. They are completely different languages with completely different target use cases. Then why does everyone insist on comparing Rust and C++? Objectively Rust is much closer to Go than to C++. That's just dumb. Rust and Go were, in fact, contemporarily designed to similar constraints and with similar goals. That they made significantly different design choices is an interesti…

At the language level, Rust is substantially more similar to C++ than it is to Go. C++ and Rust both have many properties (lack of GC, pervasive stack allocation [even for closures], move semantics, overhead-free C FFI compatibility) that many other languages lack, and the Rust developers actively work to match C++ on features. None of this is true for Go; Rust's similarities with Go are shared by many other languages as well, many of which are much more widely used than either (hence would probably represent a more informative comparison; e.g. I think posts contrasting Rust and Java would be quite useful, but I have seen very few of them). As such, Go and Rust comparisons tend not to be very illuminating.

Re: Fearless concurrency with Rust

#54

Post by shortstuffsushi » Fri, Apr 10, 2015, 7:34 PM UTC

rationalthug wrote: post #19

Animats wrote: post #12

Rust's ownership model, and the borrow checker that enforces it, are a major breakthrough in language design. It's so simple, yet it solves so many problems. This is what Go should have done. Then Go's "share by communicating, not by sharing" would be real, not PR. Go code often passes references over channels, which results in shared memory between two threads with no locking. In Rust, when you do that, you pass own…

On a somewhat interesting note: transferable objects work similarly in web workers. There have been complaints, of course, that this makes it impossible to take advantage of shared memory in cases where it provides clear performance benefits.

Wouldn't the concept of borrowing avoid that issue in Rust though?

Re: Fearless concurrency with Rust

#55

Post by jbandela1 » Fri, Apr 10, 2015, 7:35 PM UTC

carllerche wrote: post #15

Rust has definitely been a pleasure to work with. I have been experimenting with a Future & Stream [1] abstraction in Rust that would allow easily describing complex concurrent and async operations and to allow easy composition, not unlike ES 6 promises. The interesting thing is that, thanks to Rust's ownership system, it is easy to discover when handles to a future value go out of scope. This allows the library to r…

Just looked at eventual. It seems really interesting. I looked at Rust's std Future and was turned off by the fact that is blocking.

Re: Fearless concurrency with Rust

#56

Post by mkehrt » Fri, Apr 10, 2015, 7:37 PM UTC

steveklabnik wrote: post #18

Animats wrote: post #12

Rust's ownership model, and the borrow checker that enforces it, are a major breakthrough in language design. It's so simple, yet it solves so many problems. This is what Go should have done. Then Go's "share by communicating, not by sharing" would be real, not PR. Go code often passes references over channels, which results in shared memory between two threads with no locking. In Rust, when you do that, you pass own…

> It's so simple, I think that in hindsight, this may be true, but it took a _very_ long time to figure it out. It took _years_ of iteration before we got to where we are today, and the previous work in this space, which used regions but not borrowing, didn't go further because of the ergonomic issues. In retrospect, hard things often seem obvious, but that's because the work was already done!

I'm pretty sure Cyclone used both regions and borrowing in ~2005. But it was a research project and not meant for wide use.

Re: Fearless concurrency with Rust

#57

Post by MichaelGG » Fri, Apr 10, 2015, 7:38 PM UTC

steveklabnik wrote: post #18

Animats wrote: post #12

Rust's ownership model, and the borrow checker that enforces it, are a major breakthrough in language design. It's so simple, yet it solves so many problems. This is what Go should have done. Then Go's "share by communicating, not by sharing" would be real, not PR. Go code often passes references over channels, which results in shared memory between two threads with no locking. In Rust, when you do that, you pass own…

> It's so simple, I think that in hindsight, this may be true, but it took a _very_ long time to figure it out. It took _years_ of iteration before we got to where we are today, and the previous work in this space, which used regions but not borrowing, didn't go further because of the ergonomic issues. In retrospect, hard things often seem obvious, but that's because the work was already done!

Exactly! I came to Rust thinking I knew all I needed due to trying to solve the same things by hand in the CLR. Like I figured I had a pretty good idea what I needed to allow F# to have fast memory management.

And while the core idea is correct, holy shit there's so many details that the Rust team has had to deal with and iterate over and reduce until it's nice. I suppose this is why the CLR and everyone just punt on the whole issue.

Re: Fearless concurrency with Rust

#58

Post by steveklabnik » Fri, Apr 10, 2015, 7:44 PM UTC

mkehrt wrote: post #56

steveklabnik wrote: post #18

Earlier quoted context omitted.

> It's so simple, I think that in hindsight, this may be true, but it took a _very_ long time to figure it out. It took _years_ of iteration before we got to where we are today, and the previous work in this space, which used regions but not borrowing, didn't go further because of the ergonomic issues. In retrospect, hard things often seem obvious, but that's because the work was already done!

I'm pretty sure Cyclone used both regions and borrowing in ~2005. But it was a research project and not meant for wide use.

I thought Cyclone only used regions, but I haven't read the paper in a while. (and dates from 2002 IIRC)

It certainly had a big influence on Rust, we're fans of the work.

Re: Fearless concurrency with Rust

#59

Post by pcwalton » Fri, Apr 10, 2015, 7:45 PM UTC

Jweb_Guru wrote: post #53

ajross wrote: post #51

Earlier quoted context omitted.

> First, please don't compare Go and Rust. They are completely different languages with completely different target use cases. Then why does everyone insist on comparing Rust and C++? Objectively Rust is much closer to Go than to C++. That's just dumb. Rust and Go were, in fact, contemporarily designed to similar constraints and with similar goals. That they made significantly different design choices is an interesti…

At the language level, Rust is substantially more similar to C++ than it is to Go. C++ and Rust both have many properties (lack of GC, pervasive stack allocation [even for closures], move semantics, overhead-free C FFI compatibility) that many other languages lack, and the Rust developers actively work to match C++ on features. None of this is true for Go; Rust's similarities with Go are shared by many other language…

> At the language level, Rust is substantially more similar to C++ than it is to Go. C++ and Rust both have many properties (lack of GC, pervasive stack allocation [even for closures], move semantics, overhead-free C FFI compatibility) that many other languages lack, and the Rust developers actively work to match C++ on features.

I think this is absolutely true, for what it's worth.

Re: Fearless concurrency with Rust

#60

Post by pcwalton » Fri, Apr 10, 2015, 7:46 PM UTC

shortstuffsushi wrote: post #54

rationalthug wrote: post #19

Earlier quoted context omitted.

On a somewhat interesting note: transferable objects work similarly in web workers. There have been complaints, of course, that this makes it impossible to take advantage of shared memory in cases where it provides clear performance benefits.

Wouldn't the concept of borrowing avoid that issue in Rust though?

Actually, atomics and locks (which are fully supported) are what avoid that issue in Rust. You can't borrow across multiple threads.