Comment by smokey_circles | Hacker News Reader

Comment by smokey_circles | Hacker News Reader

This opinion is just gross. Always do your required reading kids.

- nobody uses semi colons, that's a huge red flag because the tooling will literally remove these symbols from your code, did you even run any go code? clearly not

- goroutines are not threads and galloping past that obvious chasm is also telling: you're not really sure what these magical things are but, somehow, you know they're bad. this is a flawed line of reasoning that was never going to convince me

- because you don't know how goroutines and the userspace scheduler work, you skip over all the benefits they provide and thusly nurseries give me nothing than a hand holding experience less effective than the existing tools I have. Thank you for wasting my time because I was genuinely holding out for _any_ kind of empirical reasoning. My mistake.

- As proof of the author's research negligence: Not a single mention of channels. Not one. Homework was clearly not completed

I'm all for debating a language's efficacy and tradeoffs, but not when the opposing side has no idea how anything works. Then it's not a debate, it's just the ignorant proclaiming a need to interfere with others. Go away, please.

- Channels are woefully inefficient. I usually use the stdlib as a good reference for performant code, and I don’t see any use of channels in there.

- If you’re not using channels because they are slow, now you’re letting some nebulous “context” bleed into every function to handle closure and cancellation. This is basically provided implicitly by the nursery concept, but stapled on to every function in go because it was an afterthought, then google started using it, so it’s everywhere.

- The Unscoped nature of go routines does make the program more complex to reason about.

I think you read a different article, or read stuff into it that the author was not talking about.

This is about contrasting structured vs unstructured concurrency. The language, the threading model, how threads communicate and coordinate ... none of them are germane to the issue.

Wherever you have a fork without a join in the same scope, it is unstructured and gives rise to some concurrency issues.

Structured concurrency promotes composition, similar to ordinary function composition. For ordinary functions, the caller's control flow is logically blocked from proceeding until the callee is done. Similarly, in a structured concurrent setup, a function is logically blocked from proceeding until the tasks it spawned have finished and returned to the spawning scope. This makes it easier to reason sequentially. "finish doing a bunch of tasks, then do this, then do that" etc. The key word here is 'finish'. Not 'spawn a bunch of tasks in the background'. One can then reason about the effect of the function and all its nested tasks as a single unit.

The most elegant example is Occam, where SEQ and PAR are language constructs. (For those interested: http://www.transputer.net/obooks/72-occ-046-00/tuinocc.pdf)

This is not a go vs non-go debate. This is a structured concurrency discussion. Threads and goroutines are both forms of concurrency so they can be discussed together.

1. Complaining about syntactic style

2. Inferring that the author doesn’t know what threads really are when they could just be using slightly different terminology than yourself (i.e. terminology where “threads” are not narrowly defined as “OS threads”)

3. Just based on the bad inferrence in (2) + complaining about they did not appreciate goroutines enough + complaining about “hand holding”

4. Proof that the author is incompetent: they didn’t even mention this one particular concurrency construct. Cherry-pick ergo preconceived conclusion

Unsolicited inferrence by myself: peeved that the author said that `go` was harmful—even though the author also said that this is a general problem—, and thus you needed to concoct some half-assed arguments in order to justify making a reply.

Are you being facetious or did you just not read the post? (I need to ask, because it's not at all obvious!)

Reply on news.ycombinator.com