31 ms·

Go 1.20 released

318 points by petercooper 4y ago

deleted 4y ago
[deleted]
petercooper 4y ago
Release notes here: https://go.dev/doc/go1.20 https://go.dev/doc/go1.20
- dang 4y ago
  We can use that instead of https://groups.google.com/g/golang-announce/c/QMK8IQALDvA/m/JbovhzpOAAAJ https://groups.google.com/g/golang-announce/c/QMK8IQALDvA/m/.... Thanks!
donio 4y ago
Not in 1.20 yet but x/exp/maps was just accepted for inclusion in the standard library so presumably it will come in a future version. The library contains generics based helper functions for working with maps. https://github.com/golang/go/issues/57436#issuecomment-1412566002 https://github.com/golang/go/issues/57436#issuecomment-14125... https://pkg.go.dev/golang.org/x/exp/maps https://pkg.go.dev/golang.org/x/exp/maps https://cs.opensource.google/go/x/exp/+/master:maps/maps.go https://cs.opensource.google/go/x/exp/+/master:maps/maps.go
- eatonphil 4y ago
  Very useful. I am always writing a little Clone() function for maps.
- latchkey 4y ago
  Glad to see this make it into the core. I've been using this library for ages now... https://github.com/cornelk/hashmap https://github.com/cornelk/hashmap Always entertains me to see developers write all the lock/unlock code when they could just use that.
  - kyrra 4y ago
    We likely need full coverage of the "tricks" documented on https://github.com/golang/go/wiki/SliceTricks https://github.com/golang/go/wiki/SliceTricks into a generics package as well. Yes, https://pkg.go.dev/golang.org/x/exp/slices https://pkg.go.dev/golang.org/x/exp/slices gives some of that, but likely the rest should be added as well.
- impulser_ 4y ago
  Hopefully they accept the slice version as well. Both of them contain very helpful functions that would be nice to have in the std library instead of rewriting them every where.
  - tptacek 4y ago
    You don't rewrite them; you just import exp/slices. The only thing bringing them into std really changes in practice is the import path.
tiffanyh 4y ago
Off topic: I didn't realize Google Groups was still around. Does anyone still actively use Usenet?
- klodolph 4y ago
  Google Groups, if I understand correctly, is used internally at Google extensively. Last time I checked Usenet, it seemed like many of the users were pirates. The pirate releases would then get reuploaded to bittorrent sites.
- navanchauhan 4y ago
  We still use Google Groups at our Journal in my university. Although, we mainly use it as a mailing list
- dewey 4y ago
  I might be wrong there and there's different groups but these mailing list groups are a very common way of setting permissions if you are using Google Workspace so it's not some abandoned usenet leftover.
latchkey 4y ago
Someone blogged about it in a bit more detail: https://tomaszs2.medium.com/%EF%B8%8F-go-1-20-released-its-like-ayrton-senna-again-9687049d2b62 https://tomaszs2.medium.com/%EF%B8%8F-go-1-20-released-its-l...
- kardianos 4y ago
  That's less detail, not more.
  - ramchip 4y ago
    The comment might predate the submission URL change https://news.ycombinator.com/item?id=34617088 https://news.ycombinator.com/item?id=34617088
  - deleted 4y ago
    [deleted]
  - thewataccount 4y ago
    They changed the url from a rather sparse google group post - that might be why it's now relatively less content
silisili 4y ago
Really glad to see the ability to convert seamlessly from slices to arrays. Not that I use it often, but it seemed like such a 'natural thing' to convert between.
ellisd 4y ago
Been looking forward to the macOS DNS resolver changes for a LONG TIME... https://danp.net/posts/macos-dns-change-in-go-1-20/ https://danp.net/posts/macos-dns-change-in-go-1-20/
- SloopJon 4y ago
  Oh, wow, thanks for pointing that out. I have to build HashiCorp Vault from source with CGO enabled because of the broken DNS resolver. Otherwise, it's completely unusable with a split-tunnel VPN.
