Go 1.20 released

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.

tptacek4• 3 years 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• 3 years ago

Off topic: I didn't realize Google Groups was still around.

Does anyone still actively use Usenet?

klodolph• 3 years 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• 3 years ago

We still use Google Groups at our Journal in my university. Although, we mainly use it as a mailing list

dewey• 3 years 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.

latchkey2• 3 years ago

Someone blogged about it in a bit more detail:

https://tomaszs2.medium.com/%EF%B8%8F-go-1-20-released-its-l...

kardianos• 3 years ago

That's less detail, not more.

thewataccount• 3 years ago

They changed the url from a rather sparse google group post - that might be why it's now relatively less content

ramchip• 3 years ago

The comment might predate the submission URL change

https://news.ycombinator.com/item?id=34617088

silisili• 3 years 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• 3 years 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/

SloopJon• 3 years 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• 3 years 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• 3 years ago

Im struggling with previous behavior all the time. It would be much better with this

froh• 3 years 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_tes...

thiht3• 3 years 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.

majewsky2• 3 years 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

pianoben2• 3 years 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.

gouggoug2• 3 years ago

Would you be able to expand on why using a seed of 0 is an issue?

pianoben2• 3 years 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.

kiernanmcgowan• 3 years ago

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.

wvh• 3 years ago

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.

apatheticonion• 3 years ago

It appears like it's an API design that intersects the world of high level application development and computer science.

Given randomness requires a seed and UNIX's ISO standard defines the default seed as 0, it's rational from a comp sci perspective to expect to supply a seed to produce a random number.

However, due to how ergonomic and safe high level languages are today, you don't need to be a computer scientist to make a highly available, beautiful and robust application. As such, the inhabitants of the application development world are considerably less concerned with such details and want, when they call a thing, it gives an intuitive result.

It's important that tool makers consider their users when creating APIs. Supplying a seed to a function called "getRandomNumber" might be obvious to a C programmer, but not obvious to a JavaScript programmer looking to use Go to improve the performance of their back end service.

chimeracoder7• 3 years ago

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).

tptacek4• 3 years ago

The whole point of math/rand is that it's not cryptographically secure.

SpaghettiX• 3 years ago

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• 3 years ago

It's seeded using the CPU tick counter (RDTSC on x86-64), which is sufficiently random (billions of increments per second of uptime!) for this.

https://cs.opensource.google/go/go/+/refs/tags/go1.20:src/ma...

https://cs.opensource.google/go/go/+/release-branch.go1.20:s...

https://cs.opensource.google/go/go/+/master:src/runtime/asm_...

remus• 3 years ago

I remember when I started programming this was one of the first quirks that really surprised me, I can just hear myself exclaiming "This is meant to be random! Why do I keep getting the same result?!"

I feel strangely vindicated seeing this change.

pkulak• 3 years ago

Only if you started programming in Go. I've never in my life heard of another project that by default seeds with 0. That's insane.

EDIT: Okay, C and a bunch of other languages I don't use. Keep the roasts coming, guys. :D

benatkin• 3 years ago

IIRC this is how QBasic worked back in the early 90s.

I wish I had found this little throwback (whether accidental or not) before it got fixed - though I definitely agree with the change.

donatj2• 3 years ago

Hear me out, I think in its deprecated-but-not-removed state it is actually more dangerous.

Projects who have been seeding the random generator like they should suddenly think “oh I don’t need to do that anymore” and get rid of their manual seeding.

Then a compromised or rogue library decides to seed the global generator themselves to a hard coded value in an `init()`, thus meaning merely importing the library re-statics the seed.

It would look pretty innocuous and non-obvious in code AND be potentially pretty difficult to notice it happening in a lot of use cases. For bonus points/making it slightly harder to detect points they could even have a random set of seeds they use.

The right answer, probably just generally anyway, is to never use the global generator, and always create your own instance. Global state is a danger once again

spoiler• 3 years ago

