Mitchell Hashimoto

Key Insight: Programs already know their own state; OSC 7501 gives them a standard, PTY-native channel to broadcast it—eliminating the heuristic arms race that has emerged around agentic tooling.

Mitchell Hashimoto proposes OSC 7501, a new terminal escape sequence that lets programs report their current status—idle, working, blocked, done, or failed—directly to terminals and other tools. The motivation is that long-running terminal tasks (builds, deployments, coding agents) lack a standard way to communicate state, forcing agentic inbox tools to rely on brittle heuristics like regex-matching spinner characters or proprietary out-of-band socket APIs. OSC 7501 is terminal-native, transmitted over the existing PTY, and therefore works transparently across SSH and containers without extra infrastructure. The protocol is intentionally generic—key=value pairs, no SDK, implementable in a dozen lines of POSIX sh—and supports hierarchical task trees for programs managing multiple concurrent subtasks. Hashimoto has already implemented it in Ghostty and Rex, with proof-of-concepts in Terraform, Claude Code, Codex, and Homebrew.

Key Insight: Ghostty's success as a passion project wasn't a pivot to commercialization but a proof of craft that revealed a deeper unsolved problem worth building a company around.

Mitchell Hashimoto announces Superlogical, a new company he's co-founding after three years of post-HashiCorp life focused on fatherhood, philanthropy, and passion projects. During that period, Ghostty grew from a throwaway personal project into a terminal emulator with millions of daily users, which Mitchell donated to a non-profit to permanently protect its open-source mission. Building Ghostty led him to ask deeper questions about why terminal usage keeps growing and what comes next — questions that pointed toward a company. Superlogical will start by shipping a terminal multiplexer built on libghostty, with a larger vision still undisclosed.

Key Insight: SIMD follows a predictable five-step pattern that any developer can learn, and the performance gains are too significant — and too fragile under compiler auto-vectorization — to leave to chance.

Mitchell Hashimoto argues that SIMD has an undeserved reputation for complexity and should be part of every developer's toolkit. He presents a five-step pattern — broadcast constants, loop by vector width, perform the SIMD operation, reduce the result, scalar tail — that covers the vast majority of common vectorization cases. Using a real loop from Ghostty as a worked example, he shows that 12 extra lines of Zig can yield a 5x real-world throughput improvement. He addresses why compiler auto-vectorization is an unreliable substitute, especially when predictability matters. The conclusion is that developers shouldn't fear SIMD: the common shape is learnable, reusable, and worth knowing.

Key Insight: Disagreeing with a project's specific policies is fully compatible with respecting and funding it — open source's value comes precisely from allowing diverse, even unusual cultures to coexist.

Mitchell Hashimoto announces a $400,000 pledge to the Zig Software Foundation, bringing his family's total commitment to $700,000. He praises Zig's technical progress and its distinctive approach to community and maintainership, including its controversial no-LLM contribution policy. Despite being a heavy AI user who doesn't fully agree with ZSF's stance, he respects their right to set their own culture and standards. He uses the donation as a platform to criticize the toxic, empathy-lacking discourse that erupted around Zig's AI ban and Bun's fork. His core motivation is personal: Ghostty exists because Zig made it possible to build software at the quality level he demanded.

Key Insight: Even the most devoted users will eventually leave a platform when persistent reliability failures make it impossible to do serious work, no matter how deep the emotional attachment.

Mitchell Hashimoto announces that Ghostty, his terminal emulator project, will be leaving GitHub due to persistent reliability issues. He reflects on his deep, 18-year personal connection to GitHub as user #1299, describing it as the place that has made him happiest throughout his life. Despite this emotional attachment, he explains that near-daily outages have made GitHub untenable for serious work, blocking PR reviews and CI pipelines for hours at a time. The move will be incremental, with a read-only mirror kept on GitHub, while his personal projects remain there for now.

Key Insight: Removing hidden C++ ABI dependencies requires both deep toolchain knowledge and, equally important, the human discipline to present large contributions in a way that respects maintainers' time.

Mitchell Hashimoto details his work modifying simdutf, a high-performance Unicode library, to be buildable without libc++ or libc++abi dependencies. This was the final C++ standard library dependency blocking libghostty-vt from being fully portable across embedded, WebAssembly, and freestanding environments. He walks through the technical approach: creating a stl_compat.h shim for standard library types, replacing function-local statics with translation-unit statics to avoid __cxa_guard_acquire, and providing weak symbol shims for __cxa_pure_virtual. He emphasizes preserving ABI compatibility except when the new flag is enabled, and added CI audits to prevent regression. The bulk of the post reflects on the contributor etiquette of submitting a 3,000-line PR, where he spent more time on validation and PR preparation than on the code itself.

Key Insight: In the age of AI-driven software assembly, the highest-leverage strategy is to build high-quality open building blocks rather than polished applications, because agents and developers alike prefer proven components they can glue together.