jacksgt 4y ago
> Go 1.20 supports collecting code coverage profiles for programs (applications and integration tests), as opposed to just unit tests. > To collect coverage data for a program, build it with go build's -cover flag, This is absolutely awesome! I'm looking forward to trying this on some server binaries!
- alexott 4y ago
  Im struggling with previous behavior all the time. It would be much better with this
- froh 4y ago
  yay now we can combine and balance mc/dc coverage testing with fuzzing. I find SQLite verification inspiring in that regard: https://www.sqlite.org/testing.html#tension_between_fuzz_testing_and_100_mc_dc_testing https://www.sqlite.org/testing.html#tension_between_fuzz_tes...
- thiht 4y ago
  Note that it was already possible before with a command like: go test -coverpkg=./... -c . -o main.test This command builds a test binary with a coverage config. So if you run it, launch your tests, and stop it gracefully, it will spit out a coverage report. I’m not exactly sure what the change in Go 1.20 is about, maybe it’s easier somehow, I’ll have to try it.
  - majewsky 4y ago
    That's not the same. `go test -c` builds a binary that runs your tests, whereas (if I understand correctly) the new thing builds a binary that runs your main(). If it works as I understand, that would be fantastic because then I could get rid of this monstrosity: https://github.com/holocm/holo/blob/master/main_test.go https://github.com/holocm/holo/blob/master/main_test.go
pianoben 4y ago
This change makes me SO HAPPY: The math/rand package now automatically seeds the global random number generator (used by top-level functions like Float64 and Int) with a random value, and the top-level Seed function has been deprecated. Programs that need a reproducible sequence of random numbers should prefer to allocate their own random source, using rand.New(rand.NewSource(seed)). We've had some truly nasty bugs from people who weren't familiar with the prior behavior of having a default seed of zero for the global random-number generator. This is going to save many people so much heartache.
- gouggoug 4y ago
  Would you be able to expand on why using a seed of 0 is an issue?
  - deleted 4y ago
    [deleted]
  - pianoben 4y ago
    If you randomly generate numbers using `math/rand`, then every invocation of your program is going to see the same sequence of "random" numbers. If you happen to persist those random numbers and expect a uniform distribution, you're going to be sadly surprised in the future. It's the kind of "bug" that doesn't manifest until your data is thoroughly boned.
    - gouggoug 4y ago
      So, if I use `math/rand` the RNG will always output the same sequence of random numbers? How do I make sure I'm passing a random seed to my RNG? (I must be missing something here)
      - chimeracoder 4y ago
        > So, if I use `math/rand` the RNG will always output the same sequence of random numbers? math/rand provides global functions using a global RNG, as well as the ability to instantiate your own RNG and call functions (methods) on that RNG. Previously, the global functions all used a seed of 1, which made them generate identical sequences. Now, they use random seed, which makes them less-easily predictable (though still predictable). There is no change to the self-instantiated RNGs. > How do I make sure I'm passing a random seed to my RNG? With the change, using the global functions in Go 1.20+ is the same as instantiating your own RNG with a random seed.
pbohun 4y ago
> Go 1.20 is the last release that will run on any release of Windows 7, 8, Server 2008 and Server 2012. Go 1.21 will require at least Windows 10 or Server 2016. This is interesting. I wonder what Go 1.21 will depend on that requires at least Windows 10?
- mseepgood 4y ago
  https://github.com/golang/go/issues/57004 https://github.com/golang/go/issues/57004 Nothing concrete as it seems. It means that new releases are no longer tested with the old versions of Windows on their builders, and if you open a bug report about a problem with an unsupported version of Windows, nobody will care.
- zamadatix 4y ago
  I wouldn't be surprised if it's more a "we're not going to bother to keep hooking up new things or doing fixes in a way that works and is tested on old operating systems" than "there isn't a way to..." type thing. Some security stuff may break the mold on that though.
