The bun rewrite is looked to as proof that this sort of full-throttle
vibecoding is the future of software development, at least for large porting projects like this one, and for many people on this site that is a high stakes question.
To prove that, a proper release is needed, and the Bun community needs to adopt it. There's a huge partisan eagerness to declare the Claude Code release or anecdotal experiences on the canary as victory, but the viability of 1.4 hasn't been demonstrated until it has been released and adopted by the bulk of the community.
There isn't actually any hurry on that. Nobody needs Bun 1.4 tomorrow. It's Jarred that keeps saying it'll be released tomorrow, while the code churns at an astonishing rate (see below). People with a skeptical outlook will inevitably suspect that he doesn't have confidence in the release and is struggling to acquire it.
Github insights for the last week:
> Excluding merges, 57 authors have pushed 349 commits to main and 6892 commits to all branches.
> On main, 2026 files have changed and there have been 189,502 additions and 133,836 deletions
Sure but that’s how you beta test a runtime, by using it in a codebase you control. Claude is publicly released and used widely, that’s still only a single codebase
So they are being more cautious and spending more time on polish after a never been done before historical massive rewrite...? Stop the press! They are not shipping as fast they used to! Omg!
> So they are being more cautious and spending more time on polish after a never been done before historical massive rewrite...?
That's not credible at all. I mean, after a major release there are tons of low-priority low-hanging fruit issues that can be quickly sorted out. That's the nature of a release process.
However, Bun stopped releasing anything. Even after lauding it's AI push,which can easily chomp through small tickets.
It's been a couple of months since the major push. I repeat: the release cadence of a mature, stable codebase as the Zig one was at 2-3 weeks. A messy rust rewrite packed with unsafe code, which is prime ground for small bugfixes and correctness fixes, led the project to grind to a halt.
Not surprising, but Jarred has been teasing "tomorrow I swear" for months and Bun keeps missing his own deadlines.
There's clearly something wrong in their confidence about Rust Bun: If it isn't ready they should have said "whenever it's done", and if it is they'd have met some deadline by now. I suspect the speed was supposed to be part of the stunt, yet they seem to have encountered the 90:90 rule.
The rewrite was a lot faster. Actually shaking out the bugs from the rewrite (or just getting enough confidence in the new version from use by early adopters) is probably not going to be drastically faster.
Yeah. That worked before when most villages had a doctor or a clinic. In France (and my native country too) at least the situation is getting bad. You can look up medical deserts.
Driving to another part also often implies having someone to drive you.
This. I have a colleague living in Orleans. It's a city of a little more than 100k inhabits. She apparently has a hard enough time getting a doctor's appointment that she'd rather come to Paris.
If you live further out in the countryside, it can be a real PITA to find someone.
For real, after being on wireless earbuds for quite some time and going back to wired, it is absolutely incredible how many things the cords get caught on. Even just your own hands!
I ask because I find Apple's wired EarPods to be less... selective than AirPods are—by that I mean they'll pick up more background noise whereas AirPods seem to only transmit my voice—but EarPods' clarity exceeds AirPods if you grab the mic and hold it next to your mouth, which you obviously can't do with AirPods.
Regarding the "joke on the web", there's plenty of HN threads about Flutter where you will see this sentiment, not only about performance, also about UX (e.g. text rendering, selection, scrolling...).
I'm not sure if the web render engine has gotten better since then, and am too lazy to look up the links rn, but threads should be easy to find using HN search.
Still seems like a common source language + GUI toolkit that targets the web platform and various native platforms (mainly Android, iOS, macOS, Windows, and desktop Linux of course) without significant overhead has not been achieved yet. And it's questionable whether it's possible, given the special requirements (and capabilities) of the web platform and the different native platform.
Dioxus Native supports both web and native platforms because they serve HTML and CSS for the web and then on native they turn that into canvas rendered code just like Flutter, not a webview, because they built their own HTML and CSS renderer.
For Flutter web, yes as it's canvas based it doesn't have all the same web features but generally for crud apps it doesn't much matter, especially if it's near zero effort taking your Flutter mobile and desktop app and putting it on the web. With the new impeller renderer and Wasm improvements it has gotten quite faster too.
In my experience performance is about the same as native on mobile. On desktop I cannot compare as I thankfully never had to make cross platform desktop apps using native platform SDKs, but Flutter is doing fine. I am a working on a non trivial desktop app, and I am pretty happy about it.
Hopefully the desktop story is going improve as Canonical is now leading the Flutter desktop side.
I'm working on an app that's cross-platform on mobile devices. I do builds for macOS as a convenience for my colleagues demoing the app. Pretty much zero effort to add that as a target. I get some benefits out of it too in the form of being able to see how well the UI responds to unusual screen dimensions, running in a resizable window.
I have successfully added AppFunctions on Android to a Flutter app. I figure that's about as hairy a platform-specific feature as it gets. So far nothing has interfered with other platform build targets. I look forward to adding Apple's agentic tool calling interface, too.
Google lost the opportunity to actually make it take off, had they replaced the Java stack with Dart, instead of staying in the Java world and adopt Kotlin.
However the Android team was never a great supporter from Dart in first place, hence why you won't find anything Dart on https://developer.android.com.
Google uses Flutter/Dart for their own apps fairly frequently. Obviously not the right choice for the most complex apps. Android system programming and cross platform apps are use cases that are divergent enough that trying to smash them together would result in nobody being happy about the outcome.
Google never pushed Go, the UNIX/Plan 9 and Oberon folks did, as means to avoid doing C++, with support of their line managers as their 20% project.
Kubernetes was originally written in Java, and Docker in Python, it was thanks to early Go advocacy, that those projects got rewritten in Go, and then they got lucky.
Just like the download server rewrite into Go, that was done by someone from Go team, as part of their advocacy.
Check how many public projects does Google do, outside anything related to CNCF project landscape.
> Cloudflare Durable Objects really is generous, not often can you get replicated database and realtime sync for such low barrier in cost and implementation.
BEAM gives it to you for free, and you don't rely on an Internet-scale monopoly to run it.
I love the BEAM and programmed on it for many years, but it really does not provide anything like durable objects.
1) It's very difficult to ensure globally serialized ownership with strong consistency in a distributed Erlang cluster when nodes are allowed to fail. Stuff like Horde will let you do some rough "run an instance of this process somewhere in the cluster", but it's eventually consistent (you may have multiple instances at times) and doesn't deal with netsplits well.
2) Mnesia is fine to replicate state within a network switch or very reliable LAN, but not over WLAN/Internet. It can enter split brain conditions and require external reconciliation. RabbitMQ suffered from Mnesia problems for many years and ended up replacing it with their own DB implementation using the Raft protocol.
See these are things I did not know. This is why I said I was 'not qualified', in the post, haha. I do use Horde for the matchmaking. I have 2 hosts in the cluster.
