Type checking, mainly. Lack of generics makes the type system fairly useless. Go generate works around the code duplication caused by no generics, but exacerbates the debugging problems.
This is a tradeoff, increasing bugs and debugging time in exchange for faster compilation. I believe the developers when they say this makes sense in a 1 billion line codebase like Google's, but I've worked on 1 million line codebases and at that size debug time vastly outweighs compilation time in i.e. C#. I'm actually in a good passion to evaluate this because I worked in both C# and Java with and without Generics. Most codebases are far fewer than 1 million lines.
There were other big problems with Go last time I checked, but I haven't looked at it much in a while, so I won't venture to say more since those things might have changed.
Type system is pretty cool in go. Particularly how the interfaces work, you don't have to explicitly declare that your object /type implements an interface, it automatically figures it out.
The article you linked is deeply confused. He complains about a complicated generic type that he never encountered, and it's not clear if he's even used generics at all. He also says that if he needs to reuse something later he'll just implement an interface (huh?).
I'm afraid that's not a well-informed article. The assumption that the main use case for generics is collections is very limiting, for example. That might have been one of the original motivations, but today generic types are widely used for countless data structures and algorithms, and even modelling entire patterns of computation in languages like Haskell. They let you prove a lot more useful properties than just not inadvertently trying to pull a foo out of a set of bars.
The author makes the common mistake of assuming that subtype polymorphism can be a full replacement for parametric polymorphism. It isn't, and neither is parametric polymorphism a replacement for subtype polymorphism.
The blog author cannot even mocks generics right, in C# the string type in not a generic type. He recognize generics are good for map, list, but it is ok that users can't declare their own without explanations, only vague caricatures. Go community is all about choice-supportive bias (aka post-purchase rationalization).
>Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark.
>What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden. I find that an odd claim. I spend very little of my programming time struggling with those issues, even in languages without generic types.
>But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types.
>Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive
(He then continues to rant about inheritance, without mentioning generics again.)
So basically, Go does not have Generics and one of the creators justified it by conflating subtype polymorphism, parametric polymorphism and ad-hoc polymorphism (inheritance, generics and interfaces in oop terms).
I happen to agree with Rob Pike that inheritance is a bad way to model things in most cases, but that's a non-sequitur argument against generics.
I also think his arguments about composition is weak, especially compared to how function composition works in Haskell. The Doug McIlroy-quote he pulls out fits great with point-free style haskell, and parametric polymorphism/generics is extremely useful for this.
Generating the code leads to a lot easier debugging for me. In C++ debugging generics are annoying to put breakpoints in, since it is harder to hit the exact implementation I want (VS has a way to do this but it is a little annoying to get right). I don't mind doing that because all too often I've seen a 'generic' implementation gain more and more flags to make it less and less generic. I've only ever needed to do that a few times, the built in containers cover 95% of what I need. I came to go because I was formulating an opinion of c++, java, javascript etc and they aligned very closely to what the main team of three guys were talking about when they were first releasing it. Most of the time I never scale the application but I still love the way to solve problems in go, especially when I'm doing something in a concurrent manner.
I've also had a large (5M+ lines) C++ project that would need to be complied 3-4 times to do things like CI and automated testing. So each build taking 1-1.5 hours, which is not crazy, because of rebuilding code that is static 99% of the time mean that it is worth it to me.
C++ templates are a very idiosyncratic way of doing parametric polymorphism, and the C/C++ compilation model is even more idiosyncratic. You cannot make general statements about parametric polymorphism based on that.
Yeah each build would take about an hour, 4-5 hours for the whole CI/test to get finished. It was crossed complied so there was an MSBuild and a gcc build. It was sone in serial since we didn't want to waste time building the release if the testing or QA builds failed.
This is a tradeoff, increasing bugs and debugging time in exchange for faster compilation. I believe the developers when they say this makes sense in a 1 billion line codebase like Google's, but I've worked on 1 million line codebases and at that size debug time vastly outweighs compilation time in i.e. C#. I'm actually in a good passion to evaluate this because I worked in both C# and Java with and without Generics. Most codebases are far fewer than 1 million lines.
There were other big problems with Go last time I checked, but I haven't looked at it much in a while, so I won't venture to say more since those things might have changed.