8 ms·

What's Coming in Go 1.14 [slides]

107 points by ngaut 7y ago

pjmlp 7y ago
It could just as well be a bullet point list of urls. What about providing a well thought out summary?
- minxomat 7y ago
  Heh, I wish everyone would adopt the gold standard in changelogs: Noriyoshi Shinoda's write-ups of changes in Postgres versions. Example: https://h50146.www5.hpe.com/products/software/oe/linux/mainstream/support/lcc/pdf/PostgreSQL_12_Beta1_New_Features_en_20190524-1.pdf https://h50146.www5.hpe.com/products/software/oe/linux/mains... Clear scope, introduction of new features and demonstrations with examples (even of differences between versions)
  - grenoire 7y ago
    Christ, this is on the exact opposite extreme. I'm not sure if this is what I would like to dig through for each big release; could be a tad easier to digest.
    - minxomat 7y ago
      I mean, I agree. But there's a toc and I usually skip to the sections relevant to my use cases. The only people who should maybe read the entire thing are (in this case) DBAs.
    - pritambaral 7y ago
      Chapter 2 (Chapter 1 is "About This Document") is "New Features Summary".
  - bla3 7y ago
    (warning: pdf link)
  - judge2020 7y ago
    I think the laravel upgrade guide is better, you see what might actually break or cause unintended behavior and there's a release notes page with a list of new stuff you can choose to use. https://laravel.com/docs/6.x/upgrade https://laravel.com/docs/6.x/upgrade
  - divan 7y ago
    Original link is not changelog, but slides from the meetup presentation. Typical Go changelog is here: https://golang.org/doc/go1.13 https://golang.org/doc/go1.13
- mvdan 7y ago
  These are the slides from a talk; I didn't spend the extra time to change the format or write down what I explained. After all, I didn't post them here, someone else did :) I personally think it's best to just follow the links if the title sounds interesting to you.
  - pjmlp 7y ago
    Fair enough. I did follow the links, however it is a bit tedious to then make a picture from the endless mountain of comments on each issue, hence the remark.
fourseventy 7y ago
I'm a bit confused by the new -static flag. I thought that by default go was statically linked, what am i missing?
- georgyo 7y ago
  Go can link against c libraries. This would make that static as well.
- mvdan 7y ago
  Simple Go binaries do tend to be statically linked, which is where I think the confusion comes from. The most common source of dynamic linking is cgo, since CGO_ENABLED=1 is the default when not cross-compiling. For example, importing os/user will dynamically link against libc, unless you disable cgo or force statically linking with libc. See https://github.com/golang/go/issues/26492 https://github.com/golang/go/issues/26492 for more details. I think the purpose of the flag will be to force static linking in all edge cases, while not disabling cgo explicitly.
- jpgvm 7y ago
  It's not quite that simple unfortunately. If you build a Go package with CGO enabled then Go builds the binary dynamically linked to the system libc. (this can be especially surprising if you believe go is "statically linked") However when CGO is disabled it doesn't link against libc at all as Go has it's own syscall layer etc. It's not clear what this new -static flag will do, likely automatically setup some of the linker static flags when compiling with CGO to statically link other dependencies and perhaps libc itself.
  - sdegutis 7y ago
    > It's not quite that simple unfortunately. This has been my experience with Go. First a promise of everything being much simpler than the alternatives. Then, when we run into all sorts of confusion and caveats, an unapologetic disclaimer about why it's not simple and can't be, with a long exposition about Go's own internal limitations and the trade-offs they had to make.
dis-sys 7y ago
the most exciting one for me is definitely the new escape analysis.
- ithkuil 7y ago
  Does it offer any user visible improvements or is it only a compiler internal improvement?
  - mvdan 7y ago
    It might lead to fewer allocations in complex programs, as the compiler is able to put more in the stack under some edge cases.
- Insanity 7y ago
  Yeah, useful for teams that want to use pointers everywhere and disregard escape analysis xD
- aaronbee 7y ago
  Even more exciting, this is already present in go1.13. I believe the author of these slides made a mistake. Here it is mentioned in go1.13 release notes: https://golang.org/doc/go1.13#compiler https://golang.org/doc/go1.13#compiler And GitHub says the commit is present in go1.13: https://github.com/golang/go/commit/996a687ebbf81b26f81b41b8e62ef21d8b0826af https://github.com/golang/go/commit/996a687ebbf81b26f81b41b8...
  - agnivade 7y ago
    Yeah it is slightly misleading. The escape analysis rewrite was done in 1.13. But work is now going on to remove the old escape analysis code.
