[HN Gopher] Go 1.20 released
___________________________________________________________________
Go 1.20 released
Author : petercooper
Score : 147 points
Date : 2023-02-01 19:38 UTC (3 hours ago)
(HTM) web link (go.dev)
(TXT) w3m dump (go.dev)
| latchkey wrote:
| Someone blogged about it in a bit more detail:
|
| https://tomaszs2.medium.com/%EF%B8%8F-go-1-20-released-its-l...
| kardianos wrote:
| That's less detail, not more.
| thewataccount wrote:
| They changed the url from a rather sparse google group post -
| that might be why it's now relatively less content
| ramchip wrote:
| The comment might predate the submission URL change
|
| https://news.ycombinator.com/item?id=34617088
| petercooper wrote:
| Release notes here: https://go.dev/doc/go1.20
| dang wrote:
| We can use that instead of https://groups.google.com/g/golang-
| announce/c/QMK8IQALDvA/m/.... Thanks!
| silisili wrote:
| 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.
| jacksgt wrote:
| > 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 wrote:
| Im struggling with previous behavior all the time. It would be
| much better with this
| froh wrote:
| 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_tes...
| donio wrote:
| 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-14125...
|
| https://pkg.go.dev/golang.org/x/exp/maps
|
| https://cs.opensource.google/go/x/exp/+/master:maps/maps.go
| eatonphil wrote:
| Very useful. I am always writing a little Clone() function for
| maps.
| latchkey wrote:
| Glad to see this make it into the core.
|
| I've been using this library for ages now...
|
| https://github.com/cornelk/hashmap
|
| Always entertains me to see developers write all the
| lock/unlock code when they could just use that.
| kyrra wrote:
| We likely need full coverage of the "tricks" documented on
| https://github.com/golang/go/wiki/SliceTricks into a generics
| package as well.
|
| Yes, https://pkg.go.dev/golang.org/x/exp/slices gives some of
| that, but likely the rest should be added as well.
| impulser_ wrote:
| 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 wrote:
| 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.
| pbohun wrote:
| > 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?
| gabereiser wrote:
| 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 wrote:
| The Go toolchain doesn't use any Microsoft SDK.
| arp242 wrote:
| 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/57004
| mseepgood wrote:
| 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 wrote:
| 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.
| einpoklum wrote:
| It's Go time!
|
| https://www.youtube.com/watch?v=C1hdAakECUM
| pianoben wrote:
| 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_.
| chimeracoder wrote:
| > 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.
|
| Agreed, but worth nothing that this does not make it
| cryptographically secure. The output can still be predicted.
| For cryptographic security, you need crypto/rand:
| https://pkg.go.dev/crypto/rand
|
| In general, my advice is to use the cryptographically secure
| RNG unless you specifically know you need reproducibility (e.g.
| scientific simulation, or map generation in video games). With
| non-secure RNGs, it's very easy to accidentally expose yourself
| to problems without realizing it.
|
| (Also, FYI, the default seed was 1, not 0).
| tptacek wrote:
| The whole point of math/rand is that it's not
| cryptographically secure.
| chimeracoder wrote:
| > The whole point of math/rand is that it's not
| cryptographically secure.
|
| Sure, and that's even been in the documentation since
| before Go 1.0, yet people still make mistakes with it in
| practice. I've found it worth making the point explicit.
| Particularly in a case like this, where a casual reader
| might not notice the distinction between "non-reproducible"
| and "secure".
| tptacek wrote:
| OK, but a good sign that you're not using a cryptographic
| RNG is that you're somehow "seeding" it.
| chimeracoder wrote:
| > OK, but a good sign that you're not using a
| cryptographic RNG is that you're somehow "seeding" it.
|
| The change here is specific to the global RNG, which
| users often used _without_ explicitly seeding - e.g.
| calling rand.Int() without first calling the now-
| deprecated rand.Seed(int64).
|
| The distinction is obvious to people who have domain
| expertise here, but I've found many people make mistakes
| with it in practice, because it's easy to do.
| gkbrk wrote:
| What? Cryptographic RNGs can be seeded, this is done all
| the time. Being able to seed a random number generator
| has no bearing on its cryptographic security.
|
| As examples of secure cryptographic RNGs that can be
| seeded:
|
| - Fortuna (has a seedable generator without the entropy
| pool parts)
|
| - HMAC-SHA256 DRBG
|
| - ChaCha20 and Salsa20
|
| - AES-CTR
|
| - Keccak
| jchw wrote:
| I think this is more about interfaces than algorithms. A
| good cryptographic RNG interface will generally not
| expose the ability to explicitly set the seed for a given
| algorithm. Instead it would either abstract this entirely
| away, or provide some kind of interface for adding
| entropy to an entropy pool. The PRNGs themselves
| obviously do need to have seeds...
| tptacek wrote:
| The system feeds unpredictable bits into its kernel
| random number generator and then expands it, through
| /dev/urandom and getrandom. You, as a developer,
| shouldn't be messing with any of this. (Obviously:
| Keccak, AES, and ChaCha are not themselves CSPRNGs at
| all, but rather primitives cryptography engineers can use
| to create them).
|
| If you're seeding an RNG, you're almost certainly working
| with a userland RNG, which is, almost always, a mistake.
| jchw wrote:
| I think I have a better way to look at this:
|
| If you, as a developer who doesn't know much about random
| numbers or cryptography, think you need a random value,
| and you don't know if it needs to be cryptographically
| secure or not, you may as well just use a cryptographic
| RNG interface (unless you're using so much that
| performance or entropy becomes an issue.)
|
| I think in most cases, it's pretty benign if you use
| cryptographic randomness even when it's not necessary.
| But, if you use math/rand when you _wanted_ cryptographic
| randomness, to generate IDs or some such, that would be a
| much worse outcome.
|
| Maybe it's bad for someone to use an RNG without
| understanding this well enough, though, and they should
| instead use a higher level abstraction if at all
| possible. But I can get behind the general idea.
| chimeracoder wrote:
| > If you, as a developer who doesn't know much about
| random numbers or cryptography, think you need a random
| value, and you don't know if it needs to be
| cryptographically secure or not, you may as well just use
| a cryptographic RNG interface (unless you're using so
| much that performance or entropy becomes an issue.) I
| think in most cases, it's pretty benign if you use
| cryptographic randomness even when it's not necessary.
| But, if you use math/rand when you wanted cryptographic
| randomness, to generate IDs or some such, that would be a
| much worse outcome.
|
| This is more or less what I was getting at. The main two
| downsides to using crypto/rand are:
|
| - ergonomics (crypto/rand is a less user-friendly
| interface than math/rand)
|
| - concurrent performance
|
| The first one can be easily solved with a wrapper[0]. The
| second is particularly relevant here, because the main
| distinguishing feature of the global RNG in math/rand is
| that it is safe for concurrent use, whereas user-
| instantiated RNGs in math/rand are _not_. The big
| downside to this is that it 's very easy to end up with
| performance issues due to mutex contention when multiple
| packages all use the global RNG (which is common in
| practice).
|
| I actually submitted a CL (patch) to fix the mutex
| contention issue in the global RNG about five years ago,
| but it was rejected on the grounds that callers might
| depend on the specific sequence of numbers with the
| default seed, which would arguably break the
| compatibility promise. That apparently is no longer a
| concern (this change breaks the same thing, and the notes
| in the CL justify it), so I might resubmit it now.
|
| crypto/rand is a little less performant in the single-
| threaded case, but not much - I think it'd be rare for
| that to be the bottleneck in real-life workloads at
| scale. The mutex, on the other hand, _is_ a common
| bottleneck - I 've run into this multiple times in
| multiple different codebases, one of which is what
| motivated the aforementioned CL.
|
| So I generally advise people to use crypto/rand unless
| they are certain they need reproducibility, because the
| potential downside of accidentally using a non-secure RNG
| when you actually need one is quite high[1], but the
| downside of using a threadsafe cryptographically-secure
| one when you needed a threadsafe non-secure one is quite
| low: you're _already_ taking much of the performance hit
| because of the mandated mutex, so the number of use cases
| that actually require the global RNG is quite small.
|
| [0] e.g. https://pkg.go.dev/github.com/andrew-d/csmrand
|
| [1] there are a number of places where RNGs end up being
| used that don't _obviously_ result in exploits but
| nevertheless result in exploits in practice. For the
| average developer, it 's easiest just to avoid that
| quagmire altogether, rather than try to reason about the
| potential adversaries (and potentially get that wrong).
| SpaghettiX wrote:
| How does the seed value get created randomly? I presume it
| doesn't use the same global random number generator, since that
| would still make it deterministic?
| Scaevolus wrote:
| It's seeded using the CPU tick counter (RTDSC on x86-64),
| which is sufficiently random (billions of increments per
| second of uptime!) for this.
| boyter wrote:
| Have not checked but a simple time.Now().UnixNano() as the
| seed would probably do it well enough. Its how you would do
| it previously, except now its done for free.
| gouggoug wrote:
| Would you be able to expand on why using a seed of 0 is an
| issue?
| [deleted]
| pianoben wrote:
| 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 wrote:
| 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)
| Brentward wrote:
| The example in previous versions of the Go math/rand
| package suggested using time.Now().UnixNano() to seed the
| RNG source since that's essentially a random int64.
| chimeracoder wrote:
| > 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.
| wvh wrote:
| The generator returns the same sequence every time. For
| instance Kubernetes CSI drivers have a supposedly unique
| csiProvisionerIdentity but it uses math/rand without seeding
| so they're all using the integer number 8081.
| kiernanmcgowan wrote:
| Having the seed value set to the same value at run time will
| cause the pseudorandom number generator to produce the same
| sequence of values. In essence just creating a new random
| number generator in go w/o setting the seed will not actually
| generate random values.
| chimeracoder wrote:
| > In essence just creating a new random number generator in
| go w/o setting the seed will not actually generate random
| values.
|
| This change only affects the _global_ RNG. Creating a _new_
| RNG has always required setting a seed
| akira2501 wrote:
| Which is also significant because the global RNG is safe
| for concurrent use. Instantiated RNGs are not.
| chimeracoder wrote:
| > Which is also significant because the global RNG is
| safe for concurrent use. Instantiated RNGs are not.
|
| Amusingly, I submitted a patch for this some years ago,
| and it was rejected on the grounds that callers might
| depend on the specific sequence of numbers outputted by
| the global RNG using the default seed, which could break
| the compatibility promise.
|
| Now that that's been deemed a non-issue, I might
| resubmit.
| e12e wrote:
| To be clear, if setting a global seed was _required_ it
| would not be so bad - but silently seeding with 1 is an
| edge that 's pretty easy to trip on.
| tiffanyh wrote:
| Off topic: I didn't realize Google Groups was still around.
|
| Does anyone still actively use Usenet?
| navanchauhan wrote:
| We still use Google Groups at our Journal in my university.
| Although, we mainly use it as a mailing list
| dewey wrote:
| 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.
| klodolph wrote:
| 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.
| ellisd wrote:
| Been looking forward to the macOS DNS resolver changes for a LONG
| TIME... https://danp.net/posts/macos-dns-change-in-go-1-20/
___________________________________________________________________
(page generated 2023-02-01 23:00 UTC)