soasme

We're still so small but I'm loving the team we've got at Superlogical. They're so talented and kind and love their craft. It's a different era of software development and our expectations and practices reflect that. I want to share a bit about how we work. First, everyone is trusted to push to main. We do machine-aided code review pre-push and human plus more machine-aided code review post-push. Limited to no PRs. Culturally, we've all agreed that if we ever hire someone who we DON'T trust to push directly to main, then they probably aren't the right fit for the team (so far, not an issue). Some common sense here: if someone is stepping outside their lane or comfort zone, we'll open PRs. For example, I'm pretty trash at macOS/iOS UI, so I'll open PRs for UI-affecting functionality and ask for eyeballs/help. But for business logic and internals, I push to main. Second, everyone can cut a release. Our release process is fully automated and when you start a release (for any platform) it triggers a Slack notification and a 15 minute countdown. The 15 minute warning is a final gate that allows people to review plus collaborate on a changelog. During that 15 minutes, anyone in the company can pause the release rollout. After 15 minutes, the train leaves the station. You can't override the 15 minutes (except to pause). It gives everyone a chance to step in. Third, we avoid synchronization through fast remediation rather than through planning. The server and clients on various platforms ship features as fast as they can. We use post-hoc human review and AI-assistance to identify feature mismatches across products ("Windows has support for X and Mac doesn't." or "Mac and Windows differ in their behaviors for Y in this way."). This avoids expensive "sync" meetings and coordination. We trust that producers of features are mindful of what they're producing and we trust that adjacent product lines will self-synchronize quickly. In practice, we see feature parity across platforms within 24 to 48 hours. All of this works on mutual trust. It ONLY works with mutual trust. Everyone at all times has to trust that they've got each others back: 1. Push to main only works if you fix your mess, or if you don't, that someone else will quickly but that you'd do the same (and generally in equal amounts). 2. Anyone can deploy only works if you trust everyone to cut at the right time, with the right changelog, and that people will respect the 15 minute timer. 3. Sync through fast remediation only works if you trust other teams will pick up and integrate your work quickly, which only works if you would too. It also only works if you are fairly producing mismatches (e.g. not constantly). We've got a great team. I know we're still small and that these practices will change in many ways as we scale. But this is already a markedly different practice than what I would've done 15 years ago. In general, we are building from day 1 on a foundation of mutual respect, excellence, and trust. And it's been awesome.

libghostty 1.0 is here! I started Ghostty ~5yrs ago to work towards this. Today, libghostty is in hundreds of projects used by tens of millions of people. 1.0 marks ABI stability, quality, and an invite for distros to begin packaging. mitchellh.com/writing/libgho… Since starting the Ghostty project in 2022, the most common question I've been asked is "why?". Today, I'll answer this by showing the broad industry impact libghostty has already had. On top of JetBrains and Neovim already mentioned (that alone being over 10 million users): -KDE developers are experimenting with a Konsole replacement built on it. - Vercel's Turborepo uses it to render task output in its TUI. - devenv uses it to drive shells. - Antithesis used it to fuzz TUI programs and found real bugs in btop and others. -Ghostel brings it to Emacs. - ghostty-web is the WASM build with an Xterm.js-compatible API. - Commercial products like OrbStack embed it. - And a whole wave of new terminals and "agentic" coding tools, such as herdr and cmux, have been built on it rather than writing yet another emulator. There are community bindings for Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart, Java, and more, and the awesome-libghostty list tracks well over a hundred projects. More people today use a terminal powered by libghostty than use Ghostty the application, by a very large multiple. And libghostty is having a much larger impact than being "just" a terminal emulator. I'm excited to see where people take it from here.