xelekitry 7y ago
So there are no changes to address the privacy issues[1] introduced in Go 1.13. The issue raised[2] about this seems to be stalled as well. [1]https://proxy.golang.org/privacy https://proxy.golang.org/privacy [2]https://github.com/golang/go/issues/33985 https://github.com/golang/go/issues/33985
- UncleEntity 7y ago
  Are those two links even related? One talks about the privacy policy and the other is about private repos.
  - Zancarius 7y ago
    Yes, and I think the OP would've been better served by linking to the proxy page rather than its privacy policy. I can understand why, however. Privacy, proxies, and private repos are all inter-related but it might not be obvious to people who don't use Go regularly or haven't followed the introduction of proxies. The problem is that if you don't set up your environment, set it up partially, or set it up incorrectly, some information about private repositories will be sent to Google[1]. One solution is to use the envvar GONOSUMDB (either set from your shell's rc file or, preferably, from `go env`), thus instructing Go which domains it should not validate against the checksum database. Some individuals may not see this as an issue since private repos will fail to download via the default GOPROXY (`go get` should revert to "direct" mode) and nothing gets stored in the sumdb. However, Google does apparently log this information internally, and that's where the privacy issue arises. For additional protection, you can set GOPROXY to your own self-hosted server, such as Athens, and configure it similarly so it'll reject such sumdb requests with a 403 to catch clients using only GOPROXY. But, you still have to remember to set GOPROXY (at a minimum), which means that if you or anyone in your organization forgets this bit, you're back where you started and you're probably sending information about your private repos to Google. Again. Since this relies on envvars or the Go env stored in ~/.config/go/env (as an example) to set the behavior globally, you have to assume developers will correctly configuring every system they use. The GitHub issue is mostly centered on having a way to do this per-repository, and I honestly think that would have been a better solution, even combined with the `go env` settings. Personally, it doesn't bother me too much, because an external immutable append-only log of commits in upstream packages will catch nefarious changes, so I think the benefits probably outweigh the privacy concerns until I see an adequate argument countering this. Regardless, I still have my `go env` set up to ignore my private repositories. [1] The documentation says Google only logs the paths and doesn't publish them for private repositories their proxy fails to download. I thought I read somewhere that you can still use the sumdb for private repos, but it would instead send something like a SHA256 sum of the path for additional privacy. It might've been a proposal, and I can't find it now.
wolfgang42 7y ago
What happened to the try/check error-handling proposal? In June it was selected for inclusion in Go 1.14 [1], but then in the linked issue it seems to have been declined in July. Where did it go? Why the sudden change of heart? [1]: https://blog.golang.org/go2-next-steps#TOC_2 https://blog.golang.org/go2-next-steps#TOC_2.
- divan 7y ago
  It was tried, discussed and abandoned: https://youtu.be/kNHo788oO5Y?t=1026 https://youtu.be/kNHo788oO5Y?t=1026
- toxik 7y ago
  Go continues to impress me with its levelheaded design decisions, sadly I don’t really have a use for it in my work.
  - tyri_kai_psomi 7y ago
    Since go makes it so easy to build a binary for most any platform, I think one area anyone could introduce is it into their toolkits is by building small, simple, purpose-built programs you can easily run on the command line to perform a repetitive task.
- zadokshi 7y ago
  I don’t think the majority actually want this to be part of go
  - codr7 7y ago
    Vocal minority, perhaps. They got carried away with their own cleverness and forgot about the real world, shit happens. The good news is they realized and and realigned with the community, which is awesome.
- Thorrez 7y ago
  Here was the previous discussion when that was abandoned on July 16: https://news.ycombinator.com/item?id=20454966 https://news.ycombinator.com/item?id=20454966
geoah 7y ago
Go 1.13 has been by far the worse release in my memory. The go ecosystem and community was not ready nor prepared for modules. Enabling by default the sum database broke a number of codebases that had altered the history of their codebases (either themselves or their dependencies). This should have been an opt in feature for this version. Changing the way the pseudoversion behaves by expecting a correct date and specific sha length broke a larger number of codebases. This should have been a warning on this version and not cause the modules to fail. There was one more change that I have wiped from my memory that broke athens. It has to do with how go now looks for a go.mod file in parent urls that caused athens to return a 500. Overall spent about a week of swearing and trying to fix tools and deps. At the end gave up and moved back to 1.12.
- kardianos 7y ago
  This is in stark contrast to my experience, which was great. Were you able to file any issues or explain to people what happened?
  - geoah 7y ago
    Hey kardianos, first of all thank you for all your hard work with getting the golang community a worthy dep manager. --- As for reporting the issues, it's something I assumed is common knowledge from the fact that any dep I had an issue with on the first day of 1.13 already had a bug filled. Searching for `"invalid pseudo-version"` in github results in around 80 issues in different repositories that all have to do with go 1.13 and modules. [1] Similarly a search for `golang "checksum mismatch"` will result in over 130 issues in regards to the sum db complaining about broken builds. [2] There will be more that are not been correctly reported in github issues, and there will be false reports as well. But the repos that show up will have caused cascade issues. We couldn't use golangci-lint for a couple of days before it was fixed. There is a limit to the amount of mod replaces I can live with before deciding it's not worth it. Don't get me wrong. I do like mod, but I just think that for a language that prides itself on "backwards compatibility" it's doing a pretty poor job at keeping the same promise when mod is involved. --- [1] https://github.com/search?q=%22invalid+pseudo-version%22+is%3Aissue&type=Issues https://github.com/search?q=%22invalid+pseudo-version%22+is%... [2] https://github.com/search?q=golang+%22checksum+mismatch%22+is%3Aissue&type=Issues https://github.com/search?q=golang+%22checksum+mismatch%22+i...
pkaye 7y ago
Do vscode/gopls work fine with modules now? I was getting sluggish behaviour in the past.
- geoah 7y ago
  They do work pretty nicely for the most part. The only issue I'm still seeing is when having multiple go.mod files in the same workspace. I end up having to split projects with sub-modules in multiple workspaces in vscode and ignore the sub-modules on the main workspace. https://github.com/golang/go/issues/32394 https://github.com/golang/go/issues/32394
- hu3 7y ago
  Recent discussion: https://old.reddit.com/r/golang/comments/ddf721/vscode_is_a_nightmare_to_work_with_if_using/ https://old.reddit.com/r/golang/comments/ddf721/vscode_is_a_...
karmakaze 7y ago
Language changes 0. allow embedding overlapping interfaces 1. len, cap to return untyped ints if constant [0] https://golang.org/issue/6977 https://golang.org/issue/6977 [1] https://github.com/golang/go/issues/31795 https://github.com/golang/go/issues/31795 Major changes 2. Remove SSLv3 3. Make TLS 1.3 opt-out 4. Automatically check and use vendored packages 5. Low-cost defers via inline code 6. Rewrite escape analysis 7. Expose the runtime's hasher 8. Add -static flag to go build 9. Store package metadata in build cache [2] https://golang.org/issue/32716 https://golang.org/issue/32716 [3] https://golang.org/issue/30055 https://golang.org/issue/30055 [4] https://golang.org/issue/33848 https://golang.org/issue/33848 [5] https://golang.org/issue/34481 https://golang.org/issue/34481 [6] https://golang.org/issue/23109 https://golang.org/issue/23109 [7] https://golang.org/issue/28322 https://golang.org/issue/28322 [8] https://golang.org/issue/26492 https://golang.org/issue/26492 [9] https://golang.org/issue/31417 https://golang.org/issue/31417 Minor changes [a] use go.sum hashes from all downloaded modules [b] fail tests that run os.Exit(0) [c] add testing.T.Deadline [d] add regexp.SubexpIndex [e] report failing test after a panic [f] Rewrite the compiler's rulegen [g] Change js mimetype to text/javascript [a] https://golang.org/issue/28802 https://golang.org/issue/28802 [b] https://golang.org/issue/29062 https://golang.org/issue/29062 [c] https://golang.org/issue/28135 https://golang.org/issue/28135 [d] https://golang.org/issue/32420 https://golang.org/issue/32420 [e] https://golang.org/issue/32121 https://golang.org/issue/32121 [f] https://golang.org/issue/30810 https://golang.org/issue/30810 [g] https://golang.org/issue/32351 https://golang.org/issue/32351
mleonhard 7y ago
Did they add min(int32,int32) and max(int32,int32) yet?

107 points by ngaut 7y ago

pjmlp 7y ago

It could just as well be a bullet point list of urls. What about providing a well thought out summary?

minxomat 7y ago
Heh, I wish everyone would adopt the gold standard in changelogs: Noriyoshi Shinoda's write-ups of changes in Postgres versions. Example: https://h50146.www5.hpe.com/products/software/oe/linux/mainstream/support/lcc/pdf/PostgreSQL_12_Beta1_New_Features_en_20190524-1.pdf https://h50146.www5.hpe.com/products/software/oe/linux/mains... Clear scope, introduction of new features and demonstrations with examples (even of differences between versions)
- grenoire 7y ago
  Christ, this is on the exact opposite extreme. I'm not sure if this is what I would like to dig through for each big release; could be a tad easier to digest.
  - minxomat 7y ago
    I mean, I agree. But there's a toc and I usually skip to the sections relevant to my use cases. The only people who should maybe read the entire thing are (in this case) DBAs.
  - pritambaral 7y ago
    Chapter 2 (Chapter 1 is "About This Document") is "New Features Summary".
- bla3 7y ago
  (warning: pdf link)
- judge2020 7y ago
  I think the laravel upgrade guide is better, you see what might actually break or cause unintended behavior and there's a release notes page with a list of new stuff you can choose to use. https://laravel.com/docs/6.x/upgrade https://laravel.com/docs/6.x/upgrade
- divan 7y ago
  Original link is not changelog, but slides from the meetup presentation. Typical Go changelog is here: https://golang.org/doc/go1.13 https://golang.org/doc/go1.13
mvdan 7y ago
These are the slides from a talk; I didn't spend the extra time to change the format or write down what I explained. After all, I didn't post them here, someone else did :) I personally think it's best to just follow the links if the title sounds interesting to you.
- pjmlp 7y ago
  Fair enough. I did follow the links, however it is a bit tedious to then make a picture from the endless mountain of comments on each issue, hence the remark.

