jon

literally anyone can ship quickly if they sacrifice reliability. it’s not in any way impressive.

My only advice to CEOs this year.. Hire tinkerers. Make it high status. Find ones that will explore the edges and (ideally) naturally gifted at teaching people. Empower them to freely roam across the org and fix large problems that can be automated. All your execs will complain that these tinkerers don’t understand scale or systems (rollout being a favorite word). Listen, and ignore them. Or even better give them budget to hire a tinkerer to achieve their targets. Give these tinkerers ambition, purpose and hard targets and watch them fly.

Okay, I'm in a bit of a sentimental mood (it's those Sunday evenings, man), but here's one thing that I keep thinking about: I wish we all would respond to the loss that some programmers feel right now with a bit more grace. Some reactions can come across as "it's always been about shipping, dummy" or "huh-duh it's never been about the code, always the results". And that feels a bit deaf, doesn't it? I mean, let's be honest, for many of us it's been about more than that. Lots of programmers — myself included! — feel a great amount of joy when they see (or even better: write) the perfect line of code, where abstraction and syntax and semantics meet and hug and everything comes together. We travelled to meetups and conferences and had hour long conversations with strangers about favorite styles of writing code, about keyboards, colorschemes, keybindings, syntactic flourishes, ways to comment code, cherished parts of standard libs, beautiful ways to rewrite a function that we've all written. I know a guy who said he makes life decisions based on whether he gets to work with a certain programming language more or less. Digesting the fact that things are changing and that some things we cherished might be replaced by other things — that takes a different amount of time for different people.

The lack of "feature design" is why so many products over time feel hollow or messy. This isn't visual design. This isn't architectural design. I thought that a short video lecture of what feature design is and a real case study of applying it in Ghostty would be helpful. Feature design is the planning step behind how you're going to solve one or more user problems with a product feature: what that feature looks like, how it feels, and not just how its going to tactically solve these specific problems, but how that solution is going to interface with the edges of other features that currently exist or are planned to exist in the future.

@fatih I ran into the same issue and fixed it by replacing `super+1` with `super+digit1` etc. reference commit: #diff-73f90304a1cc7ac6132ae8e69d966be7e4e7e585f615c2ccc5b48ec7af777197R19-R28" target="_blank" rel="nofollow noopener">github.com/jonlinkens/dot…

This is a solid upgrade. I think 1.3 will the version I can ditch Tmux entirely . Until then though I need to emulate certain commands. But somehow my super+1, super+2, etc keybindings stopped working. All others are working fine. Searched the issues with no luck.

wrote a benchmarking TUI for measuring execution times and performance of shell commands phrase detection, live output stream with scrollback, cross-platform and more github.com/jonlinkens/chr…

