If you want to write unmaintainable code in Go, it's already very easy; just use interfaces incorrectly. Go lets bad programmers write bad programs. If you have a solution to that problem, your programming language will be the one that kills all current programming languages.
Generics will be similar; people will misuse them, and you'll curse their names when you have to dive in and debug it. But it will also let good programmers write very good programs and libraries, and that's going to be a huge benefit for everyone. As we've seen with interfaces, they can be misused, but they can also be used correctly. Just look at the standard library for examples of how they work well. io.Copy() was written once and can work on buffered streams, disk files, HTTP bodies, ... anything! That's a good use of interfaces. We're going to see the same with generics, and it will make a lot of people's lives easier and more enjoyable.
Everything you say compfort me in the fact this is going to be bad. Everything I read in the article about generics compfort me in the fact this is going to be bad.
Example: first you agree with me "its already easy to write bad code", well you agree then its gonna be easier. Your example about io.Copy. Yeah bingo, absolutely io is the exception, the only case I know in 25 years of programming that is made tasteful with generics. Actually its the only case I know in 25 years of programming where a diamond-like multi inheritance structure is okay. IoBase, IoBaseRead:ioBase, IoBaseWrite:ioBase, Io:ioBaseRead, ioBaseWrite. You get the idea.
Do you realise the language grammar is modified? They are modifying Go's grammar. Man, they gotta have some balls to make virtually a new language after 12 years of success.
Im open. I am. But the idea is bad on paper, now the signs are too.
So in your opinion, should Go also not have generics for maps and channels (as they effectively do today), or are those also one of a kind data structures that are worthy of generics?
The designers of Go recognized that generic type parameters are necessary.. it’s just that they decided to only bestow them on a few types in the standard library instead of designing a general solution.
So in your opinion, should Go also not have generics for maps and channels (as they effectively do today), or are those also one of a kind data structures that are worthy of generics?
Thats exactly the proper dichotomy. Those choices were made by great language designers, not by programmers. Generics are some type of macros, of course they are useful. In some rare, very sensible cases, where the added complexity is really worth it. In the hands of programmers eager to show how smart they are, they are deadly. Code reviewers all around the world are gonna be like "why dont you use generics here?" just because they can. Bloated code, everywhere.
Go was a niche language suitable for 10x programming. It was modern C. Not C++, not java, not C#, not F#. It was C. The extraordinary, unexpected, return of C. You could write a modern server in C. You could write a modern application in C. It was amazing. It's now victim of its success and might become an industry language. As I mentionned, the grammar being changed, it's literally a new language that's being born. Go++ is being born. Why would you terminate a language which in 12 years has become one of the top 5 choices on the server?
This is not a sensible choice. This is not the choice of the hackers. This is the industry putting its dirty paws on a great piece of technology.
> Go was a niche language suitable for 10x programming.
At first I read this as "suitable for programmers who are 10x more productive than average ones". But they must be able to judge when/how to use generics.
Do you mean programming with 10x more code, or 10x more developers?
Elm kinda had such guardrails but they are hindrance, so it's all about balance (or letting them off purposely - which makes lang implementation hard as you need to compile half-broken programs). That's why I think interpreted code will win due to productivity gain or we get something that compiles even faster than Go or real hot-reload.
Generics will be similar; people will misuse them, and you'll curse their names when you have to dive in and debug it. But it will also let good programmers write very good programs and libraries, and that's going to be a huge benefit for everyone. As we've seen with interfaces, they can be misused, but they can also be used correctly. Just look at the standard library for examples of how they work well. io.Copy() was written once and can work on buffered streams, disk files, HTTP bodies, ... anything! That's a good use of interfaces. We're going to see the same with generics, and it will make a lot of people's lives easier and more enjoyable.