35 ms·

Go 1.17 Release Notes

197 points by aofeisheng 5y ago

machinecontrol 5y ago
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.
- est31 5y ago
  Between the 1 release in 2012 and the 1.13 release in 2019, this has been the development model of the language. So it's nothing new in Go's evolution.
kplex 5y ago
Worth it if only for the go.mod tidy-up, how that made it into a release in the first place baffles me.
Techasura 5y ago
Never tried to write Go before, maybe it’s time that I stop by.
- itake 5y ago
  what about this release makes you want to try it?
- nwmcsween 5y ago
  It's meh for a language, it's simple which is what they are trying to achieve but it all comes with trade offs like all programming languages. I would say a large portion of a language is how you mesh with the syntax and tooling around it.
  - theshrike79 5y ago
    Go being "meh" is one of its best parts. It doesn't encourage you to do fancy language tricks, it kindly directs you to get your shit done, compiled and delivered.
tech_dreamer 5y ago
Golang release no longer excites me in a good way - I know my old aws hosted apps continue to work, as do my pet projects
- colesantiago 5y ago
  are release notes supposed to be exciting?
  - staticassertion 5y ago
    I think they mean "no longer excites me, in a good way"
  - xwdv 5y ago
    Usually they fill me with dread.
umvi 5y ago
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++. 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 never happened with C/C++ - the tooling was just too disparate and fragile. 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++.
- candiddevmike 5y ago
  Generics are hopefully coming February 2022 with 1.18.
  - xwdv 5y ago
    This will be when I finally use Go for something then.
    - azth 5y ago
      Even with generics, it has so many issues: * Error handling is error prone and awkward. * No proper enums * No sum types/pattern matching * Null pointers exist * Its interfaces are very awkward. There are superior implementations of what they tried to do in other languages. * Subpar IDE experience, made worse by how interfaces are implemented. You need an IDE for any non-trivial project. * Very awkward choice to have visibility be determined by the case of the first letter in the function or variable. Simple changing of visibility to public will require larger diffs if it's used a lot. * No private visibility, only package private. * Very crude import mechanism. Try to rename a package and see how the IDE fails to figure out what to change.
      - saturn_vk 5y ago
        Funny, I've only ever used vim for go projects big and small, and the experience was excellent Wouldn't any visibility change require a large diff in all languages?
skybrian 5y ago
Apparently type parameter compiler work was supposed to get merged just after 1.17. [1] Does anyone know if it’s still on? [1] https://groups.google.com/g/golang-dev/c/U7eW9i0cqmo/m/ffs0tyIYBAAJ https://groups.google.com/g/golang-dev/c/U7eW9i0cqmo/m/ffs0t...
- nappy-doo 5y ago
  The merge has already happened. The generic preview is going to be in 1.18 (early 2022).
- 4ad 5y ago
  It's already in, it has to be requested by the user with `-gcflags='-G=3'`. Of course, the feature is in heavy development and not ready for production use, YMMV.
37ef_ced3 5y ago
My appreciation for Go has been monotonically increasing for years. The more Go code I write, the more I like the language, the tools, and the standard library. Low-friction, high-quality software development. If only I could use it professionally, instead of C++.
- theshrike79 5y ago
  Go is the choice of professionals IMO. When you have a team of varying skill levels who need to deliver shit that works on a schedule and still have some kind of performance, you use Go. Even more so if you need to hand off the maintenance to a team of randoms from god knows where and THEY need to be able to keep it running and add new features. It doesn't have the fanciest new EXPRESSIVE operators or anything exciting really. It just does the job, albeit verbosely. You can do fancy shit on your own time.
  - int_19h 5y ago
    I would argue that e.g. decent error handling is not "fancy shit".
    - theshrike79 5y ago
      It's perfectly decent, it forces you to explicitly handle or ignore every error. It's verbose as all hell, but on the other hand you'll notice immediately if it's missing. Go is not a "fun" language by any means, but that doesn't mean it's not a productive one.
      - int_19h 5y ago
        I don't see how it forces you to ignore? You don't have to be explicit to ignore the returned error code.
        theshrike79 5y ago
        That's what the underscore is for, explicit ignore. And it's a huge code smell. You instantly notice it because the if err != nil -template is missing after it =)
harikb 5y ago
> 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. Very good for the ecosystem. Nudge folks to upgrade from broken/insecure versions
zz865 5y ago
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.
- debarshri 5y ago
  When I used to work for traffic enforcement company, their whole backend was written in golang.
