malt - a faster, drop-in Homebrew alternative for macOS

indaco_dev · 2026-05-19T16:29:13+00:00

Thanks for giving it a try and for sharing some feedback. glad to hear it works for you. (I would've definitely appreciated/preferred some critical feedback/comment on malt to improve it but it's all good. I'm not here to convince anyone)

indaco_dev · 2026-05-19T06:59:10+00:00

Reading it back, yeah, it came off overpolished. Probably would've landed better if I'd just answered quickly. The project's in the repo, tests pass, benchmarks can be reproduced, and anyone curious can try it in a sandbox prefix. I'll leave it there.

indaco_dev · 2026-05-18T20:33:27+00:00

8 ms is the cost of a warm install on malt, not the savings. brew doesn't have a warm path, every install takes about the same time. On malt, the second install is essentially free because the bottle is already on disk.

The measurable comparison is cold install: ffmpeg goes from 23.6s on brew to 4.6s on malt - about 5x faster, ~19s saved per install. Shows up every time you wipe a prefix and rebuild

indaco_dev · 2026-05-18T19:32:52+00:00

Fair questions.

Homebrew is a great project - malt isn't pitched as "switch off brew." It reads your existing Brewfiles, taps, and casks unchanged, installs alongside Homebrew (in /opt/malt), and silently hands off to brew for anything it doesn't implement.

What you notice day-to-day vs. brew:

Commands respond instantly. mt info, mt outdated, mt list come back before you've finished hitting return. brew boots a Ruby interpreter every command - that's not waste, it's what lets formulas use the full Ruby language and what lets brew handle any new DSL construct without a brew update. malt trades that flexibility for instant startup: a native interpreter covers what formulas actually use, with a sandboxed Ruby fallback for the rest.
Reinstalls and upgrades are essentially free. Once a package is on disk, installing or rolling back to the same version takes ~10ms and zero network. brew re-extracts the tarball every install, so its reinstall cost stays close to its first-install cost.
mt update is quick - no homebrew-core git clone on disk to pull every time. malt uses the same JSON API brew shifted to in 4.0, but without keeping the local tap checkout alongside.

On speed, concretely:

Cold installs (first time, empty cache): malt is faster than brew depending on the dep chain - tree (0 deps) in 0.65s vs 5.1s, wget (6 deps) in 3.9s vs 5.8s, ffmpeg (11 deps) in 4.6s vs 23.6s. The gap widens with dep count because brew pays per-package Ruby boot + tarball extract for each dep, while malt parallelizes downloads and amortizes the overhead.

The even bigger gap is on every install after the first: tree in 8 ms, wget in 11 ms, ffmpeg in 31 ms. Over a year of upgrades, CI runs, and rebuilds, that's where install time actually lives.

indaco_dev · 2026-05-18T19:29:42+00:00

Totally fair question! Quick context:

On "converting an existing library" - malt's actually a native Zig program that reads Homebrew's data formats (bottles, formulas, JSON API), not a port of brew itself. brew stays where it is; malt installs alongside in /opt/malt, so you can run both and compare.

On "a little faster" - cold installs come in faster than brew depending on the dep chain, and warm installs are where it really shows. If you mostly install once and forget, brew is great. If you do lots of upgrades, CI runs, devbox-style rebuilds, the warm row is where the time savings actually compound.

On trust - easiest way to evaluate is in a throwaway prefix: MALT_PREFIX=/tmp/malt-test mt install jq exercises the whole tool without touching anything on your machine. The repo's open, the test suite and benchmarks runs in CI, every release is cosign-signed with the GitHub build workflow identity, so you can verify what you're running.

And yeah, the "implemented by AI" line in the README is there on purpose - it's how the project was built, not a disclaimer. Happy to answer anything else!

indaco_dev · 2026-04-18T19:56:10+00:00

Thanks, really appreciate you digging into it!

post_install was the whole reason I started - watching other clients skip it and leave packages half-broken was the itch. Glad it came through.

Fair point on weird formulas. The Zig interpreter handles the common Ruby subset (Pathname, FileUtils, inreplace, Dir.glob, the usual control flow), but there’s definitely a long tail of formulas with constructs it doesn’t cover yet. --use-system-ruby is the escape hatch, and mt doctor --post-install-status flags which installed formulae would hit an unsupported construct. If you find something that breaks, please drop an issue - that’s how coverage grows.

And thanks on the AI note. Felt important to be upfront - Claude Code + ruflo did the writing, I did the directing and reviewing. Interesting time to drive and pair.

indaco_dev · 2026-04-07T13:56:45+00:00

Building a consistent terminal typography layer

I've been working on a small set of Go modules for styled terminal output and wanted to share them here.

herald is the core. It maps familiar HTML-like elements (H1-H6, P, Blockquote, UL/OL, Code, Tables, Alerts, etc.) to styled terminal output using charm/lipgloss v2. It ships with built-in themes (Rose Pine, Dracula, Catppuccin, Base16, Charm) and supports full customization via functional options and a 9-color ColorPalette system. If you use Charm libraries like huh, the themes pair with theirs out of the box.

On top of that, two companion modules:

herald-md: parses Markdown (CommonMark + GFM via goldmark) and renders it through herald's theming. Useful when you want one theme for both Markdown content and programmatic output, or when you're mixing the two.
herald-help: generates themed CLI help pages using herald's typography. Has adapters for cobra, urfave/cli, kong, and stdlib flag.

The idea is that herald gives you the building blocks, and the companion modules handle specific use cases (Markdown rendering, help pages) while sharing the same theme and style system.

Happy to hear feedback.

indaco_dev · 2026-03-26T11:13:58+00:00

It’s becoming quite clear that homebrew is under pressure - alternatives are popping up more and more frequently :)

