Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fearless concurrency with Rust

blog.rust-lang.org

Post reply on HN
Print view View original

41–50 of 186 posts

Re: Fearless concurrency with Rust

#41

Post by pcwalton »

steveklabnik wrote: post #37
pcwalton wrote: post #34

Earlier quoted context omitted.

> (an explicit primary design goal, to the point where the Go compiler must be written to read each file exactly once[0], no more). Same in Rust. Thanks to the module system, the Rust compiler never rereads a file more than once. > [1] I'd need to think about this, but I don't think it'd be difficult to detect this statically[2] at compile-time and enforce that stack-allocated rvalues into channels are never used aga…

> Rust's grammar is also context-free, as far as I know. I believe bytestrings are context-sensitive :( I don't remember the exact details here, so I could be wrong. But other than that...

Oh, that's just lexing though.

Re: Fearless concurrency with Rust

#42

Post by pcwalton »

chimeracoder wrote: post #40
pcwalton wrote: post #34

Earlier quoted context omitted.

> (an explicit primary design goal, to the point where the Go compiler must be written to read each file exactly once[0], no more). Same in Rust. Thanks to the module system, the Rust compiler never rereads a file more than once. > [1] I'd need to think about this, but I don't think it'd be difficult to detect this statically[2] at compile-time and enforce that stack-allocated rvalues into channels are never used aga…

> > (an explicit primary design goal, to the point where the Go compiler must be written to read each file exactly once[0], no more). > Same in Rust. Thanks to the module system, the Rust compiler never rereads a file more than once. As I said right at the beginning of my post, I'm not trying to compare Rust and Go directly, because I don't think that's meaningful. I'm explaining why these particular features would b…

> I would otherwise be interested in having a discussion about static analysis and hearing why you think it would not solve the problem

Stack allocation isn't in the semantics of Go, so that's a pretty weird thing to use a basis of a static analysis. It's also not sound because of interfaces or closures. You would want something more like "fully by-value data with no pointers in it, no interfaces, no closures".

Re: Fearless concurrency with Rust

#43

Post by nikomatsakis »

steveklabnik wrote: post #37
pcwalton wrote: post #34

Earlier quoted context omitted.

> (an explicit primary design goal, to the point where the Go compiler must be written to read each file exactly once[0], no more). Same in Rust. Thanks to the module system, the Rust compiler never rereads a file more than once. > [1] I'd need to think about this, but I don't think it'd be difficult to detect this statically[2] at compile-time and enforce that stack-allocated rvalues into channels are never used aga…

> Rust's grammar is also context-free, as far as I know. I believe bytestrings are context-sensitive :( I don't remember the exact details here, so I could be wrong. But other than that...

Technically, byte-strings (and nested comments) mean the lexer is not regular, but the grammar is still context-free. But anyway, parsing is not typically the bottle-neck these days.

Re: Fearless concurrency with Rust

#44

Post by doublec »

jallmann wrote: post #4
rntz wrote: post #3

This post observes that > the same tools that make Rust safe also help you tackle concurrency head-on. The tools that make Rust safe, in this instance, being its ownership type system. Why on earth should that be the case? Why would ownership types make concurrency easier? The post gives plenty of in-depth answers to this question, but to my mind it misses the bigger picture. The big-picture reason why ownership type…

Fantastic explanation of linear types. Another (experimental) language that uses linear types to facilitate concurrency/parallelism is LinearML: https://github.com/pikatchu/LinearML

ATS is another language that uses linear types: http://www.ats-lang.org/

Re: Fearless concurrency with Rust

#45

Post by fny »

steveklabnik wrote: post #39
fny wrote: post #27

Earlier quoted context omitted.

Never new Rust by Example existed until today actually! You really should link to it somewhere more prominent. I'm fairly far along, but would have loved the example book had I know about it sooner.

It was originally a community project, but was then abandoned for a while, and then donated to Rust proper. As such, it's always been sort of secondary. I plan on linking it more prominently once I've actually gone through it and cleaned it up to my own personal standards, for now I just keep CI green. As such, the text has gotten out of sync with the code in a number of places, and I don't want to mislead anyone. We…

Fair enough: it's definitely not a good idea to promote something half baked.

It actually took me a while to find the link there just now. I don't think "External Documentation" really imparts the right meaning. Perhaps something like "Other Guides and Resources" would make more sense?

Re: Fearless concurrency with Rust

#46

Post by rntz »

mafribe wrote: post #35
rntz wrote: post #23

Earlier quoted context omitted.

Preventing deadlocks is not an unsolvable problem. Linear-session-typed process calculi are guaranteed deadlock-free and race-free. (The connection with Rust's ownership type-system makes me wonder if there might be some way to backport this guarantee to Rust, but I suspect the connection doesn't go far enough.) This comes at a price, however: certain process topologies are impossible to construct, and there's no way…

