9 ms·

I remember Rob Pike talking about how each language has its own way of doing things and it's bad to keep adding all features to all languages. This only makes t

I remember Rob Pike talking about how each language has its own way of doing things and it's bad to keep adding all features to all languages. This only makes them all end up being the same he said. The Go way was code generation. After they included generics, I wonder if the go team has let go of that principle.

shaan7 6y ago
Code generation only solved part of the problem - saving the trouble of having to write repetitive code. It does not solve the maintainability problem because if something needs to change then you need to manually change all the generated code. I have been using Go since last ~6 years and I'm really excited that the only pain point I had with Go will soon go away \o/
- abatilo 6y ago
  Wasn't the ability to add a //go:generate comment enough to make it easy to re-generate anything that you needed?
  - isaiahg 6y ago
    Generation is a rather big solution for sometimes small problems. For many things like utility functions I think generics are much more readable and easier to understand while go generate would be heavy handed.
throwaway189262 6y ago
Yet Go's code generation is clunky even compared with Java's Annotation Processors.
hu3 6y ago
Considering how long and how much discussion it took to implement generics (coming in 1.18 according to FAQ [1]), I'd be inclined to say it supports their principle. I don't think they ever said they wouldn't implement Generics. It was a matter of maturing and consideration of different proposals. [1] https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics
pansa2 6y ago
Here’s a quote from Rob Pike (in 2015) about what Go was trying to avoid: "Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] actively borrow features from one another. They are converging into a single huge language." https://www.dotconferences.com/2015/11/rob-pike-simplicity-is-complicated https://www.dotconferences.com/2015/11/rob-pike-simplicity-i...
- nerdponx 6y ago
  It's 2021, the convergence still hasn't happened yet. It's never going to happen. I know Rob Pike is probably smarter than me, but this a bad hot take in 2015, and it's outright stinky in 2021.
  - ozkatz 6y ago
    6 years is not a lot of time if you examine the progress of modern programming languages. These languages are more similar to one another than they were 6 years ago. I don't know if it was meant to be taken literally, but I definitely don't think it's "outright stinky" to claim convergence.
  - Thaxll 6y ago
    Well look at patern matching for example, they're all adding that. Isn't that convergence? https://www.php.net/manual/en/control-structures.match.php https://www.php.net/manual/en/control-structures.match.php https://www.python.org/dev/peps/pep-0622/ https://www.python.org/dev/peps/pep-0622/ https://www.infoq.com/articles/java-pattern-matching/ https://www.infoq.com/articles/java-pattern-matching/ https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/may/csharp-8-0-pattern-matching-in-csharp-8-0 https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/... I could go on with various topics, immutability etc ... It's pretty clear that in the past 10 years language evolved more quickly and borrow concepts from other languages.
    - nerdponx 6y ago
      Languages evolving and borrowing good ideas from each other* is not the same thing as hyperbolically sneering at some of the most popular programming languages in the world because they're supposedly all converging into one single language, which they never were doing and never will do. *Note that the new Python pattern matching has a somewhat controversial design, and it probably won't see significant adoption in the wild for several years, if ever.
dkarl 6y ago
You can think of generics as providing support for a simple, common form of code generation in the language itself. That might not be technically precisely correct, but looking at it that way makes it seem like not a radical change at all.
Thaxll 6y ago
10 years later the language is still the same, not much has changed, I can't say the same about Rust, C#, Java, PHP, Python etc ... The only major thing that came in the last couple of years was Go module, and it's more on the tooling side than the language itself.
streblo 6y ago
> it's bad to keep adding all features to all languages I understand the reasoning behind this take - a lot of modern languages have wound up somewhat bloated, with features that are either non-orthogonal to other features and break the 'one way to do it' principle (Scala comes to mind), or with features that seem tacked-on and feel alien to the language (the latest versions of python come to mind). I understand, in theory, why go tries to buck this trend. The problem is that in bucking this trend, go has (at least historically) not evolved enough to fix some of its own core issues. And it does have some big issues - nils, zero values, and non-thread safe primitives come to mind for me. I'm all for being thoughtful about introducing changes and making sure those changes are idiomatic and don't violate the 'ethos of go'. But avoiding making those changes in the name of 'keeping it simple' never made sense to me in cases where programmers are shooting themselves in the feet and already not having a simple time with your language.