- jdavis703 5y ago
  While we’re not building a “business” application we are building a large web application on Go. It’s definitely not just for systems work.
- pgwhalen 5y ago
  I use (and enjoy using) both Go and Java at work, and Go is in my opinion very much a Java replacement more than it is, say, a Python or C++ replacement. It is absolutely suitable for business logic, and I've never been quite sure what its designers mean when they say it's a systems language. Yes, you can squeeze great performance out of it, but you can with Java as well. The way I see it, both Go and Java are crawling towards the same ideal: a compiled, statically typed, garbage collected, modern enough program language targeted for a majority of back-end concerns. Go has to close the gap mostly just with generics; and Java with memory layout (Valhalla), concurrency (Loom), and ergonomics (Amber); but they will both be there in 3-5 years. Take this with a grain of salt if you like, but while I probably find it more fun to program in Go, I don't think there's a compelling reason to switch a large codebase from Java to Go. It often feels like my company is needlessly divided by programming languages even though they solve fairly similar problems. It's one thing to move off of a dying language, but Java is certainly not that.
  - zz865 5y ago
    Thanks, that sounds about right. Throw Rust in there too, its an interesting time.
leo_bloom 5y ago
> 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. This is a very welcome change and make the go.mod much more obvious to understand. Hooray!
deleted 5y ago
[deleted]
avl999 5y ago
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. Once generics are finally added the language should basically be a no-brainer for any serious production code.
- ridiculous_fish 5y ago
  From a distance it looks difficult to write in. For example, two recommended ways to delete from a slice: a = append(a[:i], a[i+1:]...) // or a = a[:i+copy(a[i:], a[i+1:])] Both seem harder than necessary. Is that code just idiomatic, and Go programmers recognize it instantly? Or maybe they don't deal with slices that often? https://github.com/golang/go/wiki/SliceTricks https://github.com/golang/go/wiki/SliceTricks
  - yobert 5y ago
    I use slices all the time, but very rarely need to delete out of the middle of them. So it seems like a bit of an edge case to me.
  - barsonme 5y ago
    No, you deal with slices all the time. You just recognize the idiom. You can restructure it if you don't need to preserve order: a[i] = a[len(a)-1] a = a[:len(a)-1] In general* Go does not hide complexity from you. It's a blessing and a curse. *: because the Internet is a nitpicky place.
  - benhoyt 5y ago
    With the introduction of generics in Go 1.18 and the accompanying "slices" package (https://github.com/golang/go/issues/45955 https://github.com/golang/go/issues/45955), we might soon write that as: a = slices.Delete(a, i, i+1) That said, in code I write, I rarely need to do an in-place delete from a slice. I think it's rare enough that recognizing the idiom is okay.
dang 5y ago
Two recent related threads: Go 1.17 Beta - https://news.ycombinator.com/item?id=27462884 https://news.ycombinator.com/item?id=27462884 - June 2021 (118 comments) Go 1.17 is deprecating the traditional use of 'go get' - https://news.ycombinator.com/item?id=27630625 https://news.ycombinator.com/item?id=27630625 - June 2021 (215 comments)
benhoyt 5y ago
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: > 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). 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.
- benhoyt 5y ago
  Wow, this update is awesome: my GoAWK interpreter (https://github.com/benhoyt/goawk https://github.com/benhoyt/goawk) runs a simple CPU-bound AWK program 38% faster when compiled with Go 1.17 (compared to 1.16). $ time goawk_go1.16 'BEGIN { for (i=0; i<100000000; i++) s += i; print(s) }' 4999999950000000 real 0m10.158s ... $ time goawk_go1.17 'BEGIN { for (i=0; i<100000000; i++) s += i; print(s) }' 4999999950000000 real 0m6.268s ... I wonder why it's so much better than their advertised 5% perf improvement? Here's a quick CPU profile: https://i.imgur.com/csJyOYq.png https://i.imgur.com/csJyOYq.png ... I don't get too much out of it at a glance, just seems like everything's a bunch faster.
  - barsonme 5y ago
    just an fyi: you can use the -diff_base flag to diff the profiles without opening both profiles side-by-side.
    - benhoyt 5y ago
      Oh, good to know, thanks!
  - prattmic 5y ago
    The benefits come primarily from avoiding extra work spilling arguments to/from the stack on function calls. If you are making lots and lots of function calls, particularly to small functions that can't be inlined, there could certainly be much bigger improvements.
throw149102 5y ago
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.
- asadawadia 5y ago
  why though? some perf gains?
  - rowanG077 5y ago
    No. More because Rust offers modern language features and it's much easier to get code working then in Go.
  - DenseComet 5y ago
    Go isn't low level in the same way that Rust is. Both languages have their places, but Go seems to be more of a better Python/JS, whereas Rust is a better C++.
    - dilyevsky 5y ago
      Python/Js are interpreted by default and not good system programming choices. Go is compiled. This comparison totally misses the mark. In fact Go was developed mostly as C++ but sometimes Python replacement at Google.
      - omginternets 5y ago
        It hits the mark because it targets the niche that was once occupied by interpreted languages.
        throwaway894345 5y ago
        But it wasn't just "interpreted languages". Really the only interpreted languages in "the niche" were Python and a little bit of Ruby, but there was also a whole bunch of Java, C#, and C++.
matthewmacleod 5y ago
A couple of nice tweaks that I'm happy to see. 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. 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. 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.
- cpeterso 5y ago
  > the design decisions leading to the existence of `time.IsZero()` are bordering on criminal. What's the rationale for Time.IsZero()? Seems like every use case for Time.IsZero() I think of is a code smell. The 1970 epoch is an implementation detail that should be hidden or configurable. People probably use IsZero() as a sentinel value to indicate "undefined time", even though the 1970 epoch is a valid point in time.
  - kjksf 5y ago
    .IsZero() is a pragmatic solution given the constraints of the system (i.e. Go language). Go has a notion of "zero value". When you don't assign a value explicitly it'll be set by the compiler to "zero value" of that type. This is much better than C/C++ of "random value". For primitive types, the compiler decides what "zero value" is. For structs, each component is set to its zero value. For good reasons (language simplicity) Go doesn't allow the user to declare what the zero value is (something that you can do in e.g. C++ via a constructor). Time is a struct. Its zero value is the same as for any other struct and not meaningful time value. It's a pragmatic necessity to be able to query "is this time value an unset time value?". A pragmatic solution for this need is to provide IsZero() method on Time struct.
pxue 5y ago
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. You have no idea how amazing that feels.
- deleted 5y ago
  [deleted]
- rowanG077 5y ago
  Isn't that the case for the vast majority of languages though? The python,c,Haskell,js,language x code from 2015 works the same now as it did 5 years ago.
  - slownews45 5y ago
    python 2 -> 3 was not easy (aka a total nightmare). By 3.6 it was pretty good though and even migrations and dual code bases were easier because they went back and allowed things like u"" for unicode strings to continue to mean unicode strings in python 3 - before that they'd actually blocked unicode in 3 that was working well in 2.x code bases! It was a total in your face move to break the ecosystem even though supporting u"" would have been almost no cost in terms of improving compatibility with existing code. ASCII handling (important for things like web tech stacks header handling etc) also improved thankfully. 3.x made things a lot harder initially (and slower too). Also a lot of code doesn't look the same over time - the conventions (formatting) are either very poorly defined or change. Go seems to have pretty much one format from fmt etc
    - fny 5y ago
      Python was a unique shit show.
    - int_19h 5y ago
      Python 3 should be considered a different language from Python 2, pretty much.
      - 5y ago
kubb 5y ago
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. 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. 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.
- vp8989 5y ago
  "It feels like a missed opportunity" I agree with that. I think looking back on it, Go arrived on to the scene at a perfect time where lots of people were rearchitecting so there was lots of natural appetite in the industry for a new language. Go vacuumed up a lot of this opportunity but ultimately hasn't really evolved the practice of software engineering all that much.
- erik_seaberg 5y ago
  > feels late to make such a big change This is recoverable. The Java world was also saddled with a decade of awful pre-generic code, but we burned almost all of it to the ground and started over.
  - int_19h 5y ago
    The need to tackle generics later resulted in design decisions such as type erasure, which even today are still limiting the evolution of Java.
    - erik_seaberg 5y ago
      Yeah, that was an unforced error. Fundamental changes to a language can and should rely on upgrading deployed runtime libraries.
hakube 5y ago
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
- galleywest 5y ago
  Are you using the imports in your file? The VS Code Go addon has "format on save" enabled by default and Go will not compile if there are unused imports - so VS Code deletes the unused imports on save by default. Otherwise try a "go mod init" in the root of your project.
- jizzlepizzle 5y ago
  the vscode extension automatically formats your go file and removes any packages that aren't used in the code. https://code.visualstudio.com/docs/languages/go#_formatting https://code.visualstudio.com/docs/languages/go#_formatting
peterohler 5y ago
Just tried [OjG](https://github.com/ohler55/ojg https://github.com/ohler55/ojg) and saw anywhere from zero to 20% faster on the various benchmarks. Nice improvement overall. Hats off to the golang maintainers.
deleted 5y ago
[deleted]
_008_jb_ 5y ago
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. After a while I actually understood why Go is such a successful language / ecosystem: 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. In my Go projects, I don't have to worry about: - Memory safety - Tooling - Performance - Structure (once I understood the package desgin philosophie) - Difficult syntax - Concurrency - Libraries, as we can do most with the standard lib - Maturenes and stability Instead I focus on the things that count: - Solve the problem at hand - Create correct, stable and maintable software And as this was not enough, the Go team comes around the corner with an 5 % average performace gift. Awesome.
- systemvoltage 5y ago
  Not a GO dev, has the debugging experience improved?
  - theshrike79 5y ago
    Dunno, 20 years in the business and I still debug with print statements. It's enough in 95% of cases and it works every time in every environment. In the time it takes me to get a debugger running and attached to a process, I've print-debugged it and fixed it already =)
    - ithkuil 5y ago
      Same here. I very rarely reach for a debugger. Especially with Go where you can recompile the binary very quickly. I tend to reach for a debugger when doing post mortem debugging or when I work with C where that's usually the easiest way to get a stack trace when a program crashes. That said, time travel / reverse debuggers can be quite useful indeed: see http://choly.ca/post/debugging-go-with-rr/ http://choly.ca/post/debugging-go-with-rr/
    - 5y ago
denysvitali 5y ago
> Go 1.17 adds support of 64-bit ARM architecture on Windows (the windows/arm64 port). This port supports cgo. Yay!
rawoke083600 5y ago
Lol Good Little Go ! :) Still one of my favourite languages whenever "heavy lifting" or concurrency is required (really they make it stupidly easy). Now add pattern matching please ! Well done to everyone that worked on Go ! It's still a pleasure to use.

