Linux-for-Rust or Rust-for-Linux

Posted Aug 30, 2024 11:37 UTC (Fri) by vasvir (subscriber, #92389)
In reply to: Linux-for-Rust or Rust-for-Linux by khim
Parent article: Rust-for-Linux developer Wedson Almeida Filho drops out

> No, it wouldn't. Because these specific questions can be answered easily and in negative fashion

I am sure there are more ifs than the one I listed here. I mean it's a very big C project that tries to incorporate Rust. Lots of lessons will be drawn for all people that are unbiased. I agree though that the C side will have to make changes to accommodate Rust API. The question is: Will these changes make for a better C API? or more enforceable even with an external tool? I would suggest to grab some pop corn...

> But you, presumably, know some C and some assember, right? And you know that Unix was written in assembler and then rewritten in C, right?

Yes, yes and yes.

> It's very efficient: it's very easy to traverse the call stack with such approach and you don't even need to move arguments around!

Crazy stuff!!! and *no* I have never done that or even thought to do something like that. Didn't know about GEOS. Thanks for the pointer.

I saw the video and I would agree that Ted looked to me very rude. However, LWN coverage was more mild and his arguments came across as logical points which require some thought, work andcollaboration to address them.

Linux-for-Rust or Rust-for-Linux

Posted Aug 30, 2024 12:02 UTC (Fri) by khim (subscriber, #9252) [Link]

> The question is: Will these changes make for a better C API? or more enforceable even with an external tool?

90% of time the answer is “yes”: C API have grown to be incompatible with Rust approach simply because no one cared about Rust and when you fix it you make it easier to use from C, too.

90% of the remaining 10% you can approach some compromise where Rust API doesn't look too awful and C API is not too crazy, either.

But there are always 1-2% of these crazy corner cases where sane Rust API just pushes you to rewrite large pieces of already working code and then you either have to rewrite C code that is very fragile and rewrite-hostile, or, more often, add another implementation of the same API just for Rust.

It's always a good idea to try to avoid that, but sometimes that's really the best approach.

And if that happens then maintainership of that functionality becomes tangled between many different parties. And you spend way more than 1-2% of your time dealing with these corner cases.