[kuschku]

Yes, exactly. This is an actual issue.

My system is usually designed that I provide a function that generates a value of type T, a function to filter T (T -> boolean), and a way to display Ts.

So, the library now gets these functions, and does all the filtering on other threads.

So either I have to replicate the entire async code for every type, or I can’t keep type safety.

[rogpeppe1]

Don't keep type safety then. Think of Go as half-way between Python and Haskell in that respect. Types are great when they're useful, but they're not required.

[kuschku]

If you’re serious, that’s... the worst solution I’ve heard yet.

That’s the same mistake C did with void, Java did with Object and corrected with generics in 1.5, just called interface{} this time.

And while with python and Java, even if I circumvent the type system, I can still use annotations (see typed python, or JetBrains @Contract, Google’s @IntRange, etc), with Go I have nothing of that sort.

Types are useful to provide safety, if your type system has to be turnt off, then I am losing all that safety, and might as well code in PHP (although they also* saw that mistake, and are fixing it now, with 7.0 and later).