Hacker News Reader

Comment by jimmyed | Hacker News Reader

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.

View on HN

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/

Wasn't the ability to add a //go:generate comment enough to make it easy to re-generate anything that you needed?

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.

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

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

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.

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.

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.python.org/dev/peps/pep-0622/

https://www.infoq.com/articles/java-pattern-matching/

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.

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.

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

And yet PHP, Java and C# MVC web apps looks all the same in both syntax and structure. Same syntax for interfaces, classes, namespaces, entity models, query builders, controllers, views and so on. A modern Symfony application looks almost the same as a Spring one.

They are all similar enough that a programmer fluent in one can start writing code in the style they are familiar with in another. Remember the old saying, "You can write FORTRAN in any language[1]"? Well, with the aforementioned set of languages, you can write one of them in another and it doesn't even look wrong.

[1] https://blog.codinghorror.com/you-can-write-fortran-in-any-l...

They are all similar enough that a programmer fluent in one can start writing code in the style they are familiar with in another ... with the aforementioned set of languages, you can write one of them in another and it doesn't even look wrong.

1. Only superficially, because they all share the same basic flow-control constructs and (except for Python) the same C-inspired syntax. They all have totally different standard libraries, package ecosystems, etc.

2. I don't see what makes Go exempt, other than "wow great they didn't add generics bless the Go core team."

Go was built as a language to make communicating sequential processes[1] first-class citizens. Thus the ubiquity of channels and goroutines. No locks, no condition variables, no callbacks[2]. Writing a bunch of code using locks and callbacks in Go goes against the grain of the language.

[1]https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf

[2]https://www.youtube.com/watch?v=f6kdp27TYZs

That's not entirely a bad thing.

We've learned a lot about language ergonomics in the past forty-nine years. Generics are super useful. Lambdas and streams can cut down on a lot of boilerplate. Immutables make code easier to reason about.

And I'm glad that I have access to all of those things in Java. I'm not upset that my workday language is being polluted by outside influences, because I'm not a purist, I'm a programmer. I don't care that records were lifted from Scala and Kotlin ... I care about how they can make my code better.

The idea that we should deprive ourselves of useful features because it makes languages too similar makes no sense to me.

You should watch the talk - I actually happened to do so yesterday so it's still in my mind.

The point is not that they're withholding features because it makes the language too similar to others, and I'm sure that's not what you were really thinking the argument is either. The thing they're trying to focus on is that with ever increasing amount of features, you have an ever increasing amount of complexity added, which has implications on the amount of conversations, decisions, readability and difficulty your team is going to have when tackling any given problem. It can really just be boiled down to increasing features past what is needed can be considered bloat, which does not come free to a developer or team's collective consciousness.

To quote/paraphrase from the 5:10 mark of his talk...

"If a language has too many features, or even more than you might need, you spend time programming thinking about which features to use... you might even spend half an hour messing with a few lines of code to [see how a given feature fits into the solution]... [and even more, when you revisit that code, you have to get back into the thought process you initially went through when determining which features to use]."

That's certainly fair. I was just talking to someone about how it used to be possible to hold the entire Java ecosystem in your head at once, but that was probably 15 years ago.

On the other hand, adding language complexity can decrease program complexity a great deal. Generics are the prime example of this. If you see List<Foo> and List<Bar>, you know exactly how both work. But if you see FooList and BarList, you might have to stop and worry about how each is individually implemented.

Or the whole "while is spelled for in Go" thing. Sure, they managed to strike out one whole keyword from their language, but anyone coming from another language is going to have a momentary brain skip while they try to figure out why that is, and how they need to re-write their while loop as a for-loop-but-not.

I was with you till the List<x>, but writing the while loop as a for loop is controversial. C'mon man. That is second nature for anyone programming for a few weeks.

This is a seductive argument, but unless you're making everything from scratch and working purely on greenfield projects, there is so much more complexity involved in learning the specifics of the local system and code you're working on than there is in learning the language(s) it's written in.

Heck, even if you're greenfield 100% of the time, the way the OS, the networking stack, the browser, any runtime support libraries you depend on, all work plus just figuring out how to model the problem you're trying to solve is still more complicated than the actual programming language.

Or you could see that languages have use cases, use cases overlap, languages should adopt useful tools for their use cases, therefore languages will often adopt the same tools as other languages with overlapping use cases.

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.

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.

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

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

Reply on news.ycombinator.com