197 points by aofeisheng 5y ago

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.

est31 5y ago
Between the 1 release in 2012 and the 1.13 release in 2019, this has been the development model of the language. So it's nothing new in Go's evolution.

kplex 5y ago

Worth it if only for the go.mod tidy-up, how that made it into a release in the first place baffles me.

Techasura 5y ago

Never tried to write Go before, maybe it’s time that I stop by.

itake 5y ago
what about this release makes you want to try it?
nwmcsween 5y ago
It's meh for a language, it's simple which is what they are trying to achieve but it all comes with trade offs like all programming languages. I would say a large portion of a language is how you mesh with the syntax and tooling around it.
- theshrike79 5y ago
  Go being "meh" is one of its best parts. It doesn't encourage you to do fancy language tricks, it kindly directs you to get your shit done, compiled and delivered.

tech_dreamer 5y ago

Golang release no longer excites me in a good way - I know my old aws hosted apps continue to work, as do my pet projects

colesantiago 5y ago
are release notes supposed to be exciting?
- staticassertion 5y ago
  I think they mean "no longer excites me, in a good way"
- xwdv 5y ago
  Usually they fill me with dread.

umvi 5y ago

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++. 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 never happened with C/C++ - the tooling was just too disparate and fragile. 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++.

candiddevmike 5y ago
Generics are hopefully coming February 2022 with 1.18.
- xwdv 5y ago
  This will be when I finally use Go for something then.
  - azth 5y ago
    Even with generics, it has so many issues: * Error handling is error prone and awkward. * No proper enums * No sum types/pattern matching * Null pointers exist * Its interfaces are very awkward. There are superior implementations of what they tried to do in other languages. * Subpar IDE experience, made worse by how interfaces are implemented. You need an IDE for any non-trivial project. * Very awkward choice to have visibility be determined by the case of the first letter in the function or variable. Simple changing of visibility to public will require larger diffs if it's used a lot. * No private visibility, only package private. * Very crude import mechanism. Try to rename a package and see how the IDE fails to figure out what to change.
    - saturn_vk 5y ago
      Funny, I've only ever used vim for go projects big and small, and the experience was excellent Wouldn't any visibility change require a large diff in all languages?

