Migrating from C to Rust - Part 1: Calling Rust Code from C

[@stephenevans8355]

Very good succinct video. If your C code is stable, reliable and readable then it ain't broke - so don't fix it. But for anyone with leaking spaghetti C code then this video definitely gives an excellent clear introduction on a possible way to move forward. Remember that for businesses maintenance is currently the primary long term issue with Rust - more so than C.

[@James-l5s7k]

And what's the business case when you can't integrate with c libs?

[@stephenevans8355]

@@James-l5s7k If you can call a C lib from C, you should be capable of calling said C lib from Rust. Licensing is more of a problem when wanting to integrate C libs.

[@ernestuz]

Directly to the point. Thanks! EDIT: You can always write the bulk of the functionality in safe Rust, and then wrap it in a thin unsafe Rust adaptor, that does very little and just allows the (possibly well tested) C code to remain the same.

[@GaryExplains]

Great point!

[@James-l5s7k]

The unsafe "thin adaptor" (ffi is unsafe) allows me to break in.

[@Djzaamir]

Thank you very much! I got to learn a lot from this introductory C to Rust migration tutorial. Looking forward to the complete series.

[@nomadic_shadow]

A video on making portable C code would be neat.

[@johanngambolputty5351]

11:54, I don't know if there's caveats to it (in an ffi context), but pretty sure you can still use globals by wrapping in a type that allows for interior mutability (RefCell for single threaded contexts), that way you don't have to use an OOP style API if you don't want to, and don't need unsafe either. I'd just define ``` thread_local!{ static X: RefCell = Default::default(); } ``` I do this all the time, since I typically don't like singletons, I usually use structs when there's more than one, or when there's a lot of related data to bundle (and that data is needed as context for a few different functions). Then `X.with_borrow(|x| dbg!(x))` or `X.with_borrow_mut(|x| x+=1)`... For the other direction I've briefly messed around with libloading (e.g. allowing for a c plugin in a rust program).

[@khai96x]

That caveat is that the Rust compiler does not check the C code, it cannot tell when you will share X between threads in C (RefCell does not implement Sync).

[@JeremyChone]

Great video!

[@theokramer_za]

Some suggestions 1) program behaviour when unsafe condition occurs 2) c vs rust program size 3) c vs rust speed 4) c vs rust tools 5) c vs rust libraries 6) c vs rust i/f to other languages 7) c vs rust lowlevel support eg embedded systems

[@GaryExplains]

Thanks, that is an interesting list 👍

[@josecarloscirqueirajunior2914]

nice .. more pls

[@sumitgaur5497]

Always love your video

[@compbarn]

embedded Rust program on stm32 or esp32

[@alst4817]

I like Rust but I think it’s a Java language! What I mean is that Javas JIT compiler was a real breakthrough at the time, and made Java extremely popular. However, the design of the language syntax itself has a bunch of flaws, and it is being slowly replaced by better languages with the same JIT technology. The same idea with Rust, the core technology of the borrow checker is fantastic, but the language has some issues which make it a real pain. I’m sure there’s gonna be a better version of borrow checker technology that will come along and replace it. For me, Rust is just not worth the pain as it is.

[@DanielSantanaBjj]

More on Rust 🦀 please 👏

[@adrianbool4568]

It is possible to have a mutable global variable without the use of unsafe code: ```rust use std::sync::RwLock; static X: RwLock = RwLock::new(123456789u64); #[no_mangle] pub extern "C" fn vrandom() -> u64 { let mut x = X.write().unwrap(); *x = x.wrapping_mul(69069).wrapping_add(362437); *x } #[no_mangle] pub extern "C" fn vseed(seed: u64) { let mut x = X.write().unwrap(); *x = seed; } ``` No need for structs nor any changes to the original C main() function.

[@adrianbool4568]

Note that the calls to X.write() above do not write to X; but instead request a write (mutable) lock on the contents of X. The lock is automatically discarded at the end of the function when x goes out of scope; so there is no need for an explicit unlock function call.

