Also updated: go with modification to support emitting warnings instead of errors when it encounters unused labels, variables, and imports (warnings do not stop compilation or production of the final binary):

https://github.com/kstenerud/go

> go1.14.2 includes fixes to cgo, the go command, the runtime, os/exec, and testing packages

Nothing interesting in these releases

That's the point of bugfix releases (x.y.Z).

normally when i see new versions on hacker news it's because there's something interesting in the patch notes, just posted that to save others the time of reading through the notes

When I see a .0 release I've come to expect a fancy new feature. When there's a minor increase, especially when there's multiple versions mentioned in the same headline, I assume there's a CVE in the patch notes.

Did they fix the import error message? That one has been a PITA on 1.14

Perhaps you could link to a bug-report, so we don't need to guess what you mean?

Not sure if there is a bug report, just something we've noticed and talked about in chat

Basically the issue is not reporting where an unused import is, just displays package name and "."

Are you using dot imports on those packages?

Then you've never been bitten by bugs in the runtime. I wait a few point releases (or when I see the runtime bugs stop being fixed) to start using a major version.

There won't be any interesting thing anytime soon due to the strong belief in the "status quo" framed as "stability" in the Go community. The people in the community (thus outside google) like me that wanted (very minor) changes are long gone.

Can you give some examples of minor changes that were rejected outright? Just curious.

I'm not really involved in the Go community, but I've read a lot of arguments about it's lack of generics.

Here's a document I've found that summarizes the discussion- I thought it was a really interesting read given my lack of background in language design - https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX...

I don't know if I'd qualify the addition of Generics as a "minor change"

That's as far of a minor change as it can be.

Is there something wrong with a stable language?

Why is there a need for features that you like from other languages?

Why do you assume they're features the parent liked from other languages rather than features to make Go a better language?

I don’t know about you, but I don’t often feel a yearning to have a brand new language feature that’s never been thought of before; if it’s never been deployed in any existing programming language, you’ve got a whole lot of ground to cover to even just prove it out.

Not sure I understand? "...a brand new language feature that’s never been thought of before..." would that even be possible?

I was referring to features that may be in various other languages and not wanting them in Go just because they were "liked from other languages." I want them in Go "because they make Go a better language."™

https://curlang.org is a langauge that comes from go but is logical and unifies. Recursion is about to be removed from the language. It's real interesting both as a project and in theory

But with no practical experience in using these features, it’s basically impossible to know anything about how they would work and whether it would lead to Go being a better language. If they did not have a positive experience with these features in other languages, and also have good reason to believe it would port over and be a good impedance match for the language and community, there’s a lot of ground work to be done.

People can debate things like the complexity of compilers, parsers, etc. till the cows come home, but at the end of the day programming languages are just as much about the users as they are the actual code and specifications. Go succeeds not because it is perfect but because it has an ethos that resonates with its userbase. There is a “Go” way of writing things: flat happy path, handle every error explicitly in some way, using struct tags to hold metadata and schema information, and so on.

Meanwhile, most people who are talking about features in Go are really talking about two things: generics and exceptions/error handling. A lot of long time Go users don’t support many such proposals. And it’s not because either of those things are awful (although I don’t like exceptions.) In fact I like and use languages with either. Rust is great no doubt, although I can not claim to be an expert. All the same, Go does not need to be another Rust.

Why not generics/better metaprogramming? Because “it’s complicated.” Go takes different trade offs like using runtime reflection at the cost of CPU cycles and type safety. It works well in many cases. Generics complicated the language, of course, but moreso, it adds a new way of solving problems in an ecosystem that has already adapted to not having generics. All kinds of things may need to be re-imagined.

This is exactly why I like the Go contracts design: it offers a very limited solution to the problems that reflection do not solve so well, without a ton of implications for the remainder of the language.

Why not error handling? Of course, as usual, it adds complexity to the language/compiler/toolchain, but I also just don’t feel like there’s a problem. Go error handling is a little verbose, but its explicit and simple. Like many other things in Go, the resulting code looks dumb, but that’s what many of us like about Go. The code is dumb and simple.

And these are all features that are pretty well explored in other programming languages that are well-liked. I can’t imagine allowing too many additional features, which become part of the language and are probably stuck as such for compatibility reasons, without a real ton of research.

Where did they go and why?