skybrian 5y ago

Apparently type parameter compiler work was supposed to get merged just after 1.17. [1] Does anyone know if it’s still on? [1] https://groups.google.com/g/golang-dev/c/U7eW9i0cqmo/m/ffs0tyIYBAAJ https://groups.google.com/g/golang-dev/c/U7eW9i0cqmo/m/ffs0t...

nappy-doo 5y ago
The merge has already happened. The generic preview is going to be in 1.18 (early 2022).
4ad 5y ago
It's already in, it has to be requested by the user with `-gcflags='-G=3'`. Of course, the feature is in heavy development and not ready for production use, YMMV.

37ef_ced3 5y ago

My appreciation for Go has been monotonically increasing for years. The more Go code I write, the more I like the language, the tools, and the standard library. Low-friction, high-quality software development. If only I could use it professionally, instead of C++.

theshrike79 5y ago
Go is the choice of professionals IMO. When you have a team of varying skill levels who need to deliver shit that works on a schedule and still have some kind of performance, you use Go. Even more so if you need to hand off the maintenance to a team of randoms from god knows where and THEY need to be able to keep it running and add new features. It doesn't have the fanciest new EXPRESSIVE operators or anything exciting really. It just does the job, albeit verbosely. You can do fancy shit on your own time.
- int_19h 5y ago
  I would argue that e.g. decent error handling is not "fancy shit".
  - theshrike79 5y ago
    It's perfectly decent, it forces you to explicitly handle or ignore every error. It's verbose as all hell, but on the other hand you'll notice immediately if it's missing. Go is not a "fun" language by any means, but that doesn't mean it's not a productive one.
    - int_19h 5y ago
      I don't see how it forces you to ignore? You don't have to be explicit to ignore the returned error code.
      - theshrike79 5y ago
        That's what the underscore is for, explicit ignore. And it's a huge code smell. You instantly notice it because the if err != nil -template is missing after it =)

