It’s really hard to come up with better conditions for an open-source project than what libghostty has. I’m pretty sure it will be the last terminal emulator at this point.
Most people are in some way constrained in their AI usage, be it a session/week limit or the token pricing. So while you now can definitely build apps on your own you couldn’t before, you still have to make some economic considerations like before: My company is still not in the business of building terminal emulators. Even if an agent takes on the majority of the work to build one for me, I still have to invest some time and focus into directing it where I want it to go; it’s using up a big chunk of my usage limits if I want something anywhere near as polished as ghostty; and like all software, it wants permanent maintenance, bug fixes, and updates. AI doesn’t change any of that.
It’s time for the industry to realize that the weights may have shifted toward build vs. buy, but the general SaaS calculus is still in effect.
wow. Even today, all the modal interface options for emacs feel too slow for my fingers. Maybe a different terminal root will fix that? I should reinvestigate.
You can literally type that question into any search engine or LLM. Don't challenge me like we're on a school bus. I'm a die-hard vimmer, been hjkl-ming for 17 years. I don't mince my modes here.
The whole app is so incredibly satisfying and feels polished, down to every last button and animation. Buttery smooth, feels completely native. Better than some first-party macOS apps IMHO.
Just to reiterate to anyone reading this and being skeptical; it’s 10000000% better than what most apps give you in terms of affordances for allowing permissions in a Mac app.
Does this mean Apple might nuke those capabilities next year? It would not surprise me, but for right now, it’s really freaking good what they managed to put together.
It’s worth downloading the beta just to study their onboarding flow.
I suspect Ghostty is to Rex what Chromium is to Google Chrome (without all the negative connotations that is, I’m a happy Rex user!): both something of a tech demo for libghostty, and an open source, basic-but-fully-featured terminal emulator. Rex, then, will possibly be a paid product at some point, and adds features like the server, agent integration, and persistent session management on top.
If you had asked me two years ago if I was ready to pay for my terminal and quit my jetbrains subscription, I’d have laughed. Now I’m earnestly ready for that if Superlogical were to announce a paid plan.
It comes down to the question of if it provides enough value over other competing products (which may be free or lower cost) to justify the price. If you sell 10$ widgets that solve $100 problems, you may wonder why nobody is buying your $10 widget when it "provides so much value" and it is because a $1 widget solves the same problem just as well.
Note, I am deliberately using a generic example, I use Ghostty but I haven't tried Rex yet and I have no idea how much value it provides over competing widgets)
yeah, that's true. but I would say with dev tools and such, people might easily fork over $10 if they think it's nice
I'd say the whole "lower cost" thing is less of a problem when it comes to ergonomics, we know that many devs buy all kinds of fancy split keyboards and things like that to make their workflow smoother, so I wouldn't be surprised if people easily forked over money to this
question is if it will actually take off or actually provide/slot into workflows that people actually like etc. if it's heavily opinionated or not really innovative, I don't see how people would "move over"
Sure, but then again, Superlogical is a company and as such surely will create a commercial product at some point. I would be surprised if that wouldn’t pertain to Rex in some way.
Incredible that we’re now at the point of needing to say “without all the negative connotations” when comparing against any sort Google product. LOL. I see this often.
I don’t understand these kinds of strong emotions async python triggers in some people. It reminds me of the irrational hate towards systemd in the Linux world.
This is a platform for running workflows distributed on multiple machines, sometimes long-running and with lots of IO. Every single contender in the space advertises the same code, from temporal to hatchet to dagster. Because it makes sense to write it this way.
I also don't quite get your complaint... asyncio provides a high-level concurrency primitive with coroutines, and that's a good enough primitive for workflow engines. Even with asyncio you could fork/spawn processes easily with aiomultiprocess[1], if you'd ever want or need to.
What's your use case for having more low-level concurrency primitives (threads/processes) available, having to deal with their synchronization, and running workflows sync?
No such thing is typically necessary. If modeled correctly, the need for synchronization is minimal.
With sync code, tasks run on different threads/interpreters/processes. Message passing via queues is used to communicate which tasks need to run. Many asyncio users seem to wholly unaware of how well it works. Go-lang doesn't even have or need async.
I actually like asyncio; I am just not a religious zealot about it as many here seem to be, also without awareness of the struggles they face with loop-hogging coroutines and multicore parallelism.
I do manage more than a handful of machines, and that means using automation tools and IaC as much as possible, while avoiding humans using shells as much as possible. I’m struggling to enumerate a lot of use cases for a bespoke sudo configuration that shouldn’t be a proper setup.
Right, I thought the same. Construct it such that a Lemming falling down from the top will have to clear every level to the bottom instead of just falling past all of them.
reply