shaan7 6y ago

Code generation only solved part of the problem - saving the trouble of having to write repetitive code. It does not solve the maintainability problem because if something needs to change then you need to manually change all the generated code. I have been using Go since last ~6 years and I'm really excited that the only pain point I had with Go will soon go away \o/

abatilo 6y ago
Wasn't the ability to add a //go:generate comment enough to make it easy to re-generate anything that you needed?
- isaiahg 6y ago
  Generation is a rather big solution for sometimes small problems. For many things like utility functions I think generics are much more readable and easier to understand while go generate would be heavy handed.

throwaway189262 6y ago

Yet Go's code generation is clunky even compared with Java's Annotation Processors.

hu3 6y ago

Considering how long and how much discussion it took to implement generics (coming in 1.18 according to FAQ [1]), I'd be inclined to say it supports their principle. I don't think they ever said they wouldn't implement Generics. It was a matter of maturing and consideration of different proposals. [1] https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics

pansa2 6y ago

Here’s a quote from Rob Pike (in 2015) about what Go was trying to avoid: "Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] actively borrow features from one another. They are converging into a single huge language." https://www.dotconferences.com/2015/11/rob-pike-simplicity-is-complicated https://www.dotconferences.com/2015/11/rob-pike-simplicity-i...

nerdponx 6y ago
It's 2021, the convergence still hasn't happened yet. It's never going to happen. I know Rob Pike is probably smarter than me, but this a bad hot take in 2015, and it's outright stinky in 2021.
- ozkatz 6y ago
  6 years is not a lot of time if you examine the progress of modern programming languages. These languages are more similar to one another than they were 6 years ago. I don't know if it was meant to be taken literally, but I definitely don't think it's "outright stinky" to claim convergence.
- Thaxll 6y ago
  Well look at patern matching for example, they're all adding that. Isn't that convergence? https://www.php.net/manual/en/control-structures.match.php https://www.php.net/manual/en/control-structures.match.php https://www.python.org/dev/peps/pep-0622/ https://www.python.org/dev/peps/pep-0622/ https://www.infoq.com/articles/java-pattern-matching/ https://www.infoq.com/articles/java-pattern-matching/ https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/may/csharp-8-0-pattern-matching-in-csharp-8-0 https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/... I could go on with various topics, immutability etc ... It's pretty clear that in the past 10 years language evolved more quickly and borrow concepts from other languages.
  - nerdponx 6y ago
    Languages evolving and borrowing good ideas from each other* is not the same thing as hyperbolically sneering at some of the most popular programming languages in the world because they're supposedly all converging into one single language, which they never were doing and never will do. *Note that the new Python pattern matching has a somewhat controversial design, and it probably won't see significant adoption in the wild for several years, if ever.

dkarl 6y ago

You can think of generics as providing support for a simple, common form of code generation in the language itself. That might not be technically precisely correct, but looking at it that way makes it seem like not a radical change at all.

Thaxll 6y ago

10 years later the language is still the same, not much has changed, I can't say the same about Rust, C#, Java, PHP, Python etc ... The only major thing that came in the last couple of years was Go module, and it's more on the tooling side than the language itself.

streblo 6y ago

> it's bad to keep adding all features to all languages I understand the reasoning behind this take - a lot of modern languages have wound up somewhat bloated, with features that are either non-orthogonal to other features and break the 'one way to do it' principle (Scala comes to mind), or with features that seem tacked-on and feel alien to the language (the latest versions of python come to mind). I understand, in theory, why go tries to buck this trend. The problem is that in bucking this trend, go has (at least historically) not evolved enough to fix some of its own core issues. And it does have some big issues - nils, zero values, and non-thread safe primitives come to mind for me. I'm all for being thoughtful about introducing changes and making sure those changes are idiomatic and don't violate the 'ethos of go'. But avoiding making those changes in the name of 'keeping it simple' never made sense to me in cases where programmers are shooting themselves in the feet and already not having a simple time with your language.