3 ms·

> ownership, generics, safety, Async Aren’t they the main selling points of Rust? Why use Rust over another language if you’re not using its main features?

by dabinat 2mo ago

the__alchemist 2mo ago
Many would agree with you. For me, the main selling point is the overall pro/con balance of the language. It's just a nice language overall, especially when you place it only with other languages capable of running fast and low-level code. I don't see rust and think "I have to write using Safe abstractions, traits etc because they're the rust way". There are many reasons to choose (or not depending on your preferences) rust beyond that. For example: "I am choosing rust here because Python's slow and its module system is a mess" or, "I'm choosing Rust here because its enum and struct syntax is fantastic" or "I'm choosing rust here because I can install the toolchain with a single command, and compile + flash with another without getting frustrated". Or "I'm choosing rust here because it makes it easy to architect complicated programs, and has really nice copmile-time error messages". Stated another way: > Why use Rust over another language if you’re not using its main features? It depends on the use case and what language you're comparing it to.
crote 2mo ago
Yes, but actually no. In the embedded space the only other language worth considering is C/C++. The default is that everything is unsafe, so any Rust is already a massive improvement. Add to that the basic language UX and a lot of developers are waiting for an excuse to jump ship. However, that does not mean that every single piece of code must be 100% safe. An embedded developer today is already constantly juggling with safety. Especially when it comes to low-level hardware interaction, I'd rather have a raw unsafe API today than wait several years for an inevitably-flawed safe abstraction. I don't need Rust to track the ownership of an I2C peripheral. It's a nice-to-have, but it is easy enough to do by yourself - there aren't that many of them and interactions are rather obvious. I'm already used to the possibility of mishandling some pins resulting in the board catching fire, I promise I can handle this. On the other hand, I really do want Rust to keep track of what's going on in all my business logic, for all the same reasons you want memory safety on a regular computer. Is my 10k-line protocol handler safe? Sure would love a double-check on that! So no, I'm not really all that interested in the fancy clever abstractions. Making sure the KISS ones are rock solid is far more important to me.
- harpiaharpyja 2mo ago
  I've been introducing rust to our embedded projects at work for the past few years and I can really empathize with this. The rust embedded ecosystem seems to have way too much focus on ownership and safe handling of peripherals. Exactly as you say there's not many of them, you're limited to what's in the hardware. These are not things that you are dynamically spinning up and tearing down dozens of instances all the time but the HALs I've seen all treat them that way. The result is a lot of abstraction that creates a ton of needless boilerplate. I would rather these things just get out of the way and let me focus on building abstraction in the business logic where it's needed.

> ownership, generics, safety, Async Aren’t they the main selling points of Rust? Why use Rust over another language if you’re not using its main features?

by dabinat 2mo ago

> ownership, generics, safety, Async Aren’t they the main selling points of Rust? Why use Rust over another language if you’re not using its main features?

the__alchemist 2mo ago

Many would agree with you. For me, the main selling point is the overall pro/con balance of the language. It's just a nice language overall, especially when you place it only with other languages capable of running fast and low-level code. I don't see rust and think "I have to write using Safe abstractions, traits etc because they're the rust way". There are many reasons to choose (or not depending on your preferences) rust beyond that. For example: "I am choosing rust here because Python's slow and its module system is a mess" or, "I'm choosing Rust here because its enum and struct syntax is fantastic" or "I'm choosing rust here because I can install the toolchain with a single command, and compile + flash with another without getting frustrated". Or "I'm choosing rust here because it makes it easy to architect complicated programs, and has really nice copmile-time error messages". Stated another way: > Why use Rust over another language if you’re not using its main features? It depends on the use case and what language you're comparing it to.

crote 2mo ago

Yes, but actually no. In the embedded space the only other language worth considering is C/C++. The default is that everything is unsafe, so any Rust is already a massive improvement. Add to that the basic language UX and a lot of developers are waiting for an excuse to jump ship. However, that does not mean that every single piece of code must be 100% safe. An embedded developer today is already constantly juggling with safety. Especially when it comes to low-level hardware interaction, I'd rather have a raw unsafe API today than wait several years for an inevitably-flawed safe abstraction. I don't need Rust to track the ownership of an I2C peripheral. It's a nice-to-have, but it is easy enough to do by yourself - there aren't that many of them and interactions are rather obvious. I'm already used to the possibility of mishandling some pins resulting in the board catching fire, I promise I can handle this. On the other hand, I really do want Rust to keep track of what's going on in all my business logic, for all the same reasons you want memory safety on a regular computer. Is my 10k-line protocol handler safe? Sure would love a double-check on that! So no, I'm not really all that interested in the fancy clever abstractions. Making sure the KISS ones are rock solid is far more important to me.

harpiaharpyja 2mo ago
I've been introducing rust to our embedded projects at work for the past few years and I can really empathize with this. The rust embedded ecosystem seems to have way too much focus on ownership and safe handling of peripherals. Exactly as you say there's not many of them, you're limited to what's in the hardware. These are not things that you are dynamically spinning up and tearing down dozens of instances all the time but the HALs I've seen all treat them that way. The result is a lot of abstraction that creates a ton of needless boilerplate. I would rather these things just get out of the way and let me focus on building abstraction in the business logic where it's needed.