10 ms·

I understand what you're getting at here I tbink, but one of the ecosystem challenges we run into is that while Rust is abstractly a fantastic choice for the do

I understand what you're getting at here I tbink, but one of the ecosystem challenges we run into is that while Rust is abstractly a fantastic choice for the domain of systems development that would often be served by Ada (in fact we think it's a lot better in some respects because we can do more statically ahead of time, that Ada does dynamically at runtime, by abusing the Rust type system and borrow-checker), the Rust ecosystem isn't really focused on this class of problems. There's significantly more attention provided to things like Wasm than there is to things like embedded use cases for example. The two languages, ecosystems, and communities seem to have largely non-overlapping objectives despite having overlapping technical capabilities.

Gibbon1 7y ago
> ore attention provided to things like Wasm than there is to things like embedded use cases for example. Things might be better, but last time I checked rust's compiler was a lot slower than C and the binaries were several times bigger. That last one is a big deal for embedded.
- steveklabnik 7y ago
  You can get Rust binaries just as small; the smallest known one was 145 bytes. Some defaults were recently adjusted to make them smaller by default too. https://github.com/tormol/tiny-rust-executable https://github.com/tormol/tiny-rust-executable
  - dev_dull 7y ago
    Nobody wants to play with their compiler to get a small binary. Languages are typically judged by their defaults. If rust can produce small binaries, then it must produce small binaries.
    - vbezhenar 7y ago
      If big binary works faster, I would prefer big binary any day. Nobody cares about disk size.
      - na85 7y ago
        >Nobody cares about disk size. Embedded people care.
        Koshkin 7y ago
        To be fair, “embedded people” do not use disks.
        pjmlp 7y ago
        They do when they embedded device happens to be a phone, tablet, POS, medical monitoring device, ...
        carlmr 7y ago
        Depends on the system, embedded is a very large section of the market.
      - shakna 7y ago
        And for most compilers, changing whether you care about binary size or performance, is a single switch away, not a series of enhancements you need to refer to a blog page to ensure you're doing it right.
        steveklabnik 7y ago
        Rust does have the same switches C compilers have, that do the same things.
    - steveklabnik 7y ago
      The point is to demonstrate what's inherently overhead and what isn't. Rust has effectively the exact same inherent overhead as C does; that's the point. > Nobody wants to play with their compiler to get a small binary... If rust can produce small binaries, then it must produce small binaries. Everything is a tradeoff. Smaller binaries may or may not perform better than larger ones. This is something you need to play with, just like in C. If one single setting made everything the best in all circumstances, it wouldn't be a setting. C compilers have these settings too. > Languages are typically judged by their defaults. As I mentioned, the defaults have also been adjusted to help out too.
    - deleted 7y ago
      [deleted]
    - fluffything 7y ago
      > Languages are typically judged by their defaults. If rust can produce small binaries, then it must produce small binaries. Code size isn't the only axes that can be used to measure the quality of a binary, there are many others: like run-time performance, portability, debuggability, etc. No C compiler I know optimizes for size by default, in fact, I don't know of any C compiler that, by default, optimizes anything at all. Clang, GCC, MSVC, and all other mainstream compilers require users to enable optimizations (O1, O2, O3, Ofast, etc.) and none of these are code-size optimizations. Only relatively recently have compilers grown the ability to optimize for size, and you have to go way out of your way to do it (enable Oz, disable debug information -g0, enable LTO -flto, ...). Optimizing for size over anything else by default is one of the worst trade-offs a compiler can make. It's a bad trade-offs for most programs, and it is a bad-tradeoff for most compiler users.