> Linear-session-typed process calculi are guaranteed deadlock-free and race-free While this may be true for certain restricted systems, this claim is misleading. Session types, as invented by K. Honda and refined by numerous others, guarantee deadlock and race freedom only within any given session . Session initiation (basically messages to replicated inputs) can deadlock and race in many (most?) session typing syst…

I mostly know about the linear logic side of session types; I'm not super familiar with the older line of research starting with Honda. I'll have to read up on it!

I'm not sure what the equivalent in my world of "session initiation" is. If by "replicated inputs" you mean what in linear logic is expressed by the "!" connective (often called "replication"), it's definitely possible to have ! without deadlocks or any observable nondeterminism. See Caires & Pfenning, "Session Types as Intuitionistic Linear Propositions", for example.

I already listed a few of the limitations of this approach (limited process topologies, and no `select()` analogue). I'm not sure whether these qualify as "completely inexpressive", but I do think the lack of any `select()` analogue is pretty limiting in practice. I'm not sure how hard it might be to remove that limitation, but it wouldn't surprise me if that were a major sticking point. Still, overall I think I'm more optimistic about the possibility of capturing most reasonable forms of concurrent programming in a deadlock & race-free manner.

Re: Fearless concurrency with Rust

#47

Post by steveklabnik »

fny wrote: post #45
steveklabnik wrote: post #39

Earlier quoted context omitted.

It was originally a community project, but was then abandoned for a while, and then donated to Rust proper. As such, it's always been sort of secondary. I plan on linking it more prominently once I've actually gone through it and cleaned it up to my own personal standards, for now I just keep CI green. As such, the text has gotten out of sync with the code in a number of places, and I don't want to mislead anyone. We…

Fair enough: it's definitely not a good idea to promote something half baked. It actually took me a while to find the link there just now. I don't think "External Documentation" really imparts the right meaning. Perhaps something like "Other Guides and Resources" would make more sense?

Yeah, that was written when it wasn't an official project, it should move to a different section now.

Re: Fearless concurrency with Rust

#48

Post by look_lookatme »

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.

Almost all languages are different and thus have different design goals. That doesn't mean it should be off-limits to compare them.

Re: Fearless concurrency with Rust

#49

Post by nostrademons »

chimeracoder wrote: post #40
pcwalton wrote: post #34

Earlier quoted context omitted.

> (an explicit primary design goal, to the point where the Go compiler must be written to read each file exactly once[0], no more). Same in Rust. Thanks to the module system, the Rust compiler never rereads a file more than once. > [1] I'd need to think about this, but I don't think it'd be difficult to detect this statically[2] at compile-time and enforce that stack-allocated rvalues into channels are never used aga…

> > (an explicit primary design goal, to the point where the Go compiler must be written to read each file exactly once[0], no more). > Same in Rust. Thanks to the module system, the Rust compiler never rereads a file more than once. As I said right at the beginning of my post, I'm not trying to compare Rust and Go directly, because I don't think that's meaningful. I'm explaining why these particular features would b…

Bystander here, neither upvoted nor downvoted you, but I think one reason for the skepticism is that people have hard the "It shouldn't be hard to implement X in language Y..." refrain many times before, and until somebody actually does implement X in Y, it means nothing. "It shouldn't be hard to make Python at least as fast as V8." "It shouldn't be hard to implement static typing on top of Python 3 function annotations." "It shouldn't be hard to add lambdas to Java [well, they finally did with Java 8...which we still can't use on Android]".

If it's actually not that hard, go implement a checker for Go that does check that statically-allocated rvalues are never used again, and post it here. You'll probably shoot to the top of Hacker News, it'd be a nice open-source project for the resume, and it'd provide a very useful tool for the Go community.

Re: Fearless concurrency with Rust

#50

Post by kenko »

chimeracoder wrote: post #40
pcwalton wrote: post #34

Earlier quoted context omitted.

> (an explicit primary design goal, to the point where the Go compiler must be written to read each file exactly once[0], no more). Same in Rust. Thanks to the module system, the Rust compiler never rereads a file more than once. > [1] I'd need to think about this, but I don't think it'd be difficult to detect this statically[2] at compile-time and enforce that stack-allocated rvalues into channels are never used aga…

> > (an explicit primary design goal, to the point where the Go compiler must be written to read each file exactly once[0], no more). > Same in Rust. Thanks to the module system, the Rust compiler never rereads a file more than once. As I said right at the beginning of my post, I'm not trying to compare Rust and Go directly, because I don't think that's meaningful. I'm explaining why these particular features would b…

It's impossible for your comment not to be an implicit comparison of the two. No amount of disclaiming the intention to compare can prevent that.
Post reply on HN