Mitchell Hashimoto argues that the most effective path to software adoption has shifted from building polished mainline applications to creating high-quality building blocks that others assemble. He illustrates this with Ghostty's growth: the app reached one million daily update checks in 18 months, while libghostty reached multiple millions of daily users in just two months. AI agents are accelerating this shift by excelling at gluing together proven components, lowering the barrier to entry that previously limited the ecosystem. The positives include lower quality bars for derivative works, outsourced R&D, reduced maintenance burden, and greater awareness in niche communities. He acknowledges that closed-source commercial software is at a disadvantage as AI agents prefer open and free alternatives. Rather than fighting or fully submitting to this shift, Hashimoto advocates for pragmatically embracing the building block economy.

Key Insight: Productive AI adoption requires painful deliberate practice to learn what agents can and can't do, then systematically engineering harnesses and verification tools so agents produce correct results autonomously while you focus on the work you actually enjoy.

Mitchell Hashimoto describes his gradual journey from AI skeptic to productive AI user, structured as a six-step progression. He began by abandoning chatbot interfaces in favor of agentic tools, then forced himself through a painful period of reproducing his manual work with agents to build expertise. He discovered efficiency gains by running agents during off-hours, delegating high-confidence tasks while working on other things manually, and engineering 'harnesses' (AGENTS.md files and verification tools) to prevent recurring agent mistakes. His current goal is to always have a background agent running on useful work, though he emphasizes measured adoption over hype and respects others' choices not to use AI at all.

Key Insight: Error cleanup code is paradoxically the most error-prone part of programs because it's rarely tested, and fault injection libraries like Tripwire solve this by making error paths systematically exercisable at zero runtime cost.

Mitchell Hashimoto introduces Tripwire, a Zig library he built for Ghostty that injects failures into code to test error handling paths, specifically errdefer cleanup logic. He explains that errdefer—Zig's mechanism for undoing partial effects when errors occur—is ironically one of the most error-prone parts of Zig programs because error paths are rarely exercised in testing. Tripwire lets developers place named failure points in code that trigger errors during tests but compile to nothing in release builds, using Zig's comptime features for true zero-cost abstraction. By combining Tripwire with Zig's testing allocator, developers can verify that errdefer cleanup actually works correctly by detecting memory leaks when errors are injected. Integrating Tripwire into just a handful of places in Ghostty immediately uncovered roughly six errdefer bugs. He encourages others to copy the single-file, MIT-licensed library into their own projects.

Key Insight: Memory management bugs often hide in optimization code paths that are only exercised under specific conditions, and even comprehensive testing strategies can miss them until real-world usage patterns evolve.

Ghostty had a significant memory leak that caused one user to experience 37 GB of memory consumption after 10 days of uptime. The leak stemmed from a bug in the terminal's PageList memory management system, specifically in a scrollback optimization that reused pages. When non-standard (larger than normal) memory pages were reused during scrollback pruning, their metadata was reset to standard size while the underlying mmap allocation remained large, causing munmap to never be called when freeing them. The bug was particularly triggered by Claude Code's output patterns, which frequently produced multi-codepoint grapheme outputs requiring non-standard pages. The fix simply prevents reusing non-standard pages during scrollback pruning, properly destroying them and allocating fresh standard pages instead.

Key Insight: Critical developer infrastructure like terminal emulators should be governed by non-profit structures that legally bind projects to public benefit, preventing commercial capture while enabling sustainable community funding.

Mitchell Hashimoto announces that Ghostty, his open-source terminal emulator, is now fiscally sponsored by Hack Club, a 501(c)(3) non-profit. This structure ensures Ghostty remains free and open source, prevents any possibility of a 'rug pull' or commercial acquisition, and enables tax-deductible donations. Hashimoto emphasizes that foundational infrastructure like terminals should be stewarded by mission-driven, non-commercial entities. The arrangement includes full financial transparency, contributor compensation, and legal protections. His family is also personally donating $150,000 directly to Hack Club to support their broader mission.

Key Insight: Effective AI-assisted coding requires domain expertise to guide the AI, knowing when to take back control, and never shipping code you don't fully understand.

Mitchell Hashimoto details how he shipped a non-trivial Ghostty feature—unobtrusive macOS update notifications—using AI-assisted coding across 16 sessions costing $15.98. He emphasizes that effective AI use requires domain expertise, careful planning, and treating AI as an assistant rather than replacement. The post walks through his complete process: prototyping UI, hitting walls where AI failed, extensive cleanup sessions, backend development, and simulation testing. He stresses that he always reviews and often rewrites AI-generated code, and that the real value isn't just speed but the ability to make progress while doing other things.

Key Insight: Zig 0.15.1 delivers substantial build time improvements that are already transforming daily development workflows, even before the most impactful optimizations like incremental compilation are fully realized.

