Go Notes

This repo is just my playground to learn and try to take notes on things I learn in Golang. These notes are not going to be a perfect read, but are rather intended to be reference documents for snippets of knowledge or examples. These notes are just little jots I make while I learn and will include spelling mistakes, bad grammar, and a complete disregard for past, present, and future tense. So far I have been following this guide: https://quii.gitbook.io/learn-go-with-tests/ and have been loving it.

Go Fundamentals:

1.

Hello World

2.

Integers

3.

Iteration

4.

Arrays and Slices

5.

Struct, Methods, and Interfaces

6.

Pointers & errors

7.

Maps

8.

Dependency Injection

9.

Mocking

10.

Concurrency

11.

Select

12.

Reflection

13.

Sync

14.

Context

15.

Intro to property based tests

16.

Maths

17.

Reading files

18.

Templating

19.

Generics

20.

Revisiting arrays and slices with generics

Testing Fundamentals

1.

Introduction to acceptance tests

2.

Scaling acceptance tests

3.

Working without mocks

4.

Refactoring checklist

Build an Application

Now that you have hopefully digested the Go Fundamentals section you have a solid grounding of a majority of Go’s language features and how to do TDD.

This next section will involve building an application.

Each chapter will iterate on the previous one, expanding the application’s functionality as our product owner dictates.

New concepts will be introduced to help facilitate writing great code but most of the new material will be learning what can be accomplished from Go’s standard library.

By the end of this, you should have a strong grasp as to how to iteratively write an application in Go, backed by tests.

1.

HTTP server

Other courses

I also have worked through a couple of Udemy courses on Go and I have included my notes on those:

1.

Building Go Modules

2.

Design Patterns in Go

3.

Introduction to Testing in Go

4.

Working with Concurrency in Go

5.

Building Modern Web Applications with Go

6.

Building Web Applications with Go

7.

Working with Microservices in Go

8.

Working with React and Go

Practice programs

This is just some random practice programs I have done to test myself. To view these please go here.

Other Notes

https://tleyden.github.io/blog/2013/11/23/understanding-chan-chans-in-go/

Project Layout

Since the very first time I looked at a Go repository I have been very confused by the structure of the directories within a project. Luckily it seems that there are no hard rules around project layout from the core Go team unless you are intending your code to be an public module in which case there are some rules so that go mod can properly important your module.

I did find this repository that describes general guidelines that have been accepted by the larger Go community: here.

Go Directories:

• /cmd: Main applications for this project.

  The directory name for each application should match the name of the executable you want to have (e.g., /cmd/myapp).

  Don’t put a lot of code in the application directory. If you think the code can be imported and used in other projects, then it should live in the /pkg directory. If the code is not reusable or if you don’t want others to reuse it, put that code in the /internal directory. You’ll be surprised what others will do, so be explicit about your intentions!

  It’s common to have a small main function that imports and invokes the code from the /internal and /pkg directories and nothing else.

  See the /cmd directory for examples.

• /internal: Private application and library code. This is the code you don’t want others importing in their applications or libraries. Note that this layout pattern is enforced by the Go compiler itself. See the Go 1.4 release notes for more details. Note that you are not limited to the top level internal directory. You can have more than one internal directory at any level of your project tree.

  You can optionally add a bit of extra structure to your internal packages to separate your shared and non-shared internal code. It’s not required (especially for smaller projects), but it’s nice to have visual clues showing the intended package use. Your actual application code can go in the /internal/app directory (e.g., /internal/app/myapp) and the code shared by those apps in the /internal/pkg directory (e.g., /internal/pkg/myprivlib).

  You use internal directories to make packages private. If you put a package inside an internal directory, then other packages can’t import it unless they share a common ancestor. And it’s the only directory named in Go’s documentation and has special compiler treatment.

• /pkg: Library code that’s ok to use by external applications (e.g., /pkg/mypubliclib). Other projects will import these libraries expecting them to work, so think twice before you put something here :-) Note that the internal directory is a better way to ensure your private packages are not importable because it’s enforced by Go. The /pkg directory is still a good way to explicitly communicate that the code in that directory is safe for use by others. The I’ll take pkg over internal blog post by Travis Jeffery provides a good overview of the pkg and internal directories and when it might make sense to use them.

  It’s also a way to group Go code in one place when your root directory contains lots of non-Go components and directories making it easier to run various Go tools (as mentioned in these talks: Best Practices for Industrial Programming from GopherCon EU 2018, GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps and GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go).

  See the /pkg directory if you want to see which popular Go repos use this project layout pattern. This is a common layout pattern, but it’s not universally accepted and some in the Go community don’t recommend it.

  It’s ok not to use it if your app project is really small and where an extra level of nesting doesn’t add much value (unless you really want to :-)). Think about it when it’s getting big enough and your root directory gets pretty busy (especially if you have a lot of non-Go app components).

  The pkg directory origins: The old Go source code used to use pkg for its packages and then various Go projects in the community started copying the pattern (see this Brad Fitzpatrick’s tweet for more context).

• /vendor: Application dependencies (managed manually or by your favorite dependency management tool like the new built-in Go Modules feature). The go mod vendor command will create the /vendor directory for you. Note that you might need to add the -mod=vendor flag to your go build command if you are not using Go 1.14 where it’s on by default.

  Don’t commit your application dependencies if you are building a library.

  Note that since 1.13 Go also enabled the module proxy feature (using https://proxy.golang.org as their module proxy server by default). Read more about it here to see if it fits all of your requirements and constraints. If it does, then you won’t need the vendor directory at all.

Subdirectory guidelines can be found here.