Comment by jamesmunns
1 year ago
This post discusses the issues:
https://news.ycombinator.com/item?id=38821840
It's not to say that Go is bad in this regard! It is just (always) doing the heavy lifting for you of abstracting over different colors of functions. This may have some performance or compatibility (especially wrt FFI) concerns.
Rust chose not to do this, which approach is "right" is subjective and will likely be argued elsewhere in this thread.
I don't think anyone is suggesting that Go's concurrency model is perfect. However, the OP said "trying to remove the red/blue split will not work". This is a pretty strong claim, and Go seems like a reasonable counterexample to it.
Similarly, if someone said "trying to marry async to a language with lifetime analysis and no GC will not work", it would be reasonable to point to Rust as a counterexample, even though Rust async has various problems.
The rest of the quote was:
> ...you'll only be pretending it doesn't exist
Which is what I was providing evidence of that Go does.
It removes coloring to the user by handling it under the hood. The linked article calls this "colorblind instead of colorless".
Sure. My point is that 'pretending that the distinction doesn't exist' (aka 'abstracting away from it', in less loaded language) does in fact work. Go's concurrency model is perfectly usable and successfully reaps many of the advantages of M:N scheduling.
Let's look at a less loaded example:
"Trying to remove the distinction between stack and heap allocation will not work, and you'll only be pretending that it doesn't exist."
It's true that on some level there's going to be a distinction between stack and heap allocation. But it totally does work to abstract away from this distinction ('pretend that it doesn't exist'). Go, for example, will usually allocate non-escaping values on the stack, but unless you are tweaking your code for performance, you'll never have to worry about this.
From the blog:
> There are two key drawbacks to this otherwise interesting and useful decision. First, Go can't have exceptions. Second, Go does not have the ability to synchronize tasks in real (wall clock) time. Both of these drawbacks stem from Go's emphasis on coroutines.
1) Go can't have exceptions? What exactly are panics, if not a peculiar implementation of exceptions? They print stack trace of the panicking goroutine, just like exceptions print stack traces of the thread they are thrown in. What exactly is the difference?
2) For real-time workloads, you can pin goroutine to an OS thread and use a spinlock. How does this make it different than in any other language?
> Since goroutine stacks are thus made disparate -- goroutines do not "share" common "ancestor" stack frames like Scheme's continuations do -- they can unwind their own stacks. However, this also means that when a goroutine is spawned, it has no memory of its parent, nor the parent for the child. This has already been noticed by other thinkers as a bad thing.
Goroutines are made to resemble lightweight threads. Maybe the author considers threads bad, but that's just a subjective opinion. But-- at the end of the blog, there's a sentence:
> OS threads provide some very nice constructs for programmers, and are hardened, battle-tested tools.
Goroutines provide almost exactly the same semantics as OS threads, so I don't really get what they're trying to say.
> Consider something of a converse scenario: Goroutine a spawns a goroutine b, without using an anonymous function this time. No closure, just a simple function spawn. Coroutine a opens a database connection. Goroutine b panics, crashing the program. The database connection is then left open as a zombie TCP connection.
On any sane OS, when the program crashes, the kernel closes the TCP connection - there is no such thing as a "zombie" TCP connection.
With all due respect to whoever the author is, I think this blogpost is full of crap.
UnixODBC in Go?? Zombie TCP connections from a crashing program. The author is clueless on these subjects. Not worth arguing over a misinformed blog post.