To me, the most interesting change is the performance improvement due to the new register-based calling convention. Your CPU-bound programs will magically get 5% faster when compiled with 1.17:<p>> Go 1.17 implements a new way of passing function arguments and results using registers instead of the stack. Benchmarks for a representative set of Go packages and programs show performance improvements of about 5%, and a typical reduction in binary size of about 2%. This is currently enabled for Linux, macOS, and Windows on the 64-bit x86 architecture (the linux/amd64, darwin/amd64, and windows/amd64 ports).<p>I love how they're doing it in such an iterative fashion: even assembly functions don't have to be rewritten. Then again, I guess doing it progressively like this is the only feasible way to avoid reworking all the low-level assembly routines in one fell swoop.
At first I didn't like Go because I thought it was too opinionated. But the more I used it, the more I found the tooling to be just heads and shoulders above similar languages like C/C++.<p>I use VSCode a lot, and in VSCode you can press "F12" to jump to the location of a function definition. In Go I find myself deep diving into github libraries all the time just because F12 takes me there. That <i>never</i> happened with C/C++ - the tooling was just too disparate and fragile.<p>My biggest complaint with Go is lack of generics. I mean technically you can achieve generics with an unholy empty interface/reflection incantation but it's a huge pain compared to C++.
When I started using Go I was more than sceptical. I had to mirgrate a CLI tool written in Kotlin (still my favorite language) because the memory consumption was to high.<p>After a while I actually understood why Go is such a successful language / ecosystem:<p>Go's priority is to make projects easier. It is doing so by all it's smaller and larger features respectivly skipped features. But one soon understands the big picture of the Go team. Go is designed by very experienced devs who knew what is important and what not.<p>In my Go projects, I don't have to worry about:<p>- Memory safety<p>- Tooling<p>- Performance<p>- Structure (once I understood the package desgin philosophie)<p>- Difficult syntax<p>- Concurrency<p>- Libraries, as we can do most with the standard lib<p>- Maturenes and stability<p>Instead I focus on the things that count:<p>- Solve the problem at hand<p>- Create correct, stable and maintable software<p>And as this was not enough, the Go team comes around the corner with an 5 % average performace gift.<p>Awesome.
The go code I wrote in 2015 looks and works exactly the same way new Go code I'm writing today. Even with all the upgrades.<p>You have no idea how amazing that feels.
My appreciation for Go has been monotonically increasing for years.<p>The more Go code I write, the more I like the language, the tools, and the standard library.<p>Low-friction, high-quality software development.<p>If only I could use it professionally, instead of C++.
I’ve been using Go at a large software company for 4 years. It does the job, my biggest complaints are the low capacity for abstraction, verbosity and ergonomic pain points. It can do certain things well, but in a large enough project you’ll inevitably find that it doesn’t give you the best tools for certain types of problems.<p>I don’t know what to think about the upcoming generics. It feels late to make such a big change so long after the language has been established. At least a plan for it should have been integrated into the language from the start.<p>It feels like a missed opportunity - an effort with similar funding but a more sound theoretical foundation than being Newsqueak 3.0 could have become an industry game changer. Instead it fills a niche, which is a success, albeit smaller.
Go is my favorite language to write code in. I was very skeptical when I first started learning it for a new job with error handling that looked archaic in comparison to exceptions but once I got the hang of it it has quickly become my preferred language of choice for any project.<p>Once generics are finally added the language should basically be a no-brainer for any serious production code.
A couple of nice tweaks that I'm happy to see.<p>I didn't completely expect it, but I now find myself reaching for Go first when writing something like a small script or utility that I'd previously have written in something like Ruby or Python. It all feels much more solid.<p>That said… I really chafe against the anaemic type system when writing anything a larger than that. I hate not being able to communicate things like "this can never be nil and if it's is then it's an error" to the compiler. I resent having to write three lines of boilerplate every time I want to reverse a flipping 10-item slice, and the design decisions leading to the existence of `time.IsZero()` are bordering on criminal.<p>I don't know if I'm the odd one out for feeling like that – parts of the language and ecosystem are just absolutely wonderful to work with, but the unergonomic sharp edges bother me so much that I end up finding it really _annoying_ to write a lot of it.
It looks like the language is really maturing. The changes are all fairly minor optimizations and improvements to the stdlib.
Impressed with the Go team’s discipline for simplicity and stability.
Two recent related threads:<p><i>Go 1.17 Beta</i> - <a href="https://news.ycombinator.com/item?id=27462884" rel="nofollow">https://news.ycombinator.com/item?id=27462884</a> - June 2021 (118 comments)<p><i>Go 1.17 is deprecating the traditional use of 'go get'</i> - <a href="https://news.ycombinator.com/item?id=27630625" rel="nofollow">https://news.ycombinator.com/item?id=27630625</a> - June 2021 (215 comments)
> Module authors may deprecate a module by adding a // Deprecated: comment to go.mod, then tagging a new version. go get now prints a warning if a module needed to build packages named on the command line is deprecated.<p>Very good for the ecosystem. Nudge folks to upgrade from broken/insecure versions
> We’ve also introduced pruned module graphs in this release. Modules that specify go 1.17 or higher in their go.mod file will have their module graphs include only the immediate dependencies of other Go 1.17 modules, not their full transitive dependencies.<p>This is a very welcome change and make the go.mod much more obvious to understand. Hooray!
Apparently type parameter compiler work was supposed to get merged just after 1.17. [1] Does anyone know if it’s still on?<p>[1] <a href="https://groups.google.com/g/golang-dev/c/U7eW9i0cqmo/m/ffs0tyIYBAAJ" rel="nofollow">https://groups.google.com/g/golang-dev/c/U7eW9i0cqmo/m/ffs0t...</a>
Just tried [OjG](<a href="https://github.com/ohler55/ojg" rel="nofollow">https://github.com/ohler55/ojg</a>) and saw anywhere from zero to 20% faster on the various benchmarks. Nice improvement overall. Hats off to the golang maintainers.
Lol Good Little Go ! :)
Still one of my favourite languages whenever "heavy lifting" or concurrency is required (really they make it stupidly easy).<p>Now add pattern matching please !
Well done to everyone that worked on Go ! It's still a pleasure to use.
Anyone seen jobs for business applications? Go seems to have a sweet spot for systems. I'd like to replace Java at my work but no one else is doing it.
How do you add dependencies and in Go? I'm still confused. I use the VSCode extension and the code I wrote that uses external packages gets deleted when I save my file even though the package is installed
I hate to be "that guy", but you should try Rust. It also has amazing tooling, and is probably more comparable to C/C++, considering you don't have to use a garbage collector in Rust.