4 ms·

Honestly, the biggest thing that concerns me with using Rust for embedded is the size of the crates. We were looking to do some packages for a product, and the

Honestly, the biggest thing that concerns me with using Rust for embedded is the size of the crates. We were looking to do some packages for a product, and the Rust packages were huge compared to the C++ ones. Granted, this was mostly because the C++ ones could use .so's, while Rust had to compile those into the crate, but this is a huge issue when doing OTA updates.

steveklabnik 3y ago
It's just something you have to care about, but it's not a show-stopper. We use a bunch of crates in our projects at work, I left some example sizes in a comment a while back https://news.ycombinator.com/item?id=34032824 https://news.ycombinator.com/item?id=34032824
- infamouscow 3y ago
  It's a show stopper when size matters and you can't fit the binaries into flash. I'm sure "sorry for getting everyone to switch to this unestablished language" will go over very well with your boss and upper management. At least in C and C++ you can blame your tools. If you've stupidly convinced management the existing tooling is shit, then you've got a problem. And I don't mean a technical one, I mean a problem with paying rent, because you're not going to be employed much longer.
  - steveklabnik 3y ago
    My point is that you can always fit the binaries into flash. There’s no inherent overhead.
    - infamouscow 3y ago
      That's great it works well for AMD64 Linux ELF files. I would be surprised if it didn't given the toolchain seems to have been designed around that triple specifically. But the majority of embedded platforms are not booting or running AMD64 Linux, they're running ARMv{6,7,8}, MIPS, or 32-bit RISC-V chips.
      - steveklabnik 3y ago
        This is not for Linux, these are for the RTOS that we have authored. Bare metal 32 bit ARM. Basically, you've confused the two examples: the first one is about x86_64 Linux, yes, but the rest are all thumbv6m-none-eabi, thumbv7em-none-eabihf, thumbv8m.main-none-eabihf, stuff like that.

steveklabnik 3y ago

It's just something you have to care about, but it's not a show-stopper. We use a bunch of crates in our projects at work, I left some example sizes in a comment a while back https://news.ycombinator.com/item?id=34032824 https://news.ycombinator.com/item?id=34032824

infamouscow 3y ago
It's a show stopper when size matters and you can't fit the binaries into flash. I'm sure "sorry for getting everyone to switch to this unestablished language" will go over very well with your boss and upper management. At least in C and C++ you can blame your tools. If you've stupidly convinced management the existing tooling is shit, then you've got a problem. And I don't mean a technical one, I mean a problem with paying rent, because you're not going to be employed much longer.
- steveklabnik 3y ago
  My point is that you can always fit the binaries into flash. There’s no inherent overhead.
  - infamouscow 3y ago
    That's great it works well for AMD64 Linux ELF files. I would be surprised if it didn't given the toolchain seems to have been designed around that triple specifically. But the majority of embedded platforms are not booting or running AMD64 Linux, they're running ARMv{6,7,8}, MIPS, or 32-bit RISC-V chips.
    - steveklabnik 3y ago
      This is not for Linux, these are for the RTOS that we have authored. Bare metal 32 bit ARM. Basically, you've confused the two examples: the first one is about x86_64 Linux, yes, but the rest are all thumbv6m-none-eabi, thumbv7em-none-eabihf, thumbv8m.main-none-eabihf, stuff like that.