[killbot5000]

I love go, but I find it did little to make concurrency management easier to reason about. Race conditions are easy to write. Go routines have all the same concurrency problems of threads.

In the parallel HTTP fetcher, the error is discarded. This will likely result in a panic when the response is nil. Also, what if it a server locks up? Or the underlying socket never connects and never times out?

I know it’s a toy example, but one must consider all these things in a real system. Go does have good pathways for these concerns, but it’s also easy to do it wrong. I still have to manually reason about access to variables/struct fields from multiple go routines.

[lanstin]

I find I have to design servers from a data flow view; when my performance demands let me do everything via channels to worker goroutine pools (including sending a response Channel back to the request handler) I don’t have to do any locking at all. I find when I have to add in mutexes it means I haven’t thought enough about the problem (or I am fixing some hot spot from the profiler, rarely).

[jesseschalken]

Its absolutely laughable that Gophers act like their language solves concurrency when its actually worse than Java because it has data races. Go added nothing and moved backwards.

The language that actually solves concurrency is Rust, but they will never acknowledge that.