fourseventy 7y ago

I'm a bit confused by the new -static flag. I thought that by default go was statically linked, what am i missing?

georgyo 7y ago
Go can link against c libraries. This would make that static as well.
mvdan 7y ago
Simple Go binaries do tend to be statically linked, which is where I think the confusion comes from. The most common source of dynamic linking is cgo, since CGO_ENABLED=1 is the default when not cross-compiling. For example, importing os/user will dynamically link against libc, unless you disable cgo or force statically linking with libc. See https://github.com/golang/go/issues/26492 https://github.com/golang/go/issues/26492 for more details. I think the purpose of the flag will be to force static linking in all edge cases, while not disabling cgo explicitly.
jpgvm 7y ago
It's not quite that simple unfortunately. If you build a Go package with CGO enabled then Go builds the binary dynamically linked to the system libc. (this can be especially surprising if you believe go is "statically linked") However when CGO is disabled it doesn't link against libc at all as Go has it's own syscall layer etc. It's not clear what this new -static flag will do, likely automatically setup some of the linker static flags when compiling with CGO to statically link other dependencies and perhaps libc itself.
- sdegutis 7y ago
  > It's not quite that simple unfortunately. This has been my experience with Go. First a promise of everything being much simpler than the alternatives. Then, when we run into all sorts of confusion and caveats, an unapologetic disclaimer about why it's not simple and can't be, with a long exposition about Go's own internal limitations and the trade-offs they had to make.

