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

41–50 of 236 posts

Re: Go 1.21 Release Candidate

#41

Post by monocasa »

jeffbee wrote: post #31
monocasa wrote: post #23

Nice, my push for actually using the sha256 instructions on amd64 finally got released. 3x-4x increase in hash speed on most x86 which is really nice for content addressable storage use cases like handling container images.

Huh, that is interesting how they do that. They are enabling SHA instruction support based on CPUID and without respect to the value of GOAMD64. I did not realize Go was doing that.

AFAIK, the sha256 extension isn't a part of any of the x86_64 microarchitecture levels, so a cpuid check is most appropriate here at the moment.

Re: Go 1.21 Release Candidate

#42

Post by klodolph »

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.

Making them builtins allows them to work as you’d expect with cases like,

    func clamp(x float64) float64 {
        return max(0, min(1, x))
    }
With ordinary functions, the arguments are assigned types too soon, and you get integer types for 0 and 1 in the above code. In C++ you might make the types explicit:

    template
    T clamp(T x) {
        return std::max(0, std::min(1, x));
    }
That’s not meant to be exactly the way you’d write these functions, but just a little bit of sample code to show how the typing is different.

Re: Go 1.21 Release Candidate

#43

Post by collinvandyck76 »

panzi wrote: post #33

Wait is this now heap allocating a value in every iteration of every loop? I hope that allocation is optimized out in every case where there isn't a closure over the loop variable?

I didn't see this optimization when I read the overview. I also hope that the compiler is smart enough to avoid this.

Re: Go 1.21 Release Candidate

#45

Post by vbezhenar »

panzi wrote: post #33

Wait is this now heap allocating a value in every iteration of every loop? I hope that allocation is optimized out in every case where there isn't a closure over the loop variable?

Of course it'll be optimized. It's just semantics that's changed. Compiler will make sure to copy variable value to new address.

Re: Go 1.21 Release Candidate

#46

Post by quacker »

panzi wrote: post #33

Wait is this now heap allocating a value in every iteration of every loop? I hope that allocation is optimized out in every case where there isn't a closure over the loop variable?

They discuss this here: https://github.com/golang/go/wiki/LoopvarExperiment#will-the...

In fact, you can enable warnings/logs that indicate whether code that is affected by the loopvar experiment results in a stack-allocated or heap-allocated loop variable: https://github.com/golang/go/wiki/LoopvarExperiment#can-i-se...

I imagine that the current workarounds for this issue also end up with heap-allocated variables in many cases.

Re: Go 1.21 Release Candidate

#47

Post by fourseventy »

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 literally just updated all of my golang logging to use zerolog so i could get severity levels in my logs. Bad timing on my part! I guess ill re-do it all with slog, i prefer stdlib packages to third party packages.

Re: Go 1.21 Release Candidate

#48

Post by klodolph »

throwaway5959 wrote: post #44

Why is map copy "dst, src" vs "src, dst"?

Copy operations in Go are normally destination first, source second. This includes builtins like copy() and library functions like io.Copy(). Making it "src, dest" would make this one case the opposite of all the others.

Note that the order mimics variable assignment. You copy an integer with:

    var src, dest int
    dest = src // dest first, src second
I appreciate the consistency.

Re: Go 1.21 Release Candidate

#49

Post by francislavoie »

ubavic wrote: post #12

I enjoy Go so much. It is almost perfect language for getting things done, but I still can't understand some design choices. Does someone knows why Go uses env variables (like GOOS and GOARCH) instead command line arguments?

Env vars make it easier to automate in CI. The actual script to build for each os/arch is the same but only the vars change. It's convenient. You can always prefix the command with the env vars on the same line if you want a one-liner.
Post reply on HN