[lunar_mycroft]

Except that writing safe rust often requires designing the architecture around rust's ownership model, meaning a file by file, line by line translation doesn't necessarily leave you much closer to safe rust than you were at the start.

[selfmodruntime]

This is untrue. You can do a file by file translation by using clone and copy liberally. After you're done, you can incrementally introduce borrowing.

[lunar_mycroft]

You can also do one by using `unsafe` liberally, especially if you're flexible about actually upholding rust's rules (as the bun team just did). But either way, you're still stuck with a code base that's going to need extensive refactoring if you want to actually take advantage of rust.

[Tadpole9181]

Which is still a step ahead of Zig, which requires an entire rewrite to have the tiniest shred of RAII or borrow checking. What's your point, that if we can't do everything perfectly in one step we can't do it at all?

[lunar_mycroft]

> Which is still a step ahead of Zig

First off, you seem to be under the impression I'm a rust hater. Noting could be further from the truth. Rust is easily my favorite language at this point, I reach for it for basically everything (except quick scripts). While I do like a lot of zig's philosophy, I think at the end of the day the empirical evidence is overwhelming that manual memory management isn't sufficient.

> What's your point, that if we can't do everything perfectly in one step we can't do it at all?

My point is exactly what I initially said: you typically aren't much closer to a (mostly) safe rust codebase if you've done a line by line port to (partially unsafe) rust than you were to start with. Getting to safe rust is very likely to require substantial refactors either way. This doesn't mean you shouldn't do it (on it's own), but it does mean that the bun team's strategy/assumptions are more questionable than they appear to realize.

[selfmodruntime]

> You can also do one by using `unsafe` liberally, especially if you're flexible about actually upholding rust's rules (as the bun team just did

As in, they did not, which I can prove by using Miri and seeing hundreds of errors.

[lunar_mycroft]

I didn't say they made a good, safe port. I literally said the opposite ("especially if you're flexible about actually upholding rust's rules"). You can get a line by line port to compile by just wrapping the parts that violate rust's ownership rules in `unsafe`. You won't have fixed the problem, and it won't be memory safe, but you can do it.

[marshray]

Well, only if Clone/Copy is compatible with the semantics of the API. I.e., the called function doesn't need to modify anything. No &mut params (or data members) except perhaps `&mut self` (which would refer to definitions the same file).

That's usually the case for Rust programs because the language encourages it. Are Zig programs like that?

[lunar_mycroft]

To be fair, you can throw an Arc<Mutex<_>> or Rc<RefCell<_>> at it if you're starting from something that has multiple "mutable borrows", but that adds runtime cost and complexity.

[Klonoar]

It’s fully possible to have scoped areas of borrow checker influence, which could be introduced after the port.