dis-sys 7y ago

the most exciting one for me is definitely the new escape analysis.

ithkuil 7y ago
Does it offer any user visible improvements or is it only a compiler internal improvement?
- mvdan 7y ago
  It might lead to fewer allocations in complex programs, as the compiler is able to put more in the stack under some edge cases.
Insanity 7y ago
Yeah, useful for teams that want to use pointers everywhere and disregard escape analysis xD
aaronbee 7y ago
Even more exciting, this is already present in go1.13. I believe the author of these slides made a mistake. Here it is mentioned in go1.13 release notes: https://golang.org/doc/go1.13#compiler https://golang.org/doc/go1.13#compiler And GitHub says the commit is present in go1.13: https://github.com/golang/go/commit/996a687ebbf81b26f81b41b8e62ef21d8b0826af https://github.com/golang/go/commit/996a687ebbf81b26f81b41b8...
- agnivade 7y ago
  Yeah it is slightly misleading. The escape analysis rewrite was done in 1.13. But work is now going on to remove the old escape analysis code.

xelekitry 7y ago

So there are no changes to address the privacy issues[1] introduced in Go 1.13. The issue raised[2] about this seems to be stalled as well. [1]https://proxy.golang.org/privacy https://proxy.golang.org/privacy [2]https://github.com/golang/go/issues/33985 https://github.com/golang/go/issues/33985

