> Your entire codebase is now a surface area that is at risk of being blocked

The point of goroutines is that they can freely block when needed. It's not like async where you have to be paranoid at every moment about writing blocking code

▲

sheept an hour ago | parent | next [-]

Why would there be paranoia when writing blocking code with async?

The downside of goroutines is that you have no control when the goroutine context switches, so naively accessing a global value can lead to race conditions (which the language has no warnings for despite being such a concurrent language), while the same code works fine in JavaScript because context switches don't happen in synchronous code.

▲

assbuttbuttass 44 minutes ago | parent [-]

> Why would there be paranoia when writing blocking code with async?

In languages like JavaScript, you have to be careful to avoid blocking the event loop, and use something like worker threads for CPU-intensive tasks. Otherwise you will end up with long tail latencies. In Go, the runtime automatically manages this and can suspend and resume long-running goroutines.

> naively accessing a global value can lead to race conditions

Fair point that the language doesn't automatically catch this, but that's what a mutex is for. In return you get actual parallelism that can use all your CPU cores

	▲	Jtsummers 30 minutes ago \| parent [-]
		Amusingly, Go, a language designed for concurrent programming, also had problems with blocking code for years. They had two releases that fixed it with proper preemption (1.2 added preemption, and 1.14 fixed other issues with preemption).

▲

stymaar 2 hours ago | parent | prev [-]

You can only freely block the goroutines that you designed that way, there's plenty of ways of shooting yourself in the foot with goroutines without even touching “blocking” code (because everything is blocking).