Do we know if the Seed function is now noop or does it set the seed value like previous?

I don't think people would use the "global" random functions for deterministic randomness. At least I hope they didn't...

pgwhalen• 3 years ago

I agree that would be a rough situation, but why would a library ever do that in the first place?

65a• 3 years ago

I think that's an interesting case, but any program where the random numbers have security implications should already be using crypto/rand, and not math/rand anyway.

pbohun• 3 years 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?

mseepgood4• 3 years ago

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• 3 years 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• 3 years 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• 3 years ago

The Go toolchain doesn't use any Microsoft SDK.

arp242• 3 years 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/57004

throwboatyface• 3 years ago

I used to work at an organization that shipped a Go binary that supported Linux 2.4 kernels, which afaik Golang never supported. There was nothing in the toolchain stopping us from building on an old kernel, but we were on our own for testing and worked around some libc issues in the runtime and stdlib if I recall correctly.

I imagine there's some enterprise customer somewhere on an old version of Windows that will throw money at vendors to make a similar effort.

indrora2• 3 years ago

If they wanted to, they can now use the `LOAD_LIBRARY_REQUIRE_SIGNED_TARGET` flag in LoadLibraryEx.

Aside from that, there are a broad swath of flags to LoadLibraryEx that are only supported on earlier platforms with a KB [1] from over a decade ago installed. My suspicion is that Go has decided that requiring a security KB (while good hygiene) isn't a supportable situation.

[1] https://support.microsoft.com/en-us/topic/microsoft-security...

einpoklum• 3 years ago

It's Go time!

https://www.youtube.com/watch?v=C1hdAakECUM

pxue• 3 years ago

I for one, welcome the error wrapping change.

valyala26• 3 years 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

zeeboo• 3 years 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.

valyala26• 3 years ago

Except that these people now pollute the Internet with freaky packages, which use generics in esoteric ways :)

thunky• 3 years ago

Those comments have now been replaced with "adding generics to Go was a big mistake".

SPBS• 3 years ago

They'll never go away, it just morphed into "Go was wrong and finally learnt the lesson that Java 5 did 19 years ago by adding in generics".

Go showed that useful software could be written without user-level generics. I don't think any other language today would dare to do that. In fact most languages seem to be converging into the same thing.

Macha2• 3 years ago

I mean, here's the Go 1.18 release notes and what they have to say about the dev team's level of faith in the stability of their implementation: https://go.dev/doc/go1.18

Is it a surprise that the low uptake is there with a discouragement like that?

valyala26• 3 years ago

I'm sorry, but I don't get this comment. Go is a great programming language! It is great because it is easy to write, read and maintain programs written in Go. This is because of the following features:

- Simple syntax

- Fast compile times

- Great tooling (go fmt, go vet, go too pprof, go tool cover, race detector, ect.)

- Useful standard library

