I am struggling to come up with a witty introduction to this topic, so let me just start by telling the origin story. Several years ago, I added some tooling to help me manage secrets related to my dotfiles. The first incarnation was a simple .netrc type solution where I stored the secrets in plain text in files that only my user could read. I added some scripts to help reading and managing these a bit.
Coming from the world of Perl, one thing I find to be a weakness of most languages is their lack of CPAN. Having a comprehensive archive of all the code that is shared and mattered is amazing. You can cache locally. You can carry it with you on a laptop (at least, if you just want the most recent versions of everything). You can grep it. You can run a local documentation repository easily.
This is just to settle a dispute that mostly exists in my own head. It likely matters very, very little. However, it matters enough. I am currently interviewing for new jobs and during one interview, I was asked to design an algorithm for which I needed a set data type. Golang provides no built-in set data type, but it does provide a map, so I defined my set as follows:
Almost exactly two years ago, I began a little side project to create an email parser. I wanted to port an email sorting system I had previously written in Perl to Go. There was no particular reason to have my own email sorting system or to port it to Go except that I could and because I wanted to learn more practical skills in Go. However, in the process I was unable to find an email message parser which was able to meet all of my requirements.
The headline is a little bit click-bait-y, but I want to highlight one of the easily overlooked risks of using slices in Golang. First of all, there’s nothing really wrong with the way slices work. A trade-off was made. It is not necessarily the same trade-off I would make, but such is engineering.
Consider Arrays First, let’s map what a slice is because it might not be obvious unless you’ve been writing Golang programs for a while.
Updated 2023-01-11: This update is looooooong overdue. I had it dated as of May of last year and then never published it. My mistake. However, thanks to a reader, c0nscience, I am coming back around and geetting this correction made. He also suggested another implementation for reference by Jeff Linse on Github. After writing this post, I started working on some other projects and also started on another branch. Apparently, my testing of this change was very inadequate.
What a year, right? I had a whole load of blog posts planned for 2020, a talk to prep for YAPC, but the Lord decided that He had a better plan. I don’t know that anyone is going to read this, but I want to take some time to process what happened to the technical arm of it along the way.
The biggest change to my life technically is that I don’t think I have written more than a dozen edits to a Raku program in the last 15 months.
