- 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 longer potentially deadlock the scheduler or significantly delay garbage collection.
- Per the overlapping interfaces proposal, Go 1.14 now permits embedding of interfaces with overlapping method sets: methods from an embedded interface may have the same names and identical signatures as methods already present in the (embedding) interface. This solves problems that typically (but not exclusively) occur with diamond-shaped embedding graphs. Explicitly declared methods in an interface must remain unique, as before.
> 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.
It means the following program will happily exit now.
package main
import (
"time"
"runtime"
)
func main(){
for i := runtime.NumCPU(); i > 0; i-- {
go func() {
for {}
}()
}
time.Sleep(time.Second)
println("bye")
}
Defers can happen in a loop, so you need a stack for correctness. This change is that the compiler will now automatically inline the defer-ed call so they appear much the same as a direct call at the end of a function if they happen at most once.
> Go 1.13 implements the defer statement by calling into the runtime to push a "defer object" onto the defer chain. Then, in any function that contains defer statements, the compiler inserts a call to runtime.deferreturn at every function exit point to unwind that function's defers.
> We propose optimizing deferred calls in functions where every defer is executed at most once (specifically, a defer may be on a conditional path, but is never in a loop in the control-flow graph). In this optimization, the compiler assigns a bit for every defer site to indicate whether that defer had been reached or not. The defer statement itself simply sets the corresponding bit and stores all necessary arguments in specific stack slots. Then, at every exit point of the function, the compiler open-codes each deferred call, protected by (and clearing) each corresponding bit.
defer-ed calls are (in a very simplified way) pushed on a "stack" of methods to be called just before parent function exists. The mechanics of retrieval-call-repeat_if_more_available are cheap, but not free. They have reduced costs of these interactions.
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.
Buried in the notes is a small, but useful addition to the testing package that allows your test helpers to register their own cleanup functions (testing.(*T).Cleanup). I wrote a blog post discussing it in depth here: https://www.gopherguides.com/articles/test-cleanup-in-go-1-1...
Hey. Interesting blog post! Quick bit of feedback for you... I find the code snippets quite hard to read on mobile as the lines wrap. Could you enable horizontal overflow scrolling do you think? overflow-x:scroll
go build -gcflags=-warnunused
go test -gcflags=-warnunused
which causes the compiler to only warn about unused things instead of stopping the build:
$ go test -gcflags=-warnunused
# github.com/kstenerud/go-describe
./describe_unsafe.go:8:2: Warning: imported and not used: "fmt"
./describe.go:329:2: Warning: isInUnsignedArray declared but not used
...
PASS
ok github.com/kstenerud/go-describe 0.002s
I use this when debugging or for exploratory coding.
> When the main module contains a top-level vendor directory and its go.mod file specifies go 1.14 or higher, the go command now defaults to -mod=vendor for operations that accept that flag.
Thank you! Modules and vendoring has been a royal pain. This should help a lot.
Wish the json.Register funcion had been in 1.14. Desperately need it for a project I'm working on. If anyone has any ideas for overriding structs in a pkg I'd love to hear them!
I feel like it's generally possible to work around this by creating a wrapper struct with an overridden MarshalJSON method? But maybe that's infeasible for deeply nested structs.
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 and make them all agree with each other.
If a hosting server is compromised the hash and download can be changed with something nefarious. crypto signing/verification will catch that case. hash checking will not.
This is a legitimate case as it's happened to other projects in the past.
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 longer potentially deadlock the scheduler or significantly delay garbage collection.
- Per the overlapping interfaces proposal, Go 1.14 now permits embedding of interfaces with overlapping method sets: methods from an embedded interface may have the same names and identical signatures as methods already present in the (embedding) interface. This solves problems that typically (but not exclusively) occur with diamond-shaped embedding graphs. Explicitly declared methods in an interface must remain unique, as before.