Mitchell Hashimoto shares real-world build time improvements after upgrading Ghostty to Zig 0.15.1, demonstrating significant speedups across all build scenarios. The build script compilation dropped from 7 seconds to under 2 seconds, while full uncached builds improved from 41 to 32 seconds. Most impressively, libghostty-vt incremental builds now complete in under a second using Zig's self-hosted backend. These improvements come despite Ghostty still relying on LLVM for most builds and incremental compilation not yet being functional, suggesting even greater gains are coming.

Key Insight: By extracting Ghostty's battle-tested terminal emulation into a zero-dependency embeddable library, libghostty can have far greater industry impact than the standalone application by eliminating redundant, buggy implementations across hundreds of products.

Mitchell Hashimoto announces libghostty, an embeddable library for terminal emulation that he first envisioned over two years ago. The first component, libghostty-vt, will be a zero-dependency library for parsing terminal sequences and maintaining terminal state, extracted from Ghostty's battle-tested core. The post argues that terminal emulation is a deceptively complex problem that hundreds of applications implement poorly with ad-hoc solutions. By providing a correct, fast, and portable C API, libghostty aims to eliminate this duplicated effort across the industry. The Zig API is available now for testing, with a C API coming soon and a stable release targeted within six months.

Key Insight: The emotional experience of using software is an essential requirement that cannot be measured by specifications or demos—creators must live with their work to truly understand its quality.

Hashimoto argues that checking boxes and meeting specifications is insufficient for creating great work. Every interaction with software evokes a feeling in users, and that feeling is as much a part of the requirements as any functional specification. The difference between adequate and exceptional work lies in whether creators actually use and live with what they build. You cannot rely solely on metrics and demos—you must experience your own work to understand how it truly feels.

Key Insight: Technical non-profits fail at fundraising because they treat donations as a passive byproduct of good work rather than an active sales function requiring dedicated effort, clear communication, and genuine human relationships.

Mitchell Hashimoto argues that technical non-profits are significantly worse at fundraising than other charitable organizations, despite having eager potential donors. He identifies key failures: unclear donation methods, poor articulation of value and financial needs, lack of impact reports, and insufficient human connection with donors. The post emphasizes that non-profits are fundamentally sales-driven organizations and must treat donor relations with the same rigor as business development. Hashimoto draws on his experience as both a donor and entrepreneur to provide a concrete roadmap for improvement.

Key Insight: Fighting against a framework's native paradigms creates more problems than it solves—embracing the GObject type system eliminated an entire class of memory bugs and simplified the codebase, while Valgrind verification showed Zig's safety features work well until you hit C API boundaries.

Mitchell Hashimoto describes the complete rewrite of Ghostty's GTK application to fully embrace the GObject type system from Zig, verified with Valgrind throughout. The previous approach of avoiding GObject led to a mess of lifetime management bugs where either Zig or GTK memory would be freed but not both. By embracing GObject's reference counting, features like configuration reloading became conceptually simpler, and the team could adopt modern GTK technologies like Blueprint. The Valgrind verification process revealed that while dozens of memory issues existed at C API boundaries, the Zig codebase itself had only one leak and one undefined memory access—a surprisingly positive result that validates Zig's memory safety features.

Key Insight: The 'code' in 'Infrastructure as Code' was meant to evoke a codified system of rules for inscribing knowledge, not a mandate to apply all the complexity of modern software engineering to configuration.

Mitchell Hashimoto clarifies his personal definition of 'as code' in 'X as Code' terminology, explaining he means 'a system of principles or rules' rather than 'as programming.' As the creator of Terraform, he's often misunderstood on this point. His intent was always about inscribing knowledge—getting it out of people's heads into a shareable, versionable system. While codified knowledge often becomes computer-readable with automation benefits, he argues this doesn't mean all modern programming requirements should apply to 'as code' systems.

Key Insight: Sustainable open source governance comes from matching authority to organic expertise and explicitly removing obligation from volunteer maintainership.

Mitchell Hashimoto announces eight new subsystem maintainers for Ghostty, the terminal emulator project that went public about a month ago but had a two-year private beta. Rather than appointing general core maintainers, Ghostty follows a subsystem model where contributors become authorities over specific areas like terminal emulation, GTK, fonts, rendering, and shell integration. All new maintainers emerged organically from the private beta community, having contributed dozens of PRs and actively helped others. The role grants autonomy to define roadmaps and merge PRs but explicitly carries no obligation to review anything—it's about trust and authority, not work requirements.

Key Insight: What starts as a personal learning project can evolve into something meaningful when you recognize that 'solved problems' often have unexplored tradeoffs worth pursuing.

