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

Go 1.21 Release Candidate

go.dev

Post reply on HN
Print view View original

101–110 of 236 posts

Re: Go 1.21 Release Candidate

#101

Post by racingmars »

throwawaygo wrote: post #81

So I guess with new builtin functions we will be breaking backwards compatibility?

If you already have your own functions or variables named max, min, or clear in-scope, they will shadow the new built-in functions and your code will continue to use your own version of the functions. No breakage to existing identifiers that match the new function names.

(This is the same behavior as the append built-in function today, for example. These things in Go are _not_ reserved keywords, they are simply global functions that can be overridden at other scopes.)

Re: Go 1.21 Release Candidate

#102

Post by xyst »

jeffbee wrote: post #34
candiddevmike wrote: post #27

Earlier quoted context omitted.

Got a link to the PR? Curious to see how this is implemented.

It looks like https://go-review.googlesource.com/c/go/+/408795

Seems like these changes only benefit you if you have an Intel processor. If you have an AMD or Arm processor, you won’t see any difference.

Also, interesting to see assembly again after many years. Haven’t touched that since college during a compilers and assembly course.

Edit: never mind, amd has implemented these “sha-ni” instructions since “Zen” [1]

[1] https://en.wikipedia.org/wiki/Intel_SHA_extensions

Re: Go 1.21 Release Candidate

#104

Post by vl »

cube2222 wrote: post #40

I'm a bit surprised that the slog package was added to the stdlib, but it does seem to use the API that I think is the most ergonomic across libraries I saw in Go (specifically, varargs for key values, and the ability to create subloggers using .With), so I guess it's nice most of the community will standardize around it. If all goes well, you won't have different libraries using different loggers anymore, in some no…

I wonder if it's possible to use slog in 1.20 already, is there a back-port?

I'm changing logging on the service right now and it just makes sense to use it now, but entire service can't move to pre-release version of go.

Re: Go 1.21 Release Candidate

#105

Post by monocasa »

xyst wrote: post #102
jeffbee wrote: post #34

Earlier quoted context omitted.

It looks like https://go-review.googlesource.com/c/go/+/408795

Seems like these changes only benefit you if you have an Intel processor. If you have an AMD or Arm processor, you won’t see any difference. Also, interesting to see assembly again after many years. Haven’t touched that since college during a compilers and assembly course. Edit: never mind, amd has implemented these “sha-ni” instructions since “Zen” [1] [1] https://en.wikipedia.org/wiki/Intel_SHA_extensions

And adding that they already had support for ARM sha256 instructions https://github.com/golang/go/blob/master/src/crypto/sha256/s...

Re: Go 1.21 Release Candidate

#106

Post by onionisafruit »

stefan_ wrote: post #96
Waterluvian wrote: post #25

Earlier quoted context omitted.

It might also be that they’ve worked their way down the priority list and are getting to these features that are largely just to tidy up code.

Clearing a container is usually a much simpler and faster operation than looping through all and removing them individually. That's not a question of tidying something up.

There were compiler optimizations for clearing by iterating. I haven’t looked at the code, but I suspect this won’t be much more efficient than iterating was with the optimizations.

Re: Go 1.21 Release Candidate

#107

Post by onionisafruit »

vl wrote: post #104
cube2222 wrote: post #40

I'm a bit surprised that the slog package was added to the stdlib, but it does seem to use the API that I think is the most ergonomic across libraries I saw in Go (specifically, varargs for key values, and the ability to create subloggers using .With), so I guess it's nice most of the community will standardize around it. If all goes well, you won't have different libraries using different loggers anymore, in some no…

I wonder if it's possible to use slog in 1.20 already, is there a back-port? I'm changing logging on the service right now and it just makes sense to use it now , but entire service can't move to pre-release version of go.

Indeed it's in "golang.org/x/exp/slog"

Re: Go 1.21 Release Candidate

#108

Post by metaltyphoon »

racingmars wrote: post #101
throwawaygo wrote: post #81

So I guess with new builtin functions we will be breaking backwards compatibility?

If you already have your own functions or variables named max, min, or clear in-scope, they will shadow the new built-in functions and your code will continue to use your own version of the functions. No breakage to existing identifiers that match the new function names. (This is the same behavior as the append built-in function today, for example. These things in Go are _not_ reserved keywords, they are simply globa…

Lets be honest, its a terrible choice

Re: Go 1.21 Release Candidate

#109

Post by tedunangst »

tinco wrote: post #91
Hakkin wrote: post #9

Huh, I'm glad to see generic Min/Max functions, but the fact that they're built-ins is a little odd to me. I would have expected them to put a generic math library into the stdlib instead. The fact the stdlib math package only works with float64s has always struck me as a poorly thought out decision.

What sort of use case do you see for non-float64 math operations in a Go application?

Float32 is pretty popular in graphics.

Re: Go 1.21 Release Candidate

#110

Post by metaltyphoon »

sa46 wrote: post #20
anyoneamous wrote: post #7

Earlier quoted context omitted.

As a non-developer who has only gone as far as "hello world" in Go, I'm baffled by the idea that the log/slog thing is new - that seems like an absolutely basic language feature. TBH I'd say the same about min/max, but could forgive those being absent since Go isn't known for being numerically-focused...

Most languages include unstructured logging libraries in the standard library, including Go. Structured logging is usually provided by third party libraries.

The only other one I know would be C# with Microsoft.Extensions.Logging. Its so ubiquitous that 3rd party libraries work with its abstractions. Slog is a really good thing for Go
Post reply on HN