| ▲ | smasher164 3 hours ago |
| 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? |
|
| ▲ | Animats 3 hours ago | parent | next [-] |
| > "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. |
| |
| ▲ | dathinab 2 hours ago | parent | next [-] | | > 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). | |
| ▲ | swiftcoder 3 hours ago | parent | prev | next [-] | | > 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. | | |
| ▲ | Animats 2 hours ago | parent [-] | | 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. [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/ | | |
| ▲ | swiftcoder 2 hours ago | parent [-] | | > let the LLM generate slop, check it using formal methods I'm much more bullish on the opposite approach. Perform the naive translation, let the LLM loose on cleaning it up... |
|
| |
| ▲ | Animats 3 hours ago | parent | prev | next [-] | | The module with the code mentioned is at [1] 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... | | |
| ▲ | gpm 44 minutes ago | parent | next [-] | | > It doesn't enforce the Rust rule that strings must be strict UTF-8 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. | |
| ▲ | mananaysiempre 2 hours ago | parent | prev | next [-] | | 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. | |
| ▲ | 2 hours ago | parent | prev [-] | | [deleted] |
| |
| ▲ | wrs 3 hours ago | parent | prev | next [-] | | What they’ve done here isn’t safe either, and doesn’t have the consistent translation of rust2c. | |
| ▲ | xienze 2 hours ago | parent | prev [-] | | 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. |
|
|
| ▲ | rattray 3 hours ago | parent | prev | next [-] |
| > why not just build a translation tool for it? They did ;) a highly dynamic one... |
| |
| ▲ | giancarlostoro 2 hours ago | parent [-] | | 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. | | |
| ▲ | bendmorris 19 minutes ago | parent [-] | | They don't have to do that at all. They could've used mainline Zig, without their vibe coded changes to it. |
|
|
|
| ▲ | mr_00ff00 3 hours ago | parent | prev | next [-] |
| “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. |
| |
|
| ▲ | lioeters 2 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | 3 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | whateveracct 3 hours ago | parent | prev | next [-] |
| [flagged] |
| |
| ▲ | brookst 2 hours ago | parent [-] | | Thanks for updating the age-old complaint about the printing press. | | |
|
|
| ▲ | ModernMech 3 hours ago | parent | prev [-] |
| Because they aren't trying to raise billions of dollars to build a translation tool. |
