3 ms·

It is right there in black-and-white: 28 years of C to be interfaced with -> more FFI -> more unsafe blocks -> less that Rust can verify. I don't think there w

It is right there in black-and-white: 28 years of C to be interfaced with -> more FFI -> more unsafe blocks -> less that Rust can verify. I don't think there will be enough left outside of unsafe blocks to justify a second toolchain here. If the kernel were also in Rust, it would be a different story.

pornel 7y ago
It's quite the opposite. Wrapping existing C code in Rust FFI can make it safer. Rust side can add missing type information to C interfaces. Things that are "RTFM" for C, such as thread safety of the types involved and which function arguments are borrowed/owned, can be expressed on the Rust side even for C code, and automatically enforced when it's used via FFI. This adds a layer of safety to existing C code.
- jstewartmobile 7y ago
  "Using C libraries in a portable way involves a bit of work: finding the library on the system or building it if it's not available, checking if it is compatible, finding C headers and converting them to Rust modules, and giving Cargo correct linking instructions. Often every step of this is tricky..." Adding loads of complexity (i.e. more opportunities to screw something up) for a minor gain.
  - pornel 7y ago
    Note that this mess isn't created by Rust. The difficulty of building arbitrary C libraries on all platforms comes from C.
roca 7y ago
Look at what the people working on Rust-in-Linux are actually doing. They are writing safe Rust wrappers around internal Linux APIs that drivers use and the Linux interfaces that drivers implement. Then you can write a driver in Rust that needs little or no unsafe code of its own. Better still, then you can write ten drivers in safe Rust reusing the same glue. And honestly, writing safe Rust wrappers around C APIs is not hard to do. The community has tons of experience with this. It does not wreck the coherence of the safe Rust code that uses those wrappers, like you seem to think.

pornel 7y ago

It's quite the opposite. Wrapping existing C code in Rust FFI can make it safer. Rust side can add missing type information to C interfaces. Things that are "RTFM" for C, such as thread safety of the types involved and which function arguments are borrowed/owned, can be expressed on the Rust side even for C code, and automatically enforced when it's used via FFI. This adds a layer of safety to existing C code.

jstewartmobile 7y ago
"Using C libraries in a portable way involves a bit of work: finding the library on the system or building it if it's not available, checking if it is compatible, finding C headers and converting them to Rust modules, and giving Cargo correct linking instructions. Often every step of this is tricky..." Adding loads of complexity (i.e. more opportunities to screw something up) for a minor gain.
- pornel 7y ago
  Note that this mess isn't created by Rust. The difficulty of building arbitrary C libraries on all platforms comes from C.

roca 7y ago

Look at what the people working on Rust-in-Linux are actually doing. They are writing safe Rust wrappers around internal Linux APIs that drivers use and the Linux interfaces that drivers implement. Then you can write a driver in Rust that needs little or no unsafe code of its own. Better still, then you can write ten drivers in safe Rust reusing the same glue. And honestly, writing safe Rust wrappers around C APIs is not hard to do. The community has tons of experience with this. It does not wreck the coherence of the safe Rust code that uses those wrappers, like you seem to think.