Mitchell Hashimoto reflects on the release of Ghostty 1.0, a terminal emulator he started in 2022 as a way to learn Zig and graphics programming with no intention of releasing it publicly. What began as a learning project evolved into a serious endeavor when he recognized opportunities for improvement in existing terminals. The controversial private beta, while generating unintended hype and frustration, successfully allowed him to manage his bandwidth during his first year of fatherhood while cultivating an exceptional community of contributors. He remains committed to Ghostty as a passion project, with plans to release a standalone libghostty library in 2025 that could have broader impact on the terminal ecosystem.

Key Insight: A terminal emulator can be fast, feature-rich, and platform-native simultaneously—users just didn't know they were settling for less until they experienced all three together.

Mitchell Hashimoto announces that Ghostty, his terminal emulator project developed over nearly two years with 2,000 private beta testers, will be publicly released as open-source under MIT license in December 2024. The project aims to be the best drop-in replacement for existing terminal emulators by combining speed, rich features, and platform-native GUIs—a combination Hashimoto felt was unnecessarily absent in the market. The extensive private beta allowed him to prioritize family time after his first child while ensuring stability. Beyond 1.0, he envisions libghostty as a cross-platform library enabling a diverse ecosystem of terminal applications, and expanding terminal functionality to make text-based applications more attractive to build and use.

Key Insight: Supporting independent, passion-driven software projects through substantial personal investment can both give back to the community and encourage a culture of building for the love of building.

Mitchell Hashimoto announces a $300,000 personal donation to the Zig Software Foundation, paid in two annual installments. He traces his journey with Zig from following the project in 2019 to becoming an active contributor and building Ghostty in the language. The donation reflects his family's philosophy of supporting independent software projects that embody building for the love of building. He emphasizes Zig's strong management, transparent funding model, and clear path to broader adoption as reasons for the investment.

Key Insight: Zig's comptime enables generating specialized subset types from tagged unions at compile time, providing both type safety and self-documenting APIs without runtime overhead.

Mitchell Hashimoto demonstrates how to use Zig's comptime features to create type-safe subsets of tagged unions, solving a real problem in Ghostty where keybind actions need to be handled separately by terminal and application code. The naive solutions—using catch-all else clauses or explicitly listing ignored cases—either sacrifice compiler safety or result in verbose, poorly self-documenting code. By leveraging comptime type generation with @typeInfo and @Type builtins, he creates a ScopedAction function that generates union types containing only actions belonging to a specific scope. The solution provides compile-time exhaustiveness checking, self-documenting function signatures, and zero runtime cost for the type generation itself.

Key Insight: Zig's comptime eliminates the need for preprocessor languages and complex build systems by allowing conditional compilation to be expressed in standard Zig code that can seamlessly mix compile-time and runtime conditions.

This post explains how Zig's comptime feature enables conditional code compilation using standard Zig syntax rather than preprocessor directives or build system complexity. Hashimoto contrasts this with C's preprocessor macros and Go's build tags, both of which require separate languages or external tooling. The key advantage is that comptime conditions can be mixed with runtime conditions in the same expression, allowing code to reference libraries or types that may not exist in certain build configurations without causing compiler errors. He demonstrates this with a real example from Ghostty that checks both build-time and runtime library versions. The post also covers important gotchas around function boundaries and the need for explicit comptime keywords or inlining.

Key Insight: The venture capital path to working on passion projects is valid but shouldn't be the only option—developers need more sustainable paths to get paid for their work.

Mitchell Hashimoto announces his role as advisor to Polar, a platform helping developers get paid for their passion projects. He reflects on his own journey from 2010-2012 when he built Vagrant while working full-time, eventually leading him to found HashiCorp with venture capital. After leaving HashiCorp in 2023, he's focused on helping 'developers in the small' find sustainable paths beyond the VC route. He emphasizes that he only advises projects he actively uses, and is already using Polar for his terminal project Ghostty.

Key Insight: By exploiting domain-specific constraints unique to terminal emulators—like guaranteed absence of control characters in certain parsing stages—you can achieve correctness and speed simultaneously, often outperforming simpler but less correct implementations.

This devlog details a series of performance optimizations that dramatically improved Ghostty's IO throughput. The improvements include SIMD-based parsing that processes plain text 7-16x faster, precomputed lookup tables for Unicode codepoint width calculation that eliminated 30% of character processing time, and optimized grapheme break detection that runs nearly 8x faster while using less than 1KB of memory. A community contributor also implemented CSI sequence fast-path parsing for control-sequence-heavy applications. The combined optimizations result in Ghostty being faster at reading plain text with full grapheme clustering than most terminals that don't perform grapheme detection at all.

Key Insight: Building a great terminal emulator requires treating it as a genuine application platform, which means investing in developer tooling, internationalization, and rigorous compatibility testing rather than just adding flashy features.

