Link: HugoConf · Making News Apps with the THANG Stack
I gave a quick lightning talk at HugoConf based on a Tweet.
Here are the slides: Making News Apps with the THANG Stack.
I gave a quick lightning talk at HugoConf based on a Tweet.
Here are the slides: Making News Apps with the THANG Stack.
Update: Want to listen to a podcast about Go 1.19 instead of reading a blog post? Check out Go Time episode 240.
Go 1.18 was a big release with huge features like generics, fuzzing, and workspaces. There was plenty of excitement around its minor or even ultra-minor features. Go 1.19 is not a release on that scale. But it does pack in a lot of small improvements that can help the average Go developer. Let’s take a look at what some of them are.
Go 1.18 was just released, bringing with it generics, fuzzing, and workspaces. Those are major features people have been asking about for years, but my last post about the minor features of Go 1.18 was an unexpected hit, so I’m following up on popular demand by bring you three even more minor features of Go. Get excited for some very small improvements to Go!
I gave a talk at FOSDEM 2022 based on my post on using errors.As
. Here is the abstract:
Error handling is one of Go’s key features. The errors.As helper added in Go 1.13 gives Gophers the tools they need to build their own error domains and ensure that all errors are handled properly across their applications.
The errors.As feature of Go 1.13 makes it easy to create error systems that work for your particular applications, users, and operators without being straitjacketed by the language into a one-size-fits-all approach that inadvertently exposes users to the internal operations of your system. Don’t let your end users be distracted by irrelevant warning messages. Handle errors properly by thinking about their roles and domain within your application.
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.†
Whenever this topic comes up, I’m used to seeing other programmers declare that the solution is simply to make something better. I understand where this thought comes from; when you have a hammer, everything looks like a nail, and it’s comforting to think that your primary skill and passion is exactly what the problem needs. Making better tools doesn’t do anything about the backwards profit motive though, and besides, have you tried using any of the centralized alternatives lately? They’re all terrible. Quality of tools really isn’t what we’re losing on.
No, the solution has to be political. That’s uncomfortable for me, as it probably is for you too. Software I can do, politics though? That’s hard. Something needs to change about these profit motives though. I’m not arrogant enough to declare that I know the one true answer here, I doubt there even is one true answer.
An example I bring up that people sometimes don’t know about is that when Time Warner bought AOL in 2002 one of the conditions from the FCC was that AOL open up its instant messenger platform before going into videoconferencing. The Bush administration ultimately just decided to just ignore the condition. But you can imagine another universe where instead of jumping from AOL to GChat to Slack to Discord every few years, we could just… use an instant message client and expect it work with whatever servers our friends and companies happen to use. We don’t live in that world because there wasn’t the political will to create it.
I was on episode 171 of the Go Time podcast talking more about //go:embed
. Check it out!
Update: Want to listen to a podcast about go:embed instead of reading a blog post? Check out Go Time episode 171.
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.