- gabereiser 4y ago
  I would assume it's problems with Microsoft not maintaining those older windows sdk's in favor of their current monolithic windows sdk which only seems to target 10 and 11.
  - 4ad 4y ago
    The Go toolchain doesn't use any Microsoft SDK.
- arp242 4y ago
  Nothing specifically AFAIK; it's just fewer platforms to test and support, making development overall easier. Microsoft ended extended support for Windows 7 in 2020, and special enterprise security updates this month. Windows 8 will end extended support July this year (before Go 1.21 is released); I can't find anything about any volume security updates; I think few people care, as Windows 8 is used less than Windows 7 today. https://github.com/golang/go/issues/57003 https://github.com/golang/go/issues/57003 https://github.com/golang/go/issues/57004 https://github.com/golang/go/issues/57004
einpoklum 4y ago
It's Go time! https://www.youtube.com/watch?v=C1hdAakECUM https://www.youtube.com/watch?v=C1hdAakECUM
pxue 4y ago
I for one, welcome the error wrapping change.
valyala 4y ago
It is great that Go1.20 improves compile times after generics were added in Go1.18 [1]! Overall, I think adding generics to Go was a big mistake. It brings the following drawbacks: - Slower compile times, even if generics aren't used. This slows down development pace in Go. - The reduced code readability if generics are used. This slows down development pace in Go. - The increased complexity of Go compiler. This slows down Go compiler development and increases chances for bugs. - Very low adoption of generics in practice, since they aren't useful in most Go code bases. The generics are actively used in some freaky packages only after the year since they were released in Go1.18. The only useful thing from Go generics is a syntactic sugar, which allows replacing `interface{}` with `any`. [1] https://go.dev/doc/go1.20#compiler https://go.dev/doc/go1.20#compiler
- zeeboo 4y ago
  You forgot to list the most useful feature of adding generics: people on the internet can no longer say "lol no generics", drastically reducing the amount of garbage comments about Go.
  - valyala 4y ago
    Except that these people now pollute the Internet with freaky packages, which use generics in esoteric ways :)
    - 0x62c1b43e 4y ago
      But if adoption is “very low”, then it’s not much pollution, is it?
  - thunky 4y ago
    Those comments have now been replaced with "adding generics to Go was a big mistake".
    - philosopher1234 4y ago
      Maybe they will, but they haven't, since this is the first time I've seen that comment. The "lol no generics" was endemic.
politician 4y ago
math/rand: The original behavior never bothered me and actually motivated deterministic tests. File this under "won't be bothered to read the docs", I guess.
- thiht 4y ago
  > File this under "won't be bothered to read the docs" Do you read the docs of every basic feature you use? When you call a rand function, you usually expect it to be seeded. In any language, I'll only read the docs of a rand function to know how it handles bounds. You still can seed it manually in your tests if you want a deterministic behavior. It's like if you used `time.Now()` only to discover that you first have to call `time.StartClock()` for it to work as expected, it can make sense but is not the commonly expected behavior.
  - politician 4y ago
    Yes, I do. All languages have weird corner cases in the standard libraries, and third-party dependencies have even worse edge cases. "Plug and play" rarely works for me, and it's better to know how something you plan to rely on in a production environment works, then to just assume it will work.
  - indil 4y ago
    >Do you read the docs of every basic feature you use? Yes? You don't?
    - thiht 4y ago
      No.
kurtoid 4y ago
Package size dropped by 200MB on Arch. What happened?
- philosopher1234 4y ago
  They stopped including precompiled shared libs for the stl
- mseepgood 4y ago
  https://go.dev/doc/go1.20#go-command https://go.dev/doc/go1.20#go-command "The directory $GOROOT/pkg no longer stores pre-compiled package archives for the standard library: go install no longer writes them, the go build no longer checks for them, and the Go distribution no longer ships them. Instead, packages in the standard library are built as needed and cached in the build cache, just like packages outside GOROOT. This change reduces the size of the Go distribution and also avoids C toolchain skew for packages that use cgo."
