@lanzafame: I found this article on Go precisely summed up my own frustrations with Go's limitations: http://bravenewgeek.com/go-is-unapologetically-flawed-heres-why-we-use-it/ It manages to go over the drawbacks in reasonably balanced way and addresses it as a matter of tradeoffs.

I too, would no longer use Go by choice in most contexts, though

@bo: Cheers. I have read that article before and I agree that it is a well balanced write up on the trade-offs. I guess for me the trade-offs are worth it for the project I am working on. Not saying I wouldn’t love generics, but I like goroutines and the different ways you can solve problems with them.

sure; in my experience they are less of the golden bullet than advertised, but they're a step in the right direction

at the end of the day the shared mutable state can still exist and so can deadlocks between goroutines

no great model for single-write, multi-read chan messaging has also been a frustration of mine in the past

makes it really hard to model kind of "pubsub" style communication between routines or clients

at the end of the day, it's not the lack of generics itself, so much as the lack of good tools of abstraction in general. You can't participate in their slice or map abstraction at all, for instance. In practice I find most non-trivial Go code ends up using empty interfaces to completely bypass the type system because of its limitations.

Well I will see how I go. I will report back in a week or two as to whether I have had any major run-ins with the issues mentioned.

@lanzafame: I'd definitely be interested in that!