I'm not sure what the take-home of this message is since you can replace "AI" with just about anything... "If you use a keyboard to do your work, you can be replaced by someone else using a keyboard to do your work." Sure? You can always be replaced by someone/something that can do your job better.
A keyboard doesn't "do" the work. In other words, the more work you outsource to AI, the lower your value-add becomes, the easier your are to replace by someone doing the same thing for cheaper.
I'm not convinced by this. I've had good managers and bad managers. Generally the manager isn't "doing the work", so much as setting the direction and smoothing the path. The current state of AI tools still need "good managers" to set the direction, otherwise they end up nowhere. Especially in large complex projects.
Maybe at some point the AI tooling will be good enough for me to say "do my work for me today" and sit back. At that point, yes, I am irrelevant and could be replaced by anyone else. But is it anywhere close to that right now? My experience says no.
Perhaps the current models are capable of that with the right tooling - some system to define clear goals and stick to them. I haven't seen evidence of that yet though. Have other people?
I’d reframe it: you won’t be replaced by someone using AI, you’ll be replaced by someone who is better at using AI and understands the code it generates
Over the last couple of years, I’ve seen plenty of developers who remain barely competent despite having access to powerful AI tools. Generating code is easy. Evaluating whether it’s actually correct and maintainable is the hard part.
>you’ll be replaced by someone who is better at using AI
I place very little value in the idea of "getting better at using AI". It's like getting better at using a library, or getting better at using Google. Now that LLMs are widely available, their entire intent is to make it significantly easier to access information held in a truly vast body of written work.
I have also seen no evidence that understanding the resulting generated code is necessary.
If your job has a large component of regurgitating existing information, you are now competing with a machine that can regurgitate hugely more information and with lower-skilled operators.
If Ai can generate code, review code, validate correctness, understand reqs, make architectural tradeoffs, operate systems, and take responsibility for outcomes, then we're no longer talking about replacing programmers. We’re talking about replacing most knowledge workers
At that point the debate isn’t really about software engineering anymore
> > Evaluating whether it’s actually correct and maintainable is the hard part.
> But AI can also do that.
Citation needed.
> So, what’s the point?
The point is that there haven't been broad demonstrations of your claim.
> And if you think it can’t, wait one more year
You surely must understand that this isn't an argument? How many hundreds of billions have been burned through now? Yet we still have to suffer "soon" as an argument? I can't take any of this seriously anymore.
PS: Just to be absolutely sure you don't misunderstand me: I am NOT claiming that AI will never be able to do this stuff. Nor am I even claiming that it's too far off or too expensive. Just, for the love of god, you cannot build an industry on promises of how amazing it'll be in the future. Technology is evaluated based on how it performs. Not how you think it might perform in the future.
PPS: The last paragraph does also not mean that I think it's bad to invest in things that haven't yet paid off. On the contrary! What I am saying is you cannot claim success until there's success!
Right. If you were previously digging with your bare hands, and one day everyone starts turning up with these new-fangled shovels, you'll find that both your hand-digging skills are not needed, and that hole production may exceed demand.
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.
reply