yes but afaik it defaults to this behavior, allow_assert is defined here
In my opinion the only reasonable approach when you have falsifiable asserts that the test suite doesn’t cover, and that you can’t figure out how to trip, is to make ReleaseSafe builds and use those to get actionable bug reports.
And then more in general software meant to be exposed on the internet (such as a node replacement) should probably not ship ReleaseFast, especially when it’s so full of bugs.
This needs more than a pinch of “it depends” and “know what you are doing”, but “always” asserts also have their place: The Use Of assert() In SQLite
(to clarify, this statement has zero bits of information related to Bun, and deals exclusively with design space around assertions 
)
I mean, if users are able to trip those asserts, but you can’t, what other solution do you suggest other than giving them a build that can then provide you with a repro?
There are two problems here:
My thrust here is that the second problem exists, and that “make falsified assertions not actually crash the default build of the program deliver to users” sometimes can be a legitimate part of the solution there.
For the first one, my ideal normal-style approach is actually telemetry on pre-releases — as much as people like to hate on telemetry (for different and valid reasons), getting a database of backtraces when stuff crashes is invaluable. (tiger style approach is to treat any “user hit a bug” situation as a “bug in the fuzzer”).
I can see the point in general terms, but I’m having trouble coming up with a concrete example.
That said, I will 100% accept the criticism that I made a universal statement while thinking mainly about the Bun usecase.
Actually as I’m typing this I’m realizing that an example could be a videogame where a falsified assert means that some secondary thing (an non-key item for example) stops working and that’s it. As you try to figure out the bug it would make sense to temporarily turn off the assert so that people don’t lose game progress if they try to interact with that thing. Although in this context it would probably still be better to cut a bit above the rot (i.e. remove or replace the item) because even if the disabled assert won’t induce UB, by construction your understanding is not complete enough to really know what else that issue could enable (e.g. in a game it could turn out that the bug can leveraged to duplicate other items).
In Bun’s case specifically (feel free to skip this part :^)) this is not what happened though, the setting still defaults to silencing asserts in release-fast, and afaik it’s been like this for a long time.
I think this is more of a difference in philosophy.
While yes, you should have a testsuite which covers pretty much everything (which applies to you), it’s also very hard to actually test that in every possible edge case.
After all, weird and unexpected cases exist and thinking of every possible case with software you ship to users is imo impractical.
So one has to instead look at the possible outcomes of the assertion being wrong and either crashing or not crashing, and depending on the problem domain one or the other can be the right answer.
This discussion essentially boils down to the same one the C++ community had about contracts and if they should be recoverable, not recoverable and when they should be on or off. And different industries all answered differently and is the reason why you can chose the strategy for every compilation unit independently of the optimisation level.
In my opinion that does go for every kind of software which has network access, even ones which have provably no bugs.
Yeah! I think the example that SQLite devs have in mind is similar, but worse: at some point, somewhere, there will be (an extremely poorly and irresponsibly designed) self-driving car whose self-driving component will live in the same process as the component that uses SQLite database to serve the adds to the “driver”, and it would be bad for a crash in this secondary SQLite database to bring down the whole safety critical process. SQLite is embeddable, which means that people might embed it into places where such things shouldn’t be embedded, but that’s not something SQLite devs can control.
A direct-experience example is rust-analyzer. It’s not problem at all if completion list misses some particularly crazy item, or a niche refactor isn’t shown in the menu for a tricky file. In contrast, if the whole thing crashes on you, it can be pretty painful. So we have three modes in rust-analyzer:
Though, this setup is a product of me treating rust-analyzer as an experiment for the eventual goal of refactoring rustc in place. If I new that it’ll be a long-lived project, I’d invest way more time into building a smith and making sure there are no bugs.
It’s not that Bun put Zig on the map — it’s Zig that built the foundation for Bun.
The new code is fraught with issues. Posting just this one from the list. Grab popcorn and your fav beverage and enjoy:
Going back to ignoring those PR stunts.
But I understand that the earlier zig bun code was full of errors, segfaults, etc, too, and thus in for a change anyway?
The whole bun repository feels dystopian. Bots talking to each other and making absolutely insane PRs. For example Android aarch64 binary killed by SIGSYS (seccomp) on close_range syscall · Issue #30766 · oven-sh/bun · GitHub
My thoughts exactly - it was a PR stunt from the very beginning
problem solved! 
Lol, yolo! 
Man, this mess backfires even for Rust’s reputation.
I don’t feel very comfortable with the direction of this discussion.
(of course, you can say: don’t participate.)
It was Bun’s decision or their big boss—it doesn’t really matter.
The Bun developers will have to work hard to solve all these problems
As developers, we understand very well how they feel right now
Let’s just say to them: “Good luck with your hard work.”
Let’s return to Zig and continue solving our own problems
As Jarred himself wrote, it’s nothing but AI bots at work now. I highly doubt they have feelings.
I am extremely glad for Bun and this rewrite, because it will provide a solid data point about vibe coding. I suspect the resulting code is / will be unmaintainable crap, and it seems it was already crap for a while now (“no humans involved”).
Perhaps I am 100% wrong and Bun (vibe-coded in zig and vibe-migrated to Rust) will become the most successful project ever – that would truly be the end of an era. I am hoping it is exactly the opposite (and if that’s the case, that this will somehow not be hidden behind an impenetrable corporate shield).
We’ll see. Interesting times (in both senses – I would rather not be living them, to be honest).
To hopefully turn this discussion to something productive and constructive, I have the following observation.
It has been common knowledge in software engineering that re-writes and language re-writes are not to be taken lightly. However I think the mistake is that the caution against re-writes overemphasizes the cost in developer time for little to no visible benefit. i.e When you do a re-write you spend a lot of money on developers to get a product that works the same as the old, but is just written in a different language.
However I think that is the wrong point of emphasis. The cost being prohibitive was useful to sway people away from doing it. But the cost wasn’t the reason to not do it in the first place. The problem with re-writes is that it risks a lot of loss in knowledge when you do one.
In other words, software development is more than just writing code, (F.P Brooks says that’s accidental complexity). The core is the decisions made around it, and doing an automated translation from one language to any language risks a lot of that value, so you need to make sure the benefits outweigh the costs.
The result of this we will never know. Bun was bought by a company that’s business model is give us money so our AI can think for you . If this transition is a flop they will never say it was because vibing everything and understanding nothing is a bad model.
hopefully not, there is no reason for them to do so as a reaction. they would be developing Zig -almost- the same even if bun did not exist, so an AI company vibe-coding a rewrite for to their new acquired project is just an event which feels more related to AI than Zig. Rust might have more data to train LLMs and more stable time (time between breaking changes) so LLMs might hallucinate less
I think this might be conflating two things: rewriting software from scratch (like what Joel Spolsky famously warned about a quarter century ago), and straightforward automated translation to another language. The latter is what the Go team did with their compiler for example, translating it from C to Go, and it worked out great for them. Granted, the languages involved were more similar than here, and there was an order of magnitude less code to translate and review.
But the point is, a close-to-literal translation followed by incremental improvements to make the code more idiomatic is a less risky approach than starting from nothing. And the loss of knowledge you mention is minimized – for example, I suspect many of the issues found by Miri in the ticket mentioned above in this thread already existed before and were faithfully translated from the Zig codebase. And they did get to mostly reuse their test suite, including tons of regression tests.
Overall, the Bun project never really gave off a rigorous technical approach vibe, but out of all ways to do such a language switch, doing it fast and starting with as close to a literal translation as possible is probably the least disastrous way to do it.