harikb 5y ago

> 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. Very good for the ecosystem. Nudge folks to upgrade from broken/insecure versions

zz865 5y ago

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.

debarshri 5y ago
When I used to work for traffic enforcement company, their whole backend was written in golang.
jdavis703 5y ago
While we’re not building a “business” application we are building a large web application on Go. It’s definitely not just for systems work.
pgwhalen 5y ago
I use (and enjoy using) both Go and Java at work, and Go is in my opinion very much a Java replacement more than it is, say, a Python or C++ replacement. It is absolutely suitable for business logic, and I've never been quite sure what its designers mean when they say it's a systems language. Yes, you can squeeze great performance out of it, but you can with Java as well. The way I see it, both Go and Java are crawling towards the same ideal: a compiled, statically typed, garbage collected, modern enough program language targeted for a majority of back-end concerns. Go has to close the gap mostly just with generics; and Java with memory layout (Valhalla), concurrency (Loom), and ergonomics (Amber); but they will both be there in 3-5 years. Take this with a grain of salt if you like, but while I probably find it more fun to program in Go, I don't think there's a compelling reason to switch a large codebase from Java to Go. It often feels like my company is needlessly divided by programming languages even though they solve fairly similar problems. It's one thing to move off of a dying language, but Java is certainly not that.
- zz865 5y ago
  Thanks, that sounds about right. Throw Rust in there too, its an interesting time.

leo_bloom 5y ago

> 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. This is a very welcome change and make the go.mod much more obvious to understand. Hooray!

deleted 5y ago

[deleted]

avl999 5y ago

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. Once generics are finally added the language should basically be a no-brainer for any serious production code.

ridiculous_fish 5y ago
From a distance it looks difficult to write in. For example, two recommended ways to delete from a slice: a = append(a[:i], a[i+1:]...) // or a = a[:i+copy(a[i:], a[i+1:])] Both seem harder than necessary. Is that code just idiomatic, and Go programmers recognize it instantly? Or maybe they don't deal with slices that often? https://github.com/golang/go/wiki/SliceTricks https://github.com/golang/go/wiki/SliceTricks
- yobert 5y ago
  I use slices all the time, but very rarely need to delete out of the middle of them. So it seems like a bit of an edge case to me.