Mitchell Hashimoto provides an update on Ghostty's development, highlighting major new features including a terminal inspector (similar to browser dev tools), improved Asian language input support, custom shader capabilities, and an xterm compatibility audit. The beta testing group has grown from 100 to over 350 people, with stability improving dramatically—beta waves that once caused dozens of bug reports now handle 50+ new testers smoothly. The post emphasizes Ghostty's commitment to being a proper platform for terminal applications while maintaining high performance and compatibility standards.

Key Insight: Terminal emulators and programs must coordinate on character width calculations through standards like mode 2027, because the legacy wcwidth approach fundamentally cannot handle modern Unicode's multi-codepoint graphemes.

Terminal emulators struggle with modern Unicode characters like complex emoji because they traditionally process individual bytes or codepoints rather than grapheme clusters. The farmer emoji '🧑‍🌾' is actually three Unicode codepoints joined together, causing terminals to report widths of 2, 4, 5, or 6 cells depending on implementation. Grapheme clustering—the process of recognizing multiple codepoints as a single user-perceived character—solves this problem but breaks compatibility with existing terminal programs that assume wcwidth behavior. Mode 2027 is a proposed standard that allows programs to opt into grapheme clustering support, enabling terminals and programs to agree on character widths. The author implemented mode 2027 in Ghostty after initially being disappointed that proper grapheme clustering broke fish shell's prompt rendering.

Key Insight: GitHub's fundamental flaw is treating pull requests as mutable entities rather than versioned changesets, causing review feedback to constantly lose its context and making large-scale collaboration unnecessarily painful.

Mitchell Hashimoto argues that GitHub pull requests are fundamentally flawed because they treat branches as single mutable changesets, leading to chaos in code review. The current model causes reviews to become outdated mid-submission, loses context when contributors push changes during review, and makes it impossible to compare different states of a PR effectively. He proposes implementing versioned changesets where each PR version is immutable and feedback is attached to specific versions. This pattern, already proven in tools like Gerrit and Phabricator, would make reviews cleaner, safer, and more scalable for large projects.

Key Insight: Building a proper terminal emulator means not just implementing features correctly, but also discovering and fixing bugs in the broader ecosystem where programs have accumulated bad assumptions over decades.

This devlog covers Ghostty's growth from 30 to 100 beta testers, with waves now adding 15-20 people as stability improves. The post details significant GUI improvements on both macOS and Linux, including native Wayland support. A major technical challenge emerged around terminal identification: Ghostty's attempt to use `TERM=ghostty` instead of `TERM=xterm-ghostty` exposed bugs in Vim and other programs that incorrectly hardcode terminal names rather than querying terminfo. The post also covers implementing XTGETTCAP (a protocol for querying terminal capabilities via escape sequences) using Zig's comptime for compile-time optimization, and adding variable font support—a rare feature among terminal emulators.

Key Insight: By leveraging Zig's comptime capabilities for zero-cost abstractions and platform-specific implementations, you can build software that achieves properties previously thought to be mutually exclusive.

Mitchell Hashimoto introduces Ghostty, a new terminal emulator written from scratch in Zig that aims to be fast, feature-rich, and native all at once—a combination he argues existing terminals fail to achieve. The talk covers the project's architecture, including its cross-platform core with native GUI implementations (Swift/AppKit for macOS, GTK for Linux), and explores several Zig patterns that make this possible. Hashimoto positions Ghostty not just as another terminal, but as a potential modern platform for text application development, analogous to how browsers serve GUI apps. The project was in closed beta at the time of the talk, with plans for a 1.0 FOSS release in 2024.

Key Insight: Building a truly cross-platform terminal emulator requires solving the surprisingly complex problem of keyboard input handling, where the seemingly simple act of pressing a key involves layers of translation between physical scancodes, logical keys, and character output that vary dramatically across keyboard layouts and operating systems.

This devlog covers major progress on Ghostty's keyboard input handling, which required solving the complex problem of supporting non-US keyboard layouts, dead key sequences, and unicode character input across platforms. Mitchell implemented support for multiple keyboard protocols (xterm modified keys, fixterms, and Kitty Keyboard Protocol), making Ghostty one of only a handful of terminals to support all of them. The Linux/GTK experience received significant improvements including single instance mode, primary clipboard support, and automatic shell integration. The post emphasizes how expanding the beta tester pool, particularly to non-US users and Linux users, exposed critical issues that led to these improvements.

Key Insight: Floating-point math in graphics programming can cause subtle rendering bugs that are nearly impossible to reproduce, making integer types the safer choice for screen dimensions and padding values.

This second Ghostty devlog covers two major technical improvements: implementing non-native fullscreen on macOS and fixing a subtle font blurriness bug on Linux. The non-native fullscreen feature required a substantial rewrite, moving from SwiftUI to AppKit for window and app lifecycle management while keeping SwiftUI for views. The Linux font blurriness was caused by a subtle floating-point rounding error in window padding calculations that led to fractional pixel values, which the GPU would round up and then downscale, introducing anti-aliasing blur. The post also announces that Ghostty will be free and open source, likely under GPLv3.