Generics do not improve any of these features :( They complicate syntax, they slow down compile times and they complicate internals of go compiler and tools.

philosopher12346• 3 years ago

I doubt that was very widely read. I think it would be a mistake to attribute much of the adoption to that statement.

iio7• 3 years ago

Exactly this! It's such a shame generics where added.

zxcvbn4038• 3 years ago

You missed the highlight - the best part of go generics is it shut up all the people whining that go didn't have generics! =)

mseepgood4• 3 years ago

You acknowledge in the first sentence that compile times are back in line with Go 1.17 (i.e. pre generics), yet you claim that generics mean slower compile times.

valyala26• 3 years ago

Go1.18 and Go1.19 have slower compile times comparing to Go1.17 even for codebases, which do not use generics. For example, VictoriaMetrics [1] - the project I work on, which is written in Go without generics.

[1] https://github.com/VictoriaMetrics/VictoriaMetrics/

0x62c1b43e11• 3 years ago

I’m gonna be that guy, but do you have sources for any of this? That link shows that compiler performance is the same as before generics, for instance.

Are there more bugs in the compiler? Is readability reduced, and having an effect on pace? Especially if adoption is so low to begin with? Is adoption actually so low, or just rising?

valyala26• 3 years ago

That link admits that the compiler performance was lower than needed in Go1.18 and Go1.19, because of generics, even when compiling Go code without generics. I can confirm this based on my own open source projects written in Go [1].

[1] https://github.com/valyala/

jen204• 3 years ago

- The reduced code readability if generics are used. This slows down development pace in Go.

Speak for yourself: I prefer generics to the mess if copy-pasta or generated stuff that one had to use before.

valyala26• 3 years ago

Could you provide a few links to popular open source projects, which switched to generics and got better code because of this?

0x62c1b43e11• 3 years ago

Yeah, and I don’t tend to keep this around quantitatively, but I’ve certainly run into bugs in Go programs that would’ve been categorically prevented with generics.

Of course I want sync.Map to use generics instead of interface{}. How could I not? And it’s less complex-looking than type-asserting everywhere.

smasher164• 3 years ago

I use generics all the time in my Go code, in particular with the exp/slices library and lo. I do not find it less readable. I think readability is subjective based on people's programming experience and familiarity with type systems.

12345hn67892• 3 years ago

worse program readability is not a true con. Any codebase can have positive or negative code quality, generics do not make this worse.

In fact, it can improve readability and maintainability in some cases instead of having multiple structs copy pasted everywhere.

philosopher12346• 3 years ago

worse program readability is not a true con. Any codebase can have positive or negative code quality, generics do not make this worse.

While true that generics are not necessarily going to make programs harder to read, it's also not very interesting to talk about theory.

The question which is answerable is, "on average, were go programs easier to read before the introduction of generics". The interesting point is what actually happens, not what could.

kune• 3 years ago

At first I was on the fence too. I'm not use it all the time, but when I need it, it works as expected and it is much less a hassle than I remember writing C++ templates.

I have not seen a lot of comments that complained about the slower compile times. In my own experience it didn't really had an impact. But I agree the compiler should not become slower over time, so I appreciate the effort of the Go team to bring the compiler speed back.

I don't think that code readability is so much impacted. The square brackets work well. I find the angle brackets from C++ harder to read and there is the problem that >> is a token and cannot be used for two closing template angle brackets.

The increased complexity of the compiler is an issue, but cannot be avoided if you want to support Generics. But they took the time to make it right and as I stated it works for me.

I don't think that there is low adaption. Using type parameters visibly in a public API, breaks the API, which is the reason there are not a lot of uses in the standard library and with popular packages now. But this will change when maps and slices will be integrated in the standard library, which provide completely new APIs. Yesterday I found a library writing and reading parquet files, which used it quite extensively. But since I simply checked what libraries existed to assess how well the file format is supported, I cannot say much whether the use of type parameters by the library is useful.

umanwizard• 3 years ago

there is the problem that >> is a token and cannot be used for two closing template angle brackets.

This was fixed years ago in C++11.

politician2• 3 years 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.

thiht3• 3 years 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.

indil• 3 years ago

Do you read the docs of every basic feature you use?

Yes? You don't?

politician2• 3 years 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.

kurtoid• 3 years ago

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

philosopher12346• 3 years ago

They stopped including precompiled shared libs for the stl

mseepgood4• 3 years ago

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."

subarctic3• 3 years 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?

subarctic3• 3 years 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• 3 years ago

Why did you reply to yourself?

tapirl2• 3 years ago

It is really a pity Go didn't support the comparable interface from 1.0. The Go 1.20 change is just a compromise between theory perfection and the pity.

yawaramin• 3 years 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.

skybrian• 3 years 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?

martisch• 3 years 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.

niij• 3 years 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.

gepoch2• 3 years 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

coolgoose• 3 years ago

It's still Imho one of the worst decisions Go did, it definitely not easier to read or reason about.

Go 1.20 released

Related Stories