When there are concurrency problems using Go's built-in map (which is not designed to be safe for concurrent use) and a fatal error happens, the stack traces for each goroutine will only show the access from the goroutine that crashed, and not for the other.

The reason for this seems to be that the second goroutine will have moved on by the time the stack trace is printed. Furthermore, fixing this in the language would have a performance penalty.

To help debug this issue, Go provides a built-in data race detector, which makes it show more obvious what happened. This has a significant performance cost, so it shouldn't be used in production.

As long as the types match, you can pass the return values from a function directly into another function as its parameters.

Go provides a "context" package to help keep track of data and timeouts, which is especially useful on servers where, for example, you want a piece of data to be available from when a middleware runs all throughout the request, or to limit how long a handler is allowed to run.

"Type embedding" allows for something close to inheritance in Go. If you add a type as a nameless parameter on a struct, the field and methods of that type are "promoted" to the new type.

Go stores interfaces as a pair of values: a type, and the actual value, and will only be equal to nil if both are.

As a consequence, a nil value stored in an interface variable, but as a pointer to another type, will not pass the == nil test.

You can run all Go tests in the current directory and any subdirs with the following command:

$ go test ./...

Go relies on the operating system for timezone data, so when you do time.LoadLocation("America/Guayaquil"), it runs code that's different in different OSes. If you use a Docker container to run your code, it's possible to include this data in the form of a .zip file.

If you want to measure the time that it takes to run an operation, a common solution is to look at the current time before and after and compare the results. But what if the computer's time is changed between the two measurements? Then the result could be anything.

To solve this issue, computers provide a "monotonic clock", which doesn't change even if the computer's time does (maybe the system synchronizes with a time server, or the user just manually changed it). Some languages provide ways to access this value, so you have to decide what clock to use based on what you're doing with it.

You can change an object from a specific type to a interface{}, and then change it back to the original type, using Type assertions.

In the Go language, when you define an interface, you only need to implement the functions and your type automatically "implements" that interface, without explicitly saying so.