Increasing language surface area will generally increase the complexity of all api surfaces written in the language. This has obvious costs.

It’s true genetics will shrink some specific APIs, where they are a good fit.

But they will also be used opportunistically by developers excited to push their boundaries.

Of course you can say “just don’t do that” which works if you have a tightly controlled codebase. But most code is not that, and will be handed off to novices over and over for fixes.

So, it’s a question of whether you cater to the advanced developer who can capably handle a vast toolset, or do you commit as a community to more rudimentary tools, in order to reap the rewards of systemic simplicity.

There is no right answer.

I believe in the future all languages will fork into a simpler novice subset for general use and an expansive language for infrastructure. These will both be valid in the same parser, but the subset will be quarantined at the package management level.

Go, EZ-Go, C, EZ-C, etc

I am writing all of my code in EZ-JS

It’s C’s lack of complexity which makes it necessary to do dangerous things for everyday purposes. I’d much rather a novice interact with generics, where the compiler is a safety net, than with void * and interface{}.

void * and interface{} are not going away when generics come. Try searching for "Object" or "<?>" in some Java code...

Which is why Go 1's type system was a bad decision. interface{} should have never existed in the first place.

At least it'll definitely get rarer.

>> It’s C’s lack of complexity which makes it necessary to do dangerous things for everyday purposes.

That's not the case anymore. We have C++ which has generics and "fixed" C's lack of complexity for sure...Now for some 'weird' reasons some people still use C. Wonder why ?

Compare C++ to Standard ML. Simplicity is compatible with generics.

It is not the case since 1993, when CFront was dropped.

In certain domains like UNIX like OSes, I don't see C ever going away, due to the infrastructure, symbiotic relation with the OS that gave it birth, and the culture.

> Of course you can say “just don’t do that”

This exactly. The beauty of Go is that currently you do not need a book called "Go, The Good Parts".

Yes, generics would make a lot of things easier, but almost everything more complex and footgunnish.

>I believe in the future all languages will fork into a simpler novice subset for general use and an expansive language for infrastructure. These will both be valid in the same parser, but the subset will be quarantined at the package management level.

I don't think we'll see this happen much for existing languages, but it could be a very interesting angle for a newly-designed language (or rather pair of languages).

To some extent this is already happening in languages popular for machine learning. Libraries are written in C/C++ and the users just glue things together with very accessible API's.

It’s already happening. For example many people code in a subset of C++.

Although ultimately I do want generics in Go I am afraid they will make the language more difficult to use and understand. Generics in c++, c#, scala, java, etc all tend toward being very complex and change the way programs are written.

The focus moves towards a taxonomy of types and developers (myself included) sometimes get stuck on difficult type problems. There's something about trying to preserve type safety which sets the bar extremely high for bypassing the type system when there's not an easy solution and before you know it you've wasted 2 or 3 days writing code which doesn't actually do anything but placate the compiler.

And often that type-safe concoction you create is almost indecipherable when you come back to it later.

For example here's a project I worked on recently which cached a concrete version of a generated method using generics:

https://github.com/DataDog/dd-trace-dotnet/blob/develop/src/...

Used like this:

    var originalMethod = DynamicMethodBuilder<Func<object, byte[][], object, object, bool, T>>
               .GetOrCreateMethodCallDelegate(
                    redisNativeClient.GetType(),
                    "SendReceive",
                    methodGenericArguments: new[] { typeof(T) });

At least for me that was really hard to figure out how to do and I still have to squint to see what the heck its doing. The non-generic version wasn't type-safe and it wasn't as fast, but it sure was a lot easier to read and understand.

And to give some sense of the complexity involved, Rob Pike mentioned in his talk that the proposal spec for adding generics to Go is longer than the spec for the entire language.

I think the complexity is worth it, but I just hope we can be cautious about how and where generics get used in real-world code, otherwise we'll end up with gobbledy-gook that only experts can decipher... and that would be really sad, because the promise of Go was a language normal engineers could be productive with.

>Generics in c++, c#, scala, java

They're not all the same though are they.

C++/CLI had both compile-time generics (templates) from C++, and run-time generics from the CLR. And they could be complementary at times.

For compile-time generics, Dlang are a lot more sane that C++, having had the benefit of coming later, and dumping C compatability.

