5 ms·

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 singl

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.

brokencode 5y ago
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.
ohCh6zos 5y ago
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.
- convolvatron 5y ago
  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
  - ohCh6zos 5y ago
    Thank you, that’s an excellent point.
- handrous 5y ago
  What it offers is that code you didn't write is significantly easier to read & understand than in most languages.
  - ohCh6zos 5y ago
    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.
  - kaba0 5y ago
    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.
    - handrous 5y ago
      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.
noah_buddy 5y ago
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?
jrockway 5y ago
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.
- machiaweliczny 5y ago
  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.
- quadcore 5y ago
  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.
  - deleted 5y ago
adwn 5y ago
> 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...
AnimalMuppet 5y ago
> 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".
- quadcore 5y ago
  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.

brokencode 5y ago

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.

ohCh6zos 5y ago

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.

convolvatron 5y ago
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
- ohCh6zos 5y ago
  Thank you, that’s an excellent point.
handrous 5y ago
What it offers is that code you didn't write is significantly easier to read & understand than in most languages.
- ohCh6zos 5y ago
  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.
- kaba0 5y ago
  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.
  - handrous 5y ago
    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.

noah_buddy 5y ago

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?

jrockway 5y ago

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.

machiaweliczny 5y ago
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.
quadcore 5y ago
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.
- deleted 5y ago

adwn 5y ago

> 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...

AnimalMuppet 5y ago

> 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".

quadcore 5y ago
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.