Learning Go with code pop quizzes is a fun way to zoom in on different language features. People are looking forward to pop quizzes on Twitter and in conferences, and they also learn from that. Let’s chat about pop quizzes!

Dave Cheney talks to us about the Zen of Go (ten engineering values for writing simple, readable, maintainable Go code). What makes code good in Go? What guiding principles should we bear in mind when writing Go?

How do you write good code? How do you know when you’ve written good code? Dave Cheney writes this with inspiration from PEP 20 - The Zen of Python.

If there’s a continuum between good and bad, how to do we know what the good parts are? What are its properties, its attributes, its hallmarks, its patterns, and its idioms?

Which brings me to idiomatic Go. To say that something is idiomatic is to say that it follows the style of the time. If something is not idiomatic, it is not following the prevailing style. It is unfashionable.

More importantly, to say to someone that their code is not idiomatic does not explain why it’s not idiomatic. Why is this?

Dave Cheney’s ten engineering values for writing simple, readable, and maintainable Go code. Some of these apply outside of Go, as well. For instance, Simplicity matters:

Simplicity is not a synonym for unsophisticated. Simple doesn’t mean crude, it means readable and maintainable. When it is possible to choose, defer to the simpler solution.

(Originally presented at GopherCon Israel 2020.)

Mat and Carmen along with guest panelists Dave Cheney, Peter Bourgon, and Marcel van Lohuizen discuss errors in Go, including the new try proposal. Many questions get answered…What do we think about how errors work in Go? How is it different from other languages/approaches? What do/don’t we like? What don’t we like? How do we handle errors these days? What’s going on with the try proposal?

If you haven’t attended the workshop directly, the next best thing is to learn indirectly by reading the workshop’s docs.

The goal for this workshop is to give you the tools you need to diagnose performance problems in your Go applications and fix them.

It’s licensed under the Creative Commons Attribution-ShareAlike 4.0 International license and the source is on GitHub.

This is Dave Cheney’s working document for his Practical Go workshop. So much wisdom shared.

My goal over the next two sessions is to give you my advice for best practices writing Go code.

This is a workshop style presentation, I’m going to dispense with the usual slide deck and we’ll work directly from the document which you can take away with you today.

There’s also this page of the same name on his site, but I’m not sure if they’re directly connected.

At RubyConf, Chad Fowler spoke on writing software systems that mirror the process of continual replacement observed in biological systems. Dave Chaney ponders:

What would happen if we developed software this way? What benefits could it bring?

No hard answers here, but interesting questions for sure…

Dave Cheney joined the show this week to discuss SOLID Go design, software design in Go, what it means to write “good Go code”, and error handling.