4 ms·

Rust binaries, once stripped, are not necessarily much fatter than their C++ counterparts. We're not expecting a huge increase there. Embedded distros should s

Rust binaries, once stripped, are not necessarily much fatter than their C++ counterparts. We're not expecting a huge increase there. Embedded distros should still be supported, though you might need to cross-compile for a few depending on rust toolchain availability. Cygwin is supposed to be getting a working rust target at some point, but who knows?

aragilar 2y ago
I fully expect fish 4.0 to be in openwrt (because openwrt runs on x86_64), but what percentage openwrt machines have the space to run it would be interesting (I suspect it won't be an issue, as likely those near the lower limit of openwrt are probably sticking with busybox anyway, and not installing a different shell). Personally, what I want is inexpensive hardware (routers, but also storage devices) that don't use much power (e.g. ~5W) but are also viable targets for projects like fish, so we can all have nice things.
- ComputerGuru 2y ago
  I know rust-fish is being used on at least some non-x86_64 non-aarch64 routers because we've accepted patches by those users to make it build on platforms without native 64-bit CAS.
  - saagarjha 2y ago
    That would be any pre-ARMv8.1 machine?
    - ComputerGuru 2y ago
      In this case, it was specifically openwrt on mipsel.
  - tialaramex 2y ago
    IIUC lacking 64-bit CAS is an example of a place where on the surface the Rust situation looks worse than C++ but that's misleading In this scenario C++ will provide "atomic" types that are just locking - they work but they don't have the behaviour you presumably wanted - and Rust will say OK, there's no 64-bit CAS so you can't have these features. If all you actually needed was a type that has apparently atomic behaviour then I guess the C++ feature is perfect, but I'm assuming almost nobody asks for an atomic type if they would have accepted a locked type instead and so for them Rust saying "No, sorry" is actually a good heads up that they need to think again for this target.
    - ComputerGuru 2y ago
      Interesting perspective. In our case, we accepted a patch to effectively use a lock around a 64-bit integer as the workaround for these platforms, however.

aragilar 2y ago

I fully expect fish 4.0 to be in openwrt (because openwrt runs on x86_64), but what percentage openwrt machines have the space to run it would be interesting (I suspect it won't be an issue, as likely those near the lower limit of openwrt are probably sticking with busybox anyway, and not installing a different shell). Personally, what I want is inexpensive hardware (routers, but also storage devices) that don't use much power (e.g. ~5W) but are also viable targets for projects like fish, so we can all have nice things.

ComputerGuru 2y ago
I know rust-fish is being used on at least some non-x86_64 non-aarch64 routers because we've accepted patches by those users to make it build on platforms without native 64-bit CAS.
- saagarjha 2y ago
  That would be any pre-ARMv8.1 machine?
  - ComputerGuru 2y ago
    In this case, it was specifically openwrt on mipsel.
- tialaramex 2y ago
  IIUC lacking 64-bit CAS is an example of a place where on the surface the Rust situation looks worse than C++ but that's misleading In this scenario C++ will provide "atomic" types that are just locking - they work but they don't have the behaviour you presumably wanted - and Rust will say OK, there's no 64-bit CAS so you can't have these features. If all you actually needed was a type that has apparently atomic behaviour then I guess the C++ feature is perfect, but I'm assuming almost nobody asks for an atomic type if they would have accepted a locked type instead and so for them Rust saying "No, sorry" is actually a good heads up that they need to think again for this target.
  - ComputerGuru 2y ago
    Interesting perspective. In our case, we accepted a patch to effectively use a lock around a 64-bit integer as the workaround for these platforms, however.