subarctic 4y ago
>Comparable types (such as ordinary interfaces) may now satisfy comparable constraints, even if the type arguments are not strictly comparable (comparison may panic at runtime). This makes it possible to instantiate a type parameter constrained by comparable (e.g., a type parameter for a user-defined generic map key) with a non-strictly comparable type argument such as an interface type, or a composite type containing an interface type. Wait, isn't that the whole point of the constraint in the first place, to keep you from using it with things that aren't comparable? Wouldn't it make more sense to have the constraint be a requirement in the interface itself, so that you can't create an interface value from a type that isn't comparable?
- subarctic 4y ago
  I mean, from my limited experience of Go, it's not exactly a language that tries to help you avoid unexpected runtime errors or anything, so maybe they figure Go programmers are already used to gotchas like that.
  - 2h 4y ago
    Why did you reply to yourself?
    - AnimalMuppet 4y ago
      Probably didn't know about the "edit" button. I used to reply to myself before I learned about it. (And I still do, when the two-hour edit window has expired.)
      - subarctic 4y ago
        Well actually, i think i did consider editing it, but it felt like my first comment stood fine on its own, and i'd leave the follow-up comment to be downvoted separately
      - PoignardAzur 4y ago
        Yeah, that edit window is way too short.
yawaramin 4y ago
> The specification now defines that struct values are compared one field at a time, considering fields in the order they appear in the struct type definition, and stopping at the first mismatch. This is interesting because in certain cases it can be a performance hit when comparing structs which have been declared in alignment order to save memory. Simple example: type t struct { a int64 b int32 } t1 := t{a: 1, b: 2} t2 := t{a: 1, b: 3} same := t1 == t2 When comparing `t1` and `t2`, the runtime will first compare the `a` fields, which are the same, then the `b` fields, which will differ. Only after doing both comparisons will it figure out that they're different. But the `a` fields are int64, so it has to traverse these large data types before finally getting the answer. Of course this is a trivial example, in real-world cases structs can have many more fields with much larger contents. The point is that the optimal ordering for alignment, and the optimal ordering for comparison, seem to be different.
- martisch 4y ago
  That is just the language definition. It is fine for an implementation to actually compare both at the same time as long as within the language you can not observe this happend. If we cant tell the read to be b happenend with a or before a (hello spectre) then for the implementation it should be fine to have done the comparison. This is more of a constraint if the struct contains a comparison that can panic. The panic must happen in order or not at all depending how the fields are listed. type t struct { a int64 b any } Should not panic on b if a values are already different.
- skybrian 4y ago
  In the few cases where it comes up, maybe you could write out the code to compare the fields in the order you choose?
niij 4y ago
> New diagnostic for incorrect time formats > The vet tool now reports use of the time format 2006-02-01 (yyyy-dd-mm) with Time.Format and time.Parse. This format does not appear in common date standards, but is frequently used by mistake when attempting to use the ISO 8601 date format (yyyy-mm-dd). It's frequently used by mistake because Go doesn't allow datetime layouts to use the standard YYYY,MM,DD,HH,MM,etc which they ironically used for clarity in their release notes. I don't understand why Go still forces datetime formats to be specified using "magic numbers" from some time in 2006.
- gepoch 4y ago
  From the docs, the magic reference date: 01/02 03:04:05PM '06 -0700 So that's why it's in 2006, since you asked. https://pkg.go.dev/time#pkg-constants https://pkg.go.dev/time#pkg-constants
  - coolgoose 4y ago
    It's still Imho one of the worst decisions Go did, it definitely not easier to read or reason about.
    - gepoch 4y ago
      Yeah... Just have to remember that the year comes before the time zone but after the seconds :clown: No idea where that came from. Probably the time format from the punchcard machine at bell labs. If it was iso 8601 based, it would almost make sense.

