Cli on Backend Engineering Strategy Tools

Rust

Wed, 03 Jun 2026 00:00:00 +0000

Systems language with memory safety guarantees without a garbage collector. The ownership and borrow checker model enforces at compile time what other languages leave to the runtime or the programmer.

The pitch: C/C++ performance and control, without the entire class of memory safety bugs that makes systems programming treacherous. In practice the borrow checker is the learning curve, it rejects code that would be valid in any other language until you understand why it is wrong.

Where Rust is winning

CLI tooling: a significant share of modern CLI tools are written in Rust. ripgrep, fd, bat, exa/eza, zoxide, tokei. Startup time and binary distribution (single static binary) are the wins.

WebAssembly: Rust compiles to WASM with first-class tooling (wasm-pack, wasm-bindgen). Running near-native code in the browser or at the edge.

Embedded / systems: where C used to be the only option. The safety guarantees matter more, not less, when there is no OS underneath.

Cloud infrastructure tooling: parts of the ecosystem are being rewritten in Rust. Firecracker (AWS Lambda’s VMM), parts of the Linux kernel, Cloudflare Workers runtime.

Tooling

Cargo: the build system and package manager. Handles dependencies, building, testing, and publishing. One of the better-designed package managers in any ecosystem.

rustup: toolchain manager. Manages Rust versions and targets (cross-compilation).

clippy: linter. Catches more than the compiler, opinionated in useful ways.

rustfmt: formatter. Like gofmt, one style, no debate.

IDE: VS Code with rust-analyzer extension, or IntelliJ/CLion with the Rust plugin.

The learning curve

The borrow checker is a genuine obstacle. Rust enforces at compile time:

Exactly one owner of any value
Any number of immutable references OR one mutable reference — not both
References cannot outlive the value they point to

This is unfamiliar to anyone coming from languages with a GC. The compiler error messages are unusually helpful, but expect to spend real time understanding ownership before writing idiomatic Rust.

Resources

The Rust Book: the standard introduction, free online
Rustlings: small exercises for learning by doing
crates.io: the package registry
Blessed.rs: curated crate recommendations by category

The trend pattern

Language adoption tends to follow ecosystem trends rather than purely technical merit. I started with Java. Then OpenStack brought Python into infrastructure work. Then Kubernetes arrived and its ecosystem was written in Go — so Go became the language of the cloud-native world by proximity as much as by choice.

Rust looks like the next turn of that cycle. The “rewrite it in Rust” trend is real and growing — CLI tooling, parts of the Linux kernel, browser engines, cloud infrastructure. If the pattern holds, the ecosystem will pull Rust into more places where it becomes the pragmatic choice rather than the deliberate one.

Haven’t given it a serious attempt yet. Worth doing — not because Rust is clearly the right tool for the things currently being built, but because being ahead of the ecosystem trend rather than behind it is how you end up with useful experience when the moment arrives. The tooling is good, the learning resources are good, and the borrow checker will teach you something about memory regardless of whether you end up writing Rust in production.

Terminal Multiplexers

Tue, 12 May 2026 00:00:00 +0000

This note explores the choice between Zellij and tmux for terminal multiplexing.

Why use a terminal multiplexer?

Terminal multiplexers allow you to run multiple terminal sessions within a single window, detach from them, and reattach later. This is incredibly useful for:

Persistent sessions (e.g., long-running processes continue even if your SSH connection drops).
Organizing multiple tasks (tabs, panes).
Remote development.

Tmux

https://github.com/tmux/tmux

Introduction: tmux is a long-standing and extremely powerful terminal multiplexer. It’s highly configurable and has a vast user base.

Pros:

Mature and stable.
Very flexible and customizable.
Widely adopted, lots of resources and plugins.

Cons:

Configuration can be complex and requires significant effort to set up to personal taste.
Default keybindings can be arcane.
Can feel a bit dated in terms of user experience compared to newer alternatives.

Zellij

https://zellij.dev/

Introduction: Zellij is a newer, more modern terminal workspace and multiplexer, designed with a focus on good defaults and a more intuitive user experience.

Pros:

Modern design and user interface.
Sensible defaults that often require less configuration out of the box.
Built-in layout management.
Rust-based, often praised for performance and safety.

Cons:

Newer, so the ecosystem of plugins and community support is smaller than tmux.
May not have the sheer depth of customization options available in tmux (though this is also a pro for simplicity).

Initial Thoughts / Direction

Given the preference for good defaults and minimal tinkering, Zellij is the stronger contender — modern take on multiplexing without the configuration overhead of tmux.

Current status

Not using either. The setup cost hasn’t been worth it yet — plain terminal, one thing per tab works fine for now.

The main argument for multiplexers is session persistence: if your connection drops or terminal closes, the session keeps running server-side. That matters most when SSHing into remote servers and running things interactively. That pattern is largely avoided here in favour of CI/CD pipelines — if something needs to run remotely, it runs in a pipeline, not in a terminal session.

