Hacker News

Show HN: Hybrid-Transpiler – A tool to convert C++ to Rust and Go

8 points by hpscript ago | 3 comments

hpscript |next [-]

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?

Panzerschrek |previous [-]

How does it perform on real codebases? Does converted code compiles properly? Or it requires manual fixes?

hpscript |root |parent [-]

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