[sesm]

When announcements say that rewrite took 1 week, I wonder how much time went into preparing this file with very detailed instructions on mapping Zig to Rust idioms: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573...

On top of that, if you look at 'Pointers & ownership' and 'Collections' sections, the Bun codebase is already prepared, using internal smart pointer types that map 1-to-1 to Rust equivalents, and `bun_collections` Rust crate already exists.

This makes an impression, that rewrite was prepared long time ago and was Bun team proposition to Anthropic during the acquisition deal.

[jaccola]

Yeah I don’t know what’s true when reading about LLMs. Same with comments here on hacker news. So much money on the line it’s clear they would seed communities with marketing shills (and some people are just tribal).

Same since they own Bun, they have every incentive to make this seem easier than it was.

[torben-friis]

This is a huge problem regarding the specifics of ai. Tech is becoming very adversarial as a worker, since marketing and technical information are blurring lines more and more.

[smrtinsert]

Influencers are getting paid to promote ai for 10s of thousands of USD. This is one the reasons social media has been swamped with it lately.

[1alprw]

Yes, some of the latest campaigns:

https://www.wired.com/story/super-pac-backed-by-openai-and-p...

Anthropic's own talking point guide:

https://news.ycombinator.com/item?id=47945021

There were earlier initiatives from the industry. This is just what is in the open and does not even include automated LLM "influencers".

[gofreddygo]

OMG ! I've been dealing with one such AI kool aid nut for 6 months now and I can trace a lot of they've done down to specific pointers from that anthropic "champion" playbook.

[bdelmas]

This! I now have to fight bad tech decisions at my companies because many devs follow influencers.

Look also at the hate spread against UE5… It’s everywhere and half of the arguments are falsehoods made by influencers with no real experience in the industry…

[ignoramous]

> Tech is becoming very adversarial as a worker, since marketing and technical information are blurring lines

Since one of LLM's largest market (with product fit) is us developers, we are experiencing what the crypto bros did to others.

[cortesoft]

You can just use AI for yourself and see. It isn't some mysterious product that only a few people get to use.

[chromadon]

This is the thing. I do use LLMs (mostly Anthropic).

It just does not generate good useable code. I have to review every single change to a higher degree than I would my own code because it likes to slip in hidden nasties. I have to rewrite at least 50% of what it generates.

That being said, I know devs who swear that they don’t even write code anymore. Like this rust port. I can’t even fathom blindly merging something his massive.

[nipah]

"rewrite 50% of what it generates" See, I'll not claim they write good code. But have you considered maybe your standards are a little bit too high for the tool? I made like 15 tools already using AI for my use, most of them I barely needed to touch in the code. The code is not great, no, but it's not useless and that's what matter for me. You try and iteratively ask for the AI to do things. If you want to ensure a higher degree of quality you can ask for tests and use techniques such as mutation testing to increase coverage, etc.

If you expect the same level of quality as you would write by hand, then you probably is better off... not using those tools. I mean if I was rewriting 50% of the generations I get I would not be using them at all.

[SwellJoe]

I think we're still seeing pretty wild variance in how effective LLMs can be for code, depending on who is driving it. I've seen some folks getting themselves into messes pretty regularly with LLMs. But, ever since Opus 4.5, it's been pretty obviously better to work with it than without it, remarkably better in some use cases. Porting an application with source available and a huge existing test suite is pretty much the ideal use case for an LLM. It has everything it needs to succeed. I can't imagine why anyone would embark on a porting effort without an LLM at this point.

[bmitc]

Most people do use LLMs, which is why they have the so-called pessimistic opinions they do.

[vga1]

Judging by most public comments, people are really mediocre at using them. I don't get how it's possible to get such poor results from them.

[mg794613]

That's because your usecases were simple and/or small.

Otherwise, you would have known.

Unless you don't have experience and you believe the whole "You are right! it _is_ a and not b" bs...

[cortesoft]

Or, perhaps, you are the one who is mistaken and other people ARE having success with large and complex programs?

I am not saying you ARE wrong, but I don’t know how you could be so certain that no one else is having success with complex, AI written, code.

There are well known, established, and respected engineers creating AI projects right now. For example, antirez, the creator of Redis, created the DS4 project. When you see these sorts of projects, do you never think, “Maybe I might be wrong about this.”?

[nipah]

Okay, doubt. What level of complexity you believe this project has? Including the changes that required changing burn-cubecl.

https://github.com/mii-nipah/voxcpm-rs

--- Just to be clear, I'm not saying they don't make mistakes. In fact I constantly scream into the void with the sheer amount of absolute stupidity of those models, however I would never say, using them for what I use, that they can only be used for simple and small use cases.

[vga1]

Such absolutely unfounded confidence is impressive.

[abustamam]