- atoav 7y ago
  Another consideration: Rust’s compiler is also slower because it does a lot more forces you to add error handling. In terms of real impact on developers I never felt it was dramatic. The rust language support in editors is so good that you will catch most errors before compiling. So once everything is dealt with you usually compile and it just works. Binary size is also one of these areas they are dealing with atm.
  - swsieber 7y ago
    It's also slower because it hands LLVM a boat-load of IR and relies on LLVM to optimize it (instead of doing it itself).
    - Gibbon1 7y ago
      I've heard this is mostly the answer. Which makes me assume that the LLVM is a bad match for rust's backend requirements.
  - pjmlp 7y ago
    So how come Ada, Delphi, C++ Builder, VC++, .NET Native, D compilers happen to be much faster?
devnulloverflow 7y ago
> The two languages, ecosystems, and communities seem to have largely non-overlapping objectives despite having overlapping technical capabilities. I keep thinking servers should be written a bit more like embedded thingies. (Though I suspect the actual trend is in the other direction). Both kinds of software deeply interested an asynchrony and concurrency (though not necessarily parallelism). And both also tend to talk over networks to other gadgets as part of a complex system. And since my job often revolves around putting out fires when severs OOM, I'd also like to see a lot less malloc(). It would be nice if software could place hard upper limits on how many resources (including RAM) it takes to serve a request and then reject requests early. With real-world languages and frameworks, we can only do very primitive approximations to this. But a framework written from the bottom-up with a malloc-is-evil mentality () might be able to do it.
- swsieber 7y ago
  hmm... there are many libraries that are no-alloc. It seems quite feasible (well, that and custom allocators are a thing now)..
- im_down_w_otp 7y ago
  We have a crate internally that uses type-level programming to do statically tracked memory allocation (technically the method can be used for other kinds of resource management too), so that we can have compile-time guarantees that allocations will always succeed and we'll never allow memory to be allocated from inappropriate regions (e.g. mapped registers). Layered on top of that we can also ensure that if at runtime your device memory configuration is sufficiently different from what your assumptions were at compile-time, then we don't allow the device to boot so that you don't end up in a dangerous resource exhaustion situation by accident. We use this for no_std embedded shaped use cases, but you could also use this library and programming model to create a special heap in your normal programs which have statically tracked allocations to create some region of your program context that you want to have assurances like that. We have 3-4 things kind of in that vein in our pipeline to open source, and I think that's number 3.
fluffything 7y ago
> There's significantly more attention provided to things like Wasm than there is to things like embedded use cases for example. Rust is a language developed by its users. The reason less things happen in Rust embedded domain, is because less companies pay people to work on embedded Rust than they do on WASM rust.

Gibbon1 7y ago

> ore attention provided to things like Wasm than there is to things like embedded use cases for example. Things might be better, but last time I checked rust's compiler was a lot slower than C and the binaries were several times bigger. That last one is a big deal for embedded.

steveklabnik 7y ago
You can get Rust binaries just as small; the smallest known one was 145 bytes. Some defaults were recently adjusted to make them smaller by default too. https://github.com/tormol/tiny-rust-executable https://github.com/tormol/tiny-rust-executable
- dev_dull 7y ago
  Nobody wants to play with their compiler to get a small binary. Languages are typically judged by their defaults. If rust can produce small binaries, then it must produce small binaries.
  - vbezhenar 7y ago
    If big binary works faster, I would prefer big binary any day. Nobody cares about disk size.
    - na85 7y ago
      >Nobody cares about disk size. Embedded people care.
      - Koshkin 7y ago
        To be fair, “embedded people” do not use disks.
        pjmlp 7y ago
        They do when they embedded device happens to be a phone, tablet, POS, medical monitoring device, ...
      - carlmr 7y ago
        Depends on the system, embedded is a very large section of the market.
    - shakna 7y ago
      And for most compilers, changing whether you care about binary size or performance, is a single switch away, not a series of enhancements you need to refer to a blog page to ensure you're doing it right.
      - steveklabnik 7y ago
        Rust does have the same switches C compilers have, that do the same things.
  - steveklabnik 7y ago
    The point is to demonstrate what's inherently overhead and what isn't. Rust has effectively the exact same inherent overhead as C does; that's the point. > Nobody wants to play with their compiler to get a small binary... If rust can produce small binaries, then it must produce small binaries. Everything is a tradeoff. Smaller binaries may or may not perform better than larger ones. This is something you need to play with, just like in C. If one single setting made everything the best in all circumstances, it wouldn't be a setting. C compilers have these settings too. > Languages are typically judged by their defaults. As I mentioned, the defaults have also been adjusted to help out too.
  - deleted 7y ago
    [deleted]
  - fluffything 7y ago
    > Languages are typically judged by their defaults. If rust can produce small binaries, then it must produce small binaries. Code size isn't the only axes that can be used to measure the quality of a binary, there are many others: like run-time performance, portability, debuggability, etc. No C compiler I know optimizes for size by default, in fact, I don't know of any C compiler that, by default, optimizes anything at all. Clang, GCC, MSVC, and all other mainstream compilers require users to enable optimizations (O1, O2, O3, Ofast, etc.) and none of these are code-size optimizations. Only relatively recently have compilers grown the ability to optimize for size, and you have to go way out of your way to do it (enable Oz, disable debug information -g0, enable LTO -flto, ...). Optimizing for size over anything else by default is one of the worst trade-offs a compiler can make. It's a bad trade-offs for most programs, and it is a bad-tradeoff for most compiler users.
