5 ms·

Go is the poster child for not having structured concurrency, the article that started this movement was an explicit take down of go’s concurrency primitive “go

Go is the poster child for not having structured concurrency, the article that started this movement was an explicit take down of go’s concurrency primitive “go func” being dangerous. https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g... I think Kotlin still leads here, and even the Java changes don’t have the same nice ergonomics you get with Kotlin’s DSL. Would love to see more tenseness from Kotlin leak into Java.

pjmlp 2y ago
Yet, like most Go design decisions, they will end up retrofiting what should have been there. Kotlin has the issue of being a guest language, and wanting to play in many playgrounds, eventually it will diverge as it always happens. As it is already happening, like now how will Kotlin async deal with virtual threads expectations, including writing portable code that doesn't suffer from runtime semantics, depending on the target platform.
- MarkMarine 2y ago
  Something better than making everyone take context as the first arg in every function? It’s go’s own brute force way of function coloring, except you have to write it yourself and drag this arbitrary bag of data through every function, what a horrible stapled-on mess.
yubblegum 2y ago
> explicit take down of ... "go func" I stopped at "go statements are a form of goto statement." This is simply not correct. They have some diagrams and squinted and said "hey, that looks the same as a goto statement", but unfortunatley they have their diagrams wrong. "go func" will run at scheduler's pleasure, not immediately after the statement "go func..". A goto statement is a deterministic flow control directive. It will goto where you tell it.
- MarkMarine 2y ago
  you should have read the rest of it then, because in the context of Dijkstra's famous paper [0] (that this is written in the style of) the argument here is being able to understand program flow in the programmers' mind. Your description of the go func actually makes it WORSE, because the program doesn't just go there, it goes there later. [0] https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.p...
  - yubblegum 2y ago
    That may be true, but regardless, it is most definitely nothing like a goto and it is misleading. & Yes I have read Dijkstra and as it happens have my own critical views regarding Go's goroutines (which are really inspired by CSP), but just don't appreciate misleading assertions. To wit, "flow" does not really make sense in context of concurrency. Flows, plural, sure ..
    - MarkMarine 2y ago
      Well fair, but I do think you should give this article a read. It’s the genesis of kotlin’s coroutines, and other implementations of “structured concurrency” or nurseries as the author conceives of them.

pjmlp 2y ago

Yet, like most Go design decisions, they will end up retrofiting what should have been there. Kotlin has the issue of being a guest language, and wanting to play in many playgrounds, eventually it will diverge as it always happens. As it is already happening, like now how will Kotlin async deal with virtual threads expectations, including writing portable code that doesn't suffer from runtime semantics, depending on the target platform.

MarkMarine 2y ago
Something better than making everyone take context as the first arg in every function? It’s go’s own brute force way of function coloring, except you have to write it yourself and drag this arbitrary bag of data through every function, what a horrible stapled-on mess.

yubblegum 2y ago

> explicit take down of ... "go func" I stopped at "go statements are a form of goto statement." This is simply not correct. They have some diagrams and squinted and said "hey, that looks the same as a goto statement", but unfortunatley they have their diagrams wrong. "go func" will run at scheduler's pleasure, not immediately after the statement "go func..". A goto statement is a deterministic flow control directive. It will goto where you tell it.

MarkMarine 2y ago
you should have read the rest of it then, because in the context of Dijkstra's famous paper [0] (that this is written in the style of) the argument here is being able to understand program flow in the programmers' mind. Your description of the go func actually makes it WORSE, because the program doesn't just go there, it goes there later. [0] https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.p...
- yubblegum 2y ago
  That may be true, but regardless, it is most definitely nothing like a goto and it is misleading. & Yes I have read Dijkstra and as it happens have my own critical views regarding Go's goroutines (which are really inspired by CSP), but just don't appreciate misleading assertions. To wit, "flow" does not really make sense in context of concurrency. Flows, plural, sure ..
  - MarkMarine 2y ago
    Well fair, but I do think you should give this article a read. It’s the genesis of kotlin’s coroutines, and other implementations of “structured concurrency” or nurseries as the author conceives of them.