I was first interested in Bun because it was written in Zig. I was interested in Zig because I respected Andrew Kelley's decision-making, and his taste matched my own.
I got really excited about Bun for many reasons after that, but they essentially came down to a similar root: the decisions were ones that I respected and would probably have made myself if I had thought of them.
I was a little concerned when Bun was acquired by Anthropic, but forced myself to remain cautiously optimistic.
This behavior, though, is exactly the sort of decision-making that I don't respect. I've got nothing against Rust, but if this is how Anthropic is managing Bun, I can no longer bet on it being a reliable part of my toolkit. It isn't just the code, it's the thought behind it that I have to trust.
I was so excited by Bun for many of the use-cases I have, but this just turns me off completely. This looks like an Anthropic internal-only tool, based on the behavior.
Bun is really interesting project, but the amount of segmentation faults in issues was too concerning for serious production usage. I guess this is one direction to fix it, but let’s see.
It's inability to be compiled from source without a fork of the zig compiler made it unusable in many corporate environments that require deps all be from source as well (or very hard to integrate at least)
I can understand where you are coming from, but I myself am coming from a quite different place. I'm a long-time Deno fan, and to me Bun was less interesting because a.) it seemed like a much-less-ambitious Deno, and b.) I don't want to learn Zig, so I wasn't likely to try to hack on Bun itself, even just recreationally.
But, I warmed up to Bun over the last couple years almost against my own will — trying to maintain a pretty large body of TypeScript code in a runtime-agnostic way (including even Node, since 24.2). I don't want to make any specific TypeScript runtime a requirement for my TypeScript code, unless there are really good reasons to do so.
But Bun (like Deno) kept providing those reasons. Postgres, SQLite, S3, websockets, local secrets (Keychain/wallet), bundling, compilation, killer speed. So I (somewhat grudgingly) started using Bun more, and even made it a requirement for some of my projects (albeit, in ways I could walk back later if needed).
Today, I have a bunch of API servers and frontend app servers which are bun build --compile --bytecode single executables ,that can run and be deployed virtually anywhere.
I've been very happy with it so far. But also, I don’t think that the way I am doing it is super-common, and now that they are doing this, uh... extremely ambitious LLM port, I am perfectly positioned to regret all of my decisions around Bun if this port ends up sucking.
So I'm a little nervous, but... what if it doesn't suck? That would be cool, because a.) they will have shown something interesting about what is possible with LLMs (albeit if you are rounds-to-a-trillion-dollars valuation frontier AI lab, lol, but still). And b.) going forward, Bun will be developed in Rust. We all have our own preferences, obviously, but to me, that's a win.
And if it does suck, though — that's super interesting too! Will be annoying to me to re-architect my Bun-specific shit to Deno, but for the world at large (and me, too) that's still interesting information!
Because Bun is perfectly positioned to do a huge LLM-powered port. They are one of the premier TS/JS runtimes, it's obviously and insane marketing pillar for the AI lab that bought them, they have unfathomable resources and access to the cutting-edge models that all of us don't get to play with yet, and for all intents and purposes, they have unlimited money to do this.
So if they can't do it — which will be really obvious, I think, if true — then it really just isn't possible yet, and all the naysayers were right.
lol — what you're saying doesn't make sense to me, but I'm sure it makes sense to somebody
What I was specifically referring to is Deno (originally) trying to fix the (glaring, fundamental) problems that Node imposes on the world, vs just do them faster.
OK. But without changing programming laguages, "fix some fundamental Node problems" vs "don't fix those problems, just run them faster, and maybe inline the most popular dependencies"...
Surely we can agree that one of those positions is relatively less ambitious?
Well "slop" is doing a lot of work there. If it's all incomprehensible garbage-code that no human can understand? Then... yeah very marginal value to me, in terms of hacking on it.
However, I think if it turns out that that's the case, then their port will fail in two ways (to paraphrase Hemingway): gradually, and then suddenly.
I don't think this port can be a success unless they end up — on the other side of it, not necessarily immediately — with maintainable Rust code.
If they succeed the software will be more reliable with less memory issues that are very likely significant security issues at least some of the time.
When we've seen linux having a new significant exploit every other day now thanks to LLMs being better at weaponizing memory bugs this seems significant.
I'm not the person you asked, but for me, it's the package identifiers. Demo puts URLs to web infrastructure in source files, like Go. In my opinion, this is a huge mistake. There should be a mapping from logical package identifier to web infrastructure, and this mapping should happen outside of the source files. I believe in this very strongly.
Deno supports import maps, which are the mapping outside of the source files.
But yes, URL imports have a variety of other issues (duplicated dependencies, no resource integrity), though Deno solved them in later versions (npm registry support, lock files).
The only benefit of Deno is its permissions system, which has been great for safely letting agents write and run scripts on my file system.
Thanks, this is a good correction. I haven't looked seriously at Deno since way before late 2024. The "URLs as package identifiers" issue is what initially attracted me to Bun over Deno, but it may not be relevant anymore.
The core issue is philosophical. Whether you happen to have public infrastructure which provides a web front-end for your git repository, and what exact server that web front-end happens to be hosted on, ought to be completely incidental to compiling source code. But since you ask, Go is the best example of how this can go terribly wrong in practice, IMO. Here are just a few scattered pain points I've encountered:
* In order to follow convention, you need to decide on git web hosting infrastructure before you start writing code. The tooling asks you for a URL the moment you run 'go mod init'. My preferred way of doing things is to start work on a project just on my computer and then maybe put it on one or more online git web host eventually, if the project goes anywhere. That order doesn't work with ideomatic Go. To work around this, I write mostly non-ideomatic Go where I use the name of the project instead of a URL as a package name.
* I view hosting infrastructure as incidental. I may throw a project on GitHub. I may change my mind and move it to Codeberg. I may move it to my own git forge. I may get tired of hosting my own git forge and move it to sr.ht. With Go, each of these moves requires a huge "touch a bunch of lines in every file" style commit if you're using the ideomatic "git web host as package identifier" style required to work with 'go get'. In other languages, it requires at most a readme change, and for dependencies, it requires at most a git submodule or package manifest change.
* Go requires that you use a Go-compatible git web host. Because Go decided to make URLs look like 'example.com/foo/bar/baz/qux', it has no way to determine which part of that is the git repo and which part is a subdirectory of the repo; should it 'git clone example.com/foo/bar/baz.git' and look at the 'qux' subfolder or should it 'git clone example.com/foo.git' and look for 'bar/baz/qux'? The only solution is for Go to make an HTTP request to 'example.com/foo/bar/baz/qux?go_get=1' and parse the response HTML and look for a Go-specific meta tag which tells Go what part is a git repo. This is an immense "layering violation" and extremely ugly hack in my opinion. This feels so unnecessary too, since this is an easily solvable problem: just make URLs look like 'example.com/foo/bar/baz:qux', so that Go knows to look for 'qux' in 'example.com/foo/bar/baz.git'.
* Private repos are a horrible experience. You need to convince Go to not look them up in Google's package checksum database, you need to convince Go to not get them from Google's caching infrastructure, you need to make a ~/.netrc file with credentials, you need a git host web frontend which understands and supports the way Go + .netrc makes authenticated GET requests. If any of these things are misconfigured, you get a cryptic error message about how terminal prompts are disabled on Google's servers. It's all very brittle and hard to debug, and the guidance has changed drastically over time (editing your global .gitignore to rewrite relevant HTTP sources to use SSH used to be the advice, but that had its own significant problems).
* It has the "feeling" of being decentralized since it's all just git URLs, but in reality, Go's tooling depends heavily on Google's centralized package cache and checksum infrastructure which has been introduced over time to smooth over foundational issues with the design.
I was once part of separating a complex project out of a company and moving it to its own infrastructure on a different domain name and git host. The Rust and C++ repositories were a breeze, just change the URL in a CI job. The node.js repositories required changing some references in the source code from one NPM org name to another but were otherwise painless. The Go repositories were absolute hell.
I have considered writing a blog post about all this.
* The `require` directives from the `go.mod` files of your dependencies are always ignored.
Those two combined, mean that there's no easy way to fork a dependency. It's doable, but some of the maintenance overhead could have been avoided.
We don't even get a `go mod tidy` flag that lets us say, "yes, I understand the risks, just copy any `replace` directives that you find in my dependencies". With a flag like that, even if the `replace` directive is still copied everywhere, at least it's automatically copied during a routine `go mod tidy` invocation.
They already have `// indirect` comments, so those could have a `// indirect, replaced by X` comment or something like that.
Thanks, I am lucky to avoid those issues working with go, but now I’m annoyed that those decisions were made, I have honestly never thought about the trouble that assigning URLs as import locators could cause but yea that would be a pain if we ever had to deal with any of that.
Thanks for your time writing that. A blog post would be great.
> Demo puts URLs to web infrastructure in source files, like Go.
This is optional, but also really, really handy for standalone scripts that don't need to come with a package-lock.json or deno.lock file (if you're not aware, Deno did a lot of changes to package management in later versions).
What I don't understand is if they were going to translate Zig to unsafe Rust, why not just build a translation tool for it? You could do a one-to-one mapping of language constructs, hardcoding patterns in your codebase, and as one friend put it "Tbh they could've just hooked up zig translate-c to c2rust". They would get deterministic translation, would probably have not been a heavy investment to build, and the output would have the same assurances as the input.
In this case, I would trust the output even less than the input. The input was memory-unsafe but hand-written. The output is memory-unsafe but also vibe-coded and has had no eyeballs on it. What is the point of abusing agentic AI for this use-case?
> "Tbh they could've just hooked up zig translate-c to c2rust".
Have you ever seen what comes out of c2rust? It's awful. It relies on a library of functions which emulate unsafe C pointer semantics with unsafe Rust.
A few years ago, when I was struggling with bugs in OpenJPEG (a JPEG 2000 decoder), someone tried running it through c2rust. The converted unsafe rust segfaulted at the same place the C code did. It's compatible, but not safe.
Main insight: don't do string manipulation in C or unsafe Rust. It's totally the wrong tool for the job.
> Have you ever seen what comes out of c2rust? It's awful. It relies on a library of functions which emulate unsafe C pointer semantics with unsafe Rust.
which is somewhat close to what their port produced...
like their goal was from the get to go to have a mostly exactly the same as zig "just in rust" which implies mostly unsafe rust and all the soundness/memory issues zig has (plus probably some more due to AI based port instead of a tool like c2ruts)
the thing is if you don't keep things mostly 1:1 with all the problems that has there is absolutely no way to review that PR or catch the AI going rogue with hallucinations etc. With a mostly 1:1 port you can at least check if things seem mostly the same.
but it also means this is just step 1 of very many, with the other being incrementally fixing soundness, removing unsafe and (hopefully) making the code more idiomatic...
(to got to the actual question of why?, I think the answer is doing this port using AI is likely way easier/faster then first writing a tool which need in depth understanding of the languages, especially given that some features in zig do not map 1:1 in rust and fuzzily mapping is what LLMs are good at and human hand written tools tend to be very bad at).
> The converted unsafe rust segfaulted at the same place the C code did. It's compatible, but not safe
That is indeed the point of c2rust. It gives you a baseline that is semantically identical to the original codebase, and with that passing the full test suite, bug-for-bug, you can then start gradually adopting rusty idioms to improve the memory safety of the codebase.
What comes out of c2rust is not intended for human consumption. It's more verbose than the original and harder to work on, but no safer. You lose the C idioms that people understand, while not gaining Rust idioms. It's like working on compiler-generated assembly code by hand.
2022 discussion on HN.[1]
There's a DARPA funded effort called TRACTOR, Translate All C To Rust, which has funded some efforts to develop a usable translator.[2] It's about 10 months after award, with no reported progress. I've been checking the personal sites of the academics involved, and they barely mention the project, although $5 million has been allocated to it.[3] The approach comes from U.C. Berkeley - let the LLM generate slop, check it using formal methods.[4] Not expecting near-term results.
Evaluations of six translators. That's real progress.
Here are the test cases for evaluation #1.[1] There's good coverage of the C language, but the individual tests are mostly simple exercises of one C feature. The next round of test cases will probably be closer to useful programs.
> What comes out of c2rust is not intended for human consumption.
That doesn’t really mean anything.
> It's more verbose than the original and harder to work on, but no safer. You lose the C idioms that people understand, while not gaining Rust idioms.
Yes, and?
The value of c2rust is that you now have the entire codebase working with the rust toolchain, you’re not juggling toolchains and you’re not managing a wavefront of FFI, only a wavefront if unsafe.
C2rust is not the end, it’s the start. It’s never claimed to be anything more (the official website even mentions galois and immunant are working on tooling to convert unsafe to safe / idiomatic rust though i don’t know if that got anywhere yet).
no string manipulation in C ??? this is trivial stuff guys . do you think the cpu has suddenly a different isa if you use Go? -_-. if you build unsafe code u will build unsafe code. certain logic will be solved for u and then u will fall flat on your face on the next logic u need to do yourself. why did you start programming?
its not cynical, its a real question. not trying to be mean but saying that something that people have solved countless time shouldnt be done is weird statement.
This is awful. They have some internal string format borrowed from a Zig library where the address of the item is in the low end of a pointer and the length is at the high end. Why are they doing that in 2026? It lets you save a few bytes at best. It doesn't enforce the Rust rule that strings must be strict UTF-8. It's totally alien to the safe way Rust handles strings.
For the same reason the V8 team bothered to set up a 32-bit addressing scheme for the GC heap even on 64-bit platforms, I imagine? The bytes add up when there’s enough of them.
Sure, but the point remains. They could've used Claude to build a Zig to Rust converter, ended up with something that was both deterministic _and_ beneficial to the wider community.
> emulate unsafe C pointer semantics with unsafe Rust
Yes and that would be safer than the current slop translation, because c2rust does these ugly things exactly to avoid introducing new issues with the more strict Rust semantics.
It _already was and should_ be that awful to match the original code without introducing hundreds of new UBs like the current situation.
I mean, LLMs have been really good at translating code for a while now, which is why I'm more surprised that others are surprised this happened. They claim its a marketing trick despite the fact that they have to manage and maintain a fork of Zig if they don't switch languages.
“Tbh they could've just hooked up zig translate-c to c2rust”
This doesn’t work like you think it does. These things are full of errors and make the code very verbose and hard to reason about. It works with small apps, not entire rewrites.
+1 - I was making exactly this argument in other threads. But I have a slightly different take on how software should be written.
Translating zig -> rust is more complex than writing a JPEG parser in static python and then lowering it into zig and rust differently using idiomatic construct for each language.
Towards that end, I've created a parser for a dialect of python which is suitable for this purpose. It should maintain compatibility with the vast majority of python code out there, while picking up some rust/zig features that make translation easier. JPEG parser included in the assets of the skill for a flavor.
That would have been the proper way to port a codebase to another language, by parsing the syntax tree and applying deterministic and verified transformations.
Yeah, this is the same annoyance I have with AI psychosis. Deterministic tasks should be done by deterministic tools. The amount of people I've seen translate morse code using AI is far larger than it should be.
The issue isn't the existence of undefined behavior that miri would catch. The issue is exposing an API that allows undefined behavior from safe code - which miri only catches if you go write the test that proves it.
This isn't an all together unreasonable thing to happen during an initial port of code from an unsafe language. You can, and the bun team seems to be, go around later and make sure that the functions where you wrap unsafe code does so correctly. Temporarily in a porting stage incorrectly marking some unsafe functions as safe isn't a real issue. It's a bit strange to merge it into the main repo in this state, but not a wholly unreasonable thing to do if the team has decided that they're definitely doing this. The only real issue would be if they made an actual release with the code in this state.
It's also a bit unfortunate that they didn't immediately set up their tests to run in miri if only because LLMs respond so well to good tests - I know they didn't do this not because of this github issue (which doesn't demonstrate that) but because there's another test [1] that absolutely does invoke undefined behavior that miri would catch. Though the code it's testing doesn't actually appear to be used anywhere so it's not much of a real issue. That said it's obviously early in the porting process... maybe they'll get around to it (or just get rid of all this unsafe code that they don't actually need).
[1] https://github.com/oven-sh/bun/blob/4d443e54022ceeadc79adf54... - the pointers derived from the first mutable references are invalidated by creating a new mutable reference to the same object. In C terms think of "mutable reference" as "restrict reference which a trivial mutation is made through". It's easy to do this properly, derive all the pointers from the same mutable reference, it just wasn't done properly.
PS. Spamming github just makes people less likely to work in the open. Please don't. We can all judge this work just fine on third party sites.
PPS. And we might want to withhold judgement until it's in a published state. Judging intermediate working states doesn't seem terribly fair or interesting to me.
Once project reaches 1.0 for the first time, a lot of people expect that "main" branch is now working all the time. That's what the whole "CI/CD" is about after all - every commit should work.
If you are making a full rewrite and have non-working, in-progress code, you use a branch. This way you can still have the working "main", in case there is a security fix needed or something.
It depends on how you set it up, but main doesn't have to be the stable release branch. From what I have seen, in most public projects it is the staging area for the next release.
If you have to go back to previous releases you have tags.
This doesn't seem surprising, given the straight translation that they prompted.
Couldn't a case be made that it's better to get Bun to the to the language with the stronger type system first and, once there, use that stronger type system as leverage for these kinds of improvements as a follow-on effort? It seems preferable to requiring perfection on the very first step.
> Couldn't a case be made that it's better to get Bun to the to the language with the stronger type system first and, once there, use that stronger type system as leverage for these kinds of improvements as a follow-on effort? It seems preferable to requiring perfection on the very first step.
This is what they are doing.
They are working through the issues as they come in.
It's not surprising that a mostly straightforward translation to (partly unsafe) Rust exhibits UB.
What is a bit disappointing is that the Rust code apparently has APIs that aren't marked unsafe but may cause UB anyway. When doing this kind of translation, I'd always err on the side of caution and start by marking all/most things unsafe. Or prompt the slopbots to do the same I guess.
Then you can go in and verify the safety of individual bits step by step.
The point is that at a minimum you're supposed to bubble the `unsafe` up if the API does not guarantee safety is maintained for all cases (and documents the invariants that have to be kept by the caller), otherwise the system breaks down.
I was a little shocked that they could get it fully working in a week to be honest. My side project is a very similar ambition (https://tsz.dev) but I am in no way claiming success. i keep adding more and more tests to ensure things works. Even after all of TypeScript's own tests pass I am finding bugs which I was totally expecting.
The bar for matching tsc's behavior is really _really_ high. see:
> I was a little shocked that they could get it fully working in a week to be honest
It shouldn't be shocking, it was done using only compute, and the codebase is owned by the company who owns the compute, you literally just turn the dial up and it will be done faster. Efficacy of LLMs aside - anything they could do in 30 days they could also do in 3, if you spend more money.
I'm stunned that it went from 'this is an experiment' to merging a ~million lines of (likely) unreviewed code in a week. I have nothing against using agents but to rush something like this and leave the community blindsided seems extremely ameteurish. Like something you'd expect a bright eyed graduate engineer to do.
tsz for me is an experiment to see how can this kind of work be done better. With a slight difference that tsz is not a direct port and it's a different architecture. I'm also not claiming to have answers but I've learned a ton. A few things that works
- Test before code, Bun had lots of test so that's good but maybe they could start by asking Mythos to write like 20k additional tests that pass on Zig Bun first.
- Deterministic anti-slop features. LLMs love to solve the problem in the wrong abstraction layer or place. There are many ways to catch this with deterministic tests. I do this in tsz a lot
- Roadmap that constantly evolving by humans.
- Taking a pause and looking how the progress is going and undoing slop
This is awesome. Typescript really needs more of this. I hope this gets more publicized and perhaps get adopted by Microsoft.
I am not sure you should call it sound mode though.
> It is not a mathematical proof of soundness, and it does not make third-party .d.ts files truthful.
Here there are two completely unrelated things
First, soundness is a mathematical thing (sorry). If something is sound, it's really really sound. Soundness is the thing that says we don't need to manually check the details - we can trust the compiler to do the right thing. It will do the wrong thing if there's a bug, but the implementation can be fixed. Soundness means there's is no bug in the spec, no bug in the type system that would make things go wrong even in theory.
Second, and here's the important thing.. it's entirely okay and expected that real world languages need to have unchecked features where we trust the humans to do the right thing, rather than trusting the compiler to verify. That's like Haskell's unsafeCoerce or Java's sun.misc.unsafe. The problem really is when the type system breaks even when we don't do any of those
I think in the context of type systems, soundness means something like:
If type system says, x has type T, then x has type T
TypeScripts type system does not have that property. E.g. by default `stringArray[0]` has type `string` when it should be `string | undefined`.
But TypeScript could be sound if you eliminate all these cases. If that's the goal of "SoundMode" then the name sounds fair to me.
Not even sure `.d.ts` files are a problem in this regard. They are like axioms/facts. Resolution (from formal logic) is a sound inference rule but you can still derive contradictions from contradicting facts.
Thank you for the feedback. I think I should rename the "Sound Mode" to something more honest. "Strict" is already taken so I should think of a better name. Making tsz compatible with tsc and making it sound is mathematically impossible. The history of this stuff (https://hegel.js.org) is telling. If you really make a sound JS checker, nobody will really use it unless you build an entire ecosystem as big as npm with it. TypeScript's decision to embrace existing npm ecosystem and layering .d.ts on top was a very practical decision that made it so successful.
> TypeScript's decision to embrace existing npm ecosystem and layering .d.ts on top was a very practical decision that made it so successful.
This is basically the same argument made for C++ and I think it's not a very solid one. We know this worked, but that's not evidence that alternatives couldn't have succeeded. I think in a world where Queen never happened the prevailing wisdom would be that someone like Farrokh Bulsara (Freddie Mercury) can't be a rockstar because that seems ridiculous.
Actually speaking of royalty, Prince is an even more extreme case. You cannot use numeral-letter substitutions in song titles, that's something for kids and won't... oh unless you're Prince. Yeah, no, "Nothing Compares 2 U" is fine Prince, thanks.
In the Sound Mode page I mentioned that I have some ideas around this. What if we could take .d.ts and project a sound version out of it? How feasible that can be is unclear but the biggest unsoundness criminal is `any` which is relatively safe to project it into `unknown`. And method binvariance stuff are also not impossible to project something more sound out of it.
My goal with tsz is to make it practical and useful. I know how difficult it is to convince a tsc user to try something not officially from Microsoft
Calling it as working is a bit of an exaggeration. Looked at the code for a few minutes I'd expect it to crash and burn if they ever dare to turn the optimization on.
I suspect they've been planning this and experimenting for many months. Along with the large existing test suite, they have lots of tooling for parallelizing agents and an unlimited token budget. So don't feel too bad..
The author was on here claiming it was an experiment just last week. Didn't look like they have been planning much of this, but they did have some trouble with zig to the tune of having to maintain their own fork that the zig maintainers didn't want to merge. So people probably could have seen this coming
If I was the bun maintainers I wouldn't want to have to maintain a language fork either, when there are viable alternatives.
Now with LLM's getting stronger and stronger a rewrite like this is getting more and more viable, and it looks like they are just approaching this like the "how do you eat an elephant? One bite at a time"-method.
Not sure why people thing this is an elaborate PR campaign, we already know LLM's are increasingly powerful for coding tasks.
There's a book that changed a lot of the way I think about attention and media [0]. The book isn't very good, but it flags something relevant here. There is a huge asymmetry between the reach of a big, flashy announcement (here: bun was re-written in memory-safe rust in a couple weeks), and the relatively small reach of a correction (often just a footnote on an old article, here a GH issue).
This asymmetry is well understood by marketing and PR professionals, and actively exploited.
Hmmm, given the general mood in this case, I feel like there's a lot of people keen to find any criticism of the code they can and amplify it as possible. Most of it strikes me as relatively shallow at the moment, though (that is, apart from the fact that merging such a large LLM assisted port is certainly a, uh _bold_ move (to put it lightly), there's not much that people are pointing out about the actual result that feels like it's worse than any other port in progress, but there is definitely a lot of hay being made about any issue that is found).
> Most of it strikes me as relatively shallow at the moment
It is. We’re what, a week into this exercise? Absolutely everyone criticizing it, with no exceptions, is behaving like a micromanaging middle manager who couldn’t even dream of doing the work themselves.
I half want to start a list of “people to ignore”, but such people tend to expose themselves in every other comment anyway.
Idk the pr author did merge it into main and talked about writing a blog post. To me that sounds like the author felt it was ready for public critique and feedback, especially for software with a fair bit of users
I did not say that HN is turning into reddit nor indicate any view on any way in which HN is trending. Remarking that Reddit and HN are similar is not rule breaking, they are both vote systems, etc.
> a big, flashy announcement (here: bun was re-written in memory-safe rust in a couple weeks)
Did they even claim it was "memory-safe"? Every discussion of this topic has had dozens of comments noting that their vibed codebase is bursting at the seams with unaudited unsafe blocks, lightly reviewed by people who seem to not only seem to not understand Rust, but who seem incensed at the idea of needing to understand any programming language in the first place.
No, and there's been a lot of confusion about that on this website.
They did cite Rust's safety as a motivating factor for the port. That doesn't imply trying to achieve that simultaneously with the language change — which is good, because that would be insane. (Or, if you prefer, even more insane.)
You cannot faithfully port a codebase to a new language while also radically re-architecting it. You have to choose.
They want the safety benefits of Rust going forward; i.e., after it's finished, when they then write new code in Rust.
Yeah, exactly. The typical approach is to do a mechanical translation such as with rust2c, that is full of unsafe, and then gradually refactor safety in.
And the first post is about the team working on the project, with about two and a half sentences on c2rust, and making it very clear they just started.
The newer posts go into detail about the rearchitecting that follows.
actually the port is trying to be mostly 1:1 and in turn is mostly unsafe rust, which means no benefits initially
but also doing the 1:1 port to mostly unsafe rust is also only the first step of a full port, you then incrementally go through it fixing issues and remove "unsafe" usage. (And long term likely also doing some refactoring to using more idiomatic rust, but that has less priority).
The problem is there was no blog port describing the whole thing to someone without contextual knowledge. Instead just linked PRs which is in this case somewhat close to a "as if nearly all people only read the HN headline" case :/
Like a more context giving version of the first HN post would have something on the line of `Show HN: Bun is porting to safe rust (PR link), starting with an AI based automatized port to mostly unsafe rust which once it behaves mostly the same as Bun in the test suite will likely be merged. But must be followed up with incremental PRs to remove unsafeness, and likely also a lot of unsoundness related to the way it's ported (some explanation about why this port will have unsoundness).`
A bug-for-bug port to Rust is the first step to fixing that. Assuming the port is actually 1:1 without any behavioral changes, these bugs already exist in the Zig code. The difference is now it's known where effort can be dedicated in order to one day have a memory-safe release of Bun. People have absolutely lost their mind over this and completely forgotten the benefits Rust gives you. I feel like I've gone back 10 years reading threads about the Rust port of Bun these are the exact same arguments we see from people advocating continued use of C++.
> Assuming the port is actually 1:1 without any behavioral changes, these bugs already exist in the Zig code
The "1:1" assumption is a massive unjustified assumption. Rust and Zig have different memory models, so it's possible to do a "1:1" translation of Zig code to Rust and end up with undefined behavior in Rust.
For example, Zig code might make assumptions about lifetimes based on implicit knowledge of which allocator was used for some memory. That could cause problems in Rust if you erase the lifetime https://github.com/oven-sh/bun/blob/main/src/bun_core/string...
> Assuming the port is actually 1:1 without any behavioral changes
It's not, that's clear from this kind of bug popping up. Functionally this bug exists because `PathString` was converted into a "safe" Rust API but still works the same internally as the original Zig code did (via using `unsafe`), that introduces UB that wasn't there in the Zig code.
If it was attempting to be a 1:1 with no behavior changes (like c2Rust attempts to do) then this would not have been turned into a "safe" Rust API like this.
Quite to the contrary to what you write, many people pushing for Rust explicitly recommend to be very restrictive about touching existing, battle tested code and only rewrite it if you're substantially refactoring it anyways, or if it is a critical exposed piece of functionality - such as media codecs for example, which have a long history of being broken. The winning strategy that for example the google android team pursues is to not rewrite existing code, but write all new code in Rust, because real-world data shows that vulnerabilities in existing code follow a decay curve - most issues are detected in the early life of the code. That's the strategy that Firefox uses, too. (Though I'm curious about how LLMs change that equation because detecting errors in rarely used code path' seems to be what they're doing well)
And indeed, this is very much what Rust was designed to do with the ability to interface with existing C/C++ code in both directions. So this is the strategy that the designers of the language had in mind from the early days. It's a deliberate choice to offer this, and not an emergent property that was later discovered.
You have couched this correctly, because we all know there are people out there who do go around yelling "Rewrite it in X" without thought (where X is the flavour of the month)
I also wanted to say - your description of the /right/ way to align a project with tech X is a restatement of Martin Fowler's "Strangler pattern"
Can you edit your post - "equation because deteting errors" is ambiguous - deleting, or detecting - I cannot work out which you mean
And yet, all I ever see are attacks against these convenient bogeymen with artistic exaggerations like yours... but I never see the bogeymen themselves.
The only time I've ever seen anything that could be considered Rust evangelist is when someone with a chip on their shoulder shoves a github issue or random comment link in my face. I certainly don't encounter them in the wild.
I'm not saying they don't exist. I'm saying that I don't encounter them in the wild. Certainly nowhere near as often as I encounter people who have a loud and obnoxious dislike of Rust.
What I'm trying to say is that if you see Rust evangelists everywhere, your label is either so wide-ranging as to be useless or you need to rm your rust_evangelist_evidence.txt because it's likely taking up a disproportionate amount of headspace.
A quick scan of your comment history suggests that you see one every day ;)
And - the number of times I have been grossly downvoted for daring to utter a true word about Rust (or even Rust adjacent) will let you know your non-existent Rust evangelists are indeed the bullies - with one now screaming that he is a victim.
If you want definitive proof - look at this sub thread where you're so triggered that people talk about the mere existence of Rust evangelists (and evangelists exist for every tech - they always have and always will - which you would know given your [claimed] history in the field) that you want to argue they they aren't evangelists, they're just poor misunderstood victims.
Note: I say claimed not as a jab but because I don't know you and can only go on your claims in your profile.
My comment history? The very same one that keeps trying to extract out the location of those supposed Rust zealots and never even getting a single response except yesterday... and the linked comment was pretty mild? But I always get downvoted for having the gall to ask? That comment history?
Surely you mistyped that part of your comment with the one I wrote above, right? Understandable.
I guess we'll have to agree that we live in parallel realities though, reading your comment -- which I do find genuinely puzzling. Because I keep not seeing evangelists and the only one using troll-like language here is you, not me ("triggered", really?).
I am looking at the sub-thread. I guess I need new glasses. Still not seeing anyone fanatical / zealot or whatever. What I see are people who try to ground a discussion because a top comment happily tears down a straw man, and those comments are attempting to show that.
> Note: I say claimed not as a jab
Oh, I am sure. Your comment absolutely cannot be mistook for that.
They didn't need to - much of the popular hype around rust is on the back of uninformed spectators confusing Rust's tools for enabling memory-safety (good, warranting hype) with Rust itself guaranteeing automatic memory safety (fantasy).
What exactly people mean by "safe(r)" makes all the difference.
It's simply not possible to include all the nuance of safety of a language and all software written in it a single word. This leads to all kinds of miscommunication and strawmanning.
Rust's official line is specific memory safety guarantees, with caveats that it must not be broken by unsafe code, the OS, compiler bugs may happen, etc. Rust also has a bunch of best-effort features that steer users towards more robust code, but can't guarantee it.
This gets twisted in both directions:
- people ignore the caveats and limitations, pretending that Rust promised zero bugs ever, and use any bug in any Rust program as a proof by contradiction that Rust's claims are false.
- or focus solely on the caveats, ignoring all the advancements and incremental improvements, and take a "then why even bother?" There are classes of bugs Rust can't stop. Nothing is foolproof for a sufficiently advanced fool, and an infallible programmer could write bug-free code in any language, which creates a false equivalence between languages.
You could view it as a specific application of the quote.
In your quote, there is no time-dependency between the lie and the truth. Whereas here, it's an attractive lie (easily parsed, great narrative), followed up by truths (that need more than surface-level analysis).
Not just marketing and PR, the mainstream media knows that pushing out BS and then retracting it later can have lasting effects because people will remember the original article / headline, and never see the correction.
only the mainstream media knows about this? Quite odd to qualify media this way here, when most of all media uses this mechanism. We also forgot politicians who are experts in this field.
Ctrl + F "only" is only in your messaging not mine. I never said they were the only ones doing this? It's not just politicians, celebrities know about this and will use it to their advantage. Whoever makes the headlines first might have a stronger sway over their adversaries. I'm not even poking at any side in particular, this is reality across the board unfortunately. People will just blindly take and believe the primary headlines.
I don’t think the media care about having lasting effects. They just want to catch the wave of interest and not wait around and let someone else get the scoop while they fact check or add nuance.
I thought you were going to call out the problem in the other direction: There has not been a "big, flashy announcement" because the port is a work in progress. It's not done or released. The only big flashy announcements I see are these drive-by dunk attempts on the work in progress code combined with attempts to imply that they said it was done or perfect.
The rewrite was a code translation meant to be a starting point.
> a big, flashy announcement (here: bun was re-written in memory-safe rust in a couple weeks), and the relatively small reach of a correction (often just a footnote on an old article, here a GH issue).
The Bun team never made a big announcement that the code is now memory safe. They've been clear that this is the starting point.
Anyone expecting it to be perfect immediately and to have solved all of the memory problems in the original Zig code is arguing with an announcement they imagined, not what the Bun team has said.
Did anyone try to map this code back to the original codebase to see if this memory problem exists in the original codebase?
> Did anyone try to map this code back to the original codebase to see if this memory problem exists in the original codebase?
FWIW what is being discussed is not memory problems, it's breaking rust invariants (the unsafe code has to follow specific rules, e.g. annotate lifetimes properly).
A single million line commit overwriting all of main is pretty flashy and high profile. Anyone who was working in this repo previously can throw whatever the heck they were doing out the window. This isn't in a branch, this commit isn't marked WIP, this is now the committed, active, current state of the bun project. That's quite a statement to make, even if there isn't a blog post somewhere (yet).
Bun being a high profile project, that has had visible conflicts with Zig over AI contributions, and was recently purchased by Anthropic, is naturally going to make something like this big and flashy regardless of the author's intentions.
That kind of error was expected. I don't see it as an issue against the rewrite. They kept the stable versions on Zig in case ppl needs stability. Eventually, the errors will get fixed.
That kind of error was entirely avoidable. There are well-known tools in the Rust ecosystem that detect this kind of error and while the tools do not detect all instances of UB caused by mistakes in unsafe blocks, it's still considered good practice to run them.
Indeed. My point is that just using the standard tools in the Rust ecosystem - like miri - would have trivially uncovered this error before it made it to the mainline.
In any practical application there'll be a known set of errors and I'm generally fine merging code that has known deficiencies. But personally, I'd not condone merging anything that causes UB. It undermines such a fundamental guarantee of the language that it should be detected and eliminated. And bun certainly rises to the level of software where I'd expect that the project runs all available tooling to detect such cases. Especially if you LLM - code it. "Do not cause UB" should be part of the test harness.
What I find most concerning about this is the meta-dialogue. At first I was critical of the maintainers for closing this github issue as off topic.
Then I realized that the github ui was auto-collapsing a dozen messages in a row that were all completely devoid of any informational value and certainly sourced from forums and community discord channels.
This places everyone in a no-win situation. Someone who has identified critical issues that they believe the majority of a relevant community would be concerned about has good reason to signal-boost as much as they can.
It's a substantial request about very recent changes, and tone-policing it doesn't make it less true. The problem is that the additional attention literally kills the discussion. This also provides cover for people who may be making more emotive or ai-psychosis influenced decisions on the maintainer side.
Projects with a siege mentality which block and ignore criticism tend to go off the rails very quickly. On the other hand, maintainer burnout is inevitable for projects which can't shield maintainers from the anxieties and pathologies of people who seem to think that if they complain about AI enough, everyone else will stop trying to use and improve it it.
Not a single person on the Bun team nor Anthropic has yet done anything egregious to market this as anything but a swap to a more memory-safe language with better compiler guarantees.
Thus far most of the buzz and marketing has been entirely negative from people who are against AI.
My take is that most of the buzz is also tied to recent negative opinions of Anthropic themselves due to some of their recent decisions.
The best kind of marketing is when you don’t need to say it aloud by yourself. Yet, this is constantly in HN front page. Maybe engineered or not but marketing regardless.
rooted in a long 30+ year reality. you can engineer the greatest, most secure, most accessible, most ____ thing but if it doesn’t sell those amazeballs engineers will be talking to their recruiters…
That's fine but I'll say as a human, that makes you a pretty crappy one. Only caring about monetary rewards is pathetic frankly, luckily the vast majority of humans don't agree with this sentiment and continue pushing the boundaries and our imaginations onward.
> Thus far most of the buzz and marketing has been entirely negative from people who are against AI.
To me it seems like quite a lot of it is also by people who spent years maintaining a codebase just to have the metaphorical rug be pulled out from under their feet, and feel that a migration like this might be kind of disrespectful (how many of the people that have gotten good at Zig and know the codebase will find the switch over to Rust easy)? Or in some cases, that it's just bad engineering - instead of releasing it alongside the main project and focusing on gradually getting parity over months, it just got merged into the main branch.
On a more practical note, however - if you get acquired by a company that gives you almost unlimited usage of tools that might help you migrate to a language, that 3 years down the line will lead to a better codebase than today, then I guess it also makes sense to take that chance.
And of course, you get a lot of people who are opposed to AI on principle, as you said.
I mean, the phrase "Zig to Rust port of Bun" makes little sense even to many professional developers. They may know Rust, might have heard of Zig, very likely don't know what Bun is.
So the fact that this gets any attention at all says something.
Just like how they did the rewrite. It is not longer a small OSS team trying to survive in the world, it's a corporate entity with unlimited access to Anthropic resources. All the doomsayers who were prophesying that Bun will become sellout were right.
I dunno, I am commenting on it mainly because I find the intensity of the anger and accusations of bad faith to be pretty out of proportion with what's actually happening, and I kind of value pushing back on such things to try to moderate the tone of the discussion (not as a devil's advocate thing per se, but more I am more likely to comment if I feel like the average vibe is unreasonable).
The HN guidelines specifically ask you not to do what you're doing, and say what to do if you have a genuine concern:
> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.
Huh, I didn't recall that. FWIW I have e-mailed them in the past and gotten detected abusers banned, but didn't this time because it's just a suspicion. Didn't realise posting about hunches was against the guidelines, though, that's my mistake.
If you can increase your reach, why not do it? Also, HN has better reputation among tech circles than Reddit and is less niche than other resources. Modern marketing hits everything.
HN is enormously influential for programmers and employees within the tech industry. Who happen to be exactly who Anthropic, and other AI companies, desperately need adoption from...
I think HN has an outsized influence in the industry, for its size. There are a lot of big tech employees and startup founders reading it. Account purchasing absolutely happens, I've discovered and gotten banned at least a dozen years-old accounts that were blatantly sold and puppeteered by bots in the past. The comments aren't obviously bot-written this time around, so I can't conclusively prove it happened in this case, but it is a thing that happens in general and something to be aware of. There's also vote selling to promote things onto the front page. Given how cheap shilling on HN is, and the fact that many will perceive it to be organic while always viewing straightforwards ads skeptically, I wouldn't be surprised if the cost:effectiveness ratio probably beats any other form of advertising.
What do you guys assume that a codebase from an unsafe language containing bindings to another unsafe language would appear perfectly implemented right away?
It is really sad and unfortunate that coding has started falling under the omnicause. Low-denominator discourse is invading every space I find interesting and it is difficult to avoid.
I agree. I'm as skeptical as many commenters but I also think the degree of polarization in HN around this technology and the degree to which people are calling those with different views shills or naysayers is pretty sad.
I am having to blacklist a lot of commenters on this site because they are providing misinformation unnecessarily. There's all this garbage about "big flashy announcements" and so on when all the posts are by random people observing an internal detail of an open-source program's VCS or whatever.
https://news.ycombinator.com/item?id=48132488 (this one seems suspicious - 2 year old user with this being their only submission ever and they have zero comments - anthropic could have submarined it but it's not a big flashy announcement)
But definitely the one thing these things aren't are big flashy announcement. To be honest, this kind of post-truth environment where people just make up things about people they don't like are super-lame. I've generally been able to deal with it by kill-filing people who post falsehoods but the number of users who do is getting so extraordinarily large I am starting to believe that I need to auto-hide anyone who created an account in the last 10 years.
But tbh this is trivial to write these days since the boilerplate can be written by the machines and you can just write the core functionality to make it work. I only have it public because I'm hoping others will also block users who misinform as a habit and I can subscribe to their lists and crib off their work without having to do it myself.
Yeah, I suppose a nice fully featured protocol would use something decentralized, but that extension currently has them on my site. e.g. Another user made this one and I subscribe to it too: https://overmod.org/lists/view?pk=0STtY8mc3j6Pyaaf3YeKGHkcBK...
I separate mine by a bunch of categories which might be a bit complicated, but I was hoping perhaps people might not care about some of the categories https://wiki.roshangeorge.dev/w/Overmod#My_Stuff
e.g. I don't like endless repetitious "but corporations" stuff and I also don't like "but they sell your data" repetitively but maybe others want to block category A but not category B.
I think that wasn't a sound idea, though. Either people trust you to block for them as well or they don't.
AI is not good at writing Rust. The ways in which it is bad vary from writing code that just looks off to actually not working. I do not use unsafe frequently so cannot comment on this particular scenario but I have seen similar stuff often, most Rust code that I read from AIs has at least one or two issues.
In particular, if you have a situation that requires any kind of conceptual understanding then AI will likely have issues. Sync blocking async is the classic example. My theory is that humans make this worse because they will often prompt in a certain direction and AI will faithfully build the footgun.
No, the distinction with Rust is obvious from the comments on this post by people who have actually used Rust...but the features of the language are such that you need to have some deeper conceptual understanding to use those features effectively. Cpp is the same. Opus writes Rust like someone coming from Python, it is very obvious if you have a lot of hours in the lab...most people do not.
I haven't experienced these issues with latest models writing performant and correct rust fwiw. It does seem to understand Rust's safety concepts quite well when working on reviewing or writing code
I suspect "Rust is fast/low memory utilization" is the more common value proposition, with memory safety as the bonus that can push it over other fast languages.
I would imagine that the strong type system would also help steer AIs to ensure that code is written correctly. The compiler supplies backpressure to the agent that steers it toward a more correct program.
Zig is every bit as fast with typically even lower memory footprint as Rust. The main thing Rust promises that Zig cannot already do natively is memory safety. This is not about Python vs Rust. It is one systems language vs another.
I'm curious, but unable to ascertain, does the same problem exist in the original Zig code? Is this an issue introduced by the translation to Rust? Because if it is a problem that can be replicated in both code bases, it seems a point in Rust's favor, that the issue is easily identifiable with tools that exist in its ecosystem.
I'm also curious about that. One thing to keep in mind: the invariants you have to uphold in unsafe blocks are quite stringent. I expect that in some instances the Rust code has new UB due to this.
No. They introduced quite a few aliasing issues that result in immediate UB in Rust but are allowed in Zig. I skimmed over the unsafe blocks with rg for ten minutes and spotted like 3 cases and these wouldn't exist in the original code.
Also the LLM is inventing ways to get around borrow checker limitations with unsafe which is also concerning. But I didn't verify if they are UB or not (either way it's a rejection if I'm to review the code).
As for the specific issue: it does not exist in Zig, because Zig does not have ownership.
In a nutshell, the LLM created abstractions that allow you to write unsound code in safe rust, which is squarely against the language.
To be specific: the abstraction takes a (shared) reference and uses unsafe to wrap it in an owned object, completely erasing le lifetime. In practice, this means users of the abstraction think they own the underlying memory: they choose when to free it. However, it just wraps a pointer that’s owned by someone else (it was a shared reference, remember?), thus it will be freed when you don’t expect it.
So why does it not exist in Zig: it’s a false contract about what it is. The Zig pointer is a pointer with no added lifetime information. You can hold a Zig pointer wrong, but you will hold a lying abstraction wrong. You will misuse it because it doesn’t do what’s written on the tin. You will write bugs with it.
And, LLMs will too. If they do not have the abstraction definition in their context, they also have no way to know the contract is lying.
Man that issue got way too many comments from non-contributors. I agree that this shouldn't have been merged in in it's current state, but that doesn't mean posting about it on GitHub is a worthwhile way to fix the problem.
This case is wild and seems to perfectly encapsulate all the problems people complain about with vibecoded projects.
The "rewrite it in rust" commit is +1M lines of code. Humans haven't looked at that in depth. In about a week, they saw the tests passed and pushed it to main. Now people have started to look through it and are pointing out glaring issues. And the solution is just going to be "feed it to another AI and ask it to fix it".
The entire codebase is slop now. Nobody knows what it does. It manages to pass some tests, but its largely a black box just on the basis of humans haven't read it yet. The code isn't guaranteed to be anything close to 1:1 with the old codebase. Its probably vaguely shaped like the old codebase, but new bugs could be there, old bugs could be there, nobody knows anything yet.
Its going to be interesting to see how recoverable this is. They are almost certainly going to just hand every file to an AI, say "look for soundness issues and fix them" and then what? If AI is making huge,sweeping changes to the code so frequently that humans can't keep up, is that really maintainable? The only solution appears to be "even more AI" while anybody that looks closely gets scared away by the too-large-to-comprehend-and-entirely-slop codebase.
This kind of thing has been happening with many smaller projects already, but now its a larger project and happening in a much more public way, with the intent to replace human-written, mostly-understood code with slop. I suspect the same thing, with the same problems, is happening inside all the largest companies, just not quite as obviously.
That's the idea, to transform businesses to be wholly dependent on "AI" service to develop software. What better way than to re/write entire codebases until no human being understands it.
The Zig project know this, and its so-called "anti-AI" policy is actually pro-community and cultivating human understanding. It's not about the tool or technology, per se, it's about people, knowledge, and sustainability.
In contrast, the Bun project is demonstrating how they doesn't care about any of that, YOLO-ing its way to losing the trust of its users, contributors, and maintainers. Oh well, AI will maintain the project now, since no one else can.
The one thing I can't stand about the AI zealots is their anti‑intellectualism. Even before coding agents became a thing, there were so many comments here along the lines of, "doing things properly has a learning cost! I don't have time for that nonsense because, unlike you, I'm busy actually making stuff." Now, too many people openly mock the practice of reading, writing, or understanding code altogether.
It's sad to see what hacker culture has been reduced to: outright contempt for science and engineering.
One thinking is most people writing software who are not software engineers prefer using AI because they don't think software is valuable in itself, it's only a way to solve a problem. So there are two camps, the other being people who like to solve "software problems". But this latter has been solved by AI
That's exactly thing I'm trying to call out. AI coding has attracted a flood of people whose only goal is to make a quick buck out of shoddy work. They regard science and engineering as beneath them, and they're not shy about saying it, here and elsewhere.
Any serious professional in this field knows that software development is far from a solved problem. It wasn't before LLMs, and it isn't now. Responsible development takes discipline and respect for the hard-won lessons of past and present efforts.
But no, according to many here, being responsible makes you a "luddite." "Humans make mistakes too," that's what they'll say as they'll inevitably screw over people's lives with their reckless disregard for others. "It's not my issue to solve."
Seriously, haven't techbros already caused enough damage throughout society with "move fast and break things"? A lot of people are losing patience for this nonsense.
I am not against AI code, it can be perfectly fine.
The principle issue in my mind is the rate of change.
Once you rewrite a code base like this (in a week no less) the only way to work on it in the future is using AI tools because no single person has any knowledge about any specific piece of code base any more.
AI generated code that is run through a classic PR process would potentially be fine, but then you sorta lose the entire point of using AI.
That happened to my project as well. The main issue hasn’t beet that ai couldn’t solve the problem, but it became so slow and you need more and more verification layers and CI/CD that at one point you wish a simpler codebase back, with reasonable tests, with storylines in codes and so on.
After reviewing this rewrite this morning, my only logical conclusion is that it's an elaborate marketing operation orchestrated by a super-secret Deno operative.
After this was merged, my company made the decision to migrate everything away from bun and back to node. I don't say this lightly... Jarred is a guy that I held such immense respect for, and its sad to see the course he's charted for a project I spent a lot of time proselytizing internally. Its frankly a betrayal of trust.
Maybe they want a quick switchover and the UB is replicating existing problems so it is net neutral for the codebase (but positive future coz developers can do future work on rust without synchronizing two codebase? ).
exactly. If they wanted to iterate on their port they would add lifetime annotations here, which are the tool Rust be uses to ensure safety. They're just kicking the unsafety block down the road. This accomplishes nothing and is not how you get Rust to deliver its safety promise.
Lifetimes would prevent the particular use-after-free example here, but the UB that miri currently flags would still exist, as it's related to pointer provenance, not lifetimes.
Yeah, This whole type relies on the C or C++ style "pointers as integers" hack, and while that perhaps works fine in Zig (I don't know) it's wrong or at least a bad idea in Rust. Rust wants you to prefer "integers as pointers" instead because it has different validity rules and lacks C++ "pointer zap".
In C or C++ you conventionally store a suitably large integer (uintptr_t for example) and then when you sometimes need a pointer you just cast that integer to a pointer. Under the proposed C provenance semantics PNVI-ae-udi this gets you exposed provenance.
In Rust you conventionally store a pointer, and then when you sometimes need an integer you ask for the address bits from the pointer (which on popular platforms will be the whole pointer but as an integer) or you make pointers from the integer you have with no claim to their provenance. If you're careful this gets you what Rust calls "strict" provenance, it's just straight PNVI.
So this is a clear case where the LLM generated Rust port introduced a bug:
> The Zig original is a packed struct with the same shape; it "worked" only because Zig has no reference aliasing or provenance rules to violate. The Rust port inherited the shape without rethinking the API surface.
So a "robobun" clanker responds to the issue and writes a fix (probably just papering over it). This is what Anthropic wants: Let the users do the work, train the fricking bot and claim the credit.
If you find a bug, just go straight to blog posts and CVEs to denounce this idiocy. It ranks higher on Google.
I think the only way to interpret a one million line LLM-generated diff with no proper reviews as an employee of Anthropic is that my company no longer has an interest in understanding, or even looking at, its own code.
I'd be concerned that by jumping onboard with this sort of development process I'd lose touch with how to engineer software in a detail-oriented or remotely rigorous way.
It also makes me question what sort of value the entire Bun project ever had if a drop-in replacement can just be thrown in here like it's nothing. Why do we need all these JS runtimes again?
The AI bubble is so large that we've also forgotten how useless and dumb a lot of software engineering labor was even before LLMs came along. We were already in a bubble.
All that is to say, I think it's useful to reframe some conversations about AI as, "if AI can accomplish this task, was it ever actually valuable?" I think for some specific things, the answer will be yes, but the tech industry has been huffing its own farts for so long I really don't think anyone has sight anymore of what's economically valuable in a ground truth sense. Much like LLMs themselves, this confusion pollutes the entire well of discourse about their economic utility.
When my lead developer refactored my small but crucial python service into golang with Gemini and Claude, I was hesitant to merge the code into master. Yet, my service had, like 20k daily active users.
I think they shat over the community who trusted them by trying to advertise their owner company
Sure. I'm completely unaffiliated and think Zig's AI stance is ridiculous & politically-motivated and a port is absolutely justified if they will not budge. Apparently I am deeply in the minority.
The no-AI policy of the Zig compiler project is for the compiler, other projects can do whatever they want.
Bun's fork of Zig was just an unsound hack that at best would have produced a strictly inferior speedup compared to our current work with incremental compilation, which is already plenty usable:
> The no-AI policy of the Zig compiler project is for the compiler, other projects can do whatever they want.
Well, presumably they want to contribute to the compiler. I know that you did not like those contributions, and that view seems entirely valid, but obviously "no AI" rules out their development model (by design, and you likely think that's good, and maybe it is!).
Not intending to defend the bun move, but obviously a project using Zig and also using AI might feel motivated to avoid Zig since they're ruled out as contributors.
Zig rejected Bun's proposed contribution because it was a bad contribution, which they explained at length. Zig should not be made to "budge" on bad contributions. It seems you think Zig is unreasonable for rejecting bad code that happens to also be AI-generated, but believe it's reasonable for a project to be forced to accept bad code because it is AI?
No, I think Zig should reject bad AI contributions and accept good AI contributions. That is not Zig policy, they reject all AI-authored contributions.
Not sure why you're inventing a stance for me to be arguing against, when the Zig compiler stance is publicly articulated as exactly what I'm describing.
The problem as they've mentioned is AI contributors don't learn. They cannot have a working relationship with an AI contributor. The context about ongoing efforts, planned design changes to the language, etc is lost every time Claude is run. There is no way to work with that. People will submit infinite PRs while the core devs are flooded and forced to repeat themselves an infinite number of ways to an infinite number of stochastic prompts and responses.
The zig team is not that big. They don't have 200 core contributors to filter through the noise and mine PRs for "gems".
You specifically mentioned "a port is justified if they won't budge", which comes across to me as defending Bun's situation specifically, in other words expecting Zig to budge on Bun's bad contribution specifically and because they won't this slop Rust port is justified.
I think an outright rejection of AI contributions makes sense, regardless, and has nothing to do with politics. A Zig developer was forced into writing a long-form post to justify rejecting Bun's awful contribution (lest their PR be sullied, and then it was anyways), and the act of writing that post probably took 10 or 20x more human time and effort than Bun's contribution. Now multiply that by 100 for every random fucking moron with an LLM submitting a contribution. That is not sustainable. Open source maintainers of popular projects would have to make rejecting AI PRs their full time job and stop developing the project itself altogether, if they took them seriously and reviewed at length to conclusively identify whether a PR is good or bad. Given that 99.99% of AI PRs are bad, it's simply not worth it. You cannot possibly expect humans to spend more time reviewing code than drive-by contributors spent generating it, especially when many of them are unpaid volunteers. It's an absolutely ridiculous expectation.
> An example of this is the changes to type resolution which happened in the 0.16.0 release cycle—these didn’t affect users too much, but had big implications for the compiler implementation. Before those changes, the compiler’s behavior was often highly dependent on the order in which types and declarations were semantically analyzed by the compiler. Some orders might result in successful compilation, while others give compile errors. Single-threaded semantic analysis prevented these bugs from causing user-facing non-determinism. The rewritten type resolution semantics were designed to avoid these issues, but Bun’s Zig fork does not incorporate the changes (and has not otherwise solved the design problems), which means their parallelized semantic analysis implementation will exhibit non-deterministic behavior. That’s pretty much a non-starter for most serious developers: you don’t want your compilation to randomly fail with a nonsense error 30% of the time.
There is a reason why, zig is upholding the quality and they hate it.
That doesn't pass Occam's razor. The simpler explanation is that the bans exist because people continue to throw slop at open source maintainers, and the maintainers wish to stop such unproductive contributions.
Can somebody explain what the issue is? In particular, if Rust is safe, and this is safe code, then how can there possibly be use-after-free? I thought it's the entire point of the "safe code" thing that it's ..safe by construction.
The code they are complaining about is not safe code, it is unsafe code that exposes a supposedly but not actually safe interface. They demonstrate this by using the interface to get undefined behavior.
You can see this rather directly by how miri points to the exact line of unsafe code that results in undefined behavior (which isn't something miri can always do, but it can in this instance).
To make performant code sometimes requires implementing or using "unsafe" functions (it's not obligatory, and a lot of projects don't use them; but it was probably needed to map Bun's behavior 1 to 1). Those require upholding some invariants that cannot be checked by the compiler. The compiler basically goes "I trust you on this one, programmer. If you fuck this up, unsafe behavior can propagate to the rest of the code".
It doesn't. The rust compiler exposes a rich type system by which the programmer can make safe abstractions around unsafe code that can't be misused, but it doesn't (and fairly fundamentally can't, thanks to Rice's theorem) verify that people who write unsafe code and purport to have made safe abstractions actually did so.
When I was in grad school, my mentor once said, that he didn’t actually see programming as anything more than a tool to solve the problems he needed to solve. As someone who was excited about learning to program, I couldn’t understand it. As I’ve gotten older, I’ve come to understand him more. The language a program is written should be far down the list of reasons to use a programming language. Same with who happens to be the BFDL for the language, or what streamer is using it.
What matters more is if it does what you want it to do, and is well maintained.
Certainly disagree with "AIs are not good at writing Rust". We can discuss the pros and cons of AI coding in general but in my experience they do just as well with Rust as any other language. If anything I'm impressed with how seamlessly the models can work with Rust's ownership model.
I wonder if the publicity around this AI-driven rewrite will function as a (unintentional, or perhaps intentional) far-reaching nerd snipe that results in Rust developers flocking to the project to identify and fix issues.
Sorry wasn't there a post literally like a week ago about this being a long term experimental branch and how we needed to not kick the hatchling while it's an egg?
This was 100% a predictable outcome after Bun was acquired. Of course they were going to do something like this.
What would have been significantly better is just rewriting Claude in a language that's actually well suited to what it's doing in the first place (which could well be Rust, Codex is written in it as prior art). It's funny how the vibe coding promoters are keen on things like this, rewriting other codebases as fast as possible with little quality checking, but they are still defensive of their own code.
My grandfather was a tailor, and one day a client came in asking for the status of his suit getting clean. My dad as a kid grabbed the unfinished suit and showed the man, who was frustrated at the lack of progress.
My grandpa told my dad never to show a client a work in progress - You told them when you'd get the work done, and they can see the finished result when it's ready.
It's just a story so don't wrap yourself around the axle with counter-examples. I think it's fair to say that an open-source project going through a language translation is going to have transitional periods as they shake things out, and criticizing every snapshot as some proof that they're incompetent is useless.
> oven-sh locked as off topic and limited conversation to collaborators
Strong deja-vu about that time Cursor tried to slop together a browser and tried to bury dissent when people pointed out how hilariously terrible the whole thing was.
When it comes down to it, all the vitriol and animosity towards this port is really because of the implication of what its success would mean. If LLM's are capable of completely porting core software modules many people rely on (not just a CRUD app) of 1m lines in a week's time, it is a case closed moment that LLM's are currently much more capable than most people's eng, and can do it much faster. And that's at current capabilities, nevermind where we're headed in 1-3 years.
Jarred is an exceptional 1% engineer, and its likely he can succeed at this port, to the detriment of naysayers who don't believe there's any chance it's possible.
Step 1: Vibe-code a buggy, poorly-performing, 500k+ LoC desktop-installed monstrosity in TypeScript to implement a trivial TUI. Proudly note that you’re meeting a 16ms frame budget … for a trivial chat UI.
Step 2: Purchase an entire company for a product that, if you squint, might help paper over the entirely predictable problems that arise from using the wrong tools to implement the wrong architecture, because surely the solution isn’t reevaluating your original engineering choices.
Step 3: Perform a buggy, vibe-code rewrite of the tool you just bought. A tool you only need because — for whatever internal political reasons — sunk cost means you can only keep digging.
"unsafe" is a promise to the compiler that you're going to ensure invariants that the compiler can't check. Rust only promises to eliminate UB if the invariants are held. You can still get UB by violating that promise, as this bug demonstrates.
That is not Rusts guarantee. The guarantee is that safe rust cannot in itself introduce UB - UB can only ever be introduced in unsafe blocks, but it can then materialize in safe code.
I can't tell if you're trolling but `unsafe { crash() }` is safe from the compiler's perspective. Otherwise you wouldn't be able to achieve anything in 'safe' rust, even print to stdout.
I think its a good question, just because the whole UB thing is such an ideological shibboleth.
Maybe its better to think about this in the reverse, where C and C++ has 'defined behavior', but unsafe rust intentionally does not, its just whatever the complier and platform lets you get away with. Ultimately its still just a computer which stores values in memory and jumps to subroutines.
Every language has defined behavior. It's what you expect to happen through a program's execution. Sometimes there will be multiple possibilities, but you can still define them regardless. Laying this out explicitly is the purpose of a standard.
Undefined behavior is everything else. C and C++ are relatively unique in that their standards explicitly say "combining these constructs in this way is undefined", and we call those cases explicit UB. There's also a larger universe of implicit UB that standards omit. Most (all?) languages have implicit UB, even if they lack the explicit stuff. What happens when you get ENOMEM is a common one.
Rust does something similar to C/C++ and lists a bunch of UB that's only possible with incorrect code in unsafe blocks. Correct code placed in an unsafe block remains defined, as does code without unsafe (up to compiler/language bugs).
Yeah, if I understand correctly, the Rust project has no intention to formally 'define' what unsafe actually does, so its very implicit. Could be anything... so it's the Does It Work? standard.
> I thought the unsafety couldn't "spread" like that in Rust.
The goal of a library is to provide the encapsulation such that the unsafety doesn't spread.
If undefined behavior occurs, the fault lies with whoever wrote `unsafe { ... }` in the body of a function. If I write "unsafe" in order to call an unsafe library function, and I don't meet the library function's pre-requisites, then it's my fault. If the library internally writes "unsafe" in order while providing a safe wrapper, and I never actually wrote `unsafe { ... }`. If neither I nor the library wrote `unsafe { ... }`, then it is the fault of the compiler.
Using "in safe Rust" means that `unsafe` doesn't occur either in the user code nor in the library. In this context, since we've heard how many uses of `unsafe { ... }` exist in the Bun rewrite, I'd read "in safe Rust" to mean "without calling any functions marked as unsafe".
Unsafe code can break certain invariants of Rust, as `unsafe` is just a compiler "hold my beer" flag, which is why you're meant to do safety checks in your safe interface around unsafe code. If the unsafe code is wrapped in a way that does no guarding (or does something stupid in general), it is technically marked safe (because you said "rustc, hold my beer" as `unsafe` is also a contract) despite actually being unsafe
it's more straightforward to write safe rust when rust owns everything, In real world you often are interfacing with underlying libs or systems etc, which you need to treat as invariants but also handle yousrelf manually to make guarantees to compiler. unsafe exists in tons of codebases it's just you have to make sure you encapsulate it properly, which is what this bug is.
Rust has lots of undefined behavior, in general a broadly similar set to that which exists in C. What Rust does that is different is that to trigger undefined behavior, you need to execute unsafe code. (This isn't the same as saying that you have to be in unsafe code--you can violate a precondition in unsafe code and have the UB itself trigger in safe code).
I'm sure there have been attempts at defining a language that has no UB, but afaik all meaningful languages have UB in some dark corner or enumerated explicitly. For example, Java thread execution order is UB.
In this context "UB" means something different than how you're using it. The UB being mentioned here is the "nasal demons" form, i.e., programs which contain undefined behavior have no defined meaning according to the language semantics.
What you're talking about is probably better described in this context as "unspecified behavior", which is behavior that the language standard does not mandate but does not render programs meaningless. For example, IIRC in C++ the order in which g(), h(), and i() are evaluated in f(g(), h(), and i()) is unspecified - an implementation can pick any order, and the order doesn't have to be consistent, but no matter the order the program is valid (approximately speaking).
So this "unspecified behavior" might turn into the more nasal demon type when g(), h() and i() share mutable state and assume some particular sequential order of execution. No?
Not necessarily. Unspecified behavior and undefined behavior are independent concepts; a language can have one but not the other. As a result, you can have languages where incorrect reliance on unspecified behavior can lead to undefined behavior (e.g., C and C++) and languages where incorrect reliance on unspecified behavior can lead to bugs, but not nasal demons (e.g., Java)
That would depend entirely on the assumptions being made and the constructs being used. I think in most cases it would likely just result in regular garden variety bugs.
But sure, if you're writing C++ and (for example) g is depended on for initialization of pointed memory that the other two consume you could end up with UB. But if you're writing Java then no, you will not end up with UB just buggy code.
It's not difficult to have a Special Purpose language with no UB. There isn't any UB in WUFFS (a language for Wrangling Untrusted File Formats Safely) for example.
Those "dark corners" come into the picture when you decide you want a General Purpose language.
When your program might actually intend to respond to emails by executing the x86-64 machine code squirrelled away inside this logo PNG and running the output as SQL on your customer database, it's not possible for the language to ensure that programs which weren't intended to do that can't do that, how would they know? The translator isn't a mind reader, your intent is unreadable.
I think we should use general purpose languages much less often, the industry doesn't seem to agree, the results are obvious for everyone to see.
Rust has a subset, "safe Rust" which isn't a fully general purpose language but deliberately shares its syntax with a larger unsafe Rust you can use when it turns out that you needed it. Safe Rust doesn't have UB.
It is only allowed in unsafe blocks. As long as the unsafe blocks are few and well understood then Rust programmers can contain this to a small well defined portion of a program.
Unsafe Rust allows you to tell the compiler “hold my beer”. It’s a concession to the reality that the normal restrictions of Rust disallow some semantically valid programs that you might otherwise want to write. The safeguards work great in most cases, but in some they’re overly restrictive.
In practice, the overwhelming majority of code is able to be written in safe Rust and the compiler can have your back. The majority of the rest is for performance reasons, interacting with external functions like C libraries over FFI, or expressing semantics that safe Rust struggles with (e.g., circular references).
OK but the title says "in safe Rust". Am I misunderstanding something? All the replies here are saying how it's allowed in unsafe Rust, which is not what the title says.
If code in an unsafe block triggers undefined behavior, then the assumptions the compiler makes regarding safety will no longer be true, and purely safe code (code with no unsafe blocks) is no longer guaranteed to be safe. This is what's happening in the example the person on Github wrote in the issue.
Exactly and "[...]and purely safe code (code with no unsafe blocks) is no longer guaranteed to be safe" hits the nail
on the head.
I take issue with the phrasing of OP's title: "allows for UB in safe rust". AFAIK there are compiler bugs that allow UB in safe Rust, but this is not what is happening here. We have UB in an unsafe block (which is to be expected) which enables an issue outside in safe code. What is your opinion? Is calling this "UB in safe Rust" justified?
The UB is† always in the Unsafe Rust, but that's not necessarily a problem, the problem was that we caused it from our safe Rust and that's definitely not OK.
† Soundness bugs are known to exist in Rust, but for the known ones you have to be really asking for it, so it's not plausible that they'd impact you by accident.
it is, but it's a little confusing here because the library/consumer of the library are the same person.
This is a bug in the library, namely in Bun's PathString implementation. The bug is a soundness issue, precisely because usage of Bun's PathString implementation allows for UB in safe rust. Now this buggy library isn't that big of a concern for the community, because Bun is the only consumer. It's not also an indication of a compiler bug, because Bun's library is implemented using unsafe rust. But the fundamental issue is that usage of Bun's PathString implementation allows for UB in safe rust, and is therefore (clearly) unsound.
Suppose I initialize something in an unsafe block. I promise the compiler that it's properly initialized, but in reality it isn't. Importantly I never make use of the garbage values in the unsafe block so no UB has occurred - yet.
Later, the garage enters otherwise safe machinery and triggers UB. UB has now happened in safe rust as a result of my earlier contractual violation.
You can extend this example to other scenarios where UB in unsafe begets further UB in safe later on.
Actually I think Rust says UB has occurred if you return a T which isn't properly initialized. For example if you unsafely MaybeUninit<u32>::assume_init() then Rust says that's UB even though all possible bit patterns for u32 are valid.
This is because that's not going to emit any machine code at all, and yet it will cause LLVM to do very nasty things, for example code which either prints "Odd" or "Even" by examining the integer may now print neither because that's faster and this uninitialized integer isn't odd, yet it also isn't even so...
then `safe_function` can be called from safe code, and still trigger UB. This wouldn't be a soundness issue in the rust compiler, but instead a bug in safe_function.
There are many reasons you might want to do that. In particular, it's very common in rust to have a library define some data structure that uses unsafe under-the-hood, but checks whatever invariants it needs to, and provides solely safe methods to external callers. Rust's `String` type is like this: it's (roughly) a `Vec<u8>`, e.g. heap-allocated bytes. It has the additional invariant that these bytes correspond to valid UTF8 though. See for example `push_str_slice`, which (roughly) concatenates 2 strings.
1. reserve enough space for the concatenated string within the source string
2. does some pointer arithmetic and a call to Rust's equivalent to `memcpy` (unsafe)
3. re-casts this pointer to a string object without checking that it's valid utf8 (unsafe).
While these individual calls are unsafe, `push_str_slice` checks that in this particular situation they are safe, so the stdlib authors do not mark `push_str_slice` as unsafe. It has no invariants that must be maintained by external callers.
Unsafe blocks are you saying to the compiler 'trust me bro, I know this is safe'. But often that relies on some property of the code being true in order for it to actually be safe. Generally speaking, the expectation in rust is that you either encapsulate the code that enforces whatever property you are relying on behind a safe interface, so that it's not possible for other code to use it unsafely, or that you mark the interface itself unsafe so that it's obvious that the code using that interface needs to maintain that property itself. Rust code that doesn't do this will generally be considered buggy by most rust programmers (e.g. if you find a use of safe interfaces in the stdlib that causes a memory safety violation, then you should file a ticket with the rust team), but this is essentially only a social convention of where the blame lies for a bug, not something that compiler itself can enforce (and, for example, you can violate memory safety in rust with only safe std interface by abusing OS interfaces like /proc/self/mem but this is something that most people don't think can be reasonably fixed). The main reason that rust as a language is better in this regard is that it gives much better tools for being able to express that safe interface without giving up performance and that it has the means to mark and encapsulate this safe/unsafe distinction.
Here's some links on this topic which have some examples:
Dumbest point ever.
There is no value for this issue.
I don't agree with the way they did the rewrite, but they did the rewrite, and this post contributes nothing, beside making the author seem childish.
If it had any real contribution I would have waved it off, but it really doesn't.
This tribalism and "I'm better than you"-ism and the same reason everybody hated the stack overflow community, and the rust community as well.
said it in another comment [0] - that the whole rewrite thing is just a marketing exercise by LLM merchants to try sell you plebs that their wares "work"
....Thirteen thousand two hundred and fifty five lines without comments with the word "unsafe" in them in Rust code files across this rewrite.
This is so gross.
I'm a founder of an early-stage startup. I built a precision-editing tool system (called HIC Mouse). It provides coordinate-based addressing, staged batching with atomic rollback, embedded agent guidance, and more. It works well, it's available on VS Code Marketplace, and I've worked for a year and am still grinding every day, working so hard, just to get people to think about trying it, and to get attention paid to it. I did rigorous, careful benchmark research to make sure I wasn't just fooling myself. I incorporated, built a sales pipeline, changed my life by taking a chance and launching a business, and I pound the pavement and toil in obscurity every day and night, trying so hard to get interest in my product. I check every diff painstakingly before committing. I may make tools for AI agents but I am unbelievably careful about reviewing and thoroughly testing their code, and usually rather ruthlessly editing quite a bit further beyond any initial version drafted, long before deciding it is good enough to ship. I take enormous pains to get things right and worry constantly about whether I'm doing enough to make HIC Mouse secure and performant for my users. All I want is to make my users happier and to give them a genuine way to get "surgical, precise edits" that "don't touch the other lines", like we all ask of our AI agents over and over all day if we're using AI.
Or maybe not. Here we have Bun. Who cares about 90K GitHub Stars and massive community engagement -- just go crap all over them, all at once, with this AI tripe that you obviously neither tested in any meaningful manner, nor documented, nor read, I am assuming, before merging the whole bloated mess to production. What a disgraceful way to treat your users! I would be so grateful if I had a tiny fraction of the interest in my project that the Bun team has. I could never imagine shipping this garbage in a million years.
I'm sorry to vent but this just isn't defensible. It's the very worst of AI. I'm not going to wish ill on Bun, but it just makes me sad that I spend so much effort, work so hard to do things right, and painstakingly review everything because it's not just me any more and I do have folks who depend on my code being reliable and secure. And meanwhile, Bun just gives a huge middle finger to 90k+ starred supporters not to mention the millions of users who didn't click on the star but rely on the library, by acting this disrespectfully and disgracefully towards their own users. How they didn't take one look at this and promptly revert and apologize is simply beyond me. Again, sorry to vent, but this made me irrationally mad.
But they got bought out. By the tech equivalent of private equity. Every community in the USA & in most of the world is aware what happens when the friendly neighborhood business you've supported & relied on sells.
This is an old & systemic capitalistic phenomenon more than it is anything specific to AI. Hopefully someday we can figure out a real solution.
So many people are fundamentally misunderstanding everything about this rewrite.
In fact using the word "rewrite" itself is pretty inaccurate.
As has been mentioned the goal was a port so they "could" eventually rewrite most of it to be idiomatic rust. The main benefit of this now is the compiler and being able to use these tools to fix issues that were already being hidden when it was in zig.
If you go into this codebase expecting to see idiomatic rust and get angry when it's not there, you are going in with the entirely incorrect attitude.
It's understandable how people see it as AI slop or whatever given the division among developers at the moment. But please see it for what it is instead of just jumping to conclusions.
> As has been mentioned the goal was a port so they "could" eventually rewrite most of it to be idiomatic rust.
They may have said that, but quite clearly the value they actually get out of it is getting the headline "AI reimplements complex, broadly used software in 2 weeks, but makes it way better because it's rust now" in front of a million people's eyes, only 1% of whom will ever find out it was mostly fluff
> quite clearly the value they actually get out of it is getting the headline
This is entirely disingenuous. Jarred has already made it clear what value they get out of moving off of Zig. Yes they used AI heavily to attempt this goal but I don't see what the big issue is. They haven't even released it yet and Anthropic themselves have said 0 about this.
The "headlines" thus far are really just people completely uninvolved with Bun and with all to gain by perpetrating "AI BAD".
My honest take: the big issue isn't "what if it goes wrong" its the fear that a migration of this size works out of the box and being done almost entirely by AI.
Many. Let me give you a very boring example: I use mmap in some of my programs, because it's the easiest/best way to solve the problem I was working on. Mmap is unsafe in rust, because if there are modifications to the backing file it can violate some of rust's assumptions about the behavior of memory not changing unless it was changed by the rust code.
In my application I'm able to guarantee that there is no modification to the backing file by making them read-only and ensuring nobody messes with them, but that guarantee exists outside of rust. So -- unsafe with a big SAFETY comment explaining the requirements if you use it.
Much rust code will never use unsafe. Systems code is likely to use a bit but also to know what it's doing.
Things like this port of bun are unusual and presumably transitory on the way to an implementation with minimal use of unsafe.
I was first interested in Bun because it was written in Zig. I was interested in Zig because I respected Andrew Kelley's decision-making, and his taste matched my own.
I got really excited about Bun for many reasons after that, but they essentially came down to a similar root: the decisions were ones that I respected and would probably have made myself if I had thought of them.
I was a little concerned when Bun was acquired by Anthropic, but forced myself to remain cautiously optimistic.
This behavior, though, is exactly the sort of decision-making that I don't respect. I've got nothing against Rust, but if this is how Anthropic is managing Bun, I can no longer bet on it being a reliable part of my toolkit. It isn't just the code, it's the thought behind it that I have to trust.
I was so excited by Bun for many of the use-cases I have, but this just turns me off completely. This looks like an Anthropic internal-only tool, based on the behavior.
I don't have a single reason not to pick nodejs when doing JS.
But, I warmed up to Bun over the last couple years almost against my own will — trying to maintain a pretty large body of TypeScript code in a runtime-agnostic way (including even Node, since 24.2). I don't want to make any specific TypeScript runtime a requirement for my TypeScript code, unless there are really good reasons to do so.
But Bun (like Deno) kept providing those reasons. Postgres, SQLite, S3, websockets, local secrets (Keychain/wallet), bundling, compilation, killer speed. So I (somewhat grudgingly) started using Bun more, and even made it a requirement for some of my projects (albeit, in ways I could walk back later if needed).
Today, I have a bunch of API servers and frontend app servers which are bun build --compile --bytecode single executables ,that can run and be deployed virtually anywhere.
I've been very happy with it so far. But also, I don’t think that the way I am doing it is super-common, and now that they are doing this, uh... extremely ambitious LLM port, I am perfectly positioned to regret all of my decisions around Bun if this port ends up sucking.
So I'm a little nervous, but... what if it doesn't suck? That would be cool, because a.) they will have shown something interesting about what is possible with LLMs (albeit if you are rounds-to-a-trillion-dollars valuation frontier AI lab, lol, but still). And b.) going forward, Bun will be developed in Rust. We all have our own preferences, obviously, but to me, that's a win.
And if it does suck, though — that's super interesting too! Will be annoying to me to re-architect my Bun-specific shit to Deno, but for the world at large (and me, too) that's still interesting information!
Because Bun is perfectly positioned to do a huge LLM-powered port. They are one of the premier TS/JS runtimes, it's obviously and insane marketing pillar for the AI lab that bought them, they have unfathomable resources and access to the cutting-edge models that all of us don't get to play with yet, and for all intents and purposes, they have unlimited money to do this.
So if they can't do it — which will be really obvious, I think, if true — then it really just isn't possible yet, and all the naysayers were right.
I don't know, I've followed Deno, and it appeared to me an incredibly low ambition from the get go.
What I was specifically referring to is Deno (originally) trying to fix the (glaring, fundamental) problems that Node imposes on the world, vs just do them faster.
And to offer a counter example, something like Dart appeared much more ambitious to me.
Surely we can agree that one of those positions is relatively less ambitious?
Why not both? How about that: perfectly fine for Anthropic but suck for everyone else.
but sure anthropic might not agree
However, I think if it turns out that that's the case, then their port will fail in two ways (to paraphrase Hemingway): gradually, and then suddenly.
I don't think this port can be a success unless they end up — on the other side of it, not necessarily immediately — with maintainable Rust code.
When we've seen linux having a new significant exploit every other day now thanks to LLMs being better at weaponizing memory bugs this seems significant.
But yes, URL imports have a variety of other issues (duplicated dependencies, no resource integrity), though Deno solved them in later versions (npm registry support, lock files).
The only benefit of Deno is its permissions system, which has been great for safely letting agents write and run scripts on my file system.
https://deno.com/blog/your-new-js-package-manager
* In order to follow convention, you need to decide on git web hosting infrastructure before you start writing code. The tooling asks you for a URL the moment you run 'go mod init'. My preferred way of doing things is to start work on a project just on my computer and then maybe put it on one or more online git web host eventually, if the project goes anywhere. That order doesn't work with ideomatic Go. To work around this, I write mostly non-ideomatic Go where I use the name of the project instead of a URL as a package name.
* I view hosting infrastructure as incidental. I may throw a project on GitHub. I may change my mind and move it to Codeberg. I may move it to my own git forge. I may get tired of hosting my own git forge and move it to sr.ht. With Go, each of these moves requires a huge "touch a bunch of lines in every file" style commit if you're using the ideomatic "git web host as package identifier" style required to work with 'go get'. In other languages, it requires at most a readme change, and for dependencies, it requires at most a git submodule or package manifest change.
* Go requires that you use a Go-compatible git web host. Because Go decided to make URLs look like 'example.com/foo/bar/baz/qux', it has no way to determine which part of that is the git repo and which part is a subdirectory of the repo; should it 'git clone example.com/foo/bar/baz.git' and look at the 'qux' subfolder or should it 'git clone example.com/foo.git' and look for 'bar/baz/qux'? The only solution is for Go to make an HTTP request to 'example.com/foo/bar/baz/qux?go_get=1' and parse the response HTML and look for a Go-specific meta tag which tells Go what part is a git repo. This is an immense "layering violation" and extremely ugly hack in my opinion. This feels so unnecessary too, since this is an easily solvable problem: just make URLs look like 'example.com/foo/bar/baz:qux', so that Go knows to look for 'qux' in 'example.com/foo/bar/baz.git'.
* Private repos are a horrible experience. You need to convince Go to not look them up in Google's package checksum database, you need to convince Go to not get them from Google's caching infrastructure, you need to make a ~/.netrc file with credentials, you need a git host web frontend which understands and supports the way Go + .netrc makes authenticated GET requests. If any of these things are misconfigured, you get a cryptic error message about how terminal prompts are disabled on Google's servers. It's all very brittle and hard to debug, and the guidance has changed drastically over time (editing your global .gitignore to rewrite relevant HTTP sources to use SSH used to be the advice, but that had its own significant problems).
* It has the "feeling" of being decentralized since it's all just git URLs, but in reality, Go's tooling depends heavily on Google's centralized package cache and checksum infrastructure which has been introduced over time to smooth over foundational issues with the design.
I was once part of separating a complex project out of a company and moving it to its own infrastructure on a different domain name and git host. The Rust and C++ repositories were a breeze, just change the URL in a CI job. The node.js repositories required changing some references in the source code from one NPM org name to another but were otherwise painless. The Go repositories were absolute hell.
I have considered writing a blog post about all this.
* No relative imports.
* The `require` directives from the `go.mod` files of your dependencies are always ignored.
Those two combined, mean that there's no easy way to fork a dependency. It's doable, but some of the maintenance overhead could have been avoided.
We don't even get a `go mod tidy` flag that lets us say, "yes, I understand the risks, just copy any `replace` directives that you find in my dependencies". With a flag like that, even if the `replace` directive is still copied everywhere, at least it's automatically copied during a routine `go mod tidy` invocation.
They already have `// indirect` comments, so those could have a `// indirect, replaced by X` comment or something like that.
Thanks for your time writing that. A blog post would be great.
This is optional, but also really, really handy for standalone scripts that don't need to come with a package-lock.json or deno.lock file (if you're not aware, Deno did a lot of changes to package management in later versions).
In this case, I would trust the output even less than the input. The input was memory-unsafe but hand-written. The output is memory-unsafe but also vibe-coded and has had no eyeballs on it. What is the point of abusing agentic AI for this use-case?
Have you ever seen what comes out of c2rust? It's awful. It relies on a library of functions which emulate unsafe C pointer semantics with unsafe Rust.
A few years ago, when I was struggling with bugs in OpenJPEG (a JPEG 2000 decoder), someone tried running it through c2rust. The converted unsafe rust segfaulted at the same place the C code did. It's compatible, but not safe.
Main insight: don't do string manipulation in C or unsafe Rust. It's totally the wrong tool for the job.
which is somewhat close to what their port produced...
like their goal was from the get to go to have a mostly exactly the same as zig "just in rust" which implies mostly unsafe rust and all the soundness/memory issues zig has (plus probably some more due to AI based port instead of a tool like c2ruts)
the thing is if you don't keep things mostly 1:1 with all the problems that has there is absolutely no way to review that PR or catch the AI going rogue with hallucinations etc. With a mostly 1:1 port you can at least check if things seem mostly the same.
but it also means this is just step 1 of very many, with the other being incrementally fixing soundness, removing unsafe and (hopefully) making the code more idiomatic...
(to got to the actual question of why?, I think the answer is doing this port using AI is likely way easier/faster then first writing a tool which need in depth understanding of the languages, especially given that some features in zig do not map 1:1 in rust and fuzzily mapping is what LLMs are good at and human hand written tools tend to be very bad at).
That is indeed the point of c2rust. It gives you a baseline that is semantically identical to the original codebase, and with that passing the full test suite, bug-for-bug, you can then start gradually adopting rusty idioms to improve the memory safety of the codebase.
2022 discussion on HN.[1]
There's a DARPA funded effort called TRACTOR, Translate All C To Rust, which has funded some efforts to develop a usable translator.[2] It's about 10 months after award, with no reported progress. I've been checking the personal sites of the academics involved, and they barely mention the project, although $5 million has been allocated to it.[3] The approach comes from U.C. Berkeley - let the LLM generate slop, check it using formal methods.[4] Not expecting near-term results.
[1] https://news.ycombinator.com/item?id=30169263
[2] https://csl.illinois.edu/news-and-media/translating-legacy-c...
[3] https://chandrasekaran-group.github.io/
[4] https://metalift.pages.dev/
There are also some papers being published that were funded by TRACTOR, such as https://homes.cs.washington.edu/~mernst/pubs/c-rust-macros-p...
Here are the test cases for evaluation #1.[1] There's good coverage of the C language, but the individual tests are mostly simple exercises of one C feature. The next round of test cases will probably be closer to useful programs.
[1] https://github.com/DARPA-TRACTOR-Program/PUBLIC-Test-Corpus
That doesn’t really mean anything.
> It's more verbose than the original and harder to work on, but no safer. You lose the C idioms that people understand, while not gaining Rust idioms.
Yes, and?
The value of c2rust is that you now have the entire codebase working with the rust toolchain, you’re not juggling toolchains and you’re not managing a wavefront of FFI, only a wavefront if unsafe.
C2rust is not the end, it’s the start. It’s never claimed to be anything more (the official website even mentions galois and immunant are working on tooling to convert unsafe to safe / idiomatic rust though i don’t know if that got anywhere yet).
I'm much more bullish on the opposite approach. Perform the naive translation, let the LLM loose on cleaning it up...
its not cynical, its a real question. not trying to be mean but saying that something that people have solved countless time shouldnt be done is weird statement.
This is awful. They have some internal string format borrowed from a Zig library where the address of the item is in the low end of a pointer and the length is at the high end. Why are they doing that in 2026? It lets you save a few bytes at best. It doesn't enforce the Rust rule that strings must be strict UTF-8. It's totally alien to the safe way Rust handles strings.
[1] https://github.com/oven-sh/bun/blob/main/src/bun_core/string...
Judging by the name, nor should it, because OS-paths aren't always UTF-8. See for example the rust standard library type OsString https://doc.rust-lang.org/std/ffi/struct.OsString.html
The rust std library string is a reasonable default, but it's not always the right choice. Lots of projects use different things for good reasons.
Yes and that would be safer than the current slop translation, because c2rust does these ugly things exactly to avoid introducing new issues with the more strict Rust semantics.
It _already was and should_ be that awful to match the original code without introducing hundreds of new UBs like the current situation.
They did ;) a highly dynamic one...
This doesn’t work like you think it does. These things are full of errors and make the code very verbose and hard to reason about. It works with small apps, not entire rewrites.
Translating zig -> rust is more complex than writing a JPEG parser in static python and then lowering it into zig and rust differently using idiomatic construct for each language.
Towards that end, I've created a parser for a dialect of python which is suitable for this purpose. It should maintain compatibility with the vast majority of python code out there, while picking up some rust/zig features that make translation easier. JPEG parser included in the assets of the skill for a flavor.
https://github.com/py2many/static-python-skill
https://github.com/py2many/spy-ast
The issue isn't the existence of undefined behavior that miri would catch. The issue is exposing an API that allows undefined behavior from safe code - which miri only catches if you go write the test that proves it.
This isn't an all together unreasonable thing to happen during an initial port of code from an unsafe language. You can, and the bun team seems to be, go around later and make sure that the functions where you wrap unsafe code does so correctly. Temporarily in a porting stage incorrectly marking some unsafe functions as safe isn't a real issue. It's a bit strange to merge it into the main repo in this state, but not a wholly unreasonable thing to do if the team has decided that they're definitely doing this. The only real issue would be if they made an actual release with the code in this state.
It's also a bit unfortunate that they didn't immediately set up their tests to run in miri if only because LLMs respond so well to good tests - I know they didn't do this not because of this github issue (which doesn't demonstrate that) but because there's another test [1] that absolutely does invoke undefined behavior that miri would catch. Though the code it's testing doesn't actually appear to be used anywhere so it's not much of a real issue. That said it's obviously early in the porting process... maybe they'll get around to it (or just get rid of all this unsafe code that they don't actually need).
[1] https://github.com/oven-sh/bun/blob/4d443e54022ceeadc79adf54... - the pointers derived from the first mutable references are invalidated by creating a new mutable reference to the same object. In C terms think of "mutable reference" as "restrict reference which a trivial mutation is made through". It's easy to do this properly, derive all the pointers from the same mutable reference, it just wasn't done properly.
PS. Spamming github just makes people less likely to work in the open. Please don't. We can all judge this work just fine on third party sites.
PPS. And we might want to withhold judgement until it's in a published state. Judging intermediate working states doesn't seem terribly fair or interesting to me.
If you are making a full rewrite and have non-working, in-progress code, you use a branch. This way you can still have the working "main", in case there is a security fix needed or something.
Couldn't a case be made that it's better to get Bun to the to the language with the stronger type system first and, once there, use that stronger type system as leverage for these kinds of improvements as a follow-on effort? It seems preferable to requiring perfection on the very first step.
This is what they are doing.
They are working through the issues as they come in.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
What is a bit disappointing is that the Rust code apparently has APIs that aren't marked unsafe but may cause UB anyway. When doing this kind of translation, I'd always err on the side of caution and start by marking all/most things unsafe. Or prompt the slopbots to do the same I guess.
Then you can go in and verify the safety of individual bits step by step.
This is expected, because unsafe rust can leave your program in an unhealthy state, since the language doesn't doesn't hold your hand anymore.
The bar for matching tsc's behavior is really _really_ high. see:
https://github.com/type-challenges/type-challenges
I'm not against using LLMs to write a lot of code. But verification should be 100x more robust now that we can output code at this rate.
It shouldn't be shocking, it was done using only compute, and the codebase is owned by the company who owns the compute, you literally just turn the dial up and it will be done faster. Efficacy of LLMs aside - anything they could do in 30 days they could also do in 3, if you spend more money.
- Test before code, Bun had lots of test so that's good but maybe they could start by asking Mythos to write like 20k additional tests that pass on Zig Bun first.
- Deterministic anti-slop features. LLMs love to solve the problem in the wrong abstraction layer or place. There are many ways to catch this with deterministic tests. I do this in tsz a lot
- Roadmap that constantly evolving by humans.
- Taking a pause and looking how the progress is going and undoing slop
- Fuzztest(https://github.com/google/fuzztest) style "trying to break things" with the powers of LLM
This is awesome. Typescript really needs more of this. I hope this gets more publicized and perhaps get adopted by Microsoft.
I am not sure you should call it sound mode though.
> It is not a mathematical proof of soundness, and it does not make third-party .d.ts files truthful.
Here there are two completely unrelated things
First, soundness is a mathematical thing (sorry). If something is sound, it's really really sound. Soundness is the thing that says we don't need to manually check the details - we can trust the compiler to do the right thing. It will do the wrong thing if there's a bug, but the implementation can be fixed. Soundness means there's is no bug in the spec, no bug in the type system that would make things go wrong even in theory.
Second, and here's the important thing.. it's entirely okay and expected that real world languages need to have unchecked features where we trust the humans to do the right thing, rather than trusting the compiler to verify. That's like Haskell's unsafeCoerce or Java's sun.misc.unsafe. The problem really is when the type system breaks even when we don't do any of those
But TypeScript could be sound if you eliminate all these cases. If that's the goal of "SoundMode" then the name sounds fair to me.
Not even sure `.d.ts` files are a problem in this regard. They are like axioms/facts. Resolution (from formal logic) is a sound inference rule but you can still derive contradictions from contradicting facts.
This is basically the same argument made for C++ and I think it's not a very solid one. We know this worked, but that's not evidence that alternatives couldn't have succeeded. I think in a world where Queen never happened the prevailing wisdom would be that someone like Farrokh Bulsara (Freddie Mercury) can't be a rockstar because that seems ridiculous.
Actually speaking of royalty, Prince is an even more extreme case. You cannot use numeral-letter substitutions in song titles, that's something for kids and won't... oh unless you're Prince. Yeah, no, "Nothing Compares 2 U" is fine Prince, thanks.
My goal with tsz is to make it practical and useful. I know how difficult it is to convince a tsc user to try something not officially from Microsoft
If I was the bun maintainers I wouldn't want to have to maintain a language fork either, when there are viable alternatives.
Now with LLM's getting stronger and stronger a rewrite like this is getting more and more viable, and it looks like they are just approaching this like the "how do you eat an elephant? One bite at a time"-method.
Not sure why people thing this is an elaborate PR campaign, we already know LLM's are increasingly powerful for coding tasks.
This asymmetry is well understood by marketing and PR professionals, and actively exploited.
[0] https://en.wikipedia.org/wiki/Trust_Me,_I%27m_Lying
It is. We’re what, a week into this exercise? Absolutely everyone criticizing it, with no exceptions, is behaving like a micromanaging middle manager who couldn’t even dream of doing the work themselves.
I half want to start a list of “people to ignore”, but such people tend to expose themselves in every other comment anyway.
> Please don't post comments saying that HN is turning into Reddit. It's a semi-noob illusion, as old as the hills.
Did they even claim it was "memory-safe"? Every discussion of this topic has had dozens of comments noting that their vibed codebase is bursting at the seams with unaudited unsafe blocks, lightly reviewed by people who seem to not only seem to not understand Rust, but who seem incensed at the idea of needing to understand any programming language in the first place.
They did cite Rust's safety as a motivating factor for the port. That doesn't imply trying to achieve that simultaneously with the language change — which is good, because that would be insane. (Or, if you prefer, even more insane.)
You cannot faithfully port a codebase to a new language while also radically re-architecting it. You have to choose.
They want the safety benefits of Rust going forward; i.e., after it's finished, when they then write new code in Rust.
The newer posts go into detail about the rearchitecting that follows.
they didn't,
actually the port is trying to be mostly 1:1 and in turn is mostly unsafe rust, which means no benefits initially
but also doing the 1:1 port to mostly unsafe rust is also only the first step of a full port, you then incrementally go through it fixing issues and remove "unsafe" usage. (And long term likely also doing some refactoring to using more idiomatic rust, but that has less priority).
The problem is there was no blog port describing the whole thing to someone without contextual knowledge. Instead just linked PRs which is in this case somewhat close to a "as if nearly all people only read the HN headline" case :/
Like a more context giving version of the first HN post would have something on the line of `Show HN: Bun is porting to safe rust (PR link), starting with an AI based automatized port to mostly unsafe rust which once it behaves mostly the same as Bun in the test suite will likely be merged. But must be followed up with incremental PRs to remove unsafeness, and likely also a lot of unsoundness related to the way it's ported (some explanation about why this port will have unsoundness).`
The "1:1" assumption is a massive unjustified assumption. Rust and Zig have different memory models, so it's possible to do a "1:1" translation of Zig code to Rust and end up with undefined behavior in Rust.
For example, Zig code might make assumptions about lifetimes based on implicit knowledge of which allocator was used for some memory. That could cause problems in Rust if you erase the lifetime https://github.com/oven-sh/bun/blob/main/src/bun_core/string...
It's not, that's clear from this kind of bug popping up. Functionally this bug exists because `PathString` was converted into a "safe" Rust API but still works the same internally as the original Zig code did (via using `unsafe`), that introduces UB that wasn't there in the Zig code.
If it was attempting to be a 1:1 with no behavior changes (like c2Rust attempts to do) then this would not have been turned into a "safe" Rust API like this.
And indeed, this is very much what Rust was designed to do with the ability to interface with existing C/C++ code in both directions. So this is the strategy that the designers of the language had in mind from the early days. It's a deliberate choice to offer this, and not an emergent property that was later discovered.
You have couched this correctly, because we all know there are people out there who do go around yelling "Rewrite it in X" without thought (where X is the flavour of the month)
I also wanted to say - your description of the /right/ way to align a project with tech X is a restatement of Martin Fowler's "Strangler pattern"
Can you edit your post - "equation because deteting errors" is ambiguous - deleting, or detecting - I cannot work out which you mean
should be
> equation because detecting errors
Thanks for the catch, did the edit.
I am genuinely jealous.
Also, I know you made a typo, but it did make me laugh
Bogeymen is what you meant
Boogymen reminds me of the joke in Millenium Man (How do you make a handkerchief dance - put a little boogie in it)
Makes you think who is who in this situation. Bullies screaming they are the victims.
In fact it's the only technology known to humans to never have had any such thing.
Puhleease.
What I'm trying to say is that if you see Rust evangelists everywhere, your label is either so wide-ranging as to be useless or you need to rm your rust_evangelist_evidence.txt because it's likely taking up a disproportionate amount of headspace.
Your claim was clear - only people anti Rust show up in your mentions - and your own logic points out that that's because of your attitude wrt Rust.
Nothing else justifies (not that your position is justified) jumping in as a cheerleader for the other poster
You're backtracking now because you've realised the folly of your claim, and how disingenous it was for you to make the claim.
And - the number of times I have been grossly downvoted for daring to utter a true word about Rust (or even Rust adjacent) will let you know your non-existent Rust evangelists are indeed the bullies - with one now screaming that he is a victim.
If you want definitive proof - look at this sub thread where you're so triggered that people talk about the mere existence of Rust evangelists (and evangelists exist for every tech - they always have and always will - which you would know given your [claimed] history in the field) that you want to argue they they aren't evangelists, they're just poor misunderstood victims.
Note: I say claimed not as a jab but because I don't know you and can only go on your claims in your profile.
Surely you mistyped that part of your comment with the one I wrote above, right? Understandable.
I guess we'll have to agree that we live in parallel realities though, reading your comment -- which I do find genuinely puzzling. Because I keep not seeing evangelists and the only one using troll-like language here is you, not me ("triggered", really?).
I am looking at the sub-thread. I guess I need new glasses. Still not seeing anyone fanatical / zealot or whatever. What I see are people who try to ground a discussion because a top comment happily tears down a straw man, and those comments are attempting to show that.
> Note: I say claimed not as a jab
Oh, I am sure. Your comment absolutely cannot be mistook for that.
"No true Scotsman" detected
and
>> Note: I say claimed not as a jab
> Oh, I am sure. Your comment absolutely cannot be mistook for that.
I made an explicit note because I suspected that you were going to take it as such (and, as demonstrated by the sarcasm in your response, you did)
Have a nice day bud - nobody has changed their mind - it's been real.
Be more awesome, dude. :)
Editing the comment out now, thanks for pointing out the typos!
It's simply not possible to include all the nuance of safety of a language and all software written in it a single word. This leads to all kinds of miscommunication and strawmanning.
Rust's official line is specific memory safety guarantees, with caveats that it must not be broken by unsafe code, the OS, compiler bugs may happen, etc. Rust also has a bunch of best-effort features that steer users towards more robust code, but can't guarantee it.
This gets twisted in both directions:
- people ignore the caveats and limitations, pretending that Rust promised zero bugs ever, and use any bug in any Rust program as a proof by contradiction that Rust's claims are false.
- or focus solely on the caveats, ignoring all the advancements and incremental improvements, and take a "then why even bother?" There are classes of bugs Rust can't stop. Nothing is foolproof for a sufficiently advanced fool, and an infallible programmer could write bug-free code in any language, which creates a false equivalence between languages.
In your quote, there is no time-dependency between the lie and the truth. Whereas here, it's an attractive lie (easily parsed, great narrative), followed up by truths (that need more than surface-level analysis).
The rewrite was a code translation meant to be a starting point.
> a big, flashy announcement (here: bun was re-written in memory-safe rust in a couple weeks), and the relatively small reach of a correction (often just a footnote on an old article, here a GH issue).
The Bun team never made a big announcement that the code is now memory safe. They've been clear that this is the starting point.
Anyone expecting it to be perfect immediately and to have solved all of the memory problems in the original Zig code is arguing with an announcement they imagined, not what the Bun team has said.
Did anyone try to map this code back to the original codebase to see if this memory problem exists in the original codebase?
FWIW what is being discussed is not memory problems, it's breaking rust invariants (the unsafe code has to follow specific rules, e.g. annotate lifetimes properly).
c’mon.
Yes, tools like Miri, which this very post is about.
I've seen large rewrites and migrations take both approaches -- in my experience, the former usually works out better.
Then I realized that the github ui was auto-collapsing a dozen messages in a row that were all completely devoid of any informational value and certainly sourced from forums and community discord channels.
This places everyone in a no-win situation. Someone who has identified critical issues that they believe the majority of a relevant community would be concerned about has good reason to signal-boost as much as they can.
It's a substantial request about very recent changes, and tone-policing it doesn't make it less true. The problem is that the additional attention literally kills the discussion. This also provides cover for people who may be making more emotive or ai-psychosis influenced decisions on the maintainer side.
Projects with a siege mentality which block and ignore criticism tend to go off the rails very quickly. On the other hand, maintainer burnout is inevitable for projects which can't shield maintainers from the anxieties and pathologies of people who seem to think that if they complain about AI enough, everyone else will stop trying to use and improve it it.
Thus far most of the buzz and marketing has been entirely negative from people who are against AI.
My take is that most of the buzz is also tied to recent negative opinions of Anthropic themselves due to some of their recent decisions.
citation needed
> and continue pushing the boundaries and our imaginations onward.
what percentage are doing it pro bono?
To me it seems like quite a lot of it is also by people who spent years maintaining a codebase just to have the metaphorical rug be pulled out from under their feet, and feel that a migration like this might be kind of disrespectful (how many of the people that have gotten good at Zig and know the codebase will find the switch over to Rust easy)? Or in some cases, that it's just bad engineering - instead of releasing it alongside the main project and focusing on gradually getting parity over months, it just got merged into the main branch.
On a more practical note, however - if you get acquired by a company that gives you almost unlimited usage of tools that might help you migrate to a language, that 3 years down the line will lead to a better codebase than today, then I guess it also makes sense to take that chance.
And of course, you get a lot of people who are opposed to AI on principle, as you said.
It's not that they're using AI, it's the massive rug pull on bun users.
* Make a huge deal out of it how “Claude Code enabled Bun team to rewrite 1+ mil of Zig lines to Rust” and write a blogpost, VCs are salivating
* Basic checks fail
* Let Mythos rip the codebase to shreds, spend God knows how much more
* Write a separate blogpost
* Charlatans and smooth brains clap and defend against “delusional anti-AI mob”
* VCs orgasm even harder
Clap, clap, clap. That’s how you make money, folks.
And btw, we need to get rid of software engineers now.
I mean, the phrase "Zig to Rust port of Bun" makes little sense even to many professional developers. They may know Rust, might have heard of Zig, very likely don't know what Bun is.
So the fact that this gets any attention at all says something.
> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.
It’s just a standard Pavlovian response of a bootlicker, it can also be triggered if you mention “tax the rich” and “regulate AI hyperscalers”.
https://news.ycombinator.com/item?id=48073680 (seems like just a normal user - enthusiast at best)
https://news.ycombinator.com/item?id=48132488 (this one seems suspicious - 2 year old user with this being their only submission ever and they have zero comments - anthropic could have submarined it but it's not a big flashy announcement)
https://news.ycombinator.com/item?id=48150900 (this thread - user is anti-AI and anti-datacenter)
But definitely the one thing these things aren't are big flashy announcement. To be honest, this kind of post-truth environment where people just make up things about people they don't like are super-lame. I've generally been able to deal with it by kill-filing people who post falsehoods but the number of users who do is getting so extraordinarily large I am starting to believe that I need to auto-hide anyone who created an account in the last 10 years.
But tbh this is trivial to write these days since the boilerplate can be written by the machines and you can just write the core functionality to make it work. I only have it public because I'm hoping others will also block users who misinform as a habit and I can subscribe to their lists and crib off their work without having to do it myself.
If you want to save yourself the first 15 min of prompting, just point Claude Code at this https://github.com/TechnologyBrotherhood/overmod-extension and ask it to implement the local blocking functionality.
I separate mine by a bunch of categories which might be a bit complicated, but I was hoping perhaps people might not care about some of the categories https://wiki.roshangeorge.dev/w/Overmod#My_Stuff
e.g. I don't like endless repetitious "but corporations" stuff and I also don't like "but they sell your data" repetitively but maybe others want to block category A but not category B.
I think that wasn't a sound idea, though. Either people trust you to block for them as well or they don't.
Isn't the whole point of AI companies using Rust that it's explicit, safe, and AIs are fairly good at writing it?
In particular, if you have a situation that requires any kind of conceptual understanding then AI will likely have issues. Sync blocking async is the classic example. My theory is that humans make this worse because they will often prompt in a certain direction and AI will faithfully build the footgun.
Related: If AI writes your code, why use Python? (which notes why Rust has taken off for LLMs) https://news.ycombinator.com/item?id=48100433
Also the LLM is inventing ways to get around borrow checker limitations with unsafe which is also concerning. But I didn't verify if they are UB or not (either way it's a rejection if I'm to review the code).
In a nutshell, the LLM created abstractions that allow you to write unsound code in safe rust, which is squarely against the language.
To be specific: the abstraction takes a (shared) reference and uses unsafe to wrap it in an owned object, completely erasing le lifetime. In practice, this means users of the abstraction think they own the underlying memory: they choose when to free it. However, it just wraps a pointer that’s owned by someone else (it was a shared reference, remember?), thus it will be freed when you don’t expect it.
So why does it not exist in Zig: it’s a false contract about what it is. The Zig pointer is a pointer with no added lifetime information. You can hold a Zig pointer wrong, but you will hold a lying abstraction wrong. You will misuse it because it doesn’t do what’s written on the tin. You will write bugs with it.
And, LLMs will too. If they do not have the abstraction definition in their context, they also have no way to know the contract is lying.
The "rewrite it in rust" commit is +1M lines of code. Humans haven't looked at that in depth. In about a week, they saw the tests passed and pushed it to main. Now people have started to look through it and are pointing out glaring issues. And the solution is just going to be "feed it to another AI and ask it to fix it".
The entire codebase is slop now. Nobody knows what it does. It manages to pass some tests, but its largely a black box just on the basis of humans haven't read it yet. The code isn't guaranteed to be anything close to 1:1 with the old codebase. Its probably vaguely shaped like the old codebase, but new bugs could be there, old bugs could be there, nobody knows anything yet.
Its going to be interesting to see how recoverable this is. They are almost certainly going to just hand every file to an AI, say "look for soundness issues and fix them" and then what? If AI is making huge, sweeping changes to the code so frequently that humans can't keep up, is that really maintainable? The only solution appears to be "even more AI" while anybody that looks closely gets scared away by the too-large-to-comprehend-and-entirely-slop codebase.
This kind of thing has been happening with many smaller projects already, but now its a larger project and happening in a much more public way, with the intent to replace human-written, mostly-understood code with slop. I suspect the same thing, with the same problems, is happening inside all the largest companies, just not quite as obviously.
That's the idea, to transform businesses to be wholly dependent on "AI" service to develop software. What better way than to re/write entire codebases until no human being understands it.
The Zig project know this, and its so-called "anti-AI" policy is actually pro-community and cultivating human understanding. It's not about the tool or technology, per se, it's about people, knowledge, and sustainability.
In contrast, the Bun project is demonstrating how they doesn't care about any of that, YOLO-ing its way to losing the trust of its users, contributors, and maintainers. Oh well, AI will maintain the project now, since no one else can.
It's sad to see what hacker culture has been reduced to: outright contempt for science and engineering.
Any serious professional in this field knows that software development is far from a solved problem. It wasn't before LLMs, and it isn't now. Responsible development takes discipline and respect for the hard-won lessons of past and present efforts.
But no, according to many here, being responsible makes you a "luddite." "Humans make mistakes too," that's what they'll say as they'll inevitably screw over people's lives with their reckless disregard for others. "It's not my issue to solve."
Seriously, haven't techbros already caused enough damage throughout society with "move fast and break things"? A lot of people are losing patience for this nonsense.
I am not against AI code, it can be perfectly fine.
The principle issue in my mind is the rate of change.
Once you rewrite a code base like this (in a week no less) the only way to work on it in the future is using AI tools because no single person has any knowledge about any specific piece of code base any more.
AI generated code that is run through a classic PR process would potentially be fine, but then you sorta lose the entire point of using AI.
There’s no way they had time to review the code. This just seems so wildly irresponsible for such an important and high profile project.
But I think their true strategy is to have AI produce "fixes" like these which will end up infecting the entire codebase: https://github.com/oven-sh/bun/pull/30728
It's been like a day since the merge, presumably such followups are coming.
https://www.reddit.com/r/rust/comments/1hxjdvp/eli5_what_is_...
In C or C++ you conventionally store a suitably large integer (uintptr_t for example) and then when you sometimes need a pointer you just cast that integer to a pointer. Under the proposed C provenance semantics PNVI-ae-udi this gets you exposed provenance.
In Rust you conventionally store a pointer, and then when you sometimes need an integer you ask for the address bits from the pointer (which on popular platforms will be the whole pointer but as an integer) or you make pointers from the integer you have with no claim to their provenance. If you're careful this gets you what Rust calls "strict" provenance, it's just straight PNVI.
> The Zig original is a packed struct with the same shape; it "worked" only because Zig has no reference aliasing or provenance rules to violate. The Rust port inherited the shape without rethinking the API surface.
If you find a bug, just go straight to blog posts and CVEs to denounce this idiocy. It ranks higher on Google.
I'd be concerned that by jumping onboard with this sort of development process I'd lose touch with how to engineer software in a detail-oriented or remotely rigorous way.
It also makes me question what sort of value the entire Bun project ever had if a drop-in replacement can just be thrown in here like it's nothing. Why do we need all these JS runtimes again?
The AI bubble is so large that we've also forgotten how useless and dumb a lot of software engineering labor was even before LLMs came along. We were already in a bubble.
All that is to say, I think it's useful to reframe some conversations about AI as, "if AI can accomplish this task, was it ever actually valuable?" I think for some specific things, the answer will be yes, but the tech industry has been huffing its own farts for so long I really don't think anyone has sight anymore of what's economically valuable in a ground truth sense. Much like LLMs themselves, this confusion pollutes the entire well of discourse about their economic utility.
I think they shat over the community who trusted them by trying to advertise their owner company
"Zig, let me Ai you"
"no"
*Ai's Zig fork, suffers from memory bugs*
"Well I'm moving!"
*Ai's code into Rust, suffers from memory bugs*
Bun's fork of Zig was just an unsound hack that at best would have produced a strictly inferior speedup compared to our current work with incremental compilation, which is already plenty usable:
- June 2025 core team starts using it with the zig compiler itself https://ziglang.org/devlog/2025/#2025-06-14
- April 2026 https://ziglang.org/devlog/2026/#2026-04-08
> Zig's AI stance is ridiculous & politically-motivated
It's literally an issue with our business model to mess with our contributor pipeline, can't get more concrete than this.
https://kristoff.it/blog/contributor-poker-and-ai/
Well, presumably they want to contribute to the compiler. I know that you did not like those contributions, and that view seems entirely valid, but obviously "no AI" rules out their development model (by design, and you likely think that's good, and maybe it is!).
Not intending to defend the bun move, but obviously a project using Zig and also using AI might feel motivated to avoid Zig since they're ruled out as contributors.
Not sure why you're inventing a stance for me to be arguing against, when the Zig compiler stance is publicly articulated as exactly what I'm describing.
The zig team is not that big. They don't have 200 core contributors to filter through the noise and mine PRs for "gems".
I think an outright rejection of AI contributions makes sense, regardless, and has nothing to do with politics. A Zig developer was forced into writing a long-form post to justify rejecting Bun's awful contribution (lest their PR be sullied, and then it was anyways), and the act of writing that post probably took 10 or 20x more human time and effort than Bun's contribution. Now multiply that by 100 for every random fucking moron with an LLM submitting a contribution. That is not sustainable. Open source maintainers of popular projects would have to make rejecting AI PRs their full time job and stop developing the project itself altogether, if they took them seriously and reviewed at length to conclusively identify whether a PR is good or bad. Given that 99.99% of AI PRs are bad, it's simply not worth it. You cannot possibly expect humans to spend more time reviewing code than drive-by contributors spent generating it, especially when many of them are unpaid volunteers. It's an absolutely ridiculous expectation.
> An example of this is the changes to type resolution which happened in the 0.16.0 release cycle—these didn’t affect users too much, but had big implications for the compiler implementation. Before those changes, the compiler’s behavior was often highly dependent on the order in which types and declarations were semantically analyzed by the compiler. Some orders might result in successful compilation, while others give compile errors. Single-threaded semantic analysis prevented these bugs from causing user-facing non-determinism. The rewritten type resolution semantics were designed to avoid these issues, but Bun’s Zig fork does not incorporate the changes (and has not otherwise solved the design problems), which means their parallelized semantic analysis implementation will exhibit non-deterministic behavior. That’s pretty much a non-starter for most serious developers: you don’t want your compilation to randomly fail with a nonsense error 30% of the time.
There is a reason why, zig is upholding the quality and they hate it.
The code they are complaining about is not safe code, it is unsafe code that exposes a supposedly but not actually safe interface. They demonstrate this by using the interface to get undefined behavior.
You can see this rather directly by how miri points to the exact line of unsafe code that results in undefined behavior (which isn't something miri can always do, but it can in this instance).
What matters more is if it does what you want it to do, and is well maintained.
1 week turnaround I guess is what they meant.
Will definitely use that going forward
Didn't find anything on my existing vibecoded rust projects but can't hurt
- Its a throw thing at the wall and see what sticks situation
- LLMs will improve*
- Using LLMs in an agentic way will improve (git worktrees, sliced PRs, spec driven steps)
So what happened here is a mess, but you gotta break a few eggs to make a souffle.
It's a learning step and I am glad it happened, there will be so many things to debrief from this.
I don't use Bun or Rust but fair play to them having a punt.
<Shameless plug> I have been working with Claude code to spec out and bring back to life a Spring Boot starter library for Apache Solr search
https://github.com/tomaytotomato/spring-data-solr-lazarus
There were a few points I had to steer it but the result has been a good implementation.
What would have been significantly better is just rewriting Claude in a language that's actually well suited to what it's doing in the first place (which could well be Rust, Codex is written in it as prior art). It's funny how the vibe coding promoters are keen on things like this, rewriting other codebases as fast as possible with little quality checking, but they are still defensive of their own code.
I guess they can just hook up the agent to Miri checks and let it grind away, and see what happens.
My grandpa told my dad never to show a client a work in progress - You told them when you'd get the work done, and they can see the finished result when it's ready.
It's just a story so don't wrap yourself around the axle with counter-examples. I think it's fair to say that an open-source project going through a language translation is going to have transitional periods as they shake things out, and criticizing every snapshot as some proof that they're incompetent is useless.
Strong deja-vu about that time Cursor tried to slop together a browser and tried to bury dissent when people pointed out how hilariously terrible the whole thing was.
Jarred is an exceptional 1% engineer, and its likely he can succeed at this port, to the detriment of naysayers who don't believe there's any chance it's possible.
Step 2: Purchase an entire company for a product that, if you squint, might help paper over the entirely predictable problems that arise from using the wrong tools to implement the wrong architecture, because surely the solution isn’t reevaluating your original engineering choices.
Step 3: Perform a buggy, vibe-code rewrite of the tool you just bought. A tool you only need because — for whatever internal political reasons — sunk cost means you can only keep digging.
Step 4: ???
Maybe its better to think about this in the reverse, where C and C++ has 'defined behavior', but unsafe rust intentionally does not, its just whatever the complier and platform lets you get away with. Ultimately its still just a computer which stores values in memory and jumps to subroutines.
Undefined behavior is everything else. C and C++ are relatively unique in that their standards explicitly say "combining these constructs in this way is undefined", and we call those cases explicit UB. There's also a larger universe of implicit UB that standards omit. Most (all?) languages have implicit UB, even if they lack the explicit stuff. What happens when you get ENOMEM is a common one.
Rust does something similar to C/C++ and lists a bunch of UB that's only possible with incorrect code in unsafe blocks. Correct code placed in an unsafe block remains defined, as does code without unsafe (up to compiler/language bugs).
The goal of a library is to provide the encapsulation such that the unsafety doesn't spread.
If undefined behavior occurs, the fault lies with whoever wrote `unsafe { ... }` in the body of a function. If I write "unsafe" in order to call an unsafe library function, and I don't meet the library function's pre-requisites, then it's my fault. If the library internally writes "unsafe" in order while providing a safe wrapper, and I never actually wrote `unsafe { ... }`. If neither I nor the library wrote `unsafe { ... }`, then it is the fault of the compiler.
Using "in safe Rust" means that `unsafe` doesn't occur either in the user code nor in the library. In this context, since we've heard how many uses of `unsafe { ... }` exist in the Bun rewrite, I'd read "in safe Rust" to mean "without calling any functions marked as unsafe".
In this context "UB" means something different than how you're using it. The UB being mentioned here is the "nasal demons" form, i.e., programs which contain undefined behavior have no defined meaning according to the language semantics.
What you're talking about is probably better described in this context as "unspecified behavior", which is behavior that the language standard does not mandate but does not render programs meaningless. For example, IIRC in C++ the order in which g(), h(), and i() are evaluated in f(g(), h(), and i()) is unspecified - an implementation can pick any order, and the order doesn't have to be consistent, but no matter the order the program is valid (approximately speaking).
So this "unspecified behavior" might turn into the more nasal demon type when g(), h() and i() share mutable state and assume some particular sequential order of execution. No?
But sure, if you're writing C++ and (for example) g is depended on for initialization of pointed memory that the other two consume you could end up with UB. But if you're writing Java then no, you will not end up with UB just buggy code.
Those "dark corners" come into the picture when you decide you want a General Purpose language.
When your program might actually intend to respond to emails by executing the x86-64 machine code squirrelled away inside this logo PNG and running the output as SQL on your customer database, it's not possible for the language to ensure that programs which weren't intended to do that can't do that, how would they know? The translator isn't a mind reader, your intent is unreadable.
I think we should use general purpose languages much less often, the industry doesn't seem to agree, the results are obvious for everyone to see.
Rust has a subset, "safe Rust" which isn't a fully general purpose language but deliberately shares its syntax with a larger unsafe Rust you can use when it turns out that you needed it. Safe Rust doesn't have UB.
Unsafe Rust allows you to tell the compiler “hold my beer”. It’s a concession to the reality that the normal restrictions of Rust disallow some semantically valid programs that you might otherwise want to write. The safeguards work great in most cases, but in some they’re overly restrictive.
In practice, the overwhelming majority of code is able to be written in safe Rust and the compiler can have your back. The majority of the rest is for performance reasons, interacting with external functions like C libraries over FFI, or expressing semantics that safe Rust struggles with (e.g., circular references).
I take issue with the phrasing of OP's title: "allows for UB in safe rust". AFAIK there are compiler bugs that allow UB in safe Rust, but this is not what is happening here. We have UB in an unsafe block (which is to be expected) which enables an issue outside in safe code. What is your opinion? Is calling this "UB in safe Rust" justified?
The UB is† always in the Unsafe Rust, but that's not necessarily a problem, the problem was that we caused it from our safe Rust and that's definitely not OK.
† Soundness bugs are known to exist in Rust, but for the known ones you have to be really asking for it, so it's not plausible that they'd impact you by accident.
This is a bug in the library, namely in Bun's PathString implementation. The bug is a soundness issue, precisely because usage of Bun's PathString implementation allows for UB in safe rust. Now this buggy library isn't that big of a concern for the community, because Bun is the only consumer. It's not also an indication of a compiler bug, because Bun's library is implemented using unsafe rust. But the fundamental issue is that usage of Bun's PathString implementation allows for UB in safe rust, and is therefore (clearly) unsound.
Later, the garage enters otherwise safe machinery and triggers UB. UB has now happened in safe rust as a result of my earlier contractual violation.
You can extend this example to other scenarios where UB in unsafe begets further UB in safe later on.
This is because that's not going to emit any machine code at all, and yet it will cause LLVM to do very nasty things, for example code which either prints "Odd" or "Even" by examining the integer may now print neither because that's faster and this uninitialized integer isn't odd, yet it also isn't even so...
fn safe_function(...) -> (...) {
}then `safe_function` can be called from safe code, and still trigger UB. This wouldn't be a soundness issue in the rust compiler, but instead a bug in safe_function.
There are many reasons you might want to do that. In particular, it's very common in rust to have a library define some data structure that uses unsafe under-the-hood, but checks whatever invariants it needs to, and provides solely safe methods to external callers. Rust's `String` type is like this: it's (roughly) a `Vec<u8>`, e.g. heap-allocated bytes. It has the additional invariant that these bytes correspond to valid UTF8 though. See for example `push_str_slice`, which (roughly) concatenates 2 strings.
https://doc.rust-lang.org/src/alloc/string.rs.html#1107
It does the following thing
1. reserve enough space for the concatenated string within the source string 2. does some pointer arithmetic and a call to Rust's equivalent to `memcpy` (unsafe) 3. re-casts this pointer to a string object without checking that it's valid utf8 (unsafe).
While these individual calls are unsafe, `push_str_slice` checks that in this particular situation they are safe, so the stdlib authors do not mark `push_str_slice` as unsafe. It has no invariants that must be maintained by external callers.
Here's some links on this topic which have some examples:
https://doc.rust-lang.org/nomicon/working-with-unsafe.html https://www.ralfj.de/blog/2016/01/09/the-scope-of-unsafe.htm...
And it's not like Bun when written in Zig has been a beacon of stability either. It has been segfaults all over the place.
[0]: https://news.ycombinator.com/item?id=48078224
I don't see what the big deal is here.
architector4@AGOGUS:/tmp$ git clone --depth=1 'https://github.com/oven-sh/bun' Cloning into 'bun'... … architector4@AGOGUS:/tmp$ cd bun/ architector4@AGOGUS:/tmp/bun$ find -type f -name '*.rs' -exec grep unsafe {} \; | grep -v '//' | wc -l 13255
....Thirteen thousand two hundred and fifty five lines without comments with the word "unsafe" in them in Rust code files across this rewrite.
This is so gross.
I'm a founder of an early-stage startup. I built a precision-editing tool system (called HIC Mouse). It provides coordinate-based addressing, staged batching with atomic rollback, embedded agent guidance, and more. It works well, it's available on VS Code Marketplace, and I've worked for a year and am still grinding every day, working so hard, just to get people to think about trying it, and to get attention paid to it. I did rigorous, careful benchmark research to make sure I wasn't just fooling myself. I incorporated, built a sales pipeline, changed my life by taking a chance and launching a business, and I pound the pavement and toil in obscurity every day and night, trying so hard to get interest in my product. I check every diff painstakingly before committing. I may make tools for AI agents but I am unbelievably careful about reviewing and thoroughly testing their code, and usually rather ruthlessly editing quite a bit further beyond any initial version drafted, long before deciding it is good enough to ship. I take enormous pains to get things right and worry constantly about whether I'm doing enough to make HIC Mouse secure and performant for my users. All I want is to make my users happier and to give them a genuine way to get "surgical, precise edits" that "don't touch the other lines", like we all ask of our AI agents over and over all day if we're using AI.
Or maybe not. Here we have Bun. Who cares about 90K GitHub Stars and massive community engagement -- just go crap all over them, all at once, with this AI tripe that you obviously neither tested in any meaningful manner, nor documented, nor read, I am assuming, before merging the whole bloated mess to production. What a disgraceful way to treat your users! I would be so grateful if I had a tiny fraction of the interest in my project that the Bun team has. I could never imagine shipping this garbage in a million years.
I'm sorry to vent but this just isn't defensible. It's the very worst of AI. I'm not going to wish ill on Bun, but it just makes me sad that I spend so much effort, work so hard to do things right, and painstakingly review everything because it's not just me any more and I do have folks who depend on my code being reliable and secure. And meanwhile, Bun just gives a huge middle finger to 90k+ starred supporters not to mention the millions of users who didn't click on the star but rely on the library, by acting this disrespectfully and disgracefully towards their own users. How they didn't take one look at this and promptly revert and apologize is simply beyond me. Again, sorry to vent, but this made me irrationally mad.
But they got bought out. By the tech equivalent of private equity. Every community in the USA & in most of the world is aware what happens when the friendly neighborhood business you've supported & relied on sells.
This is an old & systemic capitalistic phenomenon more than it is anything specific to AI. Hopefully someday we can figure out a real solution.
In fact using the word "rewrite" itself is pretty inaccurate.
As has been mentioned the goal was a port so they "could" eventually rewrite most of it to be idiomatic rust. The main benefit of this now is the compiler and being able to use these tools to fix issues that were already being hidden when it was in zig.
If you go into this codebase expecting to see idiomatic rust and get angry when it's not there, you are going in with the entirely incorrect attitude.
It's understandable how people see it as AI slop or whatever given the division among developers at the moment. But please see it for what it is instead of just jumping to conclusions.
They may have said that, but quite clearly the value they actually get out of it is getting the headline "AI reimplements complex, broadly used software in 2 weeks, but makes it way better because it's rust now" in front of a million people's eyes, only 1% of whom will ever find out it was mostly fluff
This is entirely disingenuous. Jarred has already made it clear what value they get out of moving off of Zig. Yes they used AI heavily to attempt this goal but I don't see what the big issue is. They haven't even released it yet and Anthropic themselves have said 0 about this.
The "headlines" thus far are really just people completely uninvolved with Bun and with all to gain by perpetrating "AI BAD".
My honest take: the big issue isn't "what if it goes wrong" its the fear that a migration of this size works out of the box and being done almost entirely by AI.
I wonder what are the real legitimate use-cases for "unsafe" in the first place, it is there for a reason?
In my application I'm able to guarantee that there is no modification to the backing file by making them read-only and ensuring nobody messes with them, but that guarantee exists outside of rust. So -- unsafe with a big SAFETY comment explaining the requirements if you use it.
Much rust code will never use unsafe. Systems code is likely to use a bit but also to know what it's doing.
Things like this port of bun are unusual and presumably transitory on the way to an implementation with minimal use of unsafe.