The 'Go' Team Releases Version 1.14 (devclass.com) 13
The new 1.14 release of the Go programming language "is dotted with performance and security improvements," reports the developer news site DevClass, "but also gives devs more flexibility when it comes to module use."
And they also give a nice overview of Go's development process: Go is the language most containerization projects are built with. The wide adoption of this approach is one of the reasons that made the Go team implement a new feedback-based system for language enhancements. In it, only a limited number of new features are proposed for an upcoming release, giving the community room to weigh in on them. If they decide a change will do more good than harm the feature will make it into the new version. However, since alterations affect a quite wide range of people, they are often heavily disputed. This already led to the abandoning of a proposal thought to improve the language's often discussed error handling. Currently, a couple of new vet checks and minor adjustments are discussed for the 1.15 release.
Updates in Go 1.14 mainly concern the toolchain, runtime, and libraries. The only change to the language allows for methods of embedded interfaces to have the same name and signature as those on the embedding interface. Supposedly to facilitate the creation of somewhat safer applications, version 1.14 includes a hash/maphash package. The hash functions on byte sequences contained in it are meant to help with the implementation of hash tables or similar data structures. The Go team warns though that "the hash functions are collision-resistant but not cryptographically secure...."
Go 1.14 is the last release to run on macOS 10.11 and support 32-bit binaries on Apple's operating system. Meanwhile binaries for Windows come with data execution prevention enabled, experimental support for 64-bit RISC-V on Linux is included, and v1.14 should work with 64-bit ARM architecture on FreeBSD 12.0 or later.
And they also give a nice overview of Go's development process: Go is the language most containerization projects are built with. The wide adoption of this approach is one of the reasons that made the Go team implement a new feedback-based system for language enhancements. In it, only a limited number of new features are proposed for an upcoming release, giving the community room to weigh in on them. If they decide a change will do more good than harm the feature will make it into the new version. However, since alterations affect a quite wide range of people, they are often heavily disputed. This already led to the abandoning of a proposal thought to improve the language's often discussed error handling. Currently, a couple of new vet checks and minor adjustments are discussed for the 1.15 release.
Updates in Go 1.14 mainly concern the toolchain, runtime, and libraries. The only change to the language allows for methods of embedded interfaces to have the same name and signature as those on the embedding interface. Supposedly to facilitate the creation of somewhat safer applications, version 1.14 includes a hash/maphash package. The hash functions on byte sequences contained in it are meant to help with the implementation of hash tables or similar data structures. The Go team warns though that "the hash functions are collision-resistant but not cryptographically secure...."
Go 1.14 is the last release to run on macOS 10.11 and support 32-bit binaries on Apple's operating system. Meanwhile binaries for Windows come with data execution prevention enabled, experimental support for 64-bit RISC-V on Linux is included, and v1.14 should work with 64-bit ARM architecture on FreeBSD 12.0 or later.
Go Version uncertainty (Score:2)
Re:Go Version uncertainty (Score:4, Funny)
That's weird: Go is a Google project, like Chrome--and Chrome is up to version 80.
Re:Go Version uncertainty (Score:4, Informative)
It is Google. They will drop anything that is not a big money maker or ad data source eventually.
Re:Go Version uncertainty (Score:4, Interesting)
After those people are gone, then perhaps the project will be ejected from Google. A project that "makes money" or "ad data source" helps guarantee its survival because there will be plenty of powerful parasites (people) who want to attach their name to it, keep it going.
Re: (Score:3)
A lot of code was written in go, a.o. large parts of kubernetes and associated tooling.
Inside and outside of google. It cannot be dropped just like some service or product can.
Re: (Score:2)
I’m currently dabbling in Go, and the issue I’m constantly running into is not the versioning (there’s no problem with releasing features in point releases while also working on a breaking change version) - the issue I keep running into is the vagueness of what is acceptable and what is not.
Go is very different to other languages, especially when it comes to things like generics - the lack of generics means you have a lot of code reuse, ie for database stuff you can no longer have a single
Re: (Score:2)
Overall, I’m quite liking Go, I’m finding it flows more smoothly if I stop thinking “I do it this way in my current language, why doesn’t that work in Go” and instead embrace the idiomatic Go approach
I guess if the language is like another language, and you don't have to embrace the idiomatic approach, then it's not worth learning (to paraphrase Alan Perlis).
Re: (Score:2)
It’s more to do with the issue that the “idiomatic” approach is a loose set of rules spread across a lot of blog posts, doc sites and other things, and rarely cover larger chunks of code and structure. At least in other languages you have a standard set of templates to start you off with.
Cuture is imporant and underrated (Score:3)
It’s more to do with the issue that the “idiomatic” approach is a loose set of rules spread across a lot of blog posts, doc sites and other things, and rarely cover larger chunks of code and structure. At least in other languages you have a standard set of templates to start you off with.
I think you're stumbling into a reason why Java is still #1 and yet unfashionable. You can do good work in nearly any good language. Java has both good technology and good culture. The best practices are literally written down. There is little ambiguity. Anything you want to learn is documented in docs, blog posts, and endless stackoverflow questions. Lots of time has been spent debating and evolving the best practices.
I call this a language's culture. Most of the verbosity people hate about Java
Re: (Score:3)
My impression is that Go aims to keep the core language simple, and hopefully the code as readable and explicit in what it does. I don't miss having frameworks and frameworks on top of each other, resulting in seemingly magical black boxes you just have to trust, like in Java land. I prefer to really understand what my code does and what is happening. Go sometimes feels a bit annoying in forcing me to do that, but in the end I find it works for me.
Having more good examples and documented ways of doing thing
Re:Go Version uncertainty (Score:5, Insightful)
Apparently Go has a version 2 coming?
Yes, but it is still in an fairly early stage. Right now they are figuring out the language changes. Until those are finalized, they can't proceed with development.
So why are they still working on version 1?
Because there are still things to be improved there and it is the version actually in use today and for the foreseeable future.
Should I still make a commitment to version 1, ...
Yes.
... or is all my code going to be obsolete?
Most likely at some point. Still I expect the 1.x tool chain to remain available even after 2.x is released.
The versioning scheme for Go is pretty simple - it promises no breaking changes within a major version. Minor updates bring new features, but should not break old code. A new major version might potentially introduce breaking changes making old code incompatible.
Re: (Score:2)
Should I still make a commitment to version 1, ...
Yes.
This is the only part that you didn't give a reason supporting your answer, and it's the only part that really matters.
is all my code going to be obsolete?
Most likely at some point.
That sounds like a "No, don't use Go yet" to me.