Hacker News Reader

Comment by quadcore | Hacker News Reader

I cant believe they are moving forward with "generics". Programmers on average already tend to make things more complicated than they should be. Now every single module in the ecosystem is gonna use more abstractions, generics to fit their social environment. Its well known that abstractions are the devil. How many modules are gonna use generics when they should not? Most? Programmers are bad at programming and they are social herdy beast - they are human. Their code must follow the social norm. The consequences of that could be terrible for the language.

I dont understand why they move forward with this. Go is absolutely awesome, it's a gem, adding generics is too risky. This is such a bad news for me (i didnt know). I'm trully affected.

View on HN

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.

> But it will also let good programmers write very good programs and libraries, and that's going to be a huge benefit for everyone.

I hope we can see some good examples of generics being used in the standard library once 1.18 is released.

Generics are not that complicated or hard to understand, and most of the time developers don’t even need to interact with them, except to say what type of data will be used in a collection.

> Its well known that abstractions are the devil.

Woah there. No, it is not "well known", nor is it correct. Over abstraction is very problematic (and very common), true. But under abstraction is also problematic. There is a sweet spot, and it's hard to find. But the correct answer is emphatically not "no abstraction".

That's what I meant, in compressed form. Plus we know you better err on the side of under abstracted in practice. So what I meant is we know abstraction is where the devil lies because in practice programmers tend to over abstract to look smart. With generics as for one.

> Its well known that abstractions are the devil.

Then why are you programming in Go, instead of directly writing x86-64 machine code? Remember that even assembly is an abstraction...

I think there are many very simple and understandable situations where having the option of generics gives you a lot of power. Like any programming concept, it's just another tool in the box, if you don't want to use it, don't use it. If you disagree with how others are using it, wouldn't that mean these programmers are bad in your view and you shouldn't be using their modules anyway?

Programming is always going to be complicated as long as the domain is complex. Go as is has traded having no learning curve for having nothing to offer.

I think a dumb language for dumb programs is a really valuable contribution - hardly nothing to offer.

is it less suitable for hard programs than other environments - almost certainly

Thank you, that’s an excellent point.

What it offers is that code you didn't write is significantly easier to read & understand than in most languages.

This hasn't been my experience. Go is incredibly difficult to read because all Go code looks the so similar, lacking intentionality or style, and it's so verbose that it takes a very long time to grasp what any given thing does in totality.

But code you didn’t write yourself but still have to wade through is still harder to read and understand than code that was not required to be written due to a better abstraction.

Depends entirely on how long ago I wrote it, though.

Maybe it's a style thing, but I tend to have a lot more trouble with "WTF does this (leaky, inevitably) abstraction actually do and where does that actually happen?", when reading code, than with too much code.

Reply on news.ycombinator.com