Go 1.20 released

318 points by petercooper 4y ago

deleted 4y ago

[deleted]

petercooper 4y ago

Release notes here: https://go.dev/doc/go1.20 https://go.dev/doc/go1.20

dang 4y ago
We can use that instead of https://groups.google.com/g/golang-announce/c/QMK8IQALDvA/m/JbovhzpOAAAJ https://groups.google.com/g/golang-announce/c/QMK8IQALDvA/m/.... Thanks!

donio 4y ago

Not in 1.20 yet but x/exp/maps was just accepted for inclusion in the standard library so presumably it will come in a future version. The library contains generics based helper functions for working with maps. https://github.com/golang/go/issues/57436#issuecomment-1412566002 https://github.com/golang/go/issues/57436#issuecomment-14125... https://pkg.go.dev/golang.org/x/exp/maps https://pkg.go.dev/golang.org/x/exp/maps https://cs.opensource.google/go/x/exp/+/master:maps/maps.go https://cs.opensource.google/go/x/exp/+/master:maps/maps.go

eatonphil 4y ago
Very useful. I am always writing a little Clone() function for maps.
latchkey 4y ago
Glad to see this make it into the core. I've been using this library for ages now... https://github.com/cornelk/hashmap https://github.com/cornelk/hashmap Always entertains me to see developers write all the lock/unlock code when they could just use that.
- kyrra 4y ago
  We likely need full coverage of the "tricks" documented on https://github.com/golang/go/wiki/SliceTricks https://github.com/golang/go/wiki/SliceTricks into a generics package as well. Yes, https://pkg.go.dev/golang.org/x/exp/slices https://pkg.go.dev/golang.org/x/exp/slices gives some of that, but likely the rest should be added as well.
impulser_ 4y ago
Hopefully they accept the slice version as well. Both of them contain very helpful functions that would be nice to have in the std library instead of rewriting them every where.
- tptacek 4y ago
  You don't rewrite them; you just import exp/slices. The only thing bringing them into std really changes in practice is the import path.

tiffanyh 4y ago

Off topic: I didn't realize Google Groups was still around. Does anyone still actively use Usenet?

klodolph 4y ago
Google Groups, if I understand correctly, is used internally at Google extensively. Last time I checked Usenet, it seemed like many of the users were pirates. The pirate releases would then get reuploaded to bittorrent sites.
navanchauhan 4y ago
We still use Google Groups at our Journal in my university. Although, we mainly use it as a mailing list
dewey 4y ago
I might be wrong there and there's different groups but these mailing list groups are a very common way of setting permissions if you are using Google Workspace so it's not some abandoned usenet leftover.

latchkey 4y ago

Someone blogged about it in a bit more detail: https://tomaszs2.medium.com/%EF%B8%8F-go-1-20-released-its-like-ayrton-senna-again-9687049d2b62 https://tomaszs2.medium.com/%EF%B8%8F-go-1-20-released-its-l...

kardianos 4y ago
That's less detail, not more.
- ramchip 4y ago
  The comment might predate the submission URL change https://news.ycombinator.com/item?id=34617088 https://news.ycombinator.com/item?id=34617088
- deleted 4y ago
  [deleted]
- thewataccount 4y ago
  They changed the url from a rather sparse google group post - that might be why it's now relatively less content

silisili 4y ago

Really glad to see the ability to convert seamlessly from slices to arrays. Not that I use it often, but it seemed like such a 'natural thing' to convert between.

ellisd 4y ago

Been looking forward to the macOS DNS resolver changes for a LONG TIME... https://danp.net/posts/macos-dns-change-in-go-1-20/ https://danp.net/posts/macos-dns-change-in-go-1-20/

SloopJon 4y ago
Oh, wow, thanks for pointing that out. I have to build HashiCorp Vault from source with CGO enabled because of the broken DNS resolver. Otherwise, it's completely unusable with a split-tunnel VPN.