Working locally with a modern terminal (iTerm2, Wezterm, etc.) that has native tabs and split panes, the marginal gain is genuinely small day-to-day. Rational laziness — the cost-benefit only flips when remote work or session persistence becomes a real part of the workflow.

Will revisit if that assumption changes.

Terminal Setup Notes (macOS): Kitty → Ghostty Exploration

Wed, 06 May 2026 00:00:00 +0000

I’ve been using kitty as my main terminal for a while. It’s fast, stable, and very capable — but I’ve realized I don’t actually enjoy tweaking terminal configs or maintaining a highly customized setup.

So I’m exploring simpler alternatives with good defaults.

Current direction: Ghostty

Trying out: Ghostty
https://ghostty.org/

Why:

Clean macOS-native feel
GPU-accelerated and fast
Tabs + splits built in
Designed for sane defaults (low configuration overhead)
Keyboard-first workflow works well out of the box
My only config change: Remapped tab switching shortcut (default ][ to alt-[/] for easier access on a Swedish keyboard layout).

Goal:
Less time configuring terminal → more time working.

Why the switch

Simplified setup: I found myself spending less time tweaking and more time working.
Perceived responsiveness: Both are fast, but Ghostty felt marginally snappier in heavy-usage scenarios.
Clean design: The aesthetic and functional minimalism resonated more with my current preferences.

What I’m moving away from (for now)

kitty

https://sw.kovidgoyal.net/kitty/

What I liked:

Very fast, GPU-accelerated rendering
Highly configurable via a single kitty.conf
Excellent font rendering — ligatures, custom fonts
Extensible with Kitten modules (tabs, scrollback, multiplexing)
Stable and mature

Why I’m moving on:

Too much customization surface area
I don’t actually enjoy tuning it

Other tools I’ve looked at

Warp

https://warp.dev/

Warp feels like a “terminal reinvented” (more IDE-like, block-based UI, AI features). It’s interesting, but feels a bit too opinionated and visually heavy for my taste.

Other Terminal Emulators (briefly noted)

While Kitty and Ghostty are modern GPU-accelerated terminals, it’s worth acknowledging other terminal emulators that have been foundational or offer different philosophies.

https://www.x.org/releases/X11R7.6/doc/man/man1/xterm.1.xhtml

The classic X Window System terminal emulator. While not as feature-rich or graphically advanced as modern options, xterm (and its derivatives like urxvt, st, etc.) represent the minimalist, highly customizable end of the spectrum. They often prioritize resource efficiency and adherence to traditional Unix principles. Good for when you need something simple and rock-solid, but usually requires more effort to get a pleasant default experience.

Current philosophy

I’m optimizing for:

minimal clutter
fast keyboard workflow
good defaults (not deep config systems)
fewer moving parts

Current setup direction

Terminal: Ghostty
Tabs: built-in (no extra tooling yet)
Multiplexing: not using tmux/Zellij for now
Keeping things intentionally simple

Open question

If Ghostty tabs feel too minimal in real use, I may revisit:

Zellij (for structured sessions)
tmux (unlikely unless necessary)

For now, keeping it simple on purpose.

Bash

Mon, 01 Jan 2024 00:00:00 +0000

Bash is unavoidable in DevOps work — CI/CD pipelines, container entrypoints, system init scripts, and quick automation all end up as shell scripts eventually. Knowing how to write it well saves a lot of pain.

Tooling

Linting: ShellCheck: catches common mistakes and anti-patterns. Run it in CI, or install the IDE plugin. Most of what it flags is genuinely wrong.

IDE: Any editor works. ShellCheck integrations exist for VS Code, IntelliJ, Vim, and most others.

Good habits

Set these at the top of every non-trivial script:

#!/usr/bin/env bash
set -euo pipefail

-e — exit on error
-u — error on unset variables
-o pipefail: catch errors in pipes, not just the last command

Use shellcheck before committing. Most Bash bugs it catches are subtle and only surface under specific conditions in production.

When to reach for Python instead

When the script grows beyond ~50 lines, needs associative arrays, JSON parsing, or HTTP calls — switch to Python. Bash is great glue; it’s a poor application language.

Resources

Go

Mon, 01 Jan 2024 00:00:00 +0000

Go is my go-to language for backend services, CLI tools, and DevOps tooling. The standard library covers most of what you need, the compiler is fast, and the concurrency model (goroutines + channels) makes it well suited for infrastructure-adjacent work.

Tooling

IDE: GoLand: JetBrains’ Go-specific IDE. Solid refactoring, built-in debugger, good test runner integration.

Formatting: gofmt / goimports: no debates about style, just run it.

Linting: golangci-lint: meta-linter that runs a configurable set of linters in one pass. Worth wiring into CI.

Testing

