Hacker News new | ask | show | jobs
by freedomben 830 days ago
> Android has ported a lot of the Bluetooth code to Rust. This is a demonstration of why they need to put more resources into porting the rest of the code into Rust.

I like how they snuck that in there :-D

As someone who spent years writing C and C++, but no experience with Rust, with this porting from C to Rust, how much refactoring is required? That might should be two different questions:

1. How closely does C translate directly over to Rust? Does Rust require some reorganization/refactoring?

2. How is Google approaching this? Are they trying to closely "translate" it as much as possible, or is this an opportunity for major rewrite/refactor?

Also very curious if anyone knows, will the Android Bluetooth stack ever be usable on a standard Linux distro desktop system?

2 comments

I was recently trying to port a PIC microcontroller simulator from C++ to Rust as an (unfinished) experiment. Because there were lots of cyclic references (modules talking to each other over "signal busses" with callbacks,) I think I ended up fighting Rust more than it helped. It ended up requiring a lot of Box (pointers to heap) for things where I could store the data inline in C++.

My conclusion is that if you're writing a simple CLI or request-response thing, Rust is probably an easy port. More generally, if your code structure could work well with arena allocations, moving to lifetime-tagging of references isn't a big deal.

But if you're writing (admitted ugly) code with cyclic references the way a C programmer would :), Rust will feel like an uphill battle and is not the place to start. I need to start by restructuring the C++ code, moving ownership to a common parent. I think that'll make things better. Iteratively learning more about Rust, but continuing to work in C++ until the code has a better correspondance to Rust.

Edit: forgot the word simulator, and changed RefCell to Box.

> It ended up requiring a lot of RefCell (pointers to heap)

Just so you know, RefCell does not inherently point to the heap. If you put a Box or something inside, sure, but on its own, it doesn't allocate.

Ah, thanks, I changed it to a Box. I confused the two, since I had to use them in conjunction.
It's all good. For what it's worth, I agree with you generally that a lot of the C code I see is like, "differently shaped" than the Rust, so it's not super simple to port directly over.
It's likely pretty far from a 1:1 port, you'll be rearchitecting a lot of what you are writing. It's unavoidable due to the way Rust guarantees memory safety.