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

91–100 of 234 posts

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

#91

Post by acjohnson55 »

_Codemonkeyism wrote: post #87

The main culprit to me in Golang seems to be channels, not goroutines. If your workflow essentially is defined by a mesh of channels and goroutines, it's hard to reason or understand. I have no direct practical knowledge of Golang, but working on a large application that used BlockingQueue for concurrent communication and one which extensively used services buses for communication - both were hard to understand and r…

I think the article's point is that with Future's you can still pretty easily invoke a Future-returning function and forget to return its value, ending up with what you might call an orphan continuation.

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

#92

Post by nemothekid »

pknopf wrote: post #58
nemothekid wrote: post #53

Earlier quoted context omitted.

In Go it doesn't really matter how many "threads" you have because Go has its lightweight threading model (aka coroutines) - creating a new "thread" is very cheap. The reason C#, Python (and Rust), have that model is because they don't have coroutines and starting another thread is very expensive.

The built in thread pools must have a limit. Also, this isn't just a matter of keeping thread resources down, it's supporting scenarios like developing web and UI software. For example, if I have "OnButtonClick" and it does async work, I'd like to also call other functions that may also touch UI components. WPF has support for binding async actions to UI events, and it eliminates the need to ever wonder what thread y…

>The built in thread pools must have a limit.

The go runtime has been shown to handle millions of goroutines, and there are performant and scalable programs, like Cloudflare's RRDNS that run tens of thousands of goroutines (https://blog.cloudflare.com/quick-and-dirty-annotations-for-...). There's plenty of web software using this model written in Go.

I haven't done UI programming in Go - but in your example, I'd imagine you could simply have an event launch a goroutine - you could do whatever you want in that routine without blocking the main thread and simply pass a message back to the main thread if needed. Managing the number of goroutines isn't something you have to think about in go.

`Task.Factory`, and `Task.Run` still create threads, OS threads, which are different and much, much heavier than goroutines. You'd run out of memory trying to create 1000 OS threads, where as 1000 goroutines are a walk in the park (not just for Go, but for most runtimes using M:N threading).

async/await does have it's advantages over coroutine style concurrency, but I wouldn't count thread count as one of them.

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

#93

Post by acjohnson55 »

jaffee wrote: post #22

I LOVE Go's concurrency model, but this article has won me over (pending some experimentation anyway). If you just skimmed, this is actually worth a careful read. The parallels between "go" and "goto" are explained very clearly, and you get some awesome Dijkstra quotes to boot!

I think people are missing the merits of what the author said in their defensiveness of their existing approaches, which is a bit sad.

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

#94

Post by pnathan »

lilyball wrote: post #86
pnathan wrote: post #76

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).…

> Author is a PhD student, which bodes well for not reinventing wheels dumbly. Except that's exactly what the author did. They just reinvented scoped threadpools.

I hesitate to say that's all they did. There's a context & concept of structuring concurrency that they are building.

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

#95

Post by marshray »

jerf wrote: post #20
cousin_it wrote: post #5

Didn't expect to say this, but the article is completely right! This is obviously the right way to write concurrent programs. Kudos for writing this. One question though. The first part of the article says that "onclick" handlers should be replaced with nurseries as well. But I don't see how. Can someone explain?

I suspect that if you were to try to do this in real code, something like an onclick handler would have to be run in a nursery scoped at the page level, by the code running the page. An onclick handler on its own accord can't run itself in the correct nursery. It's like the network handling case there, where the nursery's lifetime is either unbounded, or tied to the lifetime of the OS process, depending on how you wa…

Maybe a subtle difference here is that a page doesn't get to block on anything before it gets closed.

So how is creating a nursery that matches the lifetime and visibility of the page different from not using a nursery at all?

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

#96

Post by z0r »

acjohnson55 wrote: post #91
_Codemonkeyism wrote: post #87

The main culprit to me in Golang seems to be channels, not goroutines. If your workflow essentially is defined by a mesh of channels and goroutines, it's hard to reason or understand. I have no direct practical knowledge of Golang, but working on a large application that used BlockingQueue for concurrent communication and one which extensively used services buses for communication - both were hard to understand and r…

I think the article's point is that with Future's you can still pretty easily invoke a Future-returning function and forget to return its value, ending up with what you might call an orphan continuation.

Wouldn't the unreferenced Future, once fulfilled, be garbage collected?

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

#97

Post by wilun »

iainmerrick wrote: post #72
wilun wrote: post #59

Earlier quoted context omitted.

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.

Well, you are right, it is not really "formal verification".

But I don't know how to call it, and it is way more checked on some aspects (well, obviously, we are not talking about checking each program against a spec...) that the competition. And by that, I mean that the competition is actually not even trying...

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

#98

Post by mikeurbach »

iainmerrick wrote: post #72
wilun wrote: post #59

Earlier quoted context omitted.

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.

Some people are actively working on formal verification for Rust. The RustBelt project is the first that jumps to mind. A paper and some discussion here: https://news.ycombinator.com/item?id=16302530

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

#99

Post by zamalek »

arghwhat wrote: post #19

What. This article proposes a "nursery", which is just a wrapped sync.WaitGroup/pthread_join/futures::future::join_all/a reactor that waits for all tasks to terminate/etc. It then uses an exception-like model for error propagation to "solve" error handling (which is fairly easy to handle with a channel). The construct is a decently usable, already applied tool to handle a set of problems, but the article takes the is…

Agree with everything. I think the misunderstanding here is that goroutines are not classical threads (which would share many problems with `goto`) - they exist somewhere between coroutines and actors (because of channels+select). Actors are an established and mature solution to many headaches surrounding concurrency and parallelism.

Goroutines share more in common with method calls (which are a form of branching) and even with single-threaded scenarios, methods can do surprising things - especially if you have shared global state.

Additionally, if you control how data is shared (such as message passing - channels) you shouldn't have to be concerned about what the other thread is doing - so long as it reacts to messages that you send to it.

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

#100

Post by zbobet2012 »

kolpa wrote: post #83
mpweiher wrote: post #80

Earlier quoted context omitted.

Huh? I thought "select" was "ALT"??

'go' is PAR with different syntax (Everything after the 'go' line is implicitly one branch of the PAR) 'select' is ALT

That's correct apologies.
Post reply on HN