Testing is built into the standard library — go test ./... is all you need to get started. Table-driven tests are the idiomatic pattern for covering multiple cases cleanly.

func TestAdd(t *testing.T) {
 cases := []struct{ a, b, want int }{
 {1, 2, 3},
 {0, 0, 0},
 }
 for _, c := range cases {
 if got := Add(c.a, c.b); got != c.want {
 t.Errorf("Add(%d, %d) = %d, want %d", c.a, c.b, got, c.want)
 }
 }
}

Resources

K9s & Lens

Mon, 01 Jan 2024 00:00:00 +0000

You run everything with kubectl. Get pods, describe, logs, exec, delete, apply — fifty times a day across five namespaces. It works, but every command is a context switch: type, wait, read, type again. -n namespace on every single invocation.

So you use K9s. A terminal UI that shows your entire cluster in one view. Switch namespaces and clusters in a keystroke, tail logs in real time, exec into a pod without constructing the command — everything you reach for in kubectl, but without the friction.

K9s

K9s is a TUI (terminal UI) for Kubernetes. It stays in your terminal, updates live, and is keyboard-driven throughout.

brew install derailed/k9s/k9s
k9s # connect to current context
k9s --context prod # specific context
k9s -n monitoring # start in a specific namespace

Key	Action
`:pod`	Jump to pods view
`:deploy`	Deployments
`:svc`	Services
`:ns`	Switch namespace
`/`	Filter/search
`l`	Logs
`e`	Edit resource YAML
`d`	Describe
`s`	Shell into pod
`ctrl-d`	Delete
`?`	Help / full keybinding list

Most resource types are reachable by typing : followed by the resource name — :configmap, :secret, :ingress, :pvc, and so on.

Why TUI over GUI

K9s lives in the terminal alongside your other tools. No window switching, works over SSH, starts instantly, and the keyboard-driven workflow is faster once it is in muscle memory. For day-to-day cluster work it is the right default.

Lens

Lens is a desktop GUI for Kubernetes — a full IDE-style interface with a visual cluster overview, resource browsing, metrics charts, log streaming, and terminal access built in.

It is the better choice when you need to onboard someone who is not yet comfortable with the terminal, or when you want a visual overview to share with a non-technical stakeholder. For engineers doing operational work all day, K9s is faster.

Worth noting: Lens has moved toward a commercial model (Lens Desktop Pro). OpenLens is the open-source build of the same codebase, without the account requirement.

kubectx / kubens

If K9s is more than you need and you just want to stop typing --context and -n on every command, kubectx and kubens solve exactly that:

kubectx # list contexts
kubectx prod # switch to prod context
kubectx - # switch back to previous context

kubens # list namespaces
kubens monitoring # switch default namespace

No TUI, no GUI — just fast context and namespace switching that persists for the rest of your terminal session. Install alongside K9s; they complement each other.

brew install kubectx

Resources

K9s documentation
K9s GitHub
Lens
OpenLens — open-source Lens build
kubectx/kubens — fast context and namespace switching

Python

Mon, 01 Jan 2024 00:00:00 +0000

Python is my scripting and automation language of choice. I reach for it when Bash starts getting unwieldy — data processing, API interactions, infrastructure automation scripts, and one-off tooling.

2024 note: For anything beyond quick scripts I’m increasingly reaching for Go instead. Better performance, a single compiled binary, and stronger typing make Go a more honest choice for tools that end up running in production. Python still wins for data work and anything where the ecosystem matters (ML, pandas, etc.).

Tooling

IDE: PyCharm: JetBrains’ Python IDE. Good for larger projects. For scripts and smaller work, IntelliJ IDEA with the Python plugin does the job.

Formatting: Black: opinionated formatter, no configuration needed.

Linting: Ruff: extremely fast linter and formatter, replacing Flake8 + isort in most setups.

Dependency management: uv: modern, fast package manager replacing pip/virtualenv for most workflows.

Where I use it

Infrastructure automation and scripting alongside Ansible
Data processing and log analysis
CLI tooling for internal workflows
Quick API clients and integration scripts

Cli on Backend Engineering Strategy Tools

Rust

Where Rust is winning

Tooling

The learning curve

Resources

The trend pattern

Terminal Multiplexers

Why use a terminal multiplexer?

Tmux

Zellij

Initial Thoughts / Direction

Current status

Terminal Setup Notes (macOS): Kitty → Ghostty Exploration

Current direction: Ghostty

Why the switch

What I’m moving away from (for now)

kitty

Other tools I’ve looked at

Warp

Other Terminal Emulators (briefly noted)

xterm (and related TTYs)

Current philosophy

Current setup direction

Open question

Bash

Tooling

Good habits

When to reach for Python instead

Resources

Go

Tooling

Testing

Resources

K9s & Lens

K9s

Navigation

Why TUI over GUI

Lens

kubectx / kubens

Resources

Python

Tooling

Where I use it

Resources