Source code representation
Source code representation Source code is Unicode text encoded in UTF-8. The text is not canonicalized, so a single accented code point is distinct from the same character constructed from combining an accent and a letter; those are treated as two code points. For simplicity, this document will use the unqualified term character to refer to a Unicode code point in the source text. Each code point is distinct; for instance, uppercase and lowercase letters are different characters.
Notation The syntax is specified using a variant of Extended Backus-Naur Form (EBNF): Ah, the good ol’ Extended Backus-Naur Form… EBNF is a fairly popular way to formally describe a formal language. There’s a very good chance you’ve seen something like this before, especially if you’ve ever found yourself reading an RFC. But if you haven’t, this is a great time to familiarize yourself with the basic concepts. I won’t go into a detailed explanation of EBNF or WSN (the variant used in the Go spec), as there are better online resources.
The Go Programming Language Specification Version of June 29, 2022 The Go Spec gets updated periodically. As of this writing, the latest version was updated June 29, 2022. However, Go 1.20 is scheduled for release in February, and will include some language changes. Throughout this series, I will be referencing the then-current, released version of the spec. And to reduce confusion, I’ll be sure to include the release date of the spec at the bottom of each email.
Before we start: What is the Go Spec?
It’s a new year. Time for a new daily email list, and a new series! My plan is to spend the next while (a few months, most likely) each day expounding on a small section of the Go Programming Language Specification, or Go Spec for short. But what is a programming language specification, and why should you care about it? In short, it “is a documentation artifact that defines a programming language so that users and implementors can agree on what programs in that language mean.
Go Code Roast #2: readability.js port
JSON Tricks: The Self-Referencing Marshaler
For more content like this, buy my in-progress eBook, Data Serialization in Go, and get updates immediately as they are added! The content in this post is included in my in-progress eBook, Data Serialization in Go, available on LeanPub. I’ve done a lot of JSON handling in Go. In the process, I’ve learned a number of tricks to solve specific problems. But one pattern in particular I find myself repeating ad infinitum.
JSON Tricks: Extending an Embedded Marshaler
How can you embed a struct with a custom MarshalJSON() method?
Unsure? Browse the archive.
JSON Tricks: JSON Arrays as Go Structs
How can you marshal and unmarshal JSON array as though it were a struct in Go?
JSON Tricks: "Slightly" Custom Marshaling
For more content like this, buy my in-progress eBook, Data Serialization in Go, and get updates immediately as they are added! Have you ever found yourself writing a custom JSON marshaler in Go, because you needed something only slightly different than what the standard JSON marshaler provides? Maybe the consumer of your JSON payload expects an array where you have a single item. Or maybe you need to nest your object one level deeper in your JSON than is used in your application.
Simple Go Mocks
Go’s interfaces and “duck typing” makes it very easy to create simple mock or stub implementations of a dependency for testing. This has not dissuaded a number of people from writing generalized mocking libraries such as gomock and testify/mock, among others. Here I want to describe a simple alternative pattern I frequently use when writing tests for an interface, that I think is generally applicable to many use cases. No Silver Bullet Of course neither this approach, nor any other, is a one-size-fits-all solution.
How I got go-spew to work with GopherJS