jacksgt 4y ago

> Go 1.20 supports collecting code coverage profiles for programs (applications and integration tests), as opposed to just unit tests. > To collect coverage data for a program, build it with go build's -cover flag, This is absolutely awesome! I'm looking forward to trying this on some server binaries!

alexott 4y ago
Im struggling with previous behavior all the time. It would be much better with this
froh 4y ago
yay now we can combine and balance mc/dc coverage testing with fuzzing. I find SQLite verification inspiring in that regard: https://www.sqlite.org/testing.html#tension_between_fuzz_testing_and_100_mc_dc_testing https://www.sqlite.org/testing.html#tension_between_fuzz_tes...
thiht 4y ago
Note that it was already possible before with a command like: go test -coverpkg=./... -c . -o main.test This command builds a test binary with a coverage config. So if you run it, launch your tests, and stop it gracefully, it will spit out a coverage report. I’m not exactly sure what the change in Go 1.20 is about, maybe it’s easier somehow, I’ll have to try it.
- majewsky 4y ago
  That's not the same. `go test -c` builds a binary that runs your tests, whereas (if I understand correctly) the new thing builds a binary that runs your main(). If it works as I understand, that would be fantastic because then I could get rid of this monstrosity: https://github.com/holocm/holo/blob/master/main_test.go https://github.com/holocm/holo/blob/master/main_test.go

pianoben 4y ago

This change makes me SO HAPPY: The math/rand package now automatically seeds the global random number generator (used by top-level functions like Float64 and Int) with a random value, and the top-level Seed function has been deprecated. Programs that need a reproducible sequence of random numbers should prefer to allocate their own random source, using rand.New(rand.NewSource(seed)). We've had some truly nasty bugs from people who weren't familiar with the prior behavior of having a default seed of zero for the global random-number generator. This is going to save many people so much heartache.

gouggoug 4y ago
Would you be able to expand on why using a seed of 0 is an issue?
- deleted 4y ago
  [deleted]
- pianoben 4y ago
  If you randomly generate numbers using `math/rand`, then every invocation of your program is going to see the same sequence of "random" numbers. If you happen to persist those random numbers and expect a uniform distribution, you're going to be sadly surprised in the future. It's the kind of "bug" that doesn't manifest until your data is thoroughly boned.
  - gouggoug 4y ago
    So, if I use `math/rand` the RNG will always output the same sequence of random numbers? How do I make sure I'm passing a random seed to my RNG? (I must be missing something here)
    - chimeracoder 4y ago
      > So, if I use `math/rand` the RNG will always output the same sequence of random numbers? math/rand provides global functions using a global RNG, as well as the ability to instantiate your own RNG and call functions (methods) on that RNG. Previously, the global functions all used a seed of 1, which made them generate identical sequences. Now, they use random seed, which makes them less-easily predictable (though still predictable). There is no change to the self-instantiated RNGs. > How do I make sure I'm passing a random seed to my RNG? With the change, using the global functions in Go 1.20+ is the same as instantiating your own RNG with a random seed.

pbohun 4y ago

> Go 1.20 is the last release that will run on any release of Windows 7, 8, Server 2008 and Server 2012. Go 1.21 will require at least Windows 10 or Server 2016. This is interesting. I wonder what Go 1.21 will depend on that requires at least Windows 10?

mseepgood 4y ago
https://github.com/golang/go/issues/57004 https://github.com/golang/go/issues/57004 Nothing concrete as it seems. It means that new releases are no longer tested with the old versions of Windows on their builders, and if you open a bug report about a problem with an unsupported version of Windows, nobody will care.
zamadatix 4y ago
I wouldn't be surprised if it's more a "we're not going to bother to keep hooking up new things or doing fixes in a way that works and is tested on old operating systems" than "there isn't a way to..." type thing. Some security stuff may break the mold on that though.
gabereiser 4y ago
I would assume it's problems with Microsoft not maintaining those older windows sdk's in favor of their current monolithic windows sdk which only seems to target 10 and 11.
- 4ad 4y ago
  The Go toolchain doesn't use any Microsoft SDK.
