Hacker News Reader

Comment by haolez | Hacker News Reader

I’m starting to think that I’m in the minority that agrees with most (if not all) Go’s design decision and appreciate Rob Pike’s stewardship so far.

View on HN

I'm in the opposite camp from you — I like generics, lack of null, and syntax highlighting — but that's fine! I don't think this is something we have to 'agree' or 'disagree' with. It simply means that you're within Go's target market. If you want to use a simple language, and the software you're writing works just fine without these features in your code, then of course it's OK to jettison them and stick with the simple language. I need those features because of the software I write, so I need to stick with a more feature-ful language.

Acting like there needs to be some 'one true way' when we're writing completely different pieces of software is how pointless internet arguments get started.

The problem is not all of us get to choose the language we work in and sometimes someone picks a language for all the wrong reasons and then you're stuck with it because a rewrite is costly and usually not an option.

So these debates do have some merit.

You're right, and that is unfortunate. But "people sometimes make the wrong decisions" is a much tougher nut to crack!

I agree that we should have these debates — but on a "is this language acceptable for my use case" level, not a "is this language acceptable for any use cases" level.

This. So much. I would really hope that folks could accept that different languages have different objectives, and that this is good. The problem I've seen is that there's always a feature creep by folks that like more expressiveness; "This is a solved problem and not an issue at all! You must make it a part of the language!". So there's some kind of inherent pursuit of conformity given enough adoption.

That’s true, but there are a lot of beautiful and featureful programming languages out there, and possibly only Go in the “simplicity above features” camp. I disagree with the move towards Go 2 by introducing genetics and whatnot. If I really want those features, I know where to get them.

Depends on who's opinion we're talking about.

In general, Go community is satisfied with its direction according to 2018 survey: https://blog.golang.org/survey2018-results

In my experience, most harsh criticism comes from those who either barely used Go if at all or tried to build something Go wasn't aimed for.

> In my experience, most harsh criticism comes from those who either barely used Go if at all or tried to build something Go wasn't aimed for.

How do you know the harsh critics of Go you read barely used Go at all? What things did harsh critics try to build with Go that it wasn't aimed for, and/or what is the most frequent wrong thing those critics try to build with Go?

I think it's worth pointing out that the current objections to Generics in Go have nothing to do with them being too complicated for programmers. The summary is [1]:

> The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times?

Here "slow programmers" means, "do you want a language without generics". Both quick compilation and quick execution are first-order goals of Go, so people are loathe to give them up.

[1] https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX...

That’s possible, in the early days of Go I guess they spent a lot of time trying to optimize the compiler with googles ML teams

Reply on news.ycombinator.com