>> it’s an anti-pattern for libraries to start their own goroutines The specific argument here is that by writing sync functions, the library is more abstract

>> it’s an anti-pattern for libraries to start their own goroutines The specific argument here is that by writing sync functions, the library is more abstract because the caller can decide whether to run the function sync or async. I agree with this, but there are lots of areas where we could issue guidance to make libraries more abstract. For example, instead of a library function which returns a pointer to allocated memory (e.g., `NewFoo() Foo`) we should write functions which take pointers to memory and the caller can figure out whether to allocate them on the stack or the heap (e.g., `NewFoo(out Foo)`). I'm not advocating for this as a general rule of thumb because writing that kind of code in Go would not be very ergonomic, but there's a lot of performance-sensitive code even in the standard library that is written that way. Another example would be 'inversion of control', wherein functions take interface parameters and callers decide what implementation to pass in.