2 ms·
> 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 squin
by 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 agoyou 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 agoThat 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 agoWell 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.