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.

…how to lock a piece of code so that it's guaranteed to only run once at a time. If it's running and another thread (or Goroutine in my case) reaches the same piece of code, it will wait for the first process to finish before continuing its execution.

I'm using it to lock an entire function, but apparently it works for any section of code.

Running tests with coverage on the Goland IDE is really easy, you just write the test and it gives you a "play icon" button to the left of each function, and after it runs you get the coverage report in a separate window and within the source code as well, telling you exactly which lines are covered.