Key Insight: Modern terminal emulators can dramatically improve user experience through shell integration and smart font handling, but these capabilities remain unknown to most developers.

Mitchell Hashimoto introduces the first devlog for Ghostty, a GPU-accelerated terminal emulator he's been building since 2021 using Zig. The post covers the technical stack (Zig, OpenGL/Metal, SwiftUI/GTK) and dives into two recent features: automatic shell integration injection that enables smoother prompt redrawing on resize, and auto-italicization of fonts that lack italic faces. Shell integration allows terminals and shells to communicate for better UX, though most developers don't have it configured. The font feature programmatically skews regular glyphs to create fake italics when the font doesn't provide them natively.

Key Insight: Sustained motivation on large projects comes from optimizing for continuous visible progress through demos and working tests, not from comprehensive planning or building perfect components.

Mitchell Hashimoto shares his methodology for completing large technical projects, centered on maintaining motivation through continuous visible progress. Rather than planning everything upfront or building to perfection, he advocates decomposing projects into small pieces that yield tangible results quickly. Using his terminal emulator as an example, he demonstrates how prioritizing demos over finished components, embracing 'good enough' implementations, and becoming your own first user creates a sustainable feedback loop. The approach acknowledges that perfectionism often derails projects, and that seeing working code—even imperfect code—is what keeps engineers engaged over months of development.

Key Insight: Building truly native cross-platform applications is achievable by leveraging C ABI compatibility and decades-old system tooling, allowing 90%+ code sharing while delivering platform-native experiences.

Mitchell Hashimoto explains how to build truly native cross-platform GUIs by writing business logic in a systems language like Zig and platform-specific UI code separately. His terminal emulator achieves 93% shared Zig code with only 4% macOS-specific Swift code. The post walks through the technical pipeline: exporting C APIs from Zig, building static libraries, creating universal binaries with libtool and lipo, packaging as xcframeworks, and integrating with XCode. While the process involves many steps, each relies on decades-old, stable tooling that's unlikely to break. He also explains why Objective-C isn't viable—Apple's future is clearly Swift and SwiftUI.

Key Insight: Prompt engineering is most valuable when treating language models as transactional APIs for objective tasks, not as conversational partners for creative or subjective work.

Mitchell Hashimoto distinguishes between two modes of using language models: interactive prompting (conversational, human-driven) and transactional prompting (function-like, software-driven at scale). He argues that prompt engineering primarily benefits transactional use cases where objective correctness can be measured. The post adds another dimension—objectivity vs. subjectivity—noting that prompt engineering works best for tasks with objectively correct outputs like classification or information extraction. For subjective creative tasks, arriving at good prompts is more creative writing than engineering. Hashimoto concludes that both modes exist without invalidating each other, and that agents, despite being automated interactive processes, are transactional in nature and benefit from prompt engineering.

Key Insight: The compounding benefits of using Nix across all environments—not just Docker—transform it from being harder than plain Dockerfiles to being dramatically easier while eliminating entire categories of 'works on my machine' problems.

Mitchell Hashimoto advocates for using Nix alongside traditional Dockerfiles to solve the persistent problem of inconsistent environments across development, CI, and production. The approach uses Nix as a single source of truth for building software, then leverages multi-stage Docker builds to create minimal final images. While Dockerfiles alone are simple, they create duplicated effort and brittle configurations when combined with separate local dev and CI setups. The key insight is that Nix's benefits compound when the same configuration powers all environments, eliminating 'works on my machine' issues entirely.

Key Insight: Prompt engineering becomes real engineering when you apply systematic testing, measurement, and cost-accuracy tradeoffs rather than relying on trial-and-error intuition.

Mitchell Hashimoto argues that prompt engineering is a legitimate engineering discipline, distinct from what he calls 'blind prompting'—the crude trial-and-error approach most people use. He demonstrates a systematic methodology: define the problem, create a demonstration set with expected inputs/outputs, generate multiple prompt candidates, test them for accuracy across different approaches (zero-shot, few-shot), and choose based on cost-accuracy tradeoffs. The key insight is treating prompts like any other engineering artifact—with testing, measurement, and continuous improvement based on real-world failures.

Key Insight: AI's staying power comes not from revolutionary replacement but from evolutionary improvement—it makes existing software better while opening new possibilities, the same pattern that enabled cloud computing's industry-wide adoption.

Mitchell Hashimoto analyzes the current AI/LLM moment through the lens of cloud computing's rise, arguing that AI shares the same hallmarks of a genuine platform shift. Like early AWS, AI provides immediate practical value while remaining impractical for many enterprise contexts—a gap that will close over time. He predicts AI will force an evolution in software properties similar to 'cloud-native,' where products that adapt will outcompete those that don't. Crucially, AI has a migration story: it makes existing software better rather than requiring wholesale replacement, which historically enables industry-wide adoption.

