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

41–50 of 234 posts

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

#41

Post by _bz2r »

shadowmint wrote: post #7

This is very very long to explain a very simple pair of ideas: 1) You should be able to declare scoped blocks that mandate execution of all tasks started in that block ends when the scope ends. 2) This is fundamentally superior to all other forms of concurrency. I get it; this is basically what async/await gets you, but conceptually you can spawn parallel tasks inside an awaited block, and know, absolutely that all o…

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 are exactly right, but you haven't rebutted the fact that structured concurrency is philosophically superior.

I love rust and the community; they will get to the truth of this argument eventually. But I suspect the truth is that "njs was right", and I hope the it's sooner rather than later.

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

#42

Post by dingo_bat »

jeremiep wrote: post #3
m0meni wrote: post #2

I thought the title was kinda clickbaity, but it turned out to be a great article. Also the comparison to goto really effectively conveyed the point he was trying to make. I have two questions though: * Does anything else like this currently exist (other than the Trio library he mentions), which shows that it's a superior paradigm in practice? * What are the cons to this approach? Why not do it?

I don't think its a superior paradigm, just a different one. I only see his nursery as being useful when you really want your async tasks to complete before the function in which they were dispatched returns. That's far from covering every use case of concurrency! A lot of the value of concurrency is in background operations. These simply can't be tied to the duration of a function call on the dispatch thread. Doing…

> A lot of the value of concurrency is in background operations. These simply can't be tied to the duration of a function call on the dispatch thread.

If your background operation has those characteristics, maybe it is better to spawn a new process for it. Why a thread?

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

#43

Post by algorithmsRcool »

woah wrote: post #9

Worst title ever. I never complain about this stuff, but can someone please change it? You think it’s going to be some analysis about Go, but instead it’s someone pushing their library.

I think this article is a lot more than just "someone pushing their library"

It is well organized, written and specific about it's claims.

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

#44

Post by ptero »

I was underwhelmed by reading this (maybe due to a clickbaity title and IMO sketchy extension of badness from goto to the go statement).

That said, the article has good technical content. It proposed a new concurrency library with interesting properties. Concurrency comes with additional cost. The library proposes a paradigm to minimize certain costs and should provide punchy examples of how things can be done simply and efficiently with it.

But instead it is picking shallow fights with the go statement (does the author know about the "sync" package and WaitGroup)? Overall I found the advocacy section WAY too long. Use most of that real estate to show goodness of your library, not on trying to punch holes in the competitors. My 2c.

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

#45

Post by jeremiep »

bgorman wrote: post #37

I have yet to see any of these problems in core.async (Clojure's version of goroutines). core.async has enabled fantastic programming abstractions like async pipelines using transducers and "socket select" type programming. Perhaps functional programming is the solution to solve concurrency issues.

Clojure has HUGE advantages over Go in the first place, that helps immensely in making concurrency sane and safe. Most of the goodness in Clojure is emergent of its design, very few languages have that property.

The simple fact that Clojure can implement goroutines as a library shows how flexible the language is. Then there's immutability and a strong focus on simplicity among others.

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

#46

Post by dingo_bat »

xfer wrote: post #26
jerf wrote: post #14

Earlier quoted context omitted.

How is if different that just using goto to go to either the true or false clause? It isn't about what you can do, it's about what you can't do if you use this mechanism (this restricts where you can call spawn and join) and the guarantees you can then build on top of that.

build what on top of it? If i want a blocking thread i would just call a function.. something something goto something isn't a valid argument that applies to everything. The other way to propagate errors up is chaining promises.

> If i want a blocking thread i would just call a function

That is not what this is though.

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

#47

Post by dingo_bat »

I think this has a lot of merit. And the analogy to goto is very apt and deep. I suspect that 20 years later all our concurrency interfaces may well look like this.

However, the momentum of today's programming community may be too great to surmount. When goto was criticized, there were fewer people to convince to give up on it. Now, there are orders of magnitude more devs. And all of them are comfortable in the current way of doing things.

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

#48

Post by pknopf »

bm1362 wrote: post #31
jey wrote: post #30

I'm really growing fond of the async/await abstraction. How do I get this in more C-like languages like Go, Rust, or C++? (I have a bunch of C++ code that I want to call via C ABIs.) I'm intrigued by libdill but it's mysterious enough that I'm scared to include it in my project -- I don't want to risk getting sidetracked by having to debug my concurrency primitives.

In Go you can use waitGroups to ensure that the goroutines are completed, similar to join. You’ll have to pass a cancel chan or context if you’d like to cancel/timeout.

With that approach, you increase the number of threads being used for a single "block" by how deep your "wait" stuff goes.

In C# and Python, an async context shares a single thread loop that all joins jump back to. Simply starting a thread and waiting on it isn't suitable in most scenarios, namely web and UI dev.

I wish Go had something like this as well.

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

#49

Post by lowmagnet »

dingo_bat wrote: post #42
jeremiep wrote: post #3

Earlier quoted context omitted.

I don't think its a superior paradigm, just a different one. I only see his nursery as being useful when you really want your async tasks to complete before the function in which they were dispatched returns. That's far from covering every use case of concurrency! A lot of the value of concurrency is in background operations. These simply can't be tied to the duration of a function call on the dispatch thread. Doing…

> A lot of the value of concurrency is in background operations. These simply can't be tied to the duration of a function call on the dispatch thread. If your background operation has those characteristics, maybe it is better to spawn a new process for it. Why a thread?

I use concurrency in the form of an error group combined with an injected context and a way of propagating the cancel via that context to an exec if I we're going that route. It's a best of both worlds solution IMO.
Post reply on HN