I read this article about software development, which I knew about because I saw Prime reacting to it: notashelf.dev/posts/curse-of… For the most part I think it is fine: a relatively young programmer is doing the healthy work of introspecting on what he should really be doing. But there's one part of the article that I think is a deep mistake, and the author doesn't know it's so wrong because he has never experienced the alternative: "Software doesn’t stay solved. Every solution you write starts to rot the moment it exists. Not now, not later, but eventually. Libraries deprecate. APIs change. Performance regressions creep in. Your once-perfect tool breaks silently because libfoo.so is now libfoo.so.2. 2 I have had scripts silently fail because a website changed its HTML layout. I have had configuration formats break because of upstream version bumps. I have had Docker containers die because Alpine Linux rotated a mirror URL. In each case, the immediate emotional response was not just inconvenience but something that moreso resembles guilt." Yes, this is true in much of the programming world. But there is another world in which people build things that last much longer. I have done it many times. I shipped a binary for this game Braid in 2009 that you can still download and play on Steam 16 years later. If you are pretty young (like 35), you can run binaries on Windows that were compiled before you were even born, which is amazing given how hard they have been trying to f up Windows lately. On an emulator like MAME, you can play arcade games programmed in 1979. If today's software "technology" is so much better, why does it fall apart like tissue paper? The author is not wrong about the cited decay. But this decay is not inherent to the practice of software. It's due to choices made, usually foolishly, by the people designing the systems being interacted with. And, it's due to a lack of knowing better, non-exposure to the sector of programmers who are very concerned with their code lasting a long time, actually. The way you make code last a long time is you minimize dependencies that are likely to change and, to the extent you must take such dependencies, you minimize the contact surface between your program and those dependencies. The actual algorithms you program, the actual functioning machinery you build, is a mathematical object defined by the semantics of your programming language, and mathematical objects are eternal, they will last far longer than your human life. The goal then is to avoid introducing decay into the system. You must build an oasis of peace that is insulated from this constant bombardment of horrible decisions, and only hesitantly interface into the outside world. This means, for example: If you are shipping on iOS, you only reluctantly use any functions iOS gives you, because when you use them, Tim Apple will come along and break your program next year for arbitrary pointless reasons, because Tim Apple does not respect you or anyone you know. This means a program cannot last forever on iOS, because Tim Apple likes breaking your things and watching you submissively clean them up. But the core of your program, which could be 95% of the code, is fine, and you can deploy it elsewhere. This means you have to insulate from Linux userspace, because of all the jackass decision making that introduces constant incompatibilities while somehow never making the system better. Using a library dependency to do font rendering or sparse matrix math? That dependency gets checked into your source tree, a copy of exactly the version you use. Ten years later you can pull down that source and recompile, and it works, because your program is a mathematical object. If you want to upgrade to something newer that has bug fixes and so forth, you are free to do so, but you are also free not to do so, and your program still works. (And how many of these bug fixes do you really need? Your program worked correctly when you shipped it to the greatest extent you could measure, because you are a skillful software engineer who wants to ship things of a high quality). Everyone who got into programming for the joy of it knows, at some level, that the magic of programs is that they represent complexity that is replicable over time (and thus they exist outside of time). But the trashy programmer culture of the past 20 years stopped aspiring to this, and now has forgotten it is even possible. And so long as people have forgotten, decisions will continue to be made that make the problem worse. There are programmers who only write glue code, and who think that's what programming is; to these people what I have written above will not make sense. But the good news for that contingent is, they can always just stop writing glue code and start doing something else! If today's software "technology" is so good, why do you think it needs so much glue? Maybe there is a stylistic problem. So if you are looking for what to do in the world of software that can represent a lasting contribution, maybe this is food for thought. @NotAShelf @ThePrimeagen

@wailsapp super satisfying seeing the token output update live

quickly hooked this up to a test frontend (using @wailsapp) to test, now time to map tokens -> elements to create a live preview end goal is a markdown notetaking app where I roll everything myself, from parsing to storage

wrote a markdown lexer/serializer in go after watching a rob pike talk did this over a few weekends - it can tokenize + serialize a 2000 line file in ~3ms some very messy code: github.com/jonlinkens/go-…

ghostty.org 👻

As promised, here's the best publicly available version of Facebook's Little Red Book Over 2.7k people asked for the link, and I don’t have time to send it out individually—so please share Enjoy! Will link the PDF below 👇

New blog post: Ghostty 1.0 is Coming [in December]. I restate the broader goals of the project and the specific goals for the 1.0. I have ambitious plans, but also set clear expectations for what to expect on day one versus what will come in the future. mitchellh.com/writing/ghostt…

new 2 minute rant: how optimising software is _always_ about tradeoffs

new terminal is dialed 🧘‍♂️

github.com/nikitabobko/Ae… gets very close to the hyprland experience (minus animations), just missing the alternating spiral layout - which seems to be planned. most promising so far!

new bike, built up everything myself trying out a 1x12 ali groupset will see if it's race worthy soon 🫡

jenkins

going from a linux wm to mac is painful yes yabai works but what if you cant disable SIP 🥲

@trashh_dev but you did review it