atoav 7y ago
Another consideration: Rust’s compiler is also slower because it does a lot more forces you to add error handling. In terms of real impact on developers I never felt it was dramatic. The rust language support in editors is so good that you will catch most errors before compiling. So once everything is dealt with you usually compile and it just works. Binary size is also one of these areas they are dealing with atm.
- swsieber 7y ago
  It's also slower because it hands LLVM a boat-load of IR and relies on LLVM to optimize it (instead of doing it itself).
  - Gibbon1 7y ago
    I've heard this is mostly the answer. Which makes me assume that the LLVM is a bad match for rust's backend requirements.
- pjmlp 7y ago
  So how come Ada, Delphi, C++ Builder, VC++, .NET Native, D compilers happen to be much faster?

devnulloverflow 7y ago

> The two languages, ecosystems, and communities seem to have largely non-overlapping objectives despite having overlapping technical capabilities. I keep thinking servers should be written a bit more like embedded thingies. (Though I suspect the actual trend is in the other direction). Both kinds of software deeply interested an asynchrony and concurrency (though not necessarily parallelism). And both also tend to talk over networks to other gadgets as part of a complex system. And since my job often revolves around putting out fires when severs OOM, I'd also like to see a lot less malloc(). It would be nice if software could place hard upper limits on how many resources (including RAM) it takes to serve a request and then reject requests early. With real-world languages and frameworks, we can only do very primitive approximations to this. But a framework written from the bottom-up with a malloc-is-evil mentality () might be able to do it.

swsieber 7y ago
hmm... there are many libraries that are no-alloc. It seems quite feasible (well, that and custom allocators are a thing now)..
im_down_w_otp 7y ago
We have a crate internally that uses type-level programming to do statically tracked memory allocation (technically the method can be used for other kinds of resource management too), so that we can have compile-time guarantees that allocations will always succeed and we'll never allow memory to be allocated from inappropriate regions (e.g. mapped registers). Layered on top of that we can also ensure that if at runtime your device memory configuration is sufficiently different from what your assumptions were at compile-time, then we don't allow the device to boot so that you don't end up in a dangerous resource exhaustion situation by accident. We use this for no_std embedded shaped use cases, but you could also use this library and programming model to create a special heap in your normal programs which have statically tracked allocations to create some region of your program context that you want to have assurances like that. We have 3-4 things kind of in that vein in our pipeline to open source, and I think that's number 3.

fluffything 7y ago

> There's significantly more attention provided to things like Wasm than there is to things like embedded use cases for example. Rust is a language developed by its users. The reason less things happen in Rust embedded domain, is because less companies pay people to work on embedded Rust than they do on WASM rust.