4 ms·

Fortunately, once you start refactoring the Rust to take advantage of the functionality that doesn't exist in C (like slices, iterators, etc), things start to l

by glguy 8y ago

Fortunately, once you start refactoring the Rust to take advantage of the functionality that doesn't exist in C (like slices, iterators, etc), things start to look much cleaner. Translating the code into ugly, unsafe Rust is intended to only be the first step. We're working on tools to help with that refactoring process, too.

taneq 8y ago
Sounds like a case of "writing C in Rust" compared with "writing Rust". You're not really writing in a language until you're thinking in its idioms.
- FreeFull 8y ago
  A translator like this is still really useful as the first step of transforming a C codebase into a Rust codebase. The important thing is to get working code first, and then you can modify the code to be more idiomatic.
- masklinn 8y ago
  > Sounds like a case of "writing C in Rust" compared with "writing Rust". Duh? It's literally taking C code and generating Rust code which behaves the same. > You're not really writing in a language until you're thinking in its idioms. The entire point is to get your foot in the door. This gives you a pile of Rust code which (bugs aside) should behave the exact same way C code does. From there on you're living in the Rust world and can improve that as you see fit. If you can afford doing the initial transition in one short, later improvements are much simpler than having to maintain an internal (moving) front between remaining C code and new Rust code as e.g. librsvg does.
  - lomnakkus 8y ago
    > If you can afford doing the initial transition in one short, later improvements are much simpler than having to maintain an internal (moving) front between remaining C code and new Rust code as e.g. librsvg does. That's all well and good... if you don't have to maintain the project while doing the necessary C-as-Rust -> "proper" Rust conversion. This C-as-Rust output seems[1] like it woul d be incredibly difficult to do bugfixes in and there's also the issue of what happens if the C code happened to rely on implementation-defined behavior (or even UB which the implementation happens to "do the right thing" with). Unless you have a trivial amount of code, I'd say the right thing is to do the conversion in small chunks. This also gives you a much better way to ensure (through test suites) that you're not introducing excessively many new bugs when rewriting C-as-Rust to "proper" Rust. [1] I realize this is early days, but I'm talking about the present time.
grok2 8y ago
Yeah, I assumed that this was just converting word-for-word as a first step and one was expected to then go back to use Rust idioms to tweak the code if necessary. Definitely useful if you want to move code-bases to Rust entirely.

by glguy 8y ago

taneq 8y ago

Sounds like a case of "writing C in Rust" compared with "writing Rust". You're not really writing in a language until you're thinking in its idioms.

FreeFull 8y ago
A translator like this is still really useful as the first step of transforming a C codebase into a Rust codebase. The important thing is to get working code first, and then you can modify the code to be more idiomatic.
masklinn 8y ago
> Sounds like a case of "writing C in Rust" compared with "writing Rust". Duh? It's literally taking C code and generating Rust code which behaves the same. > You're not really writing in a language until you're thinking in its idioms. The entire point is to get your foot in the door. This gives you a pile of Rust code which (bugs aside) should behave the exact same way C code does. From there on you're living in the Rust world and can improve that as you see fit. If you can afford doing the initial transition in one short, later improvements are much simpler than having to maintain an internal (moving) front between remaining C code and new Rust code as e.g. librsvg does.
- lomnakkus 8y ago
  > If you can afford doing the initial transition in one short, later improvements are much simpler than having to maintain an internal (moving) front between remaining C code and new Rust code as e.g. librsvg does. That's all well and good... if you don't have to maintain the project while doing the necessary C-as-Rust -> "proper" Rust conversion. This C-as-Rust output seems[1] like it woul d be incredibly difficult to do bugfixes in and there's also the issue of what happens if the C code happened to rely on implementation-defined behavior (or even UB which the implementation happens to "do the right thing" with). Unless you have a trivial amount of code, I'd say the right thing is to do the conversion in small chunks. This also gives you a much better way to ensure (through test suites) that you're not introducing excessively many new bugs when rewriting C-as-Rust to "proper" Rust. [1] I realize this is early days, but I'm talking about the present time.

grok2 8y ago

Yeah, I assumed that this was just converting word-for-word as a first step and one was expected to then go back to use Rust idioms to tweak the code if necessary. Definitely useful if you want to move code-bases to Rust entirely.