- barsonme 5y ago
  No, you deal with slices all the time. You just recognize the idiom. You can restructure it if you don't need to preserve order: a[i] = a[len(a)-1] a = a[:len(a)-1] In general* Go does not hide complexity from you. It's a blessing and a curse. *: because the Internet is a nitpicky place.
- benhoyt 5y ago
  With the introduction of generics in Go 1.18 and the accompanying "slices" package (https://github.com/golang/go/issues/45955 https://github.com/golang/go/issues/45955), we might soon write that as: a = slices.Delete(a, i, i+1) That said, in code I write, I rarely need to do an in-place delete from a slice. I think it's rare enough that recognizing the idiom is okay.

dang 5y ago

Two recent related threads: Go 1.17 Beta - https://news.ycombinator.com/item?id=27462884 https://news.ycombinator.com/item?id=27462884 - June 2021 (118 comments) Go 1.17 is deprecating the traditional use of 'go get' - https://news.ycombinator.com/item?id=27630625 https://news.ycombinator.com/item?id=27630625 - June 2021 (215 comments)

benhoyt 5y ago

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

benhoyt 5y ago
Wow, this update is awesome: my GoAWK interpreter (https://github.com/benhoyt/goawk https://github.com/benhoyt/goawk) runs a simple CPU-bound AWK program 38% faster when compiled with Go 1.17 (compared to 1.16). $ time goawk_go1.16 'BEGIN { for (i=0; i<100000000; i++) s += i; print(s) }' 4999999950000000 real 0m10.158s ... $ time goawk_go1.17 'BEGIN { for (i=0; i<100000000; i++) s += i; print(s) }' 4999999950000000 real 0m6.268s ... I wonder why it's so much better than their advertised 5% perf improvement? Here's a quick CPU profile: https://i.imgur.com/csJyOYq.png https://i.imgur.com/csJyOYq.png ... I don't get too much out of it at a glance, just seems like everything's a bunch faster.
- barsonme 5y ago
  just an fyi: you can use the -diff_base flag to diff the profiles without opening both profiles side-by-side.
  - benhoyt 5y ago
    Oh, good to know, thanks!
- prattmic 5y ago
  The benefits come primarily from avoiding extra work spilling arguments to/from the stack on function calls. If you are making lots and lots of function calls, particularly to small functions that can't be inlined, there could certainly be much bigger improvements.

throw149102 5y ago

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.

asadawadia 5y ago
why though? some perf gains?
- rowanG077 5y ago
  No. More because Rust offers modern language features and it's much easier to get code working then in Go.
- DenseComet 5y ago
  Go isn't low level in the same way that Rust is. Both languages have their places, but Go seems to be more of a better Python/JS, whereas Rust is a better C++.
  - dilyevsky 5y ago
    Python/Js are interpreted by default and not good system programming choices. Go is compiled. This comparison totally misses the mark. In fact Go was developed mostly as C++ but sometimes Python replacement at Google.
    - omginternets 5y ago
      It hits the mark because it targets the niche that was once occupied by interpreted languages.
      - throwaway894345 5y ago
        But it wasn't just "interpreted languages". Really the only interpreted languages in "the niche" were Python and a little bit of Ruby, but there was also a whole bunch of Java, C#, and C++.

matthewmacleod 5y ago

A couple of nice tweaks that I'm happy to see. 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. 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. 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.

cpeterso 5y ago
> the design decisions leading to the existence of `time.IsZero()` are bordering on criminal. What's the rationale for Time.IsZero()? Seems like every use case for Time.IsZero() I think of is a code smell. The 1970 epoch is an implementation detail that should be hidden or configurable. People probably use IsZero() as a sentinel value to indicate "undefined time", even though the 1970 epoch is a valid point in time.
- kjksf 5y ago
  .IsZero() is a pragmatic solution given the constraints of the system (i.e. Go language). Go has a notion of "zero value". When you don't assign a value explicitly it'll be set by the compiler to "zero value" of that type. This is much better than C/C++ of "random value". For primitive types, the compiler decides what "zero value" is. For structs, each component is set to its zero value. For good reasons (language simplicity) Go doesn't allow the user to declare what the zero value is (something that you can do in e.g. C++ via a constructor). Time is a struct. Its zero value is the same as for any other struct and not meaningful time value. It's a pragmatic necessity to be able to query "is this time value an unset time value?". A pragmatic solution for this need is to provide IsZero() method on Time struct.

pxue 5y ago

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. You have no idea how amazing that feels.

deleted 5y ago
[deleted]
rowanG077 5y ago
Isn't that the case for the vast majority of languages though? The python,c,Haskell,js,language x code from 2015 works the same now as it did 5 years ago.
- slownews45 5y ago
  python 2 -> 3 was not easy (aka a total nightmare). By 3.6 it was pretty good though and even migrations and dual code bases were easier because they went back and allowed things like u"" for unicode strings to continue to mean unicode strings in python 3 - before that they'd actually blocked unicode in 3 that was working well in 2.x code bases! It was a total in your face move to break the ecosystem even though supporting u"" would have been almost no cost in terms of improving compatibility with existing code. ASCII handling (important for things like web tech stacks header handling etc) also improved thankfully. 3.x made things a lot harder initially (and slower too). Also a lot of code doesn't look the same over time - the conventions (formatting) are either very poorly defined or change. Go seems to have pretty much one format from fmt etc
  - fny 5y ago
    Python was a unique shit show.
  - int_19h 5y ago
    Python 3 should be considered a different language from Python 2, pretty much.
    - 5y ago

kubb 5y ago

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

vp8989 5y ago
"It feels like a missed opportunity" I agree with that. I think looking back on it, Go arrived on to the scene at a perfect time where lots of people were rearchitecting so there was lots of natural appetite in the industry for a new language. Go vacuumed up a lot of this opportunity but ultimately hasn't really evolved the practice of software engineering all that much.
erik_seaberg 5y ago
> feels late to make such a big change This is recoverable. The Java world was also saddled with a decade of awful pre-generic code, but we burned almost all of it to the ground and started over.
- int_19h 5y ago
  The need to tackle generics later resulted in design decisions such as type erasure, which even today are still limiting the evolution of Java.
  - erik_seaberg 5y ago
    Yeah, that was an unforced error. Fundamental changes to a language can and should rely on upgrading deployed runtime libraries.

hakube 5y ago

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

galleywest 5y ago
Are you using the imports in your file? The VS Code Go addon has "format on save" enabled by default and Go will not compile if there are unused imports - so VS Code deletes the unused imports on save by default. Otherwise try a "go mod init" in the root of your project.
jizzlepizzle 5y ago
the vscode extension automatically formats your go file and removes any packages that aren't used in the code. https://code.visualstudio.com/docs/languages/go#_formatting https://code.visualstudio.com/docs/languages/go#_formatting

peterohler 5y ago

Just tried [OjG](https://github.com/ohler55/ojg https://github.com/ohler55/ojg) and saw anywhere from zero to 20% faster on the various benchmarks. Nice improvement overall. Hats off to the golang maintainers.

deleted 5y ago

[deleted]

_008_jb_ 5y ago

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. After a while I actually understood why Go is such a successful language / ecosystem: 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. In my Go projects, I don't have to worry about: - Memory safety - Tooling - Performance - Structure (once I understood the package desgin philosophie) - Difficult syntax - Concurrency - Libraries, as we can do most with the standard lib - Maturenes and stability Instead I focus on the things that count: - Solve the problem at hand - Create correct, stable and maintable software And as this was not enough, the Go team comes around the corner with an 5 % average performace gift. Awesome.

systemvoltage 5y ago
Not a GO dev, has the debugging experience improved?
- theshrike79 5y ago
  Dunno, 20 years in the business and I still debug with print statements. It's enough in 95% of cases and it works every time in every environment. In the time it takes me to get a debugger running and attached to a process, I've print-debugged it and fixed it already =)
  - ithkuil 5y ago
    Same here. I very rarely reach for a debugger. Especially with Go where you can recompile the binary very quickly. I tend to reach for a debugger when doing post mortem debugging or when I work with C where that's usually the easiest way to get a stack trace when a program crashes. That said, time travel / reverse debuggers can be quite useful indeed: see http://choly.ca/post/debugging-go-with-rr/ http://choly.ca/post/debugging-go-with-rr/
  - 5y ago

denysvitali 5y ago

> Go 1.17 adds support of 64-bit ARM architecture on Windows (the windows/arm64 port). This port supports cgo. Yay!

rawoke083600 5y ago

Lol Good Little Go ! :) Still one of my favourite languages whenever "heavy lifting" or concurrency is required (really they make it stupidly easy). Now add pattern matching please ! Well done to everyone that worked on Go ! It's still a pleasure to use.