Go

Prefer using Go for all code I want to run not in the browser (scripts, web services, servers of all kinds) due to it's fast compile speeds & performance.

I love the tooling around it like VS Code and its Go plugin. The powerful go command line tool and the rich ecosystem of libraries and tools that people have built.

Go promotes composition over inheritance.

Tour of Go & Learn Go with Tests are great places to learn Go.

GoReleaser is useful for publishing. revive & Staticcheck are great linters.

Only thing I dislike about Go is it's verbosity especially with respect to errors. But that decision was made so all programmers are forced to not only consider the happy paths of their code & write proper error logging.

Commenting Go code

Comments documenting declarations should be full sentences.
Comments should begin with the name of the thing being described and end in a period.

Error checking

You can log.Fatal(err) when playing with code.
- In actual applications you need to decide what you need to do with each error response - bail immediately, pass it to the caller, show it to the user, log it and continue, etc ...

Notes

I can call functions from anywhere if they are in the same package.
The package “main” tells the Go compiler that the package should compile as an executable program instead of a shared library.
Note that any type implements the empty interface interface{} because it doesn't have any methods and all types have zero methods by default.
Simply pushing my source code to GitHub, makes it go gettable.
Interface types represent fixed sets of methods.
the prevailing wisdom in Go is to use a flat directory structure and only create new directories when you are building self-contained functionality.
go get = download the source code to your PC.
go install = download, build, and put it in the path so you can use it.
I don't need to comment all functions as some are self describing. I do need to comment exported functions however.
What works well is to use Go to create an HTTP API and leave the rest (html templates etc) to a client-side frontend (e.g. React). That gives you the best of both worlds: a fast and lightweight backend in Go with a rich frontend in JS.
This is a core concept in Go’s type system; instead of designing our abstractions in terms of what kind of data our types can hold, we design our abstractions in terms of what actions our types can execute.
In Go, as long as you are not sharing data, you don't really have to care about whether something is concurrent or parallel, the runtime takes care of it for you. You just use goroutines, IO transparently happens on a dedicated threadpool, CPU heavy tasks are spread out over the available cores.
How to edit Go packages locally
The main sell point of Go is not simplicity, but overall balance and flexibility
Better make copies of a struct than passing pointers to it.
I have grown to strongly dislike passing options by variable argument in Go ("...Option"). It makes a terrible mess of package documentation. Much easier to find and understand fields in an Options or Config struct.
Go's RTS is built around a rather simple concurrent mark/sweep GC with all of the trade-offs that this implies. In the case of GHC you have a choice between a throughput-oriented moving GC and an (admittedly somewhat young) non-moving collector. On the low-latency front Go indeed has something of a head-start here, but GHC is now competitive and is improving with every release.
Name your package for what it provides, not what it contains.
Just use channels on the fly to transfer data concurrently and be done with it.
To improve testability in my Go programs, the only thing I do in func main is call out to another function, passing in the ‘global’ things it needs. I can call run in test code like a normal function, and use a buffer for stdout (to make assertions about what it outputs.)
Don't use deferred functions in main(), don't call os.Exit/log.Fatal outside of main()
go get stores downloaded files in GOMODCACHE (can be found via go env).
gotip allows you to use Go from the tip. It’s much easier than building Go from source code
Keep everything private until something outside the package needs to access it.
Go 1.18 workspaces seem awesome. One file in the root for your workspaces definitions + dependency overrides (http://go.work) and then a specfile (go.mod) and lockfile (go.sum) in each package—bigger diffs, but exactly what you want for Docker, PaaS, and sparse checkout

Code

// Log error
if err != nil {
  log.Fatal(err)
}

Go

Commenting Go code​

Error checking​

Notes​

Code​

Links​

Commenting Go code

Error checking

Notes

Code

Links