While this is true, it's also true that few people have the budget to spend a bunch of tokens on porting bun over to rust.

[_puk]

And yet we have stories[0] of companies judging merit on tokens used.

Rather than using these tokens to do rewrites that have the potential to massively improve the day to day, they're just burnt for the sake of burning them.

It's individual initiative, and company culture that are at play as much as budget.

0: https://news.ycombinator.com/item?id=48110529

[abustamam]

Tokens are the new LoC it seems!

> It's individual initiative, and company culture that are at play as much as budget.

I agree, but parent comment was insinuating that gp could just use an llm to verify their hypothesis, which is what I was attempting to point out in my comment. The tool isn't out of reach, but not everyone has employer sponsored LLM plans.

[cortesoft]

I don’t think it would cost a crazy amount of token to port the project. You could probably do it in a few days with a Claude max subscription.

[fny]

I'm not sure it matters what anyone claims. It's easy to use and experience its abilities and limitations.

[port11]

The truth lies somewhere in the middle.

Context: 20 years coding, 13-ish of which professional. Using LLMs for side projects, including a very big one. Also using them to help manage our home server.

I’ve used 20-ish agents with OpenRouter, Google’s own AGY, Mistral’s Vibe, and Claude Code. The good ones are good and can be very helpful with spec’ing work or handling repetitive tasks. Except for Opus 4.6, none of them produce TypeScript that I’d be super proud of; but they write stuff that’s good enough compared to what I’ve seen in the industry. It’s always some mix of spaghetti and shortcuts. That’s fine, you steer the model and tighten your specs and tests.

Anyone claiming ‘Model X can one-shot’ an app is delusional about maintainability, deployment, all the little things that grease the wheels. Anyone claiming ‘LLMs are useless’ is probably not being impartial. That’s it.

And any company claiming AI is awesome at everything and will replace everyone? Yeah, they’re lying, at least about their capabilities as of right now.

[sunrunner]

Ignoring things like whether the Rust that was output could be deemed qualitatively good, whether the resulting line count is appropriate, how much the codebase was ready or primed for this kind of exercise going in, and so on, is it fair to say that a 622 line artefact created up front is a relatively small cost for a potential increase in consistency or quality of output when the output is ~1M LoC? It seems like there's a multiplicative power here given how much output there is. Or is that missing a lot of nuance?

I'd also be interested generally in how much tacit knowledge was needed to come up with these rules and how much iteration on this file was needed, for example how many of the rules here came from a failure case hit as part of iterating on the translation.

[xienze]

> I'd also be interested generally in how much tacit knowledge was needed to come up with these rules and how much iteration on this file was needed, for example how many of the rules here came from a failure case hit as part of iterating on the translation.

I think that's the point the original poster was making. There's basically zero chance this file was just spit out by memory in an afternoon. It was obviously the result of a LOT of pre-planning and back and forth checking over the artifacts that Claude was incorrectly generating for one reason or another. So yeah, an extremely iterative process.

With rules as fine-grained as these, there was almost certainly many instances where hundreds of files are generated -> one particular file doesn't translate <X> correctly -> add a rule for <X> -> regenerate everything again -> crap, that rule broke a different file because <Y> -> add a rule for <X if Y>, another for <X not Y> -> regenerate everything again[0] -> repeat. The token costs must have been out of this world.

0: now I'm sure people will say "why would you regenerate a file that generated correctly once? Just mark it off the list and move on." Well, when essentially 99.9999% of your codebase is generated artifacts, the tiny fraction that is actually human-understandable is now the spec, the source of truth for everything. It HAS to be able to essentially redo the entire process if you expect any level of maintainability going forward.

[fdsajfkldsfklds]

This is effectively a very expensive and resource-intensive machine translation. As such, there is no increase in consistency or quality of output.

[antonvs]

How would you have achieved this “machine translation” without an LLM?

It seems to me it would have been highly likely to be more expensive and more resource intensive - if realistically possible at all, short of implementing a general Zig to Rust translator first.

[electroly]

"Short of..." indeed. You already know the answer, although it doesn't need to be general; it only needs to work on a single codebase.

A recent and highly relevant example is the migration of the TypeScript compiler to Go. They did not use an LLM to translate the code. Instead, they used LLM assistance to write a deterministic TypeScript-to-Go translator and then used that to translate the code. I have far more confidence in this approach than in letting the LLMs rip on the translation itself.

[mewpmewp2]

I think TypeScript to Go is far easier to translate than something to Rust though.

[ForHackernews]

Is it? I wouldn't assume that. Go is a smaller and less flexible language than Java/Typescript (I say that as a compliment) so it's not clear to me that all Typescript idioms have an obvious Go equivalent.

