Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.27

go.dev

Post reply on HN
Print view View original

221–230 of 277 posts

Re: Go 1.27

#221

Post by nasretdinov »

thiht wrote: post #204
nasretdinov wrote: post #148

Earlier quoted context omitted.

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 i…

Are rewrites from Go to Rust for performance reasons really that common?

Hard to say tbh, but there are some high-profile examples, e.g. from Discord: https://discord.com/blog/why-discord-is-switching-from-go-to...

Re: Go 1.27

#222

Post by ungerik »

iaaan wrote: post #35
guessmyname wrote: post #28

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 [2] https://go.dev/pkg/uuid [3] https://github.com/kubernetes/kubernetes/blob/2220c3853a2402... [4] https://github.com/google/uuid/issues/221

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.

uuid.UUID is implemented as [16]byte, like most other UUID implementations out there.

If you want to keep your package implementation agnostic, use [16]byte as argument type; that's assignment-compatible with any other type that is such an array underneath:

For an example, see the UUID logging of golog: https://pkg.go.dev/github.com/domonda/golog#Message.UUID

Re: Go 1.27

#223

Post by jeremyjh »

tgv wrote: post #153
jeremyjh wrote: post #93

Earlier quoted context omitted.

Oceania had always been at war with Eastasia.

Apart from the fact that your comment is against the rules: please don't trivialize that quote. It has a profound meaning, and is completely out of place here.

There is a thread linked where we literally see gophers express the belief that they do not like syntax highlighting, and mock those who do - because Great Leader - born in 1956 - does not like syntax highlighting. Its called double think.

https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/6STj...

Re: Go 1.27

#224

Post by mseepgood »

AdieuToLogic wrote: post #135
win311fwg wrote: post #122

Earlier quoted context omitted.

Generics were always planned, of course: https://www.youtube.com/watch?v=rKnDgT73v8s&t=3267s Rejecting templates does not mean rejecting generics.

> Generics were always planned, of course ... This is provably incorrect. The position held for many years by the language authors was[0]: Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do. Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to t…

"May well be added at some point" it said and added they were at some point.

Re: Go 1.27

#225

Post by nasretdinov »

stjo wrote: post #218
nasretdinov wrote: post #148

Earlier quoted context omitted.

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 i…

Odin solves this by letting you declare all arrays as either normal (AoS) or SoA, which helps with this use case a lot. Otherwise very similar ideas, except all the memory goodies. Underrated language!

Yeah, Odin's auto-SoA looks nice indeed

Re: Go 1.27

#226

Post by jerf »

pjmlp wrote: post #209
amiga386 wrote: post #201

Earlier quoted context omitted.

I'm not sure what I can say. One man's "source of bugs" is another man's "convenient syntax". The rule errs in favour of the developer and the struct they can see. Initialising (or accessing!) a named field always picks the one in the top-level struct if you have one there. It'll be there because you added it. Promoted fields can only get promoted if they are unambiguous. If you don't want to take advantage of that,…

The only, single, complaint is that this possible source of bugs should be part of go vet, just like in other programming languages static analysis tooling, Sonar, PVS, clang-tidy, Roslyn, Checkstyle, clippy, PMD,.... catch such kind of flaws. However I see that I crash again in the Go versus other programming languages ecosystems mindset.

You, or $YOU, could add that as a linter and integrate it into golangci-lint [1]. There are many things in golangci-lint that I abhor and can't even imagine turning on, things that default to false that I can't imagine working without, and some things I think just bizarre... and everyone will have their own distinct list of such things. While one can argue about the virtues of things being in linters versus in the language I do think it's a useful way to resolve these sorts of issues without having to litigate the compiler itself. If I were ever to build my own language it would ship with an equivalent of golangci-lint and its open-source ethos of linting from day one.

In the before times this would be not very helpful but in 2026 this is probably about 30 minutes of your actual time and maybe a couple of hours of AI time. The code isn't too hard to write but there are a number of edge cases to cover, as there always is in this sort of thing.

[1]: https://golangci-lint.run/docs/plugins/module-plugins/

Re: Go 1.27

#227

Post by freedomben »

saghm wrote: post #212
Joel_Mckay wrote: post #130

Earlier quoted context omitted.

Colloquialisms and slang have unstable meaning over history, location, and cultures. Generally, something to be avoided by people striving for clearer communication. =3

> Generally, something to be avoided by people striving for clearer communication Their communication seemed pretty clear to me. If anyone actually claims that they didn't understand what they meant but would have understood it by using the other form of the expression, I think that's a bold-faced lie.

I'm on the other side of this one, but take an up vote for a glorious closer. Well done good sir.

Re: Go 1.27

#228

Post by XorNot »

saturn_vk wrote: post #203
dotwaffle wrote: post #116

Earlier quoted context omitted.

Well, there's kind of a precedent at least... > Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.

That's been a major success

It basically revolutionized the entire industry and thank god.

Opinionated standard formatting is now the default.

Re: Go 1.27

#229

Post by konart »

kar1181 wrote: post #50

Go - the language no one likes, but frankly everyone needs.

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.

Re: Go 1.27

#230

Post by konart »

BeriV2 wrote: post #95

does it have goroutine termination, i recently found out you need a runtime patch for it

Terminated from the outside? No. The only way is to have a communication channel or a context that can be canceled and a proper handling of these.
Post reply on HN