Goroutines and APIs

I think that it is universal advice for libraries: do not do multithreading inside, let the client code do it and&#x2F;or pass necessary constructs.<p>Simple example for Java: do not create executorservice instances inside of a library, but allow client code to pass them.<p>Ayende wrote much better than me long time ago <a href="https:&#x2F;&#x2F;ayende.com&#x2F;blog&#x2F;159201&#x2F;multi-threaded-design-guidelines-for-libraries-part-i" rel="nofollow">https:&#x2F;&#x2F;ayende.com&#x2F;blog&#x2F;159201&#x2F;multi-threaded-design-guideli...</a>

The blog seems sadly unable to tolerate the load. I don&#x27;t see an archived version of the post anywhere either.<p>If I had to have a guess what it says, it&#x27;s probably something along the lines of:<p>* Don&#x27;t require users of your API to start goroutines to use your API correctly.<p>If Goroutines need to be started for your API to work, start them in an init function, on first use, or via some other mechanism.<p>* If possible, avoid high goroutine fanout in your implementation.<p>If a single request to your API fans out to 1k goroutines, it&#x27;s going to be a problem for a high-traffic user of your API. Especially if there are other APIs that make the same design choice. As ever, try to be parsimonious with resource consumption.<p>IMO, these are two good principles to live by, and not just in Go.

In general, decouple libraries from use case dependent assumptions. This holds true not just for concurrency, but for memory management, sockets, file streams etc. Don&#x27;t assume that a per-object heap allocation is good enough for me. Don&#x27;t assume that I want to serialize to a file system. Don&#x27;t assume that a channel has a large enough buffer.

Some operations can use green threads, while others need kernel threads. Last I tried (~2015) Go would spawn unlimited kernel threads, so function callers had to know whether a call required a kernel thread or not, and rate-limit appropriately.<p>Is this still the case? How does modern Go handle operations which require kernel threads?

I can&#x27;t read the article but hopefully it does not ironically present advice on writing webservers.<p>There is really little excuse for a web server to buckle under pressure these days - hackernews sends a spike of traffic but not enough to kill even a moderately spec&#x27;ed server.

The problem with goroutines is that an unhandled crash can cause a shutdown, and if the goroutine is started by a badly-written library with no proper recovery, you are dead.

&quot;threads&quot; (goroutines) and channels are the new gotos. They tend to make a codebase more difficult to reason about. The more you add, the more you tend to get spooky action at a distance.