It just struck me that the Go team does not provide PGP or other cryptographic signing/verification of releases.
https://golang.org/dl/
They have checksum hashes but not crypto verifiable signatures.
Go 1.14 release notes
21–30 of 42 posts
Re: Go 1.14 release notes
#22Re: Go 1.14 release notes
#23Maybe link the changelog instead? https://tip.golang.org/doc/go1.14 Selected changes: - This release improves the performance of most uses of defer to incur almost zero overhead compared to calling the deferred function directly. As a result, defer can now be used in performance-critical code without overhead concerns. - Goroutines are now asynchronously preemptible. As a result, loops without function calls no longe…
> Goroutines are now asynchronously preemptible. As a result, loops without function calls no longer potentially deadlock the scheduler or significantly delay garbage collection.
What does that mean in practice? Can I perform expensive calculations in parallel exhausting all cores?
Re: Go 1.14 release notes
#24Earlier quoted context omitted.
What assurances does that give you beyond the https certificate on their official website which contains the binary downloads and hashes?
Defense in depth, essentially. But yes, checking site X to see if site X gave you Y correctly is rather weak confidence. To argue in its favor tho, file-hosting and site-serving may be handled by different systems with different security characteristics, and potentially even different datacenters (e.g. a CDN). If you only have to compromise one system, it's generally easier to do so than when you have to compromise N…
The hash and file are not hosted on the same place so it's good enough.
Re: Go 1.14 release notes
#25Maybe link the changelog instead? https://tip.golang.org/doc/go1.14 Selected changes: - This release improves the performance of most uses of defer to incur almost zero overhead compared to calling the deferred function directly. As a result, defer can now be used in performance-critical code without overhead concerns. - Goroutines are now asynchronously preemptible. As a result, loops without function calls no longe…
> Goroutines are now asynchronously preemptible. As a result, loops without function calls no longer potentially deadlock the scheduler or significantly delay garbage collection. What does that mean in practice? Can I perform expensive calculations in parallel exhausting all cores?
This means that the threads can't be blocked forever. The way Go scheduler work is to check during function calls if the current goroutine has executed for some period of time, after that the scheduler will remove the goroutine from the thread and open space for other goroutines to execute.
But if you're doing a loop without function calls, imagine a for {}, in this case, the thread will be locked forever.
Now with 1.14, this don't happen anymore. In my opinion the expected result will be better tail latencies.
Re: Go 1.14 release notes
#26Earlier quoted context omitted.
https://golang.org/dl/
They have checksum hashes but not crypto verifiable signatures.
$ curl https://dl.google.com/go/go1.13.4.src.tar.gz.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJdu22LAAoJEGSUxtaZfCFeXigQAKc6NflWvvbaZ6S7RCVuRNzA
...Re: Go 1.14 release notes
#27Maybe link the changelog instead? https://tip.golang.org/doc/go1.14 Selected changes: - This release improves the performance of most uses of defer to incur almost zero overhead compared to calling the deferred function directly. As a result, defer can now be used in performance-critical code without overhead concerns. - Goroutines are now asynchronously preemptible. As a result, loops without function calls no longe…
> This release improves the performance of most uses of defer to incur almost zero overhead compared to calling the deferred function directly.
Anyone happen to know why there used to be overhead here/what changed?
From my comfortable sofa, it seems that there should be little difference between a defer-ed and direct call?
Re: Go 1.14 release notes
#28Earlier quoted context omitted.
They have checksum hashes but not crypto verifiable signatures.
$ curl https://dl.google.com/go/go1.13.4.src.tar.gz.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABCAAGBQJdu22LAAoJEGSUxtaZfCFeXigQAKc6NflWvvbaZ6S7RCVuRNzA ...
Nice. Thanks for sharing. I didn't see that documented. Would be great to have it documented.
Re: Go 1.14 release notes
#29Maybe link the changelog instead? https://tip.golang.org/doc/go1.14 Selected changes: - This release improves the performance of most uses of defer to incur almost zero overhead compared to calling the deferred function directly. As a result, defer can now be used in performance-critical code without overhead concerns. - Goroutines are now asynchronously preemptible. As a result, loops without function calls no longe…
> Goroutines are now asynchronously preemptible. As a result, loops without function calls no longer potentially deadlock the scheduler or significantly delay garbage collection. What does that mean in practice? Can I perform expensive calculations in parallel exhausting all cores?
Go has supported running goroutines in parallel since before 1.0, and it’s been the default behaviour since version 1.5, released in 2015.
Re: Go 1.14 release notes
#30Thanks to the Go team for the great work!
The more I use it, the more I enjoy Go. Having grown up with the healthy dose of Pascal and later Modula 2, I appreciate many traits of Go which let me just focus on the tasks at hand. With very little "magic" going on, some parts of the code might be a bit tedious, but you also always have the feeling of being in control, as everything is very explicit. Add to that a few underapreciated dynamic features. I am first of all a professional Lisp/Scheme programmer and a lot of Scheme concepts translate surprisingly well into Go due to having first class functions and a garbage collector.
It is very nice to see how the Go releases are very careful to add new features while continuosly improve on the "quality" side. Enhancing the performance of "defer" is a great example. Like unwind-protect in Lisp, it is a very elegant way to ensure that cleanup code is run under any circumstance. Removing its overhead is a big thing.