arp242 4y ago
Nothing specifically AFAIK; it's just fewer platforms to test and support, making development overall easier. Microsoft ended extended support for Windows 7 in 2020, and special enterprise security updates this month. Windows 8 will end extended support July this year (before Go 1.21 is released); I can't find anything about any volume security updates; I think few people care, as Windows 8 is used less than Windows 7 today. https://github.com/golang/go/issues/57003 https://github.com/golang/go/issues/57003 https://github.com/golang/go/issues/57004 https://github.com/golang/go/issues/57004

einpoklum 4y ago

It's Go time! https://www.youtube.com/watch?v=C1hdAakECUM https://www.youtube.com/watch?v=C1hdAakECUM

pxue 4y ago

I for one, welcome the error wrapping change.

valyala 4y ago

It is great that Go1.20 improves compile times after generics were added in Go1.18 [1]! Overall, I think adding generics to Go was a big mistake. It brings the following drawbacks: - Slower compile times, even if generics aren't used. This slows down development pace in Go. - The reduced code readability if generics are used. This slows down development pace in Go. - The increased complexity of Go compiler. This slows down Go compiler development and increases chances for bugs. - Very low adoption of generics in practice, since they aren't useful in most Go code bases. The generics are actively used in some freaky packages only after the year since they were released in Go1.18. The only useful thing from Go generics is a syntactic sugar, which allows replacing `interface{}` with `any`. [1] https://go.dev/doc/go1.20#compiler https://go.dev/doc/go1.20#compiler

zeeboo 4y ago
You forgot to list the most useful feature of adding generics: people on the internet can no longer say "lol no generics", drastically reducing the amount of garbage comments about Go.
- valyala 4y ago
  Except that these people now pollute the Internet with freaky packages, which use generics in esoteric ways :)
  - 0x62c1b43e 4y ago
    But if adoption is “very low”, then it’s not much pollution, is it?
- thunky 4y ago
  Those comments have now been replaced with "adding generics to Go was a big mistake".
  - philosopher1234 4y ago
    Maybe they will, but they haven't, since this is the first time I've seen that comment. The "lol no generics" was endemic.

politician 4y ago

math/rand: The original behavior never bothered me and actually motivated deterministic tests. File this under "won't be bothered to read the docs", I guess.

thiht 4y ago
> File this under "won't be bothered to read the docs" Do you read the docs of every basic feature you use? When you call a rand function, you usually expect it to be seeded. In any language, I'll only read the docs of a rand function to know how it handles bounds. You still can seed it manually in your tests if you want a deterministic behavior. It's like if you used `time.Now()` only to discover that you first have to call `time.StartClock()` for it to work as expected, it can make sense but is not the commonly expected behavior.
- politician 4y ago
  Yes, I do. All languages have weird corner cases in the standard libraries, and third-party dependencies have even worse edge cases. "Plug and play" rarely works for me, and it's better to know how something you plan to rely on in a production environment works, then to just assume it will work.
- indil 4y ago
  >Do you read the docs of every basic feature you use? Yes? You don't?
  - thiht 4y ago
    No.

kurtoid 4y ago

Package size dropped by 200MB on Arch. What happened?

philosopher1234 4y ago
They stopped including precompiled shared libs for the stl
mseepgood 4y ago
https://go.dev/doc/go1.20#go-command https://go.dev/doc/go1.20#go-command "The directory $GOROOT/pkg no longer stores pre-compiled package archives for the standard library: go install no longer writes them, the go build no longer checks for them, and the Go distribution no longer ships them. Instead, packages in the standard library are built as needed and cached in the build cache, just like packages outside GOROOT. This change reduces the size of the Go distribution and also avoids C toolchain skew for packages that use cgo."

