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

Notes on structured concurrency, or: Go statement considered harmful

vorpus.org

Post reply on HN
Print view View original

71–80 of 234 posts

Re: Notes on structured concurrency, or: Go statement considered harmful

#71

Post by jeremiep »

scott_s wrote: post #68
jeremiep wrote: post #65

Earlier quoted context omitted.

Whats the difference between taking a nursery and returning a promise? Both put the context in the signature, but the later is actually composable.

When I call a function, I have no way of knowing if there are any unhandled promises within it. The difference is the restriction: with nurseries, background tasks can only outlive function calls if the calling function allows them to.

I get compile-time warnings or runtime errors when I create unhandled promises. What more is needed?

Re: Notes on structured concurrency, or: Go statement considered harmful

#72

Post by iainmerrick »

wilun wrote: post #59
_bz2r wrote: post #41

Earlier quoted context omitted.

The article makes a strong case. Even if rust allows formal verification, not all programmers use it, and if you use their library, you don't know if it's been verified. Take it back to the goto analogy: can you formally verify goto? Yes. Does that mean it's good to include as a language primitive? No. You are basically taking an entire argument, ignoring its merits, and saying "but you can do it another way". You ar…

It's not only that Rust allows formal verification, it's that it does it by default, writing unsafe Rust code for no serious reason is fundamentally frowned upon, and even then there is a serious effort to bring some tooling to bring more confidence even on "unsafe" Rust code. > But I suspect the truth is that "njs was right", and I hope the it's sooner rather than later. I'm not sure. The problem can and has been so…

“Formal verification” for Rust code -- does that actually exist yet, or do people just hope/assume that the language will be proven consistent and that awesome theorem-checking tools will emerge eventually?

I agree that Rust has a great model that seems to lead to very solid code, but “formal verification” is a high bar to clear.

Re: Notes on structured concurrency, or: Go statement considered harmful

#73

Post by m0meni »

erpellan wrote: post #40

The author appears to have reinvented Communicating Sequential Processes (CSP). http://www.usingcsp.com/cspbook.pdf The (simplified, and as I understand it) gist of concurrency in CSP is that the program is expressed as a series of parallel (PAR) and sequential (SEQ) operations. Everything in a PAR block will run in parallel and all their outputs will be collected and fed as the input to the next SEQ. Everything in a…

This misses the point of the article. It's short-sighted to say that he's reinvented CSP given that the entire concurrency model in Go is based around CSP, and the author is already aware of it. The article is more related to RAII, scope, lifetimes, etc. than any model of concurrency.

Re: Notes on structured concurrency, or: Go statement considered harmful

#74

Post by ufmace »

I found it an interesting idea and writeup. It'd be good to see what could be done in a language that implemented this - concurrency only allowed in the context of nurseries. On the downside, though, I think there's a lot of concurrency patterns that could only be implemented by creating a nursery near the top level of the application and passing it around all over the place, thus getting you pretty much right back where you started.

Want a web app that sets up some long-running thing to run in the background while the request returns quickly? Well then you're going to need a nursery above the level of the request which is still available to every request. I don't see what that gives you above conventional threading. Oh, and you'd also need to implement your own runner in a thread to have a task failure not bring down the whole application.

Re: Notes on structured concurrency, or: Go statement considered harmful

#75

Post by scott_s »

jeremiep wrote: post #71
scott_s wrote: post #68

Earlier quoted context omitted.

When I call a function, I have no way of knowing if there are any unhandled promises within it. The difference is the restriction: with nurseries, background tasks can only outlive function calls if the calling function allows them to.

I get compile-time warnings or runtime errors when I create unhandled promises. What more is needed?

Needed is a strong word, but what this provides are guarantees when reading the code. Much like you know that control flow will come back to the function you're reading after calling another function. We didn't need to know that control flow will resume in the calling function, but it turned out to be very useful.

Re: Notes on structured concurrency, or: Go statement considered harmful

#76

Post by pnathan »

Article persuasive prima facie and arguments plausible. I've had to reinvent a structured method of managing threads a number of times, unfortunately.

Author is a PhD student, which bodes well for not reinventing wheels dumbly. Therefore, I look forward to the lit review of other concurrency & parallelism work through the last 40 years, which this writeup notably lacks (author mentions his stack of papers to review).

Your ideas are intriguing to me and I wish to subscribe to your newsletter.

ed: author has phd, not is a student.

Re: Notes on structured concurrency, or: Go statement considered harmful

#77

Post by vishvananda »

themihai wrote: post #61

Well they lost me at the callbacks... if go statements are harmful and callbacks are not then I rather prefer the harmful way.

You might want to read further. He didn't claim that callbacks are not harmful. In fact he suggested that they suffer from the same problems and he is using "go statements" to encompass all of the forms of concurrency handling.

Re: Notes on structured concurrency, or: Go statement considered harmful

#78

Post by mpweiher »

m0meni wrote: post #73
erpellan wrote: post #40

The author appears to have reinvented Communicating Sequential Processes (CSP). http://www.usingcsp.com/cspbook.pdf The (simplified, and as I understand it) gist of concurrency in CSP is that the program is expressed as a series of parallel (PAR) and sequential (SEQ) operations. Everything in a PAR block will run in parallel and all their outputs will be collected and fed as the input to the next SEQ. Everything in a…

This misses the point of the article. It's short-sighted to say that he's reinvented CSP given that the entire concurrency model in Go is based around CSP, and the author is already aware of it. The article is more related to RAII, scope, lifetimes, etc. than any model of concurrency.

Channels are lifted from CSP, but PAR is obviously missing.

Re: Notes on structured concurrency, or: Go statement considered harmful

#79

Post by zbobet2012 »

mpweiher wrote: post #78
m0meni wrote: post #73

Earlier quoted context omitted.

This misses the point of the article. It's short-sighted to say that he's reinvented CSP given that the entire concurrency model in Go is based around CSP, and the author is already aware of it. The article is more related to RAII, scope, lifetimes, etc. than any model of concurrency.

Channels are lifted from CSP, but PAR is obviously missing.

par is "select" effectively. While that isn't 100% the case, it is true.

Re: Notes on structured concurrency, or: Go statement considered harmful

#80

Post by mpweiher »

zbobet2012 wrote: post #79
mpweiher wrote: post #78

Earlier quoted context omitted.

Channels are lifted from CSP, but PAR is obviously missing.

par is "select" effectively. While that isn't 100% the case, it is true.

Huh? I thought "select" was "ALT"??
Post reply on HN