Key Insight: Business banking relationships are not transactional utilities but human relationships with real stakes, and treating them otherwise can have unintended consequences for everyone involved.

Mitchell Hashimoto recounts his naive approach to business banking as a 22-year-old startup founder, from opening a Chase account with $20,000 to managing $35 million four years later. He repeatedly ignored his banker Alex's calls, not understanding the significance of their relationship, then abruptly transferred all funds to Silicon Valley Bank without warning. Years later he discovered he had become a cautionary tale at Chase branches across Los Angeles, learned that Alex had faced consequences, and had to navigate a surreal process to close the forgotten account and withdraw $1M via cashier's check. The story culminates in his recognition that banks aren't fungible and relationships matter, even if no lasting harm came from his choices.

Key Insight: Complex projects become approachable through a disciplined progression: use it, build it, trace features without understanding, learn from the inside out, practice on real commits, then contribute small changes to learn the human process.

Mitchell Hashimoto presents a systematic five-step approach to understanding and contributing to complex software projects. The methodology begins with becoming a genuine user who builds something real, then learning to build the project from source before attempting to read code. The core learning technique is 'trace down, learn up'—following a feature's code path from outside to inside, then understanding components from innermost to outermost. The process concludes with studying recent commits as practice problems and making an initial small contribution to learn the human side of the project. Throughout, Hashimoto emphasizes joining the community, experimenting by breaking things, and avoiding the trap of trying to understand everything at once.

Key Insight: The Zig build system's apparent magic dissolves when you understand it's just compiling your build.zig into an executable—and knowing this internal structure makes you a more effective user of the tool.

This post provides a deep dive into how Zig's built-in build system works internally. The key insight is that `zig build` actually compiles twice: first it compiles the `build.zig` file into a standalone build binary, then that binary orchestrates the actual project compilation by spawning subprocesses to the Zig compiler. The post walks through the entire pipeline, from how the build runner is located to how steps are defined declaratively and executed in dependency order. Mitchell demonstrates how to manually build and invoke the build binary to demystify the process, emphasizing that understanding these internals makes developers more productive.

Key Insight: Zig's semantic analysis stage is where comptime magic happens - transforming untyped intermediate representation into fully-typed AIR while evaluating compile-time expressions and emulating target platform properties.

This technical deep-dive explains how the Zig compiler's Sema (semantic analysis) stage transforms ZIR (Zig Intermediate Representation) into AIR (Analyzed Intermediate Representation). The post details how AIR is a fully-typed representation where comptime evaluation occurs, enabling generic types to be realized and compile-time optimizations to be performed. Through detailed code examples, Hashimoto walks through the anatomy of AIR instructions, the Value/Type/TypedValue system, and traces the step-by-step analysis of a simple addition function. The article demonstrates how comptime evaluation can pre-compute results and how the compiler handles both comptime-known and runtime values differently.

Key Insight: Understanding compiler internals becomes manageable when you start with the simplest constructs and recursively build up complexity, mirroring how the compiler itself processes code.

This technical deep-dive explains how the Zig compiler converts its Abstract Syntax Tree (AST) into Zig Intermediate Representation (ZIR) through a stage called AstGen. ZIR is an untyped intermediate format that breaks program logic into fine-grained instructions, preparing code for comptime evaluation and further semantic analysis. The post meticulously covers ZIR instruction anatomy, including how references work, extra data encoding, and the role of scopes and string interning. It concludes by walking through progressively complex examples—from integer literals to addition to variable assignment—demonstrating how the recursive generation process builds up ZIR from simpler components.

Key Insight: Zig's parser achieves significant performance gains through data-oriented design, using MultiArrayList and indirect references that sacrifice code simplicity for memory efficiency and cache locality—a pattern that pervades the entire compiler.

This post provides a deep technical dive into how the Zig compiler's parser transforms tokens into an abstract syntax tree. The parser heavily uses MultiArrayList, a data structure that stores each struct field in a separate contiguous array, reducing memory waste from alignment and improving cache locality. AST nodes use a compact representation where data can reference the token stream, other nodes, or an extra_data array, with the meaning of each field determined by the node's tag. The parser uses a recursive descent approach, eating tokens and building up nodes while attempting to continue parsing through errors. This data-oriented design pattern is reused throughout the compiler pipeline.

Key Insight: A well-designed tokenizer maintains strict separation of concerns—it converts bytes to tokens without allocations or semantic validation, leaving meaning-making entirely to the parser.

