Everyone is excited that after a decade or so of devs asking for generics, the Go programming language is getting generic types and functions in Go 1.18 in Q1 2022. Generics are no doubt going to lead to a lot of experiments, some good, some bad, some just weird. Go 1.18 is also poised to lead to an increase in software reliability by including fuzzing as part of the standard testing package. But today, I want to look at some minor changes in Go 1.18 that might otherwise get lost in all the excitement around the marquee features.

Go is a language designed by Google for use in a modern internet environment. It comes with a highly capable standard library and a built-in HTTP client. I’m on the record as being against including a lot of dependencies. So why did I end up writing my own HTTP client helper library for Go?

Suppose that thirty something years ago, you were a middle manager at a large international bureaucracy, and a proposal landed on your desk that began like this:

Multimedia is a way to link and access information of various kinds as a honeycomb of nodes in which the user can flit at will. It provides a single user-interface to large classes of information (reports, notes, data-bases, computer documentation and on-line help). We propose a simple scheme incorporating servers already available.†

Update: Want to listen to a podcast about go:embed instead of reading a blog post? Check out Go Time episode 171.

简体中文版 by 涛叔 Tao Shu

I have previously written about how to use //go:generate. It exists to “to automate the running of tools to generate source code before compilation.” Now there is a new feature in Go that eliminates many uses of source code generation. In addition to the remarkable new flag.Func feature, Go 1.16 also introduced a new //go:embed directive that allows you to include the contents of arbitrary files and directories in your Go application. To demonstrate some of the capabilities of //go:embed, I have made an example repo which I will explain in this post.

The basic idea of embedding is that by adding a special comment to your code, Go will know to include a file or files. The comment should look like //go:embed FILENAME(S) and be followed by a variable of the type you want to embed: string or []byte for an individual file or embed.FS for a group of files. The go:embed directive understands Go file globs, so patterns like files/*.html will also work (but not **/*.html recursive globbing).

You can read the official docs for a complete technical explanation, so here let’s take a look at some examples to see what’s possible.

Go 1.16 is shaping up to be one of the most exciting releases of Go in recent memory. Among its new features is the //go:embed directive and the reorganization/deprecation of io/ioutil. It’s not due out until February 2021 (Edit: it came out Feb. 16, 2021), but now I would like to write about a minor change to the standard library flag package that might otherwise be missed in the sea of changes:

The new Func function allows registering a flag implemented by calling a function, as a lighter-weight alternative to implementing the Value interface.

I proposed and implemented flag.Func. I have made minor contributions to the Go project before, but this is the first time I’ve added a whole top level function to the standard library, so I’d like to explain a little about what it does and the process of getting it accepted into the Go standard library.

TL;DR if you have to choose, you should prioritize users with no JavaScript over users with old JavaScript.

If you’re a web developer working today, it’s probably long passed time for you to stop transpiling your modern JavaScript into ES5 for Internet Explorer. Any time or effort spent getting your JavaScript working in IE11 is wasted time that could be better spent making a better experience for users without JavaScript. Moving your resources from Internet Explorer to users without JavaScript will let you improve the SEO and accessibility of your site while providing a better experience for everyone.

First, some notes about who this advice is for: I am assuming you’re working for a small team with no Quality Assurance testing department making a content focused site. If you have a large team that actually QA tests IE11, this advice may not apply to your situation. If you’re just doing personal projects for fun, you should have already dropped ES5 years ago. If you’re making more of an app than a content site, you probably should have cut off IE11 years ago, but the calculations are more complex and site specific.

The promise of Web Components was that we’d get this convenience, but for a much wider range of HTML elements, developed much faster, as nobody needs to wait for the full spec + implementation process. We’d just include a script, and boom, we have more elements at our disposal!

Or, that was the idea. Somewhere along the way, the space got flooded by JS frameworks aficionados, who revel in complex APIs, overengineered build processes and dependency graphs that look like the roots of a banyan tree.

I think the issue is deeper than Verou’s complaints, although those are valid. Web Components don’t actually to solve the problem they purport to solve. The pitch is “get semantic elements from across the web!” But those are wrong problems to try to solve.