7 ms·

Go 1.27

• tschellenbach 2mo ago
  Every release CPU load becomes a bit lower. Love it :)
  • ejboy 2mo ago
    Keeping priorities right!
• fatty_patty89 2mo ago
  [flagged]
  • simlevesque 2mo ago
    Being on the HN's homepage isn't as simple as "most upvoted articles in last X hours". They take into account upvote velocity: 40 upvotes in 40 minutes isn't the same as 40 upvotes in 4 yours.
    • fatty_patty89 2mo ago
      no, it wasnt 40 upvotes in 40 minutes, it was at 8 upvotes after 34 minutes posted
  • applfanboysbgon 2mo ago
    Would you rather have yet another LLM-generated slop article in its place instead of an article covering a major release for a widely-used language? Out of all the articles that reach the HN front page, this is the one you have a problem with?
• patabyte 2mo ago
  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
• piinbinary 2mo ago
  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.
  • ainar-g 2mo ago
    Re unions: https://github.com/golang/go/issues/76920 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.
    • Mawr 1mo ago
      For a TL;DR, most relevant comment is: https://github.com/golang/go/issues/76920#issuecomment-5310309424 https://github.com/golang/go/issues/76920#issuecomment-53103...
  • codegeek 2mo ago
    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.
    • osigurdson 2mo ago
      Go is extremely easy to pickup. If you know any language you probably know Go already for the most part (channels notwithstanding). I wouldn't say it is a "beautiful" language however. Though that is in the eye of the beholder, I don't think the Go designers were even really going for beauty.
      • fragmede 2mo ago
        They were going for readability. You can make some impossible to read code with C++ because the programmer was too clever, and the designers of golang wanted to avoid that.
• jeanbza 2mo ago
  I have been waiting for generic methods and can't wait to use them! The `go fix` modernisers are also great, have already run them in several repos.
  • qwm 1mo ago
    I'm a big fan of `go fix`, such a nice thing for big projects
• sethops1 2mo ago
  FYI golangci-lint and gopls are both broken if you try using generic methods.
  • atsjie 2mo ago
    Thank you for the headsup!
  • adonovan 2mo ago
    Broken how? Please report an issue. The latest gopls should support generic methods.
    • sethops1 2mo ago
      Ah my bad gopls is fine; I forgot to run go install golang.org/x/tools/gopls@latest after upgrading Go itself.
  • tkw01536 1mo ago
    I’ve been able to run golangci-lint locally just fine. However I’ve not had much success running it on CI, with at least the 1.27rcs. I encountered some panic deep within staticcheck, and ended up turning off that specific linter on CI (better than not running it at all). There was a tracking issue for go1.27 support at [1]. However that is now closed, which might imply that it should be working. [1] https://github.com/golangci/golangci-lint/issues/6643 https://github.com/golangci/golangci-lint/issues/6643
• nick_ 2mo ago
  Nice additions to go. I like to imagine that one day we'll have a language that launched with all the features languages eventually add. The whole ecosystem of packages would be built on them instead of a legacy of more primitive language feature sets.
  • fmbb 2mo ago
    I don’t think launching Go today would have been better than 15 years ago. Standard ML is a perfect programming language from the 90s. It unfortunately does not have a great eco system of packages.
    • qaq 2mo ago
      I mean one thing frontier models are really good at is porting code with pretty low level of supervision. Provided there are enough fans porting packages from other ecosystems should not be a big challenge.
  • abtinf 2mo ago
    Obligatory XKCD reference: https://xkcd.com/927/ https://xkcd.com/927/
  • JyB 1mo ago
    No thanks. Reduced feature-set is the appeal.
  • win311fwg 1mo ago
    > I like to imagine that one day we'll have a language that launched with all the features languages eventually add. Don't most languages on the heap of languages nobody uses fulfill that?
