Skip to content

Instantly share code, notes, and snippets.

@mercul3s
Last active May 9, 2019 14:43
Show Gist options
  • Save mercul3s/5fac1577a54bca705484dfa39f781526 to your computer and use it in GitHub Desktop.
Save mercul3s/5fac1577a54bca705484dfa39f781526 to your computer and use it in GitHub Desktop.
Outline for a go intro talk/workshop

Outline

  • What is Go?
    • compiled, statically typed, non object-oriented language
    • C-like structure
    • Native support for handling concurrency and threads (via goroutines)
  • Basic structure of a go program
    • Package naming
      • packages live in a subdirectory of the same name with their test files
      • generally do not contain main methods, but they can
    • Main file/method
      • func main() is called when invoking a go binary or by calling go run <programfile.go>
      • I personally lean towards business logic and functionality in packages, and then calling that functionality in my main method.
    • Static typing
      • examples
      • method signatures
      • can't mix types! Must convert types or use an interface (more on this later)
    • Structs and Interfaces
      • Structs are user defined containers for data
        • structs can have methods
      • Interfaces hold information about methods, and provide a way of abstracting methods on different types of data.
      • When do we need an interface?
        • to handle larger abstractions
        • for mocking during testing
          • example: List func and mocking
    • Error handling
      • What to do with errors
        • Generally don't use them to control program flow; use them to halt execution early and return
        • bubble errors up to the surface to be output/returned in a user-readable error (ie logging, http response code, etc)
        • Don't Panic()!
          • panic() halts program execution and outputs a stack trace. This is potentially useful for debugging, but not so helpful running in production.
      • If err != nil handler
        • if you happen to have a lot of the same types of error to return, or expect to handle your errors in the same way (ie logging, http error), you can write a function to handle your errors.
      • When to ignore errors
        • if you are ok with nil/empty data or aren't returning data, or don't yet know how you'll handle the error, you can ignore it with an underscore: data, _ := function()
    • Concurrency
      • Goroutines
        • Goroutines are essentially threads, and you invoke a new goroutine by calling go <function> or by defining an anonymous function in your gouroutine with go func() {…}
        • Goroutines cannot return data or errors.
        • Output to stdout in a goroutine may go to a different stdout than the running stdout.
      • Channels
        • Channels provide the ability to pass data between running programs/methods.
        • That data can then be read by another program or method.
        • Remember how I said we couldn't return data from a goroutine? Instead, we can create a channel that's accessible from the goroutine, and pass data to it instead. We can then read that data and do something with it (pass along an error condition, data returned, etc)
      • Mutexes
      • Defer
        • Defer is a built in method to execute a function after the surrounding function has finished executing.
        • ie defer server.Stop() will call that method after everything else is done
        • typically used to clean up and gracefully exit programs
    • Testing
      • Code coverage
      • Table tests
      • Goconvey
      • Examples: handler vs router tests
    • How to read a stack trace!
    • Tooling
      • Gofmt
      • Golint
      • gometalinter
      • Errcheck
        • When to ignore and how
      • Perf tooling
    • Resources for learning
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment