I’d say that is not a strong point in this case. The code was specifically migrated almost as is, there are Rust and Zig files side by side, doing the same thing. All the workflows, logic, organization is the same.
I’m not saying this AI vibe-coded rewrite was right, but there is some logic to the way it was done. They can continue on the Rust codebase while keeping the knowledge about the Zig codebase.
Honestly this is it. I think every programmer and manager must understand this.
At this point I personally feel that the discussion has ran it’s course.
Perhaps time to lock this topic
Agree I don’t think they have a language problem, I think they have an engineering problem. Which is a shame because they are all probably very good developers, but they don’t seem to take the care and consideration to make something that isn’t borked, and while rust might patch a few things, I doubt it will bring the benefits they expect, because poor engineering isn’t fixed by language.
* Runtime crashes are better than bugs.
* Compile errors are better than runtime crashes.
I generally agree with this part of Zig Zen but I personally think it’s ideal if the baby isn’t totally thrown out with the bathwater. For example, if I have a program that’s a document editor with a “send as email” button, and an assertion fails as part of that send email flow, I’d rather the user not lose their entire document, have to restart the editor, etc etc. But I also don’t want the the assertion failing to allow the program to keep running along in some broken state.
This is one of the things I love so much about Elixir/Erlang and the BEAM. For the “send email” flow, I can handle the happy path, the expected errors, and if the state of that subsystem doesn’t match any of my expectations, just that part of the system can crash and restart in a known good state.
My favorite in here:
Jarred has proven to be an incredibly capable individual… You see he is back to putting in hours upon hours and pulling all nighters
Uh, this is NOT a good sign.
Yeah, what’s telling is that there is an obvious and sane approach to take here.
For the sake of argument, let’s assume that Rust is a good fit for their goals AND that LLMs are well suited for converting Zig to Rust. Even assuming that, anyone in their right mind would still migrate code incrementally and over many smaller releases, focusing on keeping the system in a working state the whole time.
I’m not surprised that a lot of people don’t have the long term motivation, patience, and attention span to do this anymore.
Btw. they hid most of the memes and critique as low quality or off topic.
Me personally, i dont blame them, since its non technical conversation on a GitHub issue.
I leave that to each owns interpretation, however I think they might be regretting this “promotion stunt”, neither Rust, Zig, JS nor OSS community seems happy about this, only place i “heard” they are collecting praise is on vibe coding communities. Mabye thats the 4D Anthropic move?
Just to be clear, the reason i think its just a “promotion stunt” is not because I drink pure Zig koolaid. I believe that Rust can make a lot more sense for Bun after being acquired by Anthropic which possess ton of Rust developers. But the whole lets let LLMs rewrite it all, is the reason i call BS on this. If the goal was to migrate to Rust, this is NOT the maintainable way.
Or I am wrong and Claude/Mythos will prove we are outdated in current dev space.
Robert
You can structure your Zig program like this too.
What you described is reached in Erlang by breaking up a program into multiple supervised processes where communication is then done by sending messages.
Erlang gives you quite a lot of QoL features to make this easy.
In Zig you would need to build some of the things (supervisor, IPC) yourself, but you can do that too.
What is preventing a single threaded reactor as an implementation of the Io backend?
Quite frankly, I don’t like doing this, but I have a prediction:
If they can get the whole mess controlled to a point where the (dogmatic) Rust community is satisfied (which includes massively lowering the amounts of unsafe calls) in the matter of a year, I think that the days of programs, which aren’t mostly vibe-coded, are numbered.
You can.
The implementation would just return error.ConcurrencyUnavailable on some things (since it’s single threaded), but at it’s core it would likely map to std.Io.Batch or std.Io.Select with an evented std.Io implementation.
Agree. But you need good developers to correct the errors from AI. When none will do that, it will be more difficult as expected.
That’s what I mean. Maybe they hoped the rust community would contribute enthusiastically. However, at least so far, that does not seem to be the case.
new Io does not support such mode
This is off-topic in this thread, but you are wrong. Zio is an single-threaded reactor, and at the same time a std.Io backend.
Great!!!
So I can implement single-threaded reactor on new std.Io
Do you have some advice/reference to start?
TIA
No, you can implement std.Io as an single-threaded reactor (the reactor is Io’s backend), the other way around.
OK - so i should implement own Io ?
The way I see it, you should always expect your program to crash (whether it be a panic, the OOM killer, a power loss) and make sure the user doesn’t lose their data (or only loses their changes from the last few seconds). Once you design your application around this, a crash on assertion failure suddenly is much less problematic. Of course you still don’t want this to happen too often, so you should be quick to fix it once a user reports a crash.
Not really. Erlang guarantees strong isolation even in presence of bugs, and that’s a runtime thing you can’t layer on top of something. If a Zig program panics, that aborts the process. This makes Zig completely unsuitable for fine grained recovery from bugs, unless you pop one level up and do multi OS-process architecture or place Zig itself inside a VM, a-la lunatic. At this point, that isn’t that much different from implementing BEAM in Zig and just running Erlang directly.
If a Rust or Go program panics, that panic unwinds the stack can be caught at some boundary. But if it outright crashes (abort in something like take_mut or a race on double pointer in Go), the crash is global. Similarly, if it enters while (true) {} loop its game over, you can’t kill a thread/goroutine from the outside. And even in the panic case, you can easily end up with corrupted data.
Erlang’s runtime gives you per-process heap, which makes non-cooperative forced cancellation well-defined.