"Use Claude"
[the end]
The C to Rust migration book
11–20 of 28 posts
Re: The C to Rust migration book
#12One link deeper is the actual content; can we link there instead? https://mainmatter.com/c-to-rust-migration-book/course/
[flagged]
Re: The C to Rust migration book
#13I've spent a good amount of time with C, nowhere near mastery though. Is it worth still writing C, or better off just learning Rust if my goal is to write embedded/systems code?
> embedded/systems code?
Depends on platform for embedded. It not very pleasant to write rust if you have to think about binary size. For systems code - sure, use rust.
Re: The C to Rust migration book
#14and cheadergen, Mainmatter's tool for the reverse direction So this is just an ad blogpost for the company.
cheadergen is an open source tool that our Rust lead wrote – not sth. we sell or anything
Re: The C to Rust migration book
#15I made a comment about this yesterday[0], but there's been a massive increase in people migrating from C to Rust due to LLMs.
In contrast to what the C to Rust migration book is recommending (using FFI to integrate Rust with C), I've found it much easier to start from scratch. I recently finished a project where I rewrote Postgres in Rust[1]. For context, Postgres is about one million lines of C code.
On one attempt, I tried using c2rust to convert Postgres into unsafe Rust code. That attempt succeeded in terms of getting working "Rust" code, but any attempt to change any piece to safe rust, would require thousands of changes across codebase. Even though I had working Rust code, I found it infeasible to get to working idiomatic Rust code.
Instead what I found to be more effective was starting a new codebase and rewrite each file from the Postgres codebase into Rust one at a time. This allowed me to guarantee that at all times the new codebase was idiomatic and simultaneously I could make one pass over the Postgres codebase to get working idiomatic Rust.
YMMV, but I found it way easier to generate a whole new codebase from scratch rather than incrementally rewrite an existing codebase.
Re: The C to Rust migration book
#16The “Table of Contents” in the article (https://mainmatter.com/c-to-rust-migration-book/) looks like the very basic stuff and not especially interesting, but then the headings in the book itself (https://mainmatter.com/c-to-rust-migration-book/course/) look much more in-depth and don't seem to map onto the supposed ToC. I think they're misusing that term? I guess it's aspirational too as the book isn't finished yet.
Re: The C to Rust migration book
#17I've spent a good amount of time with C, nowhere near mastery though. Is it worth still writing C, or better off just learning Rust if my goal is to write embedded/systems code?
Technically, absolutely. Whether it would suit you, depends if you can learn to like Rust's approach of moving more work to the type system. In Rust you do certain things the Rust's way, period. Programmers used to C being unopinionated about everything find that objectionable.
> moving more work to the type system
Sounds right up my alley. Thanks to you (and other siblings) for the thoughtful replies.
Re: The C to Rust migration book
#18I made a comment about this yesterday[0], but there's been a massive increase in people migrating from C to Rust due to LLMs. In contrast to what the C to Rust migration book is recommending (using FFI to integrate Rust with C), I've found it much easier to start from scratch. I recently finished a project where I rewrote Postgres in Rust[1]. For context, Postgres is about one million lines of C code. On one attempt,…
Mainmatter head of engineering here. From what we've seen on real projects, I can confirm that asking an AI to migrate the code results at best in somewhat functional but unmaintainable code, and starting from scratch is a better approach… However, starting from scratch doesn't work if the legacy codebase is actively being worked on (eg bux fixes and new features and refactorings) or lacks test coverage and documentation.
Starting from scratch also implies one major release where suddenly it's all Rust (so very risky). In contrast, we found that it's a much smoother transition for end-users and maintainers when we approach large codebases progressively, module by module, while the C engineers continue working on the C code and learn Rust in parallel.
Of course, each migration is different but I wanted to clarify with our field experience.
Re: The C to Rust migration book
#19I made a comment about this yesterday[0], but there's been a massive increase in people migrating from C to Rust due to LLMs. In contrast to what the C to Rust migration book is recommending (using FFI to integrate Rust with C), I've found it much easier to start from scratch. I recently finished a project where I rewrote Postgres in Rust[1]. For context, Postgres is about one million lines of C code. On one attempt,…
> would require thousands of changes
But LLMs are great at this, provided you have a test suite to keep the process on the rails.
Re: The C to Rust migration book
#20Earlier quoted context omitted.
Technically, absolutely. Whether it would suit you, depends if you can learn to like Rust's approach of moving more work to the type system. In Rust you do certain things the Rust's way, period. Programmers used to C being unopinionated about everything find that objectionable.
C is a tool which requires expertise but then goes out of your way and let's you do things, and do things rather efficiently, with no overhead, and exactly how you want. If you want it to cut off your arm it will do this too. But if you want to abstract things away behind types, this can also be done too (and arguable should be done more often in C). Somebody should write a C to more modern and safe C migration book.
Depends how you define "can", because you can invent your own conventions not checked by the compiler, or even make a compile-to-C language.
But more directly, C barely lets you define non-NULL pointers. It doesn't have pointers that guarantee the data behind them is initialized, it doesn't have never-leaves-this-thread data types. Const merely guarantees that you can't (strongly shouldn't) mutate data, not that it definitely won't be mutated by any thread.