4 ms·

As a side note, I am trying zig for embedded on tiny MCU and it is a better fit than rust. Not having to "move the borrow" for register around makes the code si

by kuon 4y ago

As a side note, I am trying zig for embedded on tiny MCU and it is a better fit than rust. Not having to "move the borrow" for register around makes the code simpler to reason about and also is important when flash is only a few kb. I think both languages have their applications and I am really happy with both. I hope both languages (and others!) will help us make quality and robust softwares in the long run.

lr1970 4y ago
When you are coding in Rust for tiny MCU sooner or later you would code some functions in assembler or in unsafe Rust. At this point Rust does not provide much of the advantages over Zig as far as safety guarantees are concerned. Lightweight Zig seems to fit this space better that heavy Rust.
- rowanG077 4y ago
  Besides the CTE and Cross compiling, what is objectively better in Zig then in Rust? Just the Rust ecosystem would sway me towards it honestly instead of something esotoric like Zig. Writing unsafe Rust is not really a problem I have.
  - kuon 4y ago
    Well, I am not saying it is better objectively, but for my uses it was easier. I wrote a firmware in rust and I rewrote it in zig as my first real world exercice, I ended up with 90% less code. Rust has really great abstraction and I like it, but for some things it is overkill. In zig I didn't need much of the abstraction because I did not have to make the borrow checker happy. In rust you have to structure your code in a way each part of it will have access to what it needs. In zig you just access it, as a global if needed. And sometimes the ability that zig code have to fit in memory (mine) is a real productivity boost.
- throwaway81523 4y ago
  Small MCU programming usually doesn't use dynamic memory allocation at all. Does Rust bring borrowing into play in any other situations? I don't know anything about Zig and should probably look into it, but I think Ada is underrated for MCU's.
  - steveklabnik 4y ago
    Yes. Borrow checking is unrelated to dynamic memory allocation. The borrow checker checks that references point to valid memory. The location of that memory is not relevant. Also, Rust is more than a borrow checker. My day job is working on an embedded system that has zero dynamic allocation, and Rust’s other features are still very valuable to us, independent of the borrow checker (which also does bring value, to be clear.)
saidinesh5 4y ago
Out of curiosity, what Zig features do you find useful when it comes to programming for those 8-bit MCUs with tiny flash?
- kuon 4y ago
  Native support for static allocators like arena. Ability to compile C and call it with 0 efforts.
the__alchemist 4y ago
Could you give an example of `move the borrow`? I've noticed a lot of cumbersome APIs on Rust embedded, usually with the intent of building out an ecosystem vice writing firmware.
- kuon 4y ago
  I wasn't very clear, I clarified below.
prxm 4y ago
can you elaborate on what you mean by "move the borrow around registers", an example maybe? what other things are you experienced that are struggling doing in rust?
- kuon 4y ago
  I meant move the ownership. For one firmware, I have some code that keep the MCU sleeping and it wakes with I2C address match. When the I2C code handles the match, it must change the configuration of the system registers related to sleep to stay awake when waiting for interrupt, this means my I2C controller must be the owner of that register so it can change it. But after I2C handled the request the I2C controller must pass the register to the other controller that will go back to sleep when done. In rust I do that by having an Option<TheRegister> in both controller, and when I2C is done, main controller do the_option.take() to grab the register, do its job, then put it back. The usual way to do that in rust is to use Arc<Mutex<T>> but that doesn't work in my MCU, so I use the Option trick. The other hard thing is DMA, it requires a lot of fidling, while in zig it jus works.
  - the__alchemist 4y ago
    I'd argue these are related to current rust libraries rather than with Rust itself. For practical purposes this might not matter. I've been making an effort to clarify this, as I'm worried these early APIs will scare people away from Rust on embedded. I had to write my own HAL (with ergonomics and DMA-based APIs as priorities) since I ran into the same problems you describe.

by kuon 4y ago

lr1970 4y ago

When you are coding in Rust for tiny MCU sooner or later you would code some functions in assembler or in unsafe Rust. At this point Rust does not provide much of the advantages over Zig as far as safety guarantees are concerned. Lightweight Zig seems to fit this space better that heavy Rust.

rowanG077 4y ago
Besides the CTE and Cross compiling, what is objectively better in Zig then in Rust? Just the Rust ecosystem would sway me towards it honestly instead of something esotoric like Zig. Writing unsafe Rust is not really a problem I have.
- kuon 4y ago
  Well, I am not saying it is better objectively, but for my uses it was easier. I wrote a firmware in rust and I rewrote it in zig as my first real world exercice, I ended up with 90% less code. Rust has really great abstraction and I like it, but for some things it is overkill. In zig I didn't need much of the abstraction because I did not have to make the borrow checker happy. In rust you have to structure your code in a way each part of it will have access to what it needs. In zig you just access it, as a global if needed. And sometimes the ability that zig code have to fit in memory (mine) is a real productivity boost.
throwaway81523 4y ago
Small MCU programming usually doesn't use dynamic memory allocation at all. Does Rust bring borrowing into play in any other situations? I don't know anything about Zig and should probably look into it, but I think Ada is underrated for MCU's.
- steveklabnik 4y ago
  Yes. Borrow checking is unrelated to dynamic memory allocation. The borrow checker checks that references point to valid memory. The location of that memory is not relevant. Also, Rust is more than a borrow checker. My day job is working on an embedded system that has zero dynamic allocation, and Rust’s other features are still very valuable to us, independent of the borrow checker (which also does bring value, to be clear.)

saidinesh5 4y ago

Out of curiosity, what Zig features do you find useful when it comes to programming for those 8-bit MCUs with tiny flash?

kuon 4y ago
Native support for static allocators like arena. Ability to compile C and call it with 0 efforts.

the__alchemist 4y ago

Could you give an example of `move the borrow`? I've noticed a lot of cumbersome APIs on Rust embedded, usually with the intent of building out an ecosystem vice writing firmware.

kuon 4y ago
I wasn't very clear, I clarified below.

prxm 4y ago

can you elaborate on what you mean by "move the borrow around registers", an example maybe? what other things are you experienced that are struggling doing in rust?

kuon 4y ago
I meant move the ownership. For one firmware, I have some code that keep the MCU sleeping and it wakes with I2C address match. When the I2C code handles the match, it must change the configuration of the system registers related to sleep to stay awake when waiting for interrupt, this means my I2C controller must be the owner of that register so it can change it. But after I2C handled the request the I2C controller must pass the register to the other controller that will go back to sleep when done. In rust I do that by having an Option<TheRegister> in both controller, and when I2C is done, main controller do the_option.take() to grab the register, do its job, then put it back. The usual way to do that in rust is to use Arc<Mutex<T>> but that doesn't work in my MCU, so I use the Option trick. The other hard thing is DMA, it requires a lot of fidling, while in zig it jus works.
- the__alchemist 4y ago
  I'd argue these are related to current rust libraries rather than with Rust itself. For practical purposes this might not matter. I've been making an effort to clarify this, as I'm worried these early APIs will scare people away from Rust on embedded. I had to write my own HAL (with ergonomics and DMA-based APIs as priorities) since I ran into the same problems you describe.