Warg is a command-line argument parser which eliminates some boilerplate required by the standard library's flag package without the bulk of more well-known libraries like Cobra or Urfave.

With Warg you can simply define your command-line inputs as struct tags and Unmarshal os.Args to it and off you go. The struct tags also support the ability to define required flags, default values and where to store any identified positional args.

Ever started off with some command-line tooling and thought, "I'll just use log..."?

Then, invariably, you think, "Gee, I sure do want log levels...". So then you pick up slog.

But the slog TextHandler sure is ugly to read, right? Ah well, we can live with that. How about if you want to log.Fatal? Well.. You could implement a little helper function to call slog.Error then os.Exit, right?

Ah, but then if you want to slog with the caller the program counter in your slog.Records are now off by one!

Halfway to reimplementing slog later I decided to rip off the bandaid and write Scribe. It's a logging package for in-the-terminal use cases, maintaining both the slog key-value pair API as well as the printf capability offered by log but all presented in a way that makes it easy for your eyes to quickly scan through and see the information you care about.

I prefer to use bit flags to represent configuration and state wherever possible. But, bit flags inherently don't present a super ergonomic developer experience (VAR & FLAG == FLAG gets a bit tedious). You could (and probably should) write helper functions to handle these checks. Yet if you've got more than a few flags this gets really tedious.

This wall of boilerplate is exactly what Flagger is intended to solve. With a simple:

1. go get -tool git.sr.ht/~illbjorn/flagger
2. //go:generate go tool flagger -t [MY_TYPE] -o [MY_TYPE]_flagger.go
3. go generate ./...

As mentioned in the Flagger section above, I'm a big fan of compact data representations! In pursuing this, what with operations like &^=, |= and more all piled together, I frequently find myself wanting to quickly check my work.

Bitly is a command-line shell (REPL) supporting all numeric Go operations and variable assignment! By default, inputs can be in base-2 (0b prefix), base-10 or base-16 (0x prefix). Bitly can also output the calculated result in each of these formats by simply enabling the appropriate flag with set [OPTION] = [0/1].

string to []byte conversions aren't free!

In certain scenarios, when the Go compiler can guarantee you don't mutate a []byte after you string convert it, an allocation may not occur. However, in a great many cases it does.

In the appropriate scenarios, when you have a really clear picture of what the lifetime of your []byte or string will be, I think it's reasonable to unsafe convert these. Especially in hot loops as excessive allocations can result in some unwieldy memory thrash.

Safe is my, very small, collection of useful unsafe stuff I find myself reaching for pretty regularly.

amaxwell.dev, the site you're currently browsing!

Builder was a fun little proof-of-concept for creating a strings.Builder without heap allocating it, then hiding it from the Go runtime's escape analysis (ref)!

SRM is a command-line tool which migrates repositories from GitHub to SourceHut.

Features:

• Validates clean Git status.
• Backs up the repository (pre-flight).
• Applies language-specific project processing (currently just supports Go)
• Parses the go.mod file, locating the module name and, if it uses the github.com/ format, replaces this module name in all project files with a mirrored SourceHut equivalent.
• Updates the default Git remote to a SourceHut address.
• Commits and pushes all project files to the updated remote.

Echo was my first attempt at a logging package which puts more emphasis on user-facing output!

Fstr was one of my earlier Go packages! It's a more readable string formatting package.

Semver was a quick semantic version parsing package which solved a particular need at the time.