Fearless concurrency with Rust • Hacker News Board

Re: Fearless concurrency with Rust

#61

Post by ademarre » Fri, Apr 10, 2015, 7:49 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…

Rust and Java? Not the usefulness you're looking for, but this tool popped up on HN today: http://rosetta.alhur.es/compare/Rust/Java/#

Re: Fearless concurrency with Rust

#62

Post by codahale » Fri, Apr 10, 2015, 7:50 PM UTC

steveklabnik wrote: post #20

jewel wrote: post #17

Sorry if I'm missing something obvious, but how do these locks stop a deadlock from happening? To explain, say that I have some code that locks A, then locks B, then does something, and another bit of code that locks B, then locks A, then does its thing. There's a race condition that can happen where one thread has A and the other thread has B. This has bitten me so much that I avoid fine-grained locking when possibl…

> Sorry if I'm missing something obvious, but how do these locks stop a deadlock from happening? This is the difference between a data race and a race condition. We can't generally prevent deadlocks, I would imagine that's (like all race conditions) is an unsolvable problem at the language level. Maybe some PhD will prove me right or wrong, though...

That said, the ergonomics of the mutex design and the ownership system would probably eliminate most of the race conditions I've seen. Lock ordering can be effectively established by nesting mutexes: e.g. `Mutex)>` allows you to establish that any locking of Y has already locked X.

Re: Fearless concurrency with Rust

#63

Post by djur » Fri, Apr 10, 2015, 7:51 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…

What objective criteria are you using by which Rust is much closer to Go? Go being garbage collected and Rust/C++ not being seems like a much larger gap than anything between Rust and C++.

Re: Fearless concurrency with Rust

#64

Post by dilap » Fri, Apr 10, 2015, 7:54 PM UTC

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…

"Should have done" is a silly phrase to use here -- Rust is attempting to advance the state of the art, Go was attempting to use only very-well-understood ideas to make a very-well-understood, simple language.

Perhaps some day we will see a successor language that follows the philosophy of Go using the new stuff we understand thanks to Rust.

Re: Fearless concurrency with Rust

#65

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

ademarre wrote: post #61

Jweb_Guru wrote: post #53

Earlier quoted context omitted.

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…

Rust and Java? Not the usefulness you're looking for, but this tool popped up on HN today: http://rosetta.alhur.es/compare/Rust/Java/#

The Rust on Rosetta code is exceedingly old. There's a community project to update the examples, but they're waiting until 1.0 to move upstream, so as not to cause them too much churn.

Re: Fearless concurrency with Rust

#66

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

pcwalton wrote: post #60

shortstuffsushi wrote: post #54

Earlier quoted context omitted.

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.

You can now with scoped threads, provided that you don't require mutation.

Re: Fearless concurrency with Rust

#67

Post by sanderjd » Fri, Apr 10, 2015, 7:58 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…

Rust is very similar to modern C++, just without backwards compatibility considerations, and with the (fantastic, IMO) additions of compiler-enforced ownership rules and generics instead of templates, which makes certain type checking work better.

Re: Fearless concurrency with Rust

#68

Post by steveklabnik » Fri, Apr 10, 2015, 8:01 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…

> Having a complex type system would cut into compile times

At least in Rust, type checking takes basically no time compared to things like optimization passes.

Re: Fearless concurrency with Rust

#69

Post by mkehrt » Fri, Apr 10, 2015, 8:11 PM UTC

steveklabnik wrote: post #58

mkehrt wrote: post #56

Earlier quoted context omitted.

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.

It looks like you're right.

I had an undergrad senior thesis in 2006 that futzed around with regions and borrowing, and I know I read some papers on their interactions, but I'm not immediately finding anything chasing references.

edit: Of course, I don't mean to diminish the accomplishments of Rust, which had turned these moving parts into a working language. In particular, Rust makes it easy to ignore these issues most of the time.

Re: Fearless concurrency with Rust

#70

Post by loudmax » Fri, Apr 10, 2015, 8:12 PM UTC

look_lookatme wrote: post #48

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. Go has very different design goals than Rust, so very little that Rust does would actually be possible in Go, and vice versa. Almost all languages are different and thus have different design goals. That doesn't mean it should be off-limits to compare them.

Yeah, but instead of having an interesting discussion about Rust, much of the thread devolves into a pissing contest.