Stream: gotime

Topic: 337: Crawl, walk & run your way to usable CLIs in Go

Logbot (Nov 12 2024 at 21:30):

With the number of libraries available to Go developers these days, you'd think building a CLI app was now a trivial matter. But like many things in software development, it depends. In this episode, we explore the challenges that arose during one team's journey towards a production-ready CLI. :link: https://gotime.fm/337

Tim Uckun (Nov 13 2024 at 21:33):

Coming from a ruby background I am surprised he didn't write the CLI in Crystal. Crystal does allow you to ship stand alone binaries and mimics the ruby standard library very closely. It also has meta programming in the form of macros and other features which go lacks and would feel natural to a ruby programmer.

Al Gonzalez (Nov 14 2024 at 01:32):

Has Crystal's support for Windows been completed?

Tim Uckun (Nov 14 2024 at 03:14):

I don't know about completed but they have supported it for CLI usage for a long time.

Üllar (Nov 14 2024 at 07:51):

reading the initial blog post, I came away with a sense that there were a lot of moving pieces just to create a CLI tool

is such an approach really worth it for the additional overhead of having so many dependencies (both in terms of Go and surrounding tools)?

Maxime Thomassin (Nov 14 2024 at 13:09):

I fully agree with both unpopular opinions! Especially the first one resonate really well with me. I find Linux is getting biggeer and bigger and with that, a lot more CLI usage and adoption.
When you build a system, you also have to create the controls to pilot that system, you want to offer a wheel not an electric panel. In our case, a good UX. For sure, a CLI will always remain low level interaction, but it will be higher then directly API endpoints. Having some commands that do many commands to abstract common flows is a really a good UX because if not you need to know the system really well. Kubecli is pretty good on that, it has both.

Moreover, in terms of devlopment, it allows the team that have great tooling to work with the system they are building and that is extremely important as the team grows and the system scale. Plus, it allows to start interacting with the system early in dev. This help build ideas on how the system should be interacted, fix issues and start paving the way for the next step of UX which is often a webapp and how we approach it.
Integration test --> CLI --> WebApp, are all ways to interact with the system, from low level to high level. Its necessary to do them as you learn how should people interact with your system incrementally. As you write the integration test, you think of the CLI and how it should be, as you write the CLI, you build ideas on how to webapp should be. And you start paving the way for that.

In terms of positional arguments, I also agree, or if it can be consistent across all or most commands. In one cli I have built, with around 20 commands, they all had one positional argument and it with the same effect, a filter on name/namespace. It was possible to set it by 2 flags, but that consistent shortcut as the only positional argument was a really good improvement on quick flows.

geemus (Wesley Beary) (Nov 15 2024 at 19:21):

@Tim Uckun When I joined the company, the CLI was already in-progress in go. Plus we already were working with a mono-repo that contained both a ruby/rails backend and a go backend that interoperate. Between the history and having go tooling/expertise on the team already, it seemed sensible to continue down that path. So I didn't really consider other language options that much, though I have seen Crystal in the wild (I think maybe the Crunchy Data CLI is in Crystal if I recall).

@Üllar There certainly are a lot of moving pieces and each dependency inherently has some cost. Because we already had node and go dependencies in the mono repo (for the rails and go backends respectively), the additional cost was lower than if we were adding whole languages. We incrementally built to where we are now and each addition has seemed worth it, but we continue to evaluate other options (I'm comparing vacuum and spectral for openapi linting lately for example). I've done this kind of work without external dependencies in the past and so far I think I prefer that complexity to having to roll my own and/or having gaps in tooling. Like many other programming tasks, there is a lot of "it depends" and/or "your milage may vary". But at least right now this array of things seems to be working well for me.

@Maxime Thomassin That's great to hear. I worry that people can be a bit too dogmatic about what "CLI" means or what it "should" be. I try to take a step back and ask what it's meant to accomplish and then try to figure out the best way to do that. Sometimes it's more low-level/granular, and sometimes not. And so far as that goes, I'll probably sometimes get it right and sometimes get it wrong, but we can always keep tweaking or trying again. I also agree with your analogy to other development stuff, it helps to be able to work more narrowly on just one part at a time (or sometimes to target end-to-end) instead of needing to try and consider the whole all the time. I think the tools help a lot with that and I embrace the opportunity to address one problem at a time. Finally, I think your example of the consistent positional args is a great one, that's exactly the kind of case that I think is a good fit.

Ron Waldon-Howe (Nov 16 2024 at 05:24):

FYI there's #terminals-and-shells-and-tuis-oh-my for this domain area when we don't have anything episodes-specific to discuss

Last updated: Apr 04 2025 at 01:15 UTC