subarctic 4y ago

>Comparable types (such as ordinary interfaces) may now satisfy comparable constraints, even if the type arguments are not strictly comparable (comparison may panic at runtime). This makes it possible to instantiate a type parameter constrained by comparable (e.g., a type parameter for a user-defined generic map key) with a non-strictly comparable type argument such as an interface type, or a composite type containing an interface type. Wait, isn't that the whole point of the constraint in the first place, to keep you from using it with things that aren't comparable? Wouldn't it make more sense to have the constraint be a requirement in the interface itself, so that you can't create an interface value from a type that isn't comparable?

subarctic 4y ago
I mean, from my limited experience of Go, it's not exactly a language that tries to help you avoid unexpected runtime errors or anything, so maybe they figure Go programmers are already used to gotchas like that.
- 2h 4y ago
  Why did you reply to yourself?
  - AnimalMuppet 4y ago
    Probably didn't know about the "edit" button. I used to reply to myself before I learned about it. (And I still do, when the two-hour edit window has expired.)
    - subarctic 4y ago
      Well actually, i think i did consider editing it, but it felt like my first comment stood fine on its own, and i'd leave the follow-up comment to be downvoted separately
    - PoignardAzur 4y ago
      Yeah, that edit window is way too short.

yawaramin 4y ago

> The specification now defines that struct values are compared one field at a time, considering fields in the order they appear in the struct type definition, and stopping at the first mismatch. This is interesting because in certain cases it can be a performance hit when comparing structs which have been declared in alignment order to save memory. Simple example: type t struct { a int64 b int32 } t1 := t{a: 1, b: 2} t2 := t{a: 1, b: 3} same := t1 == t2 When comparing `t1` and `t2`, the runtime will first compare the `a` fields, which are the same, then the `b` fields, which will differ. Only after doing both comparisons will it figure out that they're different. But the `a` fields are int64, so it has to traverse these large data types before finally getting the answer. Of course this is a trivial example, in real-world cases structs can have many more fields with much larger contents. The point is that the optimal ordering for alignment, and the optimal ordering for comparison, seem to be different.

martisch 4y ago
That is just the language definition. It is fine for an implementation to actually compare both at the same time as long as within the language you can not observe this happend. If we cant tell the read to be b happenend with a or before a (hello spectre) then for the implementation it should be fine to have done the comparison. This is more of a constraint if the struct contains a comparison that can panic. The panic must happen in order or not at all depending how the fields are listed. type t struct { a int64 b any } Should not panic on b if a values are already different.
skybrian 4y ago
In the few cases where it comes up, maybe you could write out the code to compare the fields in the order you choose?

niij 4y ago

> New diagnostic for incorrect time formats > The vet tool now reports use of the time format 2006-02-01 (yyyy-dd-mm) with Time.Format and time.Parse. This format does not appear in common date standards, but is frequently used by mistake when attempting to use the ISO 8601 date format (yyyy-mm-dd). It's frequently used by mistake because Go doesn't allow datetime layouts to use the standard YYYY,MM,DD,HH,MM,etc which they ironically used for clarity in their release notes. I don't understand why Go still forces datetime formats to be specified using "magic numbers" from some time in 2006.

gepoch 4y ago
From the docs, the magic reference date: 01/02 03:04:05PM '06 -0700 So that's why it's in 2006, since you asked. https://pkg.go.dev/time#pkg-constants https://pkg.go.dev/time#pkg-constants
- coolgoose 4y ago
  It's still Imho one of the worst decisions Go did, it definitely not easier to read or reason about.
  - gepoch 4y ago
    Yeah... Just have to remember that the year comes before the time zone but after the seconds :clown: No idea where that came from. Probably the time format from the punchcard machine at bell labs. If it was iso 8601 based, it would almost make sense.