I know that it's a good thing in almost every way that these bugs are being found which used to be left undiscovered, especially security bugs, knowing that state actors probably have a significant stash of them documented and ready to use when needed.
But.
Something's lost in this need for perfection, knowing that every bug will be found quickly and cheaply if not fixed. It tilts the time spent towards security hardening rather than feature development — which I still agree is a _net_ good.
An analogy I find keen is going from living in a safe neighborhood where nothing happens if you forget to lock your back patio before bed, to one where if you ever once forget to lock your back patio, it will be instantly noticed — either by something benevolent, or something malicious¹.
I know this is indisputably "better." But something's lost and something's gained in living every day², and in this case what's lost the ability to be innocent and naive on the Internet with a low likelihood of repercussions. To be clear, there's always a baseline need to be careful, don't leave port 443 open etc, but you could run a simple webserver you wrote up as a toy project without too much concern.
Will the trend towards every gap being found nearly immediately result in better software, a safer world, and overall happier people? I don't think so.
--
¹I saw this analogy somewhere on Hacker News recently, so I don't want to steal credit. I'll update if I come across it.
²Joni Mitchell, "Both Sides Now" (1966). Highly recommend a listen.
> Upon further digging, I discovered that WireServer was maintaining in-memory caches containing unencrypted tenant data, all mixed in the same memory areas, in violation of all hostile multi-tenancy security guidelines.
> It is conceivable that, with a little poking, an attacker could obtain data, including secrets such as certificates, belonging to other tenants on the node.
> Moreover, the code was leaking cached entries and even entire caches due to misunderstood memory ownership rules, and suffered from a large number of crashes, in the order of 300,000 to 500,000 crashes per month for the WireServer web server alone across the fleet.
I came to this conclusion too and felt rather defeated, existential crisis, etc. But the more I thought about it, the more I realized that if we had a country of 250 million unemployed angry folks (many of them armed), I'm not so sure it'd be the wealthy in control.
> But the more I thought about it, the more I realized that if we had a country of 250 million unemployed angry folks (many of them armed), I'm not so sure it'd be the wealthy in control.
It depends on how hard they'll fight, but technology just doesn't seem like it's a force for good anymore. I could imagine that, in the face of a revolt against automation, some fraction of the oligarchs will just establish a Ukraine-war like AI-drone kill-zone to protect their assets. If they do that, they'd probably win.
But it probably wouldn't get to that point, because, given the online nature of culture, AI-powered surveillance and AI-powered social interference could very likely thwart any revolt before it starts.
Even if you disclose to the buyer that it's counterfeit, it's _still_ illegal. You can't just use someone else's name, logo, or protected designs without authorization.
In fact, it's so severe, you can face >= 10 yrs in Federal PMIA prison and owe fines up to $2M — just for the first offense.
Pardon the snark, but they literally wrote an article [1] about giving up on code reviews because they push 30k _changes_ (I assume that means commits, but they don’t clarify), and were bottlenecked on reviews.
Instead, they claim to just review the _intent_ of the PR and presume correctness will be caught by more AI.
To me, the more absurd part is that they’re pushing that much code.
To put it in perspective:
Software # Commits Equiv. Time
--—----- --------- -----------
Nginx 8,758 7h
uv 11,081 9h
Vim 24,608 20h
Go 67,914 2.3d
Git 82,513 2.8d
VS Code 168,140 5.6d
Emacs 183,611 6.1d
Rust 343,063 11.4d
* Equiv time equals the amount of time it would take Anthropic to push that many commits, given their 30k changes/day estimate provided in the article linked below.
It generated some interesting discussions here on hacker news [2] [3].
FYI: The last is a blog post at simonwilliamson.net about the source post, which was flagged appropriately, but I left since it had a few dozen comments as well.
It’s too bad nano doesn’t support LSP [1], it makes it trivial to get IDE-level support for almost all programming languages with one simple JSON-RPC integration.
If I were to build an editor, I’d want the GUI platform-native so would probably go straight for Xcode and Swift.
If I had a strong aversion to Swift, I might consider a hybrid design where the UI is Swift and write a backend in a modern, fast language I prefer (Go/Rust/C# come to mind, but this isn’t a call-to-arms in the language wars). I believe this could be achieved since LSP works well as a backend server supplying IDE-level niceties, so I could keep most functionality implementations there. I’d have to have a strong reason though since Swift is a fine language, and AI does much of the writing now.
Then again, most devs live on a Mac and deploy to Linux, and are increasingly using Agents which may be better off cloud-hosted or at least sandboxed, so lightweight Swift UI and most logic in a headless cli app could be an interesting design choice.
But the important part to me would be low-bloat and native UI, and I’ve never found cross-platform UI frameworks to hold up in practice — even if only because different OSes necessarily have different ideas of idiomatic design, so you’d either be using least common denominator UI components that feel uncanny, or reimplementing the UI for each platform.
Have you found a language / framework combo that’s fast, fits into the OS well, and is _fun_ to write and use? Or is your idea that separate implementations are now so low cost — who cares — let the AI maintain them?
Legitimately asking in good faith, so please don’t interpret anything as snippy in there — it’s just my understanding of the state of the world. I’d genuinely love to learn about how cross-platform options have expanded if I’m missing something!
> If I were to build an editor, I’d want the GUI platform-native so would probably go straight for Xcode and Swift.
That's where we'd diverge. I'm a heavy user of Flutter especially in the age of AI because even if you could have the AI rewrite 6 different version for 6 different platforms, it's just a waste of your own tokens. Rust for desktop is good enough these days, with GPUI or iced, etc.
> lightweight Swift UI and most logic in a headless cli app could be an interesting design choice
With absolutely no hard data to back this claim, my instinct is that a library would be even better. Anything you can manage to fit into a library can be much more easily tested, and then you can define whatever frontends you want (CLI, SwiftUI, etc.) that wrap it, and even leave the door open for people to implement whatever UI they might want.
Depends on the split. You’re probably right — even after worrying about cross-language ABI stuff, compiled libraries would have many advantages.
But especially with Agentic AI, I could imagine some scenarios where being able to run the guts of your editor out of process, e.g. on a cloud box or even a local docker container, being pretty advantageous.
This is how Claude Code GUI works but to be fair that’s less of an editor.
Ok so first off I haven't done this in the agential era myself. In fact, I've made multiple (small/toy-ish) TUIs in the meantime! So I'm something of a hypocrite off the bat lol -- my only excuse is that I'm pretty darn webpilled, AKA the ultimate cross-platform system ;)
That said: I indeed was referring to rust in particular[1], based on some vague recollections that I finally took some time to confirm:
1. There is indeed a host of relatively mature options for the mapping to the boring ol' native route(s): Qt through `cxx-qt`, FLTK via `fltk-rs`, wxWidgets via `wxdragon`, and Tk via... itself, I guess? GTK also has `gtk4-rs` and `relm` and is supposedly cross platform, but with some confusing caveats. See the very end for the other "just build three apps" options, on that note.
2. The most practical option for time-crunched, not-huge projects (IMHO) is anything that lets you still use web languages for styling; obviously this stretches the sense of "GUI", but it's also wildly popular and is still far better than a full Electron monstrosity. Namely: `tauri`(/`yew`/`leptos`) automatically ties into a separate WebView impl per OS, `dioxus` made their own impl to afford React-like rendering goodies, and `ply` seems like a really promising minimalist option. All actively maintained & growing.
3. It seems the default for not-technically-native-but-feels-native apps (i.e. most apps) is `egui`, which does WASM magic for you across platforms and web (!), or `iced` which seems far too Java-y for my tastes. Neither are at v1.0.0, but I blame the abandonment of semver for that goofiness -- both have sizable teams developing in them full time, with ~30k stars each. `slint` is more mature but seems targeted at IoT/embedded.
4. I'll be honest: I was really just hinting at "whatever Zed uses", since the thread's about text editors! It turns out to be `gpui`, their own custom (yet OSS) engine with a popular external metaframework: https://github.com/longbridge/gpui-kit . As above, does WASM wizardry. More niche options that similarly implement their own languages: `xilem`, `freya`, `floem`, and `ribir` are popular growing options with ~beta vibes (i.e. pre-v1.0.0 but, like, for real this time); `vizia` and `cushy` are more alpha vibes.
5. There's a crowd of "GPU-heavy" (?) frameworks that go beyond my capability to really assess in the first place, but `makepad` is the only one that seems definitely cross-platform. `kas`, `blinc`, `tessera`, `azul`, `pax`, `rosin`, and `rui` (nice snag, that) came up too, but are (pre-)alpha vibes. Game-focused ones also exist, somewhat bafflingly (people make games in Rust??): `imgui-rs`, SDL3 via `yakui`, and Bevy via `bevy_egui` all seem mature.
6. As a bonus there's options to just build a Flutter GUI and attach a rust process to its backside via `flutter_rust_bridge` (genius!) and/or (?) `Rinf`. I've never touched Flutter at all, so uhh take that as you will, I suppose.
7. Finally, to your Swift suggestion: I think you're privileging your OSX and/or Swift preference a lot, there. I'm not sure how that even gets to be cross platform based on what I'm seeing right now, but even if it it's possible, all the OSX-specific apps I see these days (RIP Orion...) put fear into the depths of my heart. What Swift would work for is the megacorp strategy: just implementing three separate apps! Via `UniFFI` or `cacao` for Mac, `windows-rs` for DOS, and any of the open ones above for Linux.
TL;DR: I'd go with `tauri` for something tame, and `gpui` for a text editor in particular; regardless of what you choose, I think it's a lot, lot more tractable than you expect!
[1]: After the `bun` debacle turned out shockingly well, I don't think there are "language wars" anymore, just the right tool for the job for the center ~95% of the capabilities/adventerousness bellcurve, so-to-speak. Absent some necessary integration planned in another language and/or extensive experience that you don't want to waste, I think it's just straight up incorrect to pick any "general" systems language (so C, C++, Java?) over rust.
Certainly there are specialized languages that rule in their own arenas --Golang for piping data around, Haskell/LISP/Racket for cool people, Zig for Whatever Zig Does, TS for the web and cloud, Python for science, etc.-- but none of those seem necessary to tie into the GUI.
Honestly, I initially regretted posting my comment because besides a native iPhone app, I've never built GUI software. I did no research of my one and asked a very open-ended question and felt intellectually dishonest and lazy, and almost deleted it.
I'm so glad I didn't.
This comment is one of the most information-dense helpful resources I've read in a long time (and such a welcome reprieve from the "slop"), that anything I did to contribute to its existence was worth it.
Thank you so much for writing this, and I strongly recommend you post this somewhere very public — on your _beautiful_ personal site at the very least, and I'll do my best to spread it around. I've only built an exquisitely designed iPhone app, as the sole eng alongside a great designer, and barely considered anything but native because our brand was very high-end in the startup-of-a-lifetime great way, and we wouldn't settle for anything else.
I forward my catch-all to gmail so I get they're great spam filtering while preserving the ability to switch off of them instantly should I decide to in the future.
reply