Announcing gfold 4

Tuesday, May 10, 2022

gfoldRust

Today marks the release of gfold 4 🎉!

Before we talk about what’s been changed, let’s talk about how far the project has come. Here are some present day statistics of note:

As some of you might recognize, these metrics are the same as those introduced in the gfold 3 announcement. Here are the statistics from that post:

Those are big leaps! I’m excited for all new and existing users to try out gfold 4, which I think is the best release yet.

There’s two technical reasons that fuel a significant portion of my excitement.

  1. I hope this release will contain the last major semver bump that will be needed for a long time (i.e. no more user-facing breaking changes for a long time). It’s a polishing iteration on the domain-driven refactor of gfold 3.
  2. There will likely be significant performance improvements for most users. In recent tests mimicking real world use, I’ve seen up to 5.1x speed increases when loosely benchmarking the most recent release candidate on macOS 12.3.1.
Average: 686.645865ms - /Users/nick - 4.0.0-rc.4
Average: 810.047984ms - /Users/nick - 3.0.0
Average: 6.156336ms - /Users/nick/src - 4.0.0-rc.4
Average: 31.491704ms - /Users/nick/src - 3.0.0

Please note: I use the term “loose benchmarking” to mean measuring average runtime duration with realistically-shaped dummy data and execution scenarios reflecting real world use. The latter translates to direct invocations of the gfold binary on mobile hardware.

True benchmarking is difficult, especially when using consumer-grade mobile processors that can produce highly variable results based on temperature and battery. However, gfold users will likely be using consumer-grade mobile hardware (i.e. laptops) on battery power, so I’ve been mostly happy with “loosely” benchmarking real world usage scenarios on similar hardware.

TLDR: these benchmarks aren’t precise, but they have been useful in making changes that can help result in perceptible performance enhancements for most gfold users.

If gfold 3 was the domain-driven refactor that helped revitalize the project, gfold 4 is the follow-up that takes lessons learned from the initial design and makes breaking changes based on them whilst retaining the skeleton of the previous release. In fact, gfold 4 was originally slated to release as gfold 3.1 due to its core execution loop remaining the same, but I am generally not a fan of deviating from semver rules and since there were user-breaking changes, I bumped the major semver field.

So… what are these major breaking changes that prompted the major semver field bump? Let’s go over them.

Despite these big changes, gfold still follows the same execution pattern as before: no subcommands and operates on the current working directory (or config file setting) if a positional argument is not provided. Migrating exciting scripts, config files, aliases, etc. should be relatively painless since user-facing changes were limited to configuration and not to execution patterns.

That leads us into the best part: what are the improvements, features, and enhancements in this release?

There have also been significant non-user-facing changes both internally and externally to the application that have helped ensure this release is stable.

Finally, a major shoutout to a community member, AcksID! AcksID has released the excellent Neovim plugin for gfold, nvim-gfold.lua. Please show AcksID some love. The plugin is great and has a bright future ahead of it. I highly recommend Neovim users to try it out!

All in all, this is my favorite release of gfold yet. I’m excited for you to try it out and I hope you enjoy using it.

For more information, access the 4.0.0 changelog or the rolling changelog.

See More Posts