I'm pretty sure they'll miss the full developer salary that Oven used to sponsor them, which they no longer do.
I'd wager one doesn't do a rewrite like that, if you are in great personal standing with the language foundation.
That same "just don't use it" attitude was what drove me away from Zig btw. I would have been fine in restricting myself to a somewhat stable subset, e.g. if, loop + function calls, but they didn't want to provide any tiered stability guarantees for the language.
Opinionated is great, no local minima is great, but you have to accept that if you don't want to engage with the needs of your (professional) community then what you do is a hobby project. A very cool hobby project beloved by thousands, but a hobby project.
I'm not expecting the whole language to be stable, but I expect certain parts of it to be more stable than others. E.g. control flow vs. async.
I'm not saying that they can't work that way, more power to them. But then having the expectation of anybody using it in a professional setting is also unrealistic. You can't have your cake and eat it too, either it's your personal project and you are fine with nobody using it but you, or you evangelise for people to use it, but then you also need to make at least some effort to not break their stuff on a whim, or to accept their change requests when they put in the work as was apparently the case for bun.
Tbh I don't see Zig hit 1.0 with a meaningful user-base, it's probably going to mostly get eaten by Rust or some other language and will continue to exist as a niche thing, kinda like D.
Having one of the flagship/showcase codebases rewritten to Rust in a week feels like a death knell. Either the community or the language is too unworkable if someone that heavily invested into it jumps ship, and I'm afraid it's kinda both.
Having tried both, I think Zig is a replacement for C, while Rust is a replacement for C++.
One thing Zig has that lots of "niche" languages don't is that you can include C headers directly. This means if you want to make a game in SDL, for example, you don't need to wait until someone ports SDL to your new language. You can just include SDL.h directly and start using it. D also has this feature, by the way, but Rust requires you to generate the bindings.
Even if people move from Zig to Rust for some things or vice-versa, the strengths of Zig remain there.
I know these strengths, I've written Zig fulltime for ~1 year before switching to Rust, and I do miss comptime pretty much every day.
Still in my experience the strengths do not outweigh the weaknesses.
I'd also push back on the narrative that Rust is not a C replacement. For one because that characterization based on surface level syntactic similarities misses the point of WHY you'd want to have a C replacement in the first place. And also because if this whole situation has shown anything it's that if you want to generate the "extern C" boilerplate in Rust, then these days it requires little more than "hey claude/codex please write the imports for this C library" or even "please port this C library to Rust".
It's actually baffling that Github struggles to load a 1000 comments. It can't even load a single one it seems like. It just straight up silently fails. How is this a thing in 2026?
It's also a recipe for failure for ports in general. Same goes for the "not idiomatic Rust" comments above — that would be nonsense.
You want to port it as faithfully as possible to the original, porting it bug-for-bug, quirk-for-quirk. Then, over time, after the port has been proven to be as identical to the original as possible, you can gradually fix those kinds of internals.
That's why TypeScript's tsgo native port is so good.
tsgo will inherit many benefits from go, even if it is never fully "idiomatic".
This is in direct contrast to this port, which requires significant re-architecting (or made "idiomatic", if you wish) in rust to achieve any of the benefits of the language. You can't re-architect one step at a time.
I don't think you want to achieve any benefits of Rust in the initial port. Because at this scale you will definitely introduce new, and probably subtle, bugs that are not present in the Zig version.
You just want it to be the same, to the maximum extent the language allows. E.g. 1000+ unsafe is the right move, for now.
Reaping the benefits of Rust is for _future_ development.
To be very frank, nothing in the blog post is ground-breaking or interesting enough to be on HN. The only thing it has is its (probably knowingly) controversial title, and as such, I have no problem directing technical and nit-picking ire at it.
For starters, I'm talking about @Ferret7446's post, so I don't know why you are talking for them.
Still, if the lack of something of note was the main issue, just say that. Nitpicks like these are only informative to people who doesn't know how computers work. They can serve as fun tongue-in-cheeks, but that was seemingly not the intention here.
As it stands, in my eyes, this just a small fun project. How is the title even controversial? Because it has "Rust?"
Given the current state of battery technology, this is probably the only possible commercial use case. Even then, you have serious limitations like low passenger capacity, takeoff/landing still requires a helipad, recharge time, and the questionable safety in the event of motor or hinge malfunction.
And once this gets in use improvements will lead to bigger, longer range, etc etc etc. Batteries too are rapidly improving and this will push more emphasis on that. The first Write flyer couldn't do much either.
This isn’t meant to slot into the role of other planes, though, it’s meant for rideshare. It can take off and land on my suburban lawn. There’s a lot to figure out before we can get to that point, so they’re just displace helicopters for the moment, but it can be a lot more. It’s basically the long awaited flying car, in nascent form.
No, it can't take off and land on your suburban lawn. The wires and trees overhead would make that ridiculously dangerous, a last resort only for emergencies. Plus they need to recharge for the next flight. These e-VTOL aircraft will operate from dedicated pads.
Just talking about what they've talked about as goals in interviews. And I'm surprised you're willing to make definitive statements about my lawn, we have a large enough area with none of those obstructions you're talking about, we live on a few acres. And if it's running 20 miles here and there, it can do a few trips before it needs to go somewhere to charge or battery swap. That would cover our trip to our nearest international airport.
If these e-VTOL aircraft get used for air taxi service at all it's going to be for short hops in denser urban areas. Not in rural areas where people have acres of open land.
Go watch one of JoeBen's interviews. His original inspiration for the company was making something that could make where he grew up in the redwoods of the Santa Cruz mountains more accessible. His stated long term vision is vertiports embedded in communities. In the short term, I agree that they're going to start in denser areas.
Heh it doesn't have to be literally on one's own lawn, it could just be a little helipad per community. And my understanding is that the vast majority of private helipads don't have air traffic control - your hospital's roof doesn't have its own air traffic control. Pilots operate under "see and avoid" rules.
Use your imagination a little. So much status quo bias here.
Who would want to privately own a community helipad? Sounds like an insurance and liability nightmare.
This is an impressive enough achievement, but let's not kid ourselves this is going to revolutionaise suburban or semi-rural transport. Its maximum payload weight (450kg) barely covers 5 passengers with no baggage. It's for hopping from the country club to the golf course.