[@richardyao9012]

I prefer C. I am not going to Rust.

[@Perspectologist]

I’m really enjoying Rust. I really like how it simultaneously feels like a high level and low level language. Iterators, slices and closures are awesome. Destructuring and match expressions are very powerful. Macros are like crawling inside the complier and casting magical spells. Getting started in Rust was easy because that part is simple. Getting proficient took some time and frustration. I’m still not an expert, but have been building useful projects. The more I work with it the more powerful I become. This was a great example. I’m looking forward to seeing more Rust content.

[@Onyx-it8gk]

IMO the language design is actually really good, but the Rust zealots in the community really ruin it for me. You're not allowed to express any opinion outside of the official Rust dogma. On a more technical level, there's no language spec and many of the features are still experimental and unstable. Those issues will probably get worked out in time, but at the moment it isn't production-grade for many use cases.

[@mrpocock]

It clearly is production ready, as a lot of rust code is in production, and the amount is increasing as big projects move to it. You're correct about the lack of maturity. This is far more of an issue for things that aren't self-contained rust, like calling to or from c. Personally I've not had issues with the rust culture, but I may have been lucky.

[@Onyx-it8gk]

​@@mrpocock I did not say Rust wasn't production ready. I said it isn't production ready for some use cases just yet.

[@mrpocock]

@Onyx-it8gk I agree with that. There are certainly things it could be used for if it was more mature and stable. Kind of like me, I guess.

[@johanngambolputty5351]

Be like me and don't talk to other people, just enjoy using the language.

[@kamertonaudiophileplayer847]

Yesterday, I called C code from some my Rust crate. It worked great.

[@loc4725]

Looks like Rust has gone down that all to common route with languages where it's later realised that _mistakes were made_ C++. No inital planning for how people would link to C, a syntax which is quite different to what it replaces but for no obvious benefit and perhaps worst of all, it's overly verbose without adding much in the way of readability benefits. Good video though.

[@U_H89]

ANSI-C-1970 developing 👍...

[@AndrewRoberts11]

C was K&R flavoured for the first couple decades, till being ANSI'ed around 1990.

[@SlideRSB]

I'll stick to pure C. Thank you.

[@gsestream]

java and c99 together, c99 in opencl, instead of opengl

[@LA-MJ]

Part 2: Calling rust routines from python. Manipulating (python) strings. Interacting with numpy

[@GaryExplains]

Interesting, but I think the series should stick to C/C++ and Rust, not open up to how to use Rust from Python or Java or Lua or JavaScript or whatever. That is a different topic.

[@LA-MJ]

​@@GaryExplainsyeah and resources are scarce last time I have checked. Using rust with Python seems natural to me, with many pros, unlike your other language examples. Personally I have no intention of writing C any more

[@rubitwa]

i hate rust

[@GaryExplains]

Interesting comment. Why do you hate Rust?

[@rubitwa]

@@GaryExplains kzbin.info/www/bejne/jZqzoWyPeqeJZrM&ab_channel=TheLinuxFoundation Programming is primarily about working with memory, there have been many attempts to blame everything on the compiler. And why Rust and not something else? TrapC might be better))

[@GaryExplains]

Eh? The clip you sent has nothing to do with the pros or cons of Rust, that is simply a developer showing classic resistance to change. Also no one is blaming the compiler for anything, in fact the blame is with the programmer, I have never heard anyone blame the compiler. So, I ask again, why don't you like Rust?

[@rubitwa]

@@GaryExplains Okay, I worded it wrong, my fault. I don't hate Rust, I hate how it's promoted and where, I don't think it should be in the Linux kernel. And its only advantage is that it doesn't care whether you handle memory correctly or not. We already have one foot stuck in the Java interpreter, why do we need a generation of people who don't know how to work with memory.

[@LA-MJ]

​@@rubitwahistorical evidence points to the fact that nobody can work with memory bug-free so your point is invalid and boils down to yelling to clouds