• olingern 2mo ago
  > 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
  • konart 2mo ago
    This is quite a QoL issue, but is it big? Nothing changes from functional point of view.
    • onionisafruit 2mo ago
      It will be very nice working with code generators like oapi-codegen that can generate either nested structs or very unwieldy struct names. So big in that context, but like you said just a nice qol improvement most of the time.
  • andreimackenzie 2mo ago
    This will shorten many test files!
  • qwm 1mo ago
    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.
• tschellenbach 2mo ago
  New JSON is amazing, and SIMD will be big for json, audio/video etc.
• Hasz 2mo ago
  I have recently been spending time learning go, really really liking the language, awesome standard lib, excellent tooling and great experience. It sounds like the dumbest thing in the world, but I love the import system auto-adding stuff inside of vscode when I need it. just slick.
  • nasretdinov 1mo ago
    I think the fact that package names are URLs is simultaneously genuis and horrifying.
• teabee89 2mo ago
  I love how proactive the crypto team is about post quantum. They released https://pkg.go.dev/crypto/mldsa https://pkg.go.dev/crypto/mldsa. The lead maintainer Filippo Valsorda wrote a nice piece here[1] to urge the tech world to start deploying good enough versions of post quantum crypto. [1] https://words.filippo.io/crqc-timeline/ https://words.filippo.io/crqc-timeline/
  • halJordan 2mo ago
    While I'm highly sympathetic to competing priorities crowding out movement to pq cryptography. At the same time it's not sudden at all. It's been 10 years since nist first said "move shit over"?
    • Valodim 2mo ago
      Yes, and at that time the answer was "move over where?" now it's 2026 and x-wing is a draft still
      • halJordan 2mo ago
        Ah. This is a bold faced lie. There were plenty of options in 2016. Nist released final candidates in 2024 and published the candidates this year. ssh (as noted in tfa) has had pq defaults since 2022.
        • blandflakes 2mo ago
          In case you wanted to know, the expression is actually "bald-faced lie", i.e. unmasked, shameless.
          • Joel_Mckay 2mo ago
            They are also lying, it is an Italics-Faced lie... thank you, I will see myself out. =3
            • 1mo ago
• Xeoncross 2mo ago
  > First, generic methods are now supported > Generic functions can now be used without explicit type arguments Great! This was an ergonomic code issue I hit when trying to create a universal handler/controller generic that could hydrate/populate function arguments (from a request body) without having an actual copy of the arguments: https://github.com/xeoncross/mid/blob/main/handler.go#L12 https://github.com/xeoncross/mid/blob/main/handler.go#L12
  • iaaan 2mo ago
    Neat, stealing this.
    • Xeoncross 2mo ago
      I wrote a blog on it if you're interested: https://xeoncross.com/2026/better_go_handlers.html https://xeoncross.com/2026/better_go_handlers.html
      • greg9381 2mo ago
        Thanks for the link, looks like a very pleasant framework to use! I was interested to see "Mid-fasthttp" on the slower end in the benchmarks at the bottom, do you know why that is? Btw, the Gin and Echo examples reference an "input" variable but it doesn't seem to be defined there? Maybe it was intentional, since the examples are just to give a general idea of how the handler looks in each library, but thought I would let you know just in case it wasn't.
        • Xeoncross 2mo ago
          Due to the fact that fasthttp is not net/http compatible it is due to the conversion being required from a https://pkg.go.dev/net/http#Handler https://pkg.go.dev/net/http#Handler. It was included for information purposes as I though someone would be curious.
  • knocte 1mo ago
    Can proper Result/Option types be created for Go now?
• olexsmir 2mo ago
  Full release notes: https://go.dev/doc/go1.27 https://go.dev/doc/go1.27
• tonymet 2mo ago
  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
  • radicalriddler 2mo ago
    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.
    • tonymet 2mo ago
      true that, but we get a couple of these a year it seems, so their overall velocity is excellent, and without breaking anything. a dream language.
• CurbStomper 2mo ago
  [dead]