Similarly, CLR (C#, ...) generics had the benefit of being designed having seen Java first, so IIRC they're baked into the CLR. CKR generics were derived from work done at MS Research Cambridge, and I seem to remember Don Syme (F# creator) being rather proud of them. Disclosure: I was contracting at MSR Cambridge back in 2007.

Anyway, the golang designers will be aware of these implementations, so hopefully they'll come up with a nice design.

I'll answer from my perspective.

I don't hate generics. I see the value of generics, especially after having worked with Go for so long; I've had to do some mental gymnastics to get around not having proper generic collections.

That being said, I'm not excited about seeing generics in other people's code. The added complexity doesn't really solve problems I have anymore.

That being said, I'm actually way less excited about overloading.

I think generics and function overloading is going to make me think "where the hell is this coming from?" a lot more often and then I'm going to need to load it up in my IDE, or vim with way too many plugins, and start following definitions.

I think the main fear people have isn't the concept of generics, but the implementation of generics. Go's primary goal is simplicity, and implementing generics isn't simple.

But like I said, Go doesn't have an answer for generics. So the complexity just lives in userland code instead of the language itself. The problem and complexity doesn't go away.

If the choice is between badly implemented generics, and having the problem manifested as userland code, I'll take the latter. I've actually had to debug C++ production code produced by the confluence of templates that had no source code of it's own. At least with boilerplate, you can simply see what's going on right there.

If language features were free we'd likely have had generics for a long time now. Unfortunately generics is a trade-off: you get development speed/ease and pay for it in compile time, binary size and/or execution speed.

This seems to be slowly changing, but Go was designed to be a solution to Google problems - python being slow but some c++ applications taking literal hours to compile. Keeping that perspective in mind makes it easier to understand why Go maintainers have not accepted an implementation of generics into the language yet.

If you maintain type safety, you'll pay in increased compile times with or without generics. You'll either hand-roll an implementation for each type (https://golang.org/pkg/sort/) or you'll generate code before actually compiling. The problem doesn't go away.

It's people that have seen the abuses of C++ templates. They're very powerful and therefore people tend to want to use them for really complicated things.

Look up things like SFINAE and compile time metaprogramming. Templates were not intended for those things. When they work they're ok, but if they go wrong good luck following the 10 line error message.

Here's an example from Rust:

https://www.reddit.com/r/rust/comments/5nifpm/they_said_rust...

That's what people don't want.

That's not compile time metaprogramming at all, it's just series of wrapped closures. It's basically the sequence of function call names preceding that call backwards, with different capitalization.

The big difference between C++ and Rust is that, when you scroll down in this Reddit thread, it shows that the Rust guys have a clear path for fixing this issue, whereas there is no fix for this in C++ (that I'm aware of).

Ha ha, "10 line error". [ Puts on Monty Python voice] "What I wouldn't give for a 10 line error..."

Incautious use of the template mechanism - or just a minor typo - has given me couple screenfuls in the past.

Any sufficiently advanced type system can be used for compile-time metaprogramming - that's just an inevitable side effect of a type system expressive enough to capture all the more convoluted (but still plenty common) cases without hacks like interface{}.

I'm of 2 minds. I come from a Java background so I've personally wanted generics. ORM's are 1 use case that comes to mind.

But. There are many modern languages that already have generics. Why can't Go be that one that doesn't cave in and remains powerful in its niche and perhaps may never be the preferred tool in other areas? Why must it be useful for web development, microservices, DAL, etc.?

Any implementation of generics in Go will come with complexity tradeoffs.

I feel like the community learns more about languages and software engineering when we maintain language diversity and see the pros and cons of each approach in practice.

I want generics for selfish reasons, but would also like to see how a modern strongly-typed language solves problems without it.

As someone who quite likes generics, I'd love to see how a modern strongly-typed language solves problems without them. And I think that's what the Go community and developers have been trying to do up until now. It looks like they're giving up. I'm not sure whether we'll ever find another way to tackle composition/scalability as effectively as generics do, but such a technique would be fascinating to see.

For me at least, the reluctance comes from the new proposal process not having yet proved itself for large backwards-incompatible features. I want to be assured that a Go with generics is a Go with a really well-integrated feature, and not some grafted mutant appendage whose only real purpose is to appease the greater community.

It's great that they're trying out the process on smaller, more simple proposals. My hope is that this system will either produce really good features, or reveal that there are simply no satisfying solutions.

Coming up with a complex solution is much easier than finding a simple one. Go forces you to find those simple solutions. There are places where generics are the only solution, but they also enable lazy design.