Hi HN, I'm building a transpiler specifically focused on migrating C++ to Rust and Go.
Modernizing legacy C++ codebases is a huge challenge. While there are some tools for C++ to Rust (like c2rust), I wanted to create a more flexible approach that handles both memory-safe (Rust) and concurrency-focused (Go) targets from the same C++ source.
What it does:
Parses C++ code and maps it to equivalent constructs in Rust and Go.
Aims to reduce the manual effort in language migration.
Current Status:
Focus is strictly on C++ to Rust/Go (no other languages planned).
It's in the early stages, and I'm currently refining the AST mapping.
I would love to hear your thoughts on:
What are the biggest pain points you've faced when migrating C++ to Rust/Go?
Are there specific C++ patterns you'd like to see automated first?
Thanks for the question!
On real codebases: Currently, the transpiler works best on "clean" C++ (logic-heavy code, algorithms, and data structures). It can handle a significant portion of the syntax, but for large, complex codebases using heavy template metaprogramming or platform-specific APIs, there are still limitations.
Compilation & Manual Fixes: Does it compile out-of-the-box? For small to medium-sized snippets and standard logic, yes. However, for real-world projects, manual fixes are usually required, especially for:
- Rust's Borrow Checker: C++'s pointers don't always map 1:1 to Rust's ownership model. The transpiler generates code that is syntactically correct, but you might need to adjust lifetimes or use Arc/Mutex where C++ was more permissive.
- External Dependencies: Mapping C++ libraries to their Rust/Go equivalents still requires some manual configuration.
Goal isn't necessarily "100% automated migration" (which is the holy grail), but rather to automate the tedious 80-90% of the porting process, allowing developers to focus on fixing the architectural differences.
I have some examples in the repo, and looking for more "real-world" test cases to improve the conversion logic
Hi HN, I'm building a transpiler specifically focused on migrating C++ to Rust and Go.
Modernizing legacy C++ codebases is a huge challenge. While there are some tools for C++ to Rust (like c2rust), I wanted to create a more flexible approach that handles both memory-safe (Rust) and concurrency-focused (Go) targets from the same C++ source.
What it does: Parses C++ code and maps it to equivalent constructs in Rust and Go. Aims to reduce the manual effort in language migration.
Current Status: Focus is strictly on C++ to Rust/Go (no other languages planned). It's in the early stages, and I'm currently refining the AST mapping. I would love to hear your thoughts on:
What are the biggest pain points you've faced when migrating C++ to Rust/Go? Are there specific C++ patterns you'd like to see automated first?
How does it perform on real codebases? Does converted code compiles properly? Or it requires manual fixes?
Thanks for the question! On real codebases: Currently, the transpiler works best on "clean" C++ (logic-heavy code, algorithms, and data structures). It can handle a significant portion of the syntax, but for large, complex codebases using heavy template metaprogramming or platform-specific APIs, there are still limitations.
Compilation & Manual Fixes: Does it compile out-of-the-box? For small to medium-sized snippets and standard logic, yes. However, for real-world projects, manual fixes are usually required, especially for:
- Rust's Borrow Checker: C++'s pointers don't always map 1:1 to Rust's ownership model. The transpiler generates code that is syntactically correct, but you might need to adjust lifetimes or use Arc/Mutex where C++ was more permissive.
- External Dependencies: Mapping C++ libraries to their Rust/Go equivalents still requires some manual configuration.
Goal isn't necessarily "100% automated migration" (which is the holy grail), but rather to automate the tedious 80-90% of the porting process, allowing developers to focus on fixing the architectural differences.
I have some examples in the repo, and looking for more "real-world" test cases to improve the conversion logic