Leaving aside ownership, Rust is a big, complex, expressive language. I'm not that familiar with Zig, but I think it tries to be a "better, modern C" so it seems like it should be easily possible to mechanically translate Zig into direct Rust equivalences. You probably won't get "good" idiomatic Rust at the end, but you should get working code that does the same thing.

[drzaiusx11]

Even before the advent of LLMs, I have personally (and largely successfully) translated several production systems from one language to another. I've learned it's best to start with a mechanical translation, literally bug for bug, leaving shit exactly as I found it (just in another language.)

I've done Perl to Java, Java to Kotlin, Python to Ruby, Ruby to Java, C to Swift, you name it.

It's only when you change behavior during the rewrite that it becomes an intractable problem. If you ship a 1:1 translation, THEN you can start going through the list of "bugs" you found along the way. Tread carefully when it comes to this, however, as I can almost guarantee that within your non-trivial codebase there will be some code that implicitly _depends_ on a "bug" to function at all. This where shit hits the fan.

[inamorty]

"Load bearing bugs"

[drzaiusx11]

It really is incredible how frequently these occur in everyday codebases of sufficient size.

[Aurornis]

The translation is a starting point to enable follow-on work to take advantage of Rust's features.

[cyanydeez]

I would guess it was a for ... each loop. They likely wrote a bunch of skills. The foor loop went through each file and generated a complimentary file, then had another process integrate/validate.

I doubt the entire process was a single week, just whatever harness they specially prepared for the work.

[billywhizz]

> I doubt the entire process was a single week, just whatever harness they specially prepared for the work.

it wasn't. probably quite a lot of preparation i would think. and it's very much a first pass which is far from idiomatic rust and far from memory safe. still impressive though for what it is.

https://x.com/jarredsumner/status/2053588764774269292 https://x.com/jarredsumner/status/2054984043708740093

[ryukoposting]

Similar highly crafted success stories getting passed around within some big tech firms right now.

We got told that someone wrote a huge, sophisticated driver in Rust in a single day using Claude Code. This is being pushed as a case of AI doing something that we encounter on a regular basis, way faster than a human could do it.

Some ommitted details: Turns out the official spec for this driver is written in C, and the standard has a massive official suite of unit tests.

[ares623]

It's the same thing with their gcc stunt.

It would be _so_ easy to alleviate any doubt from this and hype up the IPO even more. They just need start a separate repo with all the hidden work they needed to do to prod the AI along, and let everyone replicate the results. After all, isn't that what all their customers are trying to achieve? A million lines of usable code in "7" days? Never mind the fact that it will also boost Anthropic's usage metrics as everyone tries to replicate it into their workflows.

If it was beautiful, they would've started with a blog post about this with links and instructions. Perhaps I will still be proven wrong and a blog post is being written as I type this.

[SwellJoe]

Which part of a Zig to Rust port (working, passing tests) of a quite large codebase in a little over a week is not worthy of hype do you reckon? That they didn't one-shot it? What could possibly make it impressive if not the sheer velocity of the thing? That's a months or years long operation for a human. There's a reason porting large programs to new languages was vanishingly rare throughout most of computing history, and there's a reason people are suddenly doing it almost on a whim, now.

[Aurornis]

> using internal smart pointer types that map 1-to-1 to Rust equivalents

Smart pointers weren't invented by Rust. If you write code in other languages with pointers you mentally model the same types already.

> and `bun_collections` Rust crate already exists.

This is wrong. It's part of the PR in the codebase. It did not previously exist.

[sesm]

Agree, after closer look smart pointer types are pretty standard and collections were indeed a part of migration.

But still, in order to prepare those detailed and very project-specific instructions you need to iterate on trying to convert the files from this specific codebase.

[gofreddygo]

Its like that hackathon winner project that everyone knows wasn't ideated or built there. True to the law, not to the spirit.

[illiac786]

Yes, there is exaggeration going on.

Nonetheless, it’s a fact it would have taken much longer without LLMs, I’d say all possible.

I find this is a valid success story if you can look past the embellishments. More than that, it’s really cool, actually.

[exac]

Based on the use of "≥" and em-dashes, I'd say this markdown file was written with or by an LLM.

[bmitc]

That makes the Bun owner's claim, just a week ago in this site, even more dubious when he came on here and said this code was just an experiment and likely to be thrown away.

[user34283]

I don't think the owner lied, but rather that the entirely speculative comment on here is obviously wrong.

It says here in the comments that it's mistaken about the supposed previous existence of the crate.

[tln]

Seems like Zig Bun had 3 pointer types that map neatly to existing Rust pointer types. The other 7-8 needed types to be created.

Is that the conspiracy?

bun_collections doesn't look much older than the porting guide.

[thayne]

Given zig instability (as in frequent breaking changes), it wouldn't surprise me if they intentionally design bun from the start in a way to make it easier to migrate to rust if needed.