This post explains how the Zig programming language's tokenizer works as the first step in the compiler pipeline. The tokenizer converts source code bytes into a stream of tokens without performing any heap allocations, operating on slices rather than streams. Each token consists of a tag (one of ~120 types) and a location (start/end indices into the source). The implementation uses a state machine that examines one character at a time, switching between states until it unambiguously determines each token. Importantly, tokenizers don't handle semantics—they'll happily tokenize nonsensical code, leaving validation to the parser.

Key Insight: VMware dramatically outperforms VirtualBox for shared folder reads, NFS excels at reads but fails at writes, and hypervisors gain performance by lying about write synchronization—making the choice of filesystem mechanism critical for development environment performance.

Mitchell Hashimoto presents comprehensive benchmarks comparing filesystem performance across different virtual machine configurations, focusing on VirtualBox, VMware, and NFS shared folders. The analysis reveals that VMware shared folders dramatically outperform VirtualBox for reads (sometimes by 70x), while NFS provides excellent read performance but terrible write performance due to network overhead. Interestingly, virtual machine filesystems often outperform the host machine's native filesystem because hypervisors buffer operations and lie about synced writes. The practical takeaway is to use NFS when possible for read-heavy workloads, move database files out of shared folders, and recognize that VMware's read performance advantage matters more than VirtualBox's marginal write advantage for typical development work.

Key Insight: A single portable template that generates identical machine images across multiple platforms closes the gap between infrastructure-as-code ideals and practical DevOps workflows.

Mitchell Hashimoto announces Packer, an open source tool for creating machine images across multiple platforms from a single template. Packer addresses the gap between powerful machine image concepts and the tooling needed for modern cloud workflows. The tool can generate AMIs, VirtualBox images, and Vagrant boxes in parallel, enabling use cases like continuous delivery pipelines and synchronized production/development environments. While version 0.1 has limitations, Hashimoto draws parallels to Vagrant's early days, expressing confidence the project will grow with community involvement.

Key Insight: The ideal developer tool should be invisible - it does its job perfectly while the developer remains focused on their actual work, not the tooling.

This post introduces the 'Tao of Vagrant' - a philosophy for using Vagrant to create consistent, reproducible development environments. Developers can check out any repository, run 'vagrant up', and have a fully functional environment without manual setup. The same automation scripts used in development are also used in production, ensuring parity between environments. The workflow is transferable across projects and companies, eliminating 'works on my machine' bugs.

Key Insight: The most successful technologists often discover their defining obsession early—for Hashimoto, every project from Neopets bots to HashiCorp followed the same core drive: eliminating manual work through software.

Mitchell Hashimoto reflects on his career trajectory and realizes that automation has been his driving passion from the very beginning. Starting with cheating at Neopets as a kid, he progressed through automating ad clicks for money, college course registration, and eventually created Vagrant and founded HashiCorp. Each project followed the same pattern: identifying tedious manual processes and building software to eliminate them. He concludes that automation isn't just what he does—it defines who he is.

Key Insight: Developer tools should optimize for the actual user base rather than the original community, and controlling the full dependency stack enables both reliability and the freedom to make improvements users benefit from without noticing.

Mitchell Hashimoto explains why Vagrant 1.1+ abandoned RubyGems in favor of pre-made installers and packages. The decision was driven by three factors: most Vagrant users aren't Ruby developers and found RubyGems installation burdensome, dependency mismatches caused bugs that were perceived as Vagrant instability, and bundling dependencies gave him flexibility to swap in better libraries without user friction. By controlling the entire environment, he could replace slow pure-Ruby implementations with high-performance C libraries like libarchive and cURL. The change ultimately made Vagrant more accessible, stable, and performant for its growing user base.

Key Insight: Treating every customer interaction with genuine care and solving problems at their root—not just addressing symptoms—is what separates successful products from failed ones.

Mitchell Hashimoto explains how the APPLE customer service framework he learned as an Apple Store employee became foundational to his entrepreneurial success. The acronym guides interactions through warm approach, polite probing, presenting solutions, listening, and fond farewells. He demonstrates the principle through a real support email exchange where instead of dismissing a canceling customer, he engaged genuinely, fixed the underlying product issue, and invited them back. This philosophy helped him build three successful projects including the one that funded HashiCorp and Vagrant.

Key Insight: The people you surround yourself with fundamentally reshape what you believe is possible, and deliberately choosing those people is one of the most powerful decisions you can make.

Mitchell Hashimoto introduces the concept of the 'new normal' - the phenomenon where your perception of what's normal shifts based on the people you surround yourself with, fundamentally changing your ambitions and likelihood of success. He traces four pivotal moments in his life: accidentally joining an online BBS community of game hackers at age 12, receiving a job opportunity through his open source work, deliberately choosing to move to San Francisco, and gaining the confidence to start HashiCorp. The essay argues that these shifts in normality can happen through serendipity, opportunity, deliberate choice, or confidence-building. He emphasizes that actively seeking a new normal can steer your life in unexpected directions.