Our great sponsors
-
-
carbon-lang
Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
We rebuilt solo v2 [1] firmware in rust, compared to v1 in C [2]. I haven't written any rust code so take what I say with a grain of salt, but generally speaking I think our experience has been very positive.
Rust forced us to structure the code a bit better, that makes it easier for multiple people to collaborate on it. Slightly harder learning curve, but that wasn't an issue in our case.
In the history of solo, we had a couple security bugs that rust would probably have prevented, so this is a plus for the language. Moreover, the cryptography community is pretty active and we can leverage solid + well maintained libraries.
One downside has been collaboration with other OS projects. When we had the C firmware and fido2 library, in less than 1 year we've got 3 other products embedding our code and also a couple manufacturers making demos with it -- a great win. With rust to my knowledge we're not there yet, but of course we're very positive.
[1] https://github.com/solokeys/solo2
[2] https://github.com/solokeys/solo1
> If you can use Rust, ignore Carbon.
So that's probably one reason.
[1]: https://github.com/carbon-language/carbon-lang/blob/trunk/do...
I started to explore the area, mostly arm based (rp2040 and STM) and a little bit of ESP32.
Tool chain wise:
ESP32 support is very recent and still based on the C tool chain and this makes it very fragile (you can break your environment easily and it is never clear how to recover except recompiling the entire tooolchain from 0)
Arm is a little better because the support is native.
The community is trying to make a generic embedded Hal platform API and implement it for specific devices. And it is pretty bad: almost no documentation, very few examples, tons of autogenerated code where you need to come back to the C world to understand the actual concepts.
Once you start to get going Rust is a blast to program in and the generated code is pretty efficient.
A small project a shared to help people starting on a lilygo device: https://github.com/gbin/rp2040-mandel-pico
I'm not a Rust-only developer, but a systems programmer, and my foray into embedded is limited to a side project, but no, I haven't switched to C/C++. Rust brings too much goodness to give it up.
Rust-embedded is an easy ecosystem to work with (if immature), and if you want more flexibility, Tock OS [0] is trying to cover that space (also immature, but I'm working on it).
[0] https://www.tockos.org/
On the code side it's pretty much the same as C++. You have a module that defines an interface and per-platform implementations that are included depending on a "configuration conditional checks" #[cfg(target_os = "linux")] macro.
https://github.com/tokio-rs/mio/blob/c6b5f13adf67483d927b176...
I’ve been super curious about both Rust and ESP. It seems like Espressif is interested enough to commission a Rust dev board (ESP32-C3-DevKit-RUST-1) and training using it.
https://github.com/esp-rs/esp-rust-board/
https://github.com/ferrous-systems/espressif-trainings
I’ve been super curious about both Rust and ESP. It seems like Espressif is interested enough to commission a Rust dev board (ESP32-C3-DevKit-RUST-1) and training using it.
https://github.com/esp-rs/esp-rust-board/
https://github.com/ferrous-systems/espressif-trainings
We rebuilt solo v2 [1] firmware in rust, compared to v1 in C [2]. I haven't written any rust code so take what I say with a grain of salt, but generally speaking I think our experience has been very positive.
Rust forced us to structure the code a bit better, that makes it easier for multiple people to collaborate on it. Slightly harder learning curve, but that wasn't an issue in our case.
In the history of solo, we had a couple security bugs that rust would probably have prevented, so this is a plus for the language. Moreover, the cryptography community is pretty active and we can leverage solid + well maintained libraries.
One downside has been collaboration with other OS projects. When we had the C firmware and fido2 library, in less than 1 year we've got 3 other products embedding our code and also a couple manufacturers making demos with it -- a great win. With rust to my knowledge we're not there yet, but of course we're very positive.
[1] https://github.com/solokeys/solo2
[2] https://github.com/solokeys/solo1