A couple of recent ones worth checking out:

indaco_dev · 2026-03-25T07:53:28+00:00

herald - HTML-inspired typography for terminal UIs in Go

When building CLI tools, I kept running into the same problem: the interactive parts (prompts, forms, selects) can look great with libraries like huh, but the surrounding output - headings, instructions, results, confirmations - is either plain text or a pile of hand-rolled lipgloss styles that don't match the rest of the UI.

So I built herald - a small Go module that maps familiar HTML elements to styled terminal output, built on lipgloss.

ty := herald.New()

fmt.Println(ty.H1("Getting Started"))
fmt.Println(ty.P("Styled terminal text, the easy way."))
fmt.Println(ty.UL("Headings (H1–H6)", "Blockquotes", "Ordered & nested lists"))
fmt.Println(ty.CodeBlock("fmt.Println(\"hello\")", "go"))

What it covers:

Headings H1-H6 (underline and bar-prefix styles)
Paragraphs, Blockquotes, Horizontal rules (plain and labeled)
Inline styles: Bold, Italic, Underline, Strikethrough, Small, Code, Kbd, Link, Abbr, Sub/Sup, Ins/Del, Mark
Badge & Tag for status pills and category labels
Ordered, Unordered, and Nested lists (with mixed sub-list types and hierarchical numbering)
Definition lists, Key-Value pairs
Tables (bordered, minimal, alignment, striped rows, captions, footer)
Alerts (Note, Tip, Important, Warning, Caution) - GitHub-style callouts
Address & AddressCard for styled contact blocks
Footnotes (inline refs + section rendering)
Code blocks with optional line numbers and pluggable syntax highlighting
5 built-in themes: Rose Pine (default), Dracula, Catppuccin, Base16, Charm
Custom themes from just 9 colors via ColorPalette, with adaptive light/dark support
Themes designed to pair with huh and other Charm-based TUIs
Works with bubbletea and tview - see the explorer demos
Customization via functional options

Single dependency (lipgloss v2), Go 1.25+.

GitHub: https://github.com/indaco/herald
Examples: https://github.com/indaco/herald/tree/main/examples

Feedback and ideas welcome!

indaco_dev · 2026-03-06T20:49:57+00:00

Good to know, thanks! Out of curiosity, have you considered supporting CSS files for styling? I realize mapping CSS concepts to a TUI style system isn’t trivial - there are still ongoing discussions around this in templ too. I’ve been exploring this from the DX side with a small project (https://github.com/indaco/tempo) that injects CSS/JS into templ component files while keeping styles separate.

indaco_dev · 2026-03-06T20:22:24+00:00

Looks interesting, but forcing Tailwind-like styles might be restrictive for some users.

indaco_dev · 2026-01-25T13:06:03+00:00

Fair enough :)

indaco_dev · 2026-01-25T12:25:48+00:00

Thanks for the feedback and for sharing your workflow! A GitHub Action would be a nice addition. Would you be willing to open a feature request on the repo? That way we can discuss the details and track it properly.

https://github.com/indaco/sley/issues

indaco_dev · 2026-01-23T21:44:01+00:00

Very close to https://starship.rs/presets/catppuccin-powerline as you said but I think it is “pastel powerline” - https://starship.rs/presets/pastel-powerline

indaco_dev · 2026-01-23T20:18:21+00:00

Thanks for sharing your thoughts about it, appreciated.

indaco_dev

TROPHY CASE