I feel about the same way the author does. I've written one largish (large for a 3 man team) production codebase in go (as well as numerous side projects). At

I feel about the same way the author does. I've written one largish (large for a 3 man team) production codebase in go (as well as numerous side projects). At first I loved it--it was simple, and I really loved the fact that it compiles to a native binary. I also really liked gofmt. But looking back through what the code has evolved into 2 years later, a huge portion of it is essentially copy and paste code to work around the lack of generics. Another large portion is copy and paste error handling. I was essentially using go to fill several niches. I wanted a higher level language to handle business logic, but I also needed to work with serial ports, and I wanted something that would run fast with a small memory footprint. Go seemed to fit the bill perfectly, but eventually go started to feel like jack of all trades master of non type of thing. Since I had to eventually rewrite my serial port code in C anyway, I think I would have been better choosing a language with more modern features for the rest of the project. Maybe it's because I've been using F# (and C# to a lesser extent) lately, but I just don't think I want to go back.