So I guess with new builtin functions we will be breaking backwards compatibility?
Go 1.21 Release Candidate
81–90 of 236 posts
Re: Go 1.21 Release Candidate
#82Overall, a release more for engineering than language. Even the new API's are mainly optimizations, and optimizations are netting ~10% (pretty good for an mature toolset).
The WASI preview shows Google is committing engineering resources to WASM, which could grow the community a touch.
Re: Go 1.21 Release Candidate
#83Earlier quoted context omitted.
They're not reserved keywords. Existing/package defined min/max functions would take precedence. They have the same semantics as `append`
You refactored your code, you think you wrote your ``min`` function, but no, it'll call the builtin one, without warning you.. I don't like this design..
Qt uses qMin and qMax, it may have been nice if go went with like gMin and gMax
Re: Go 1.21 Release Candidate
#84Earlier quoted context omitted.
You refactored your code, you think you wrote your ``min`` function, but no, it'll call the builtin one, without warning you.. I don't like this design..
The compiler will tell you if the types aren't compatible, and this is only for primitive comparable types. What `min()` implementation could you have that even does something different?
A heap?
Re: Go 1.21 Release Candidate
#85[flagged]
What big thing are you expecting? Go is more of a stable language, a reliable and boring language for building software now that in ten years you can still maintain. Go isn't peaking, Go isn't an exciting or cool or hype language, it's just... there. And that's just fine. Too many languages just started borrowing features from others, saying "yes" to every suggestion, until they got out of control and all over the pl…
> ...generics took a long time because they wanted to understand the problem and not add more like what happened to Java
Just out of curiosity, can anyone regale me with that history with Java's generics?
Re: Go 1.21 Release Candidate
#86These new packages, like slices and maps, were a long time coming. So glad it's finally here. I cannot even begin to tell you how many different itemInSlice functions I've written over the years.
tbh whenever I write one of these it makes me wonder if I can accomplish the same logic in a better way.
Re: Go 1.21 Release Candidate
#87Earlier quoted context omitted.
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.
Fair point. But what surprised me was the way HasAVX2 is getting set. It is set on the hardware that has AVX2, even if you set GOAMD64=v1.
In case anyone else was wondering what this is about, here's some useful background https://github.com/golang/go/issues/45453
Re: Go 1.21 Release Candidate
#88> New built-in functions: min, max and clear. What a mistake.. reserved keywords are words I can no longer use for myself... Zig does it better by requiring a prefix @ for most their builtin needs
breaks all my variables named min and max
Re: Go 1.21 Release Candidate
#89Earlier quoted context omitted.
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.
Fair point. But what surprised me was the way HasAVX2 is getting set. It is set on the hardware that has AVX2, even if you set GOAMD64=v1.
Yup, that's standard, including in other ecosystems. It's what I do in ripgrep for example when your target is just standard `x86_64` (v1). GNU libc does it as well. And I believe Go has been doing it for quite some time. (The specific one I'm aware of is bytes.Index.)
This was especially important back before the days of v1/v2/v3/etc of x86_64, since Linux distros distributed binaries compiled for the lowest common denominator. So the only way you got fast SIMD instructions (beyond SSE2) was with a CPUID check and some compiler features that let you build target specific functions. (And I'm not sure what the status is of Linux distros shipping v1/v2/v3/etc binaries.)
Re: Go 1.21 Release Candidate
#90Can we get arenas yet?