teensy4-rs VS Rust-for-Linux

the nRF line is very well supported by Rust, but you'd have to get a canbus breakout since the nrf line doesn't support canbus out of the box. An alternative is the teensy line of MCUs - the higher-end models have CAN built in and there's decent Rust support. https://github.com/mciantyre/teensy4-rs

The most complete teensy environment I could find that isn't Arduino is this: https://github.com/mciantyre/teensy4-rs which is Rust not C.

You're welcome.

> Any concerns of the same kind of thing?

Here's the canonical list: https://github.com/Rust-for-Linux/linux/issues/2

There's a lot, and I don't know the status of many of them, personally. But I don't see anything there that I know is not gonna work out, like for example, they aren't using specialization. Most of it feels like very nuts and bolts codegen options and similar things.

That said, back in August, the Rust Project announced their goals for the second half of this year: https://blog.rust-lang.org/2024/08/12/Project-goals.html

They say that they're committed to getting this stuff done, and in particular: https://rust-lang.github.io/rust-project-goals/2024h2/rfl_st...

> Closing these issues gets us within striking distance of being able to build the RFL codebase on stable Rust.

So, things sound good, in my mind.

The goal of rust for linux isn't to wholesale translate linux into rust, but simply to be able to write pieces of linux (largely new ones) in rust. I think it's very unlikely anyone (including google) will take on a wholesale translation anytime soon. That said

> It's unlikely that Google has much sway here

Google has helped fund the rust for linux project pretty much from the start [1], they're one of three organizations mentioned on the homepage due to their sponorship [2]. They're actively involved in it, and have already ported their android "binder" driver into it with the intent to ship it in android. This strikes me as a very weird take.

[1] https://www.memorysafety.org/blog/supporting-miguel-ojeda-ru...

[2] https://rust-for-linux.com/

Rust is backwards compatible when you stick to stable features, but the kernel uses unstable features that can and do incur breaking changes.

https://github.com/Rust-for-Linux/linux/issues/2

> How would this work?

Don't know exactly what you're asking.

> And why would it be a better idea?

Poorly written device drivers are a significant attack vector. It's one of the reasons Linux is now exploring using Rust for its own device drivers.[0] You may be asking -- why Rust and not some other language? Rust has many of the performance and interoperability advantages of C and C++, but as noted, makes certain classes of memory safety issues impossible. Rust also has significant mindshare among systems programming communities.

[0]: https://rust-for-linux.com

Rust-for-Linux issue tracker