UncleEntity 7y ago
Are those two links even related? One talks about the privacy policy and the other is about private repos.
- Zancarius 7y ago
  Yes, and I think the OP would've been better served by linking to the proxy page rather than its privacy policy. I can understand why, however. Privacy, proxies, and private repos are all inter-related but it might not be obvious to people who don't use Go regularly or haven't followed the introduction of proxies. The problem is that if you don't set up your environment, set it up partially, or set it up incorrectly, some information about private repositories will be sent to Google[1]. One solution is to use the envvar GONOSUMDB (either set from your shell's rc file or, preferably, from `go env`), thus instructing Go which domains it should not validate against the checksum database. Some individuals may not see this as an issue since private repos will fail to download via the default GOPROXY (`go get` should revert to "direct" mode) and nothing gets stored in the sumdb. However, Google does apparently log this information internally, and that's where the privacy issue arises. For additional protection, you can set GOPROXY to your own self-hosted server, such as Athens, and configure it similarly so it'll reject such sumdb requests with a 403 to catch clients using only GOPROXY. But, you still have to remember to set GOPROXY (at a minimum), which means that if you or anyone in your organization forgets this bit, you're back where you started and you're probably sending information about your private repos to Google. Again. Since this relies on envvars or the Go env stored in ~/.config/go/env (as an example) to set the behavior globally, you have to assume developers will correctly configuring every system they use. The GitHub issue is mostly centered on having a way to do this per-repository, and I honestly think that would have been a better solution, even combined with the `go env` settings. Personally, it doesn't bother me too much, because an external immutable append-only log of commits in upstream packages will catch nefarious changes, so I think the benefits probably outweigh the privacy concerns until I see an adequate argument countering this. Regardless, I still have my `go env` set up to ignore my private repositories. [1] The documentation says Google only logs the paths and doesn't publish them for private repositories their proxy fails to download. I thought I read somewhere that you can still use the sumdb for private repos, but it would instead send something like a SHA256 sum of the path for additional privacy. It might've been a proposal, and I can't find it now.

wolfgang42 7y ago

What happened to the try/check error-handling proposal? In June it was selected for inclusion in Go 1.14 [1], but then in the linked issue it seems to have been declined in July. Where did it go? Why the sudden change of heart? [1]: https://blog.golang.org/go2-next-steps#TOC_2 https://blog.golang.org/go2-next-steps#TOC_2.

divan 7y ago
It was tried, discussed and abandoned: https://youtu.be/kNHo788oO5Y?t=1026 https://youtu.be/kNHo788oO5Y?t=1026
toxik 7y ago
Go continues to impress me with its levelheaded design decisions, sadly I don’t really have a use for it in my work.
- tyri_kai_psomi 7y ago
  Since go makes it so easy to build a binary for most any platform, I think one area anyone could introduce is it into their toolkits is by building small, simple, purpose-built programs you can easily run on the command line to perform a repetitive task.
zadokshi 7y ago
I don’t think the majority actually want this to be part of go
- codr7 7y ago
  Vocal minority, perhaps. They got carried away with their own cleverness and forgot about the real world, shit happens. The good news is they realized and and realigned with the community, which is awesome.
Thorrez 7y ago
Here was the previous discussion when that was abandoned on July 16: https://news.ycombinator.com/item?id=20454966 https://news.ycombinator.com/item?id=20454966

geoah 7y ago

Go 1.13 has been by far the worse release in my memory. The go ecosystem and community was not ready nor prepared for modules. Enabling by default the sum database broke a number of codebases that had altered the history of their codebases (either themselves or their dependencies). This should have been an opt in feature for this version. Changing the way the pseudoversion behaves by expecting a correct date and specific sha length broke a larger number of codebases. This should have been a warning on this version and not cause the modules to fail. There was one more change that I have wiped from my memory that broke athens. It has to do with how go now looks for a go.mod file in parent urls that caused athens to return a 500. Overall spent about a week of swearing and trying to fix tools and deps. At the end gave up and moved back to 1.12.

kardianos 7y ago
This is in stark contrast to my experience, which was great. Were you able to file any issues or explain to people what happened?
- geoah 7y ago
  Hey kardianos, first of all thank you for all your hard work with getting the golang community a worthy dep manager. --- As for reporting the issues, it's something I assumed is common knowledge from the fact that any dep I had an issue with on the first day of 1.13 already had a bug filled. Searching for `"invalid pseudo-version"` in github results in around 80 issues in different repositories that all have to do with go 1.13 and modules. [1] Similarly a search for `golang "checksum mismatch"` will result in over 130 issues in regards to the sum db complaining about broken builds. [2] There will be more that are not been correctly reported in github issues, and there will be false reports as well. But the repos that show up will have caused cascade issues. We couldn't use golangci-lint for a couple of days before it was fixed. There is a limit to the amount of mod replaces I can live with before deciding it's not worth it. Don't get me wrong. I do like mod, but I just think that for a language that prides itself on "backwards compatibility" it's doing a pretty poor job at keeping the same promise when mod is involved. --- [1] https://github.com/search?q=%22invalid+pseudo-version%22+is%3Aissue&type=Issues https://github.com/search?q=%22invalid+pseudo-version%22+is%... [2] https://github.com/search?q=golang+%22checksum+mismatch%22+is%3Aissue&type=Issues https://github.com/search?q=golang+%22checksum+mismatch%22+i...

pkaye 7y ago

Do vscode/gopls work fine with modules now? I was getting sluggish behaviour in the past.

geoah 7y ago
They do work pretty nicely for the most part. The only issue I'm still seeing is when having multiple go.mod files in the same workspace. I end up having to split projects with sub-modules in multiple workspaces in vscode and ignore the sub-modules on the main workspace. https://github.com/golang/go/issues/32394 https://github.com/golang/go/issues/32394
hu3 7y ago
Recent discussion: https://old.reddit.com/r/golang/comments/ddf721/vscode_is_a_nightmare_to_work_with_if_using/ https://old.reddit.com/r/golang/comments/ddf721/vscode_is_a_...

karmakaze 7y ago

Language changes 0. allow embedding overlapping interfaces 1. len, cap to return untyped ints if constant [0] https://golang.org/issue/6977 https://golang.org/issue/6977 [1] https://github.com/golang/go/issues/31795 https://github.com/golang/go/issues/31795 Major changes 2. Remove SSLv3 3. Make TLS 1.3 opt-out 4. Automatically check and use vendored packages 5. Low-cost defers via inline code 6. Rewrite escape analysis 7. Expose the runtime's hasher 8. Add -static flag to go build 9. Store package metadata in build cache [2] https://golang.org/issue/32716 https://golang.org/issue/32716 [3] https://golang.org/issue/30055 https://golang.org/issue/30055 [4] https://golang.org/issue/33848 https://golang.org/issue/33848 [5] https://golang.org/issue/34481 https://golang.org/issue/34481 [6] https://golang.org/issue/23109 https://golang.org/issue/23109 [7] https://golang.org/issue/28322 https://golang.org/issue/28322 [8] https://golang.org/issue/26492 https://golang.org/issue/26492 [9] https://golang.org/issue/31417 https://golang.org/issue/31417 Minor changes [a] use go.sum hashes from all downloaded modules [b] fail tests that run os.Exit(0) [c] add testing.T.Deadline [d] add regexp.SubexpIndex [e] report failing test after a panic [f] Rewrite the compiler's rulegen [g] Change js mimetype to text/javascript [a] https://golang.org/issue/28802 https://golang.org/issue/28802 [b] https://golang.org/issue/29062 https://golang.org/issue/29062 [c] https://golang.org/issue/28135 https://golang.org/issue/28135 [d] https://golang.org/issue/32420 https://golang.org/issue/32420 [e] https://golang.org/issue/32121 https://golang.org/issue/32121 [f] https://golang.org/issue/30810 https://golang.org/issue/30810 [g] https://golang.org/issue/32351 https://golang.org/issue/32351

mleonhard 7y ago

Did they add min(int32,int32) and max(int32,int32) yet?