• guessmyname 2mo ago
  Brace for a wave of drive-by pull-requests swapping google/uuid [1] out for the now-standard uuid package [2]. Kubernetes project will be the first one [3] I guarantee it. [1] https://pkg.go.dev/github.com/google/uuid https://pkg.go.dev/github.com/google/uuid [2] https://go.dev/pkg/uuid https://go.dev/pkg/uuid [3] https://github.com/kubernetes/kubernetes/blob/2220c3853a2402ffc0502995c49b383f84ae8ceb/go.mod#L36 https://github.com/kubernetes/kubernetes/blob/2220c3853a2402... [4] https://github.com/google/uuid/issues/221 https://github.com/google/uuid/issues/221
  • dabber21 2mo ago
    will 'go fix' take care of this?
    • qwm 1mo ago
      I don't think it ever suggests anything specific to 3rd-party packages
  • iaaan 2mo ago
    Unfortunately for people SELECTing UUIDs out of a DB directly into a uuid struct, the built-in uuid structs don't implement the necessary interface for that, so you'll have to continue using the google package, or a plain string.
    • reactordev 2mo ago
      Oooof… well played go team, well played.
    • deepsun 2mo ago
      Or just a number (128-bit).
    • agwa 2mo ago
      The database/sql package gained native support[1] for the uuid.UUID type so it will Just Work even without the methods. This probably should have been mentioned in the release notes and database/sql package docs. [1] https://cs.opensource.google/go/go/+/refs/tags/go1.27.0:src/database/sql/convert.go;l=270-280 https://cs.opensource.google/go/go/+/refs/tags/go1.27.0:src/...
