Go 1.27

Join the discussion

• Hacker News
• I love Go because even minor versions deliver great value like this. The struct literal inits and generic methods are great conveniences to clean up clumsy boilerplate.

  Not to mention it’s just a dream language to work with , especially when building concurrent applications. I love engaging all of my cores. And memory is so expensive nowadays

  by tonymet
• Minor versions are basically major versions for Go. They’ll “never” create a Go v2 because they prioritise maintaining backwards compatibility as a language feature, thus following semver rules, no majors.
  by radicalriddler
• Used to code primarily in Java. Now my app stack is about 80% Go. I love that it enables lightweight application development. Glad to see the platform evolving with a focus on resource efficiency.
  by ejboy
• Same. Go feels like the language that does everything I like about Java with a lot more control than Java gives
  by qwm
• I'm so glad the new uuid package landed - it's overdue but a very welcome addition! I've already replaced github.com/google/uuid with `uuid` in several projects
  by patabyte
• This makes me want to find a side project for an excuse to give Go another try (I last used it professionally pre-generics).

  I do still wish it had discriminated unions (algebraic data types) and some better error handling ergonomics.

  by piinbinary
• Tagged unions can be implemented in user code, you dont actually need language support to use them.

  https://github.com/splizard/tagged

  by Splizard
• I think you're gonna like it a lot more now. The language has gained a lot of nice things since they added generics
  by qwm
• Do it. It is just a beautiful language to write and much simpler to pickup than many others. I am a fan boy of course but I love Go.
  by codegeek
• Having worked a couple of greenfield go shops post generics, it’s still quite rare to find them in first party code. They’re just not that useful outside of library APIs. Proper algebraic data types would be a huge game changer.
  by catlifeonmars
• Re unions:

  https://github.com/golang/go/issues/76920

  You might want to follow this proposal, if you aren't already. It's the most recent one, and it's supported by quite a few “core members” of the Go Team. I don't think it'll land in 1.28, but I like the fact that it's still a feature that's being actively discussed.

  by ainar-g
• The SIMD stuff is incredible. I have been having lots of fun with it. You can use LLMs as a scalar to SIMD transpiler, it works amazingly well.

  Sure a SIMD expert writing assembly can probably do a better job than an LLM using these new intrinsics, but it’s still massively faster.

  by tyho
• “Do a breakthrough and make this SIMD fastest”
  by drivebyhooting
• I still believe that SIMD support is one of the most underrated new features in Go.

  It's relatively straightforward to read and to write code using Go's SIMD package (the caveat being that you have to convert your data to SoA manually), and it gives comparable performance to other languages, since there's little in the way of GC overhead, bounds checking, etc, in this case.

  So SIMD not only increases performance on its own, but it also closes the performance gap between Go and C++ / Rust, which has been a major cause for rewrites in the past. The memory usage overhead due to GC doesn't go anywhere of course, so there are still performance reasons to "Rewrite in Rust", but it's now become much easier to just optimise the hell out of Go code instead.

  by nasretdinov
• Agreed. I've recently translated a pangram generator project written in Rust [1] leveraging SIMD to do the same in Go [2] to see how it fairs in terms of speed - the results are pretty close. In my local machine I'm getting ~3GHz in Rust vs ~2.4GHz in Go, which I think is really impressive.

  [1]: https://github.com/tuzz/pangram-machine

  [2]: https://github.com/nkanaev/pangram-machine-go

  by nkanaev
• Struct literal changes while welcomed, have the issue of being a possible source of bugs, if there are overlapping fields,

  type Habitat struct { Burrow string }

  type Gopher struct { Name string Burrow string Habitat }

  It will not initialise what one expects, here it is a contrived example, however it may not be easy to spot in more complex source code.

  https://go.dev/play/p/dsY6tK5S8Ie

  Better generics and improved SIMD are nice additions as well.

  by pjmlp
• Mhm, probably worth a golang-ci check for duplicate field names which are accessed by methods on the embedded type.
  by 0x696C6961
• I've missed something - what were you expecting from that code? Would anyone expect the `Burrow` inside the `Habitat` to be initialised instead of the top-level `Burrow`?
  by zimpenfish
• Funny enough, in one of my projects I created a struct with a string field just to have a distinct type that couldn't accidentally be initialized by typing a string. This update completely messes that up lol
  by qwm
• I'd say it is as expected https://go.dev/play/p/sy6SMrOiw4y
  by j3nz
• Go has had this behaviour for promoting fields (provided they don't clash) for some time, this is just extending the language feature to initialisers.

  Your contrived example doesn't initialise the embedded struct that also contains a "Burrow" field. If it did that at all, even without naming the Burrow field... you would not be allowed to initialise the struct, because of the ambiguity.

  https://go.dev/ref/spec#Composite_literals

  > A key must not denote a promoted field inside an embedded struct if that struct is also specified by another key.

  > Given the declarations

      type Object  struct { name, color string }
      type Point3D struct { Object; x, y, z float64 }
      type Line    struct { Object; p, q Point3D }
  

  > .... field selectors may not denote overlapping fields:

      obj   := Object{"edge", "black"}
      line3 := Line{Object: obj, name: "diagonal"} // invalid: name denotes a field inside Object

  by amiga386
• > Second, a key in a struct literal may now be any valid field selector for the struct type, allowing fields in nested or embedded structs to be initialized directly

  It's been a while since I've written more than anything trivial in golang, but this seems like a big deal to me. As in, I can define a struct that is consistent and reusable in other structs

  by olingern
• If I'm being honest, I actually hate this feature. I like things being obvious, and structs were always something I could rely on being very explicit.
  by qwm
• This is quite a QoL issue, but is it big? Nothing changes from functional point of view.
  by konart
• This will shorten many test files!
  by andreimackenzie
• I love these release notes but I really wish they would add syntax highlighting to the Go blog. I'm always a little bit surprised/disappointed whenever I land on a go.dev link since I know the code will be just a little harder to visually parse than it needs to be.
  by xavdid
• The Go official web site doesn't even use the Go fonts: https://go.dev/blog/go-fonts

  I wonder if the Go fonts has been created just to get a trademark on the "Go" word...

  by dolmen
• When I started learning Go I went all in including using the recommended editor (acme editor) which has no syntax highlighting, no autocomplete and a very different way of writing code. My production went down a lot but the quality of the code went up a lot.

  I think the lack of syntax highlighting was one reason for that. It makes you think more about the code you write and how it should compose, while a fully fledged IDE encourages you to just throw more code at the problem.

  I think the ACME way should be used for love of code and ideally when you want to create libraries that stand the test of time. When you just want to get things done fast bring the full IDE and now some LLM vibes and it’s done.

  by theplumber
• I get the why, kind of - if you need colors to make sense of code, maybe the code isn't clear enough. If you send blobs of code through email and other systems that don't necessarily have syntax highlighting, it also makes sense. But on a website, whyever not?

  Personally I can't say when I was last actually aware of syntax highlighting. The only time I'm actively engaged with it is to change the default low contrast comment color that a lot of themes have (for some reason, as if comments are unimportant / noise) to something better. For Go, I don't really notice when it has or doesn't have syntax highlighting, at least not on e.g. go's website.

  by Cthulhu_
• I just have a tampermonkey profile for go.dev to fix that for me.
  by ClikeX