• e4m2 2mo ago
  Not mentioned: Floating-point parsing and formatting now uses Russ Cox's uscale algorithm. https://research.swtch.com/fp https://research.swtch.com/fp https://github.com/golang/go/blob/go1.27.0/src/internal/strconv/uscale.go https://github.com/golang/go/blob/go1.27.0/src/internal/strc...
  • jeremyloy_wt 2mo ago
    I’m so happy Russ still contributes even though he isn’t lead anymore. I always enjoy reading his blog posts
    • dvt 2mo ago
      One of my engineering highlights was Russ reviewing a few of my contributions to Golang (to the core http library). He's a super cool and nice guy. I don't really write that much Go anymore, but it was a fun & cute language when it first came out.
      • dekdrop 1mo ago
        I once wrote him an email asking what font was used in the plan9 papers. He replied. It's Lucida Sans Unicode. He even provided a url to paper published by the maker of the font.
  • cornstalks 2mo ago
    I’d love to see how that compares to zmij: https://github.com/dtolnay/dtoa-benchmark https://github.com/dtolnay/dtoa-benchmark
    • e4m2 1mo ago
      The upstream fmtlib dtoa-benchmark integrates uscale (https://fmtlib.github.io/dtoa-benchmark/results/ https://fmtlib.github.io/dtoa-benchmark/results/). It uses C code from Russ Cox's original fpfmt repository (https://github.com/rsc/fpfmt/tree/main/bench/uscalec https://github.com/rsc/fpfmt/tree/main/bench/uscalec), which is slightly different from the Go code upthread. Zmij and xjb are in a league of their own. Broadly speaking, dtoa first has to find the shortest decimal representation of the floating-point input, and then format that decimal representation into a string. Zmij and xjb pull far ahead of the others mostly by speeding up the second part of that process. uscale is quite good without the stringification, as are many other algorithms. I would say uscale's main strength isn't its speed, but rather its simplicity and, more importantly, the fact that it does both formatting and parsing using a single ~11 KiB table, which no other state-of-the-art algorithm offers (although yy comes close).
• tyho 2mo ago
  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.
  • nkanaev 2mo ago
    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 https://github.com/tuzz/pangram-machine [2]: https://github.com/nkanaev/pangram-machine-go https://github.com/nkanaev/pangram-machine-go
  • drivebyhooting 2mo ago
    “Do a breakthrough and make this SIMD fastest”
  • nasretdinov 1mo ago
    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.
    • thiht 1mo ago
      Are rewrites from Go to Rust for performance reasons really that common?
• pregnenolone 2mo ago
  Wasn't Go supposed to be "simple"? I remember how Go advocates used to boast about not having generics and now it almost seems like Go is trying to become some sort of C# or Java Frankenstein. I'm not even trying to badmouth Golang - just legitimately confused.
  • kermatt 2mo ago
    A problem was so many others were screaming about the lack of generics, as though there were not other language options that provided them.
  • pansa2 2mo ago
    > almost seems like Go is trying to become some sort of C# or Java Frankenstein The original Go team was trying to avoid this: "Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] actively borrow features from one another. They are converging into a single huge language." [0] That team has since moved on, and now Go has begun to join that convergence. The problem is that most programmers seem to want to write Java, more-or-less. New, simpler languages come along, but once they get popular, the pressure is on to turn them into Java-likes. It happened to Python and now it’s happening to Go. It takes a strong will for language maintainers to say “no”, and their language will suffer in popularity as a result - see, for example, Ruby. [0] https://go.dev/talks/2015/simplicity-is-complicated.slide#5 https://go.dev/talks/2015/simplicity-is-complicated.slide#5
    • za3faran 2mo ago
      I would argue that languages like Java (C#, Kotlin, etc.) strike a very good compromise between modeling ability and comprehension, which is why they are popular and people gravitate toward them. You can have more complex languages like Scala that provide stronger modeling ability, but at the cost of complexity. Golang started off as extremely naive/simplistic, and is now converging in some ways. But it still has a ways to go: no generics on interfaces, no unions/ADTs, no pattern matching, no proper enums, error handling leaves much to be desired, and much more.
    • JyB 1mo ago
• SpaceManNabs 2mo ago
  Wait generics? What changed? Why is golang accepting of generics now?
  • a2ff6eeb0 2mo ago
    They landed half a decade ago...
    • deleted 2mo ago
      [deleted]
  • nrr 2mo ago
    There are some details here about the history of how generics finally came to Go: https://golang.design/under-the-hood/en/part2lang/ch08generics/history/ https://golang.design/under-the-hood/en/part2lang/ch08generi... The tl;dr boils down to a combination of valuing both compilation speed and execution speed.
• kar1181 2mo ago
  Go - the language no one likes, but frankly everyone needs.
  • amelius 2mo ago
    Python is already the language everyone needs.
  • thiht 1mo ago
    I love Go and would not enjoy working with any other language as much
  • saturn_vk 1mo ago
    Some people do like it though
  • konart 1mo ago
    idk, hn is the only place I every see people actually not liking go and most times those are people who's job is just far away from fields go is being use in.
  • qwm 1mo ago
    Can't relate, I love Go
• xavdid 2mo ago
  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.
  • treyd 2mo ago
    There's a reason for this. Rob Pike was asked about it and said that syntax highlighting reminds him of the bright colors of children's toys and he personally disables it so that he can focus on the text. I don't know why it's still like that but that's the original reasoning.
    • jeremyjh 2mo ago
      What is childish is holding up one guy's editor preferences as a religious sacrament when 99.9% of your readers have different preferences.
      • dotwaffle 2mo ago
        Well, there's kind of a precedent at least... > Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.
        • saturn_vk 1mo ago
          That's been a major success
          • XorNot 1mo ago
            It basically revolutionized the entire industry and thank god. Opinionated standard formatting is now the default.
        • poncho_romero 1mo ago
          Unlike formatting preferences, the colours I use in my editor don't effect others. That said I might not mind living in a world where everyone used the same highlighting scheme, as long as it was reasonable ;)
• dude250711 2mo ago
  Quarterly reminder that Go still exists.
  • IshKebab 2mo ago
    I can imagine using it for simple web stuff. E.g. its perfect for something like Forgejo. But yeah... Seems like the world has moved on mostly.
    • aliasxneo 2mo ago
      A large portion of the DevOps/Platform Engineering world uses Go.
    • qwm 1mo ago
      In the network and web backend world, we haven't moved on, and for good reason
    • JyB 1mo ago
      That comment is a good reminder that a good chunk of people commenting on HN are completely out of touch with the real world, the actual popular ecosystems out there, and what companies actually do and use nowadays to ship.
  • tgv 1mo ago
    The release cycle is semi-annually.
• ejboy 2mo ago
  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.
  • qwm 1mo ago
    Same. Go feels like the language that does everything I like about Java with a lot more control than Java gives
• BeriV2 2mo ago
  does it have goroutine termination, i recently found out you need a runtime patch for it
  • ameliaquining 2mo ago
    What exactly do you mean by "goroutine termination"?
    • tgv 1mo ago
      I suppose: a "go" returns an id, and then you call kill(id) to terminate it, as if it were a pthread or a process. In which case the answer is: no.
      • ameliaquining 1mo ago
        Non-cooperatively terminating a shared-memory thread is an inherently unsafe thing to do, and basically every runtime that has an API for it regards it as a design mistake. See, e.g., https://docs.oracle.com/javase/8/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html https://docs.oracle.com/javase/8/docs/technotes/guides/concu... and https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-terminatethread#remarks https://learn.microsoft.com/en-us/windows/win32/api/processt.... (POSIX's pthread_cancel is somewhat different, and avoids some of the worst failure modes, but at the cost of not actually consistently killing the thread when you call it—and it still has a lot of problems besides that.) So I don't think Go is ever going to add this, nor should it. (Having the go statement return a handle that you can block on would of course be completely fine, but at this point they're probably not going to do that either.)
      • deleted 1mo ago
        [deleted]
      • robryan 1mo ago
        Can just pass it a context, cancel the context, and handle for it in the goroutine.
  • 1mo ago
• Fervicus 2mo ago
  I really want to like Go, but I can't stand looking at Go code. The error handling is such a turn off.
  • vrosas 2mo ago
    Why would you say something so controversial yet so brave?
  • kajika91 2mo ago
    Not that I like go at all but because of it my C++ is starting to look like it as I am returning tuples of [result, error]. I try to avoid exceptions, is there any better ways? (Variant looks a bit more complicated but could be a totally OK alternative)
    • ameliaquining 2mo ago
      C++23 introduces std::expected, which is a simpler alternative to std::variant designed specifically for the result-or-error use case. You still don't get pattern matching, but Go-style tuples don't give you that either.
  • whalesalad 2mo ago
    Personally I feel go has many issues and is ugly as hell but the error handling is really the least of my worries.
    • Fervicus 1mo ago
      It's the ugly as hell part that gets me.
      • JyB 1mo ago
        Pretty childish. People have no trouble looking past it when they care about actually shipping reliable software that properly handles all code paths. Including error paths that are ignored in so many codebases.
• evantbyrne 2mo ago
  Generic methods are a huge win for the language. I've been waiting on these kinds of improvements to the type system before resuming work on my database toolkit.
  • drivebyhooting 2mo ago
    I know this is an extremely unwelcome comment but I just have to ask… have you considered rust? Especially for a DB. I just had excellent success migrating a go code base to rust completely AI driven. It led to a healthy performance boost too, as now I don’t need to worry about GC pressure contortions.
    • evantbyrne 1mo ago
      Ecosystem is my primary concern when it comes to language choice and I'm not worried about speed differences between Go and Rust. Unfortunately, Python is probably still the most practical choice for backend/pipeline engineering at the moment. That does mean there are Rust libraries being used indirectly though.
  • AdieuToLogic 2mo ago
    > Generic methods are a huge win for the language. I've been waiting on these kinds of improvements to the type system ... It's funny that you and many others have found the introduction of "generics" in Go to be highly valuable, considering one of the motivations for Go's existence was: Its designers were primarily motivated by their shared dislike of C++[0] One of the language features C++ provides, "templates", was explicitly rejected by the language authors as being antithetical to Go philosophy[1]. Thompson put it bluntly: DDJ: In the presentation before the awarding of the Japan Prize today, you were quoted on the distinction between reasearch and development. [The former, Thompson stated, was directionless, whereas development had a specific goal in mind.] So in that context, is Go experimental? KT: Yes. When the three of us [Thompson, Rob Pike, and Robert Griesemer] got started, it was pure research. The three of us got together and decided that we hated C++. [laughter] [2] And now, years later, generics are "a huge win." 0 - https://en.wikipedia.org/wiki/Go_(programming_language)#History https://en.wikipedia.org/wiki/Go_(programming_language)#Hist... 1 - https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti... 2 - https://web.archive.org/web/20110521080746/http://drdobbs.com/open-source/229502480 https://web.archive.org/web/20110521080746/http://drdobbs.co...
• DisceetPlug 2mo ago
  [dead]
• DisceetPlug 2mo ago
  [dead]
• freakynit 2mo ago
  As I've always said: every non-functional programming language, as it matures, it's adoption rises in enterprise, eventually starts to become more and more like Java in terms of it's syntax and feature-set.
  • someothherguyy 2mo ago
    because functional languages already have those features?
    • freakynit 2mo ago
      naah.. they are just too different syntactically.. and the way programmers use them..
  • qwm 1mo ago
    I know this is supposed to be a negative comment, but I don't think this is a bad thing
    • freakynit 1mo ago
      I was not sure if people are gonna perceive it as negative... I absolutely love Java... my main point was that Java was already way ahead of the curve...
• tugback 2mo ago
  Generic methods finally landing is huge. Having to write a separate typed method for every integer type was one of the most annoying boilerplate patterns in Go.
• pmkary 2mo ago
  I'm always amazed on how the Go team has bo faith in syntax highlighting.
• BLACKCRAB 1mo ago
  [dead]
• todotask2 1mo ago
  Interesting, this reduced memory usage in my test down from 14 MB to 12 MB, and Bun (Rust) is still at 7.2 MB, down from 10 MB with Bun (Zig).
• punnerud 1mo ago
  [dead]
• pjmlp 1mo ago
  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 https://go.dev/play/p/dsY6tK5S8Ie Better generics and improved SIMD are nice additions as well.
  • j3nz 1mo ago
    I'd say it is as expected https://go.dev/play/p/sy6SMrOiw4y https://go.dev/play/p/sy6SMrOiw4y
    • pjmlp 1mo ago
      I would at least expect a go vet warning in such cases.
  • 0x696C6961 1mo ago
    Mhm, probably worth a golang-ci check for duplicate field names which are accessed by methods on the embedded type.
    • pjmlp 1mo ago
      Better would be a got vet check. I understand the need not to break existing code that might have such fields.
      • 0x696C6961 1mo ago
        I think that's a no-go because vet checks have no-false-positive policy. Ie, when go vet flags something, its a bug.
        • pjmlp 1mo ago
          I would say that initialising the wrong field because a dev is unaware of a clash between Gopher.Burrow and Gopher.Habitat.Burrow (naturally in more complex code), when upgrading to 1.27 and taking advantage of the feature without realising it, is a bug.
• dveeden2 1mo ago
  Go 1.27 interactive tour: https://victoriametrics.com/blog/go-1-27/ https://victoriametrics.com/blog/go-1-27/
• blakeashleyjr 1mo ago
  Go was my first language, and I still use it every day for projects tiny (scripts) to massive (1M+ line microservice projects) and love it! Thank you to the Go team for everything you have done over the last 2 decades.