5 ms·

> -While Ada is not as memory safe as Rust it's a lot more memory safe than popular languages Popular languages typically have garbage collectors and are memor

> -While Ada is not as memory safe as Rust it's a lot more memory safe than popular languages Popular languages typically have garbage collectors and are memory safe. If a language is not memory safe, like Ada, then it's automatically one of the least memory safe languages, measured by amount of use.

worik 3y ago
> Popular languages typically have garbage collectors and are memory safe. I Yes And those languages are unsuitable for real time systems Where Rust, and it seems Ada, excell
- kaba0 3y ago
  For hard real-time normal Rust (and I guess also Ada) is insufficient. This is such a niche of a sub-niche, that you no longer write the same language as for everything else, most OSs already preclude hard real-time by their very existence, etc. Soft real-time is absolutely doable with a GC, depending on the required targets. Java’s low-lat GC (ZGC) has <1ms max pause times - you might not make the latest AAA game with it, but for the vast majority of popular games that is more than good enough.
  - v9v 3y ago
    Ada has inbuilt features allowing you to restrict yourself to a safe subset of the language for real-time computing.[0] It can be argued that this is not "normal" Ada since you are restricting the use of the entire language, but the restriction profile itself is a feature of the language. [0]:https://learn.adacore.com/courses/Ada_For_The_Embedded_C_Developer/chapters/03_Concurrency.html#ada-for-embedded-c-dev-ravenscar https://learn.adacore.com/courses/Ada_For_The_Embedded_C_Dev...
  - worik 3y ago
    > For hard real-time normal Rust (and I guess also Ada) is insufficient Really? Expand on that please. I did not think so > Soft real-time is absolutely doable with a GC Some slippery definitions here. Clearly there is a middle ground (where I live) where rust works. GC languages do not One GC pause, ever, is too many
    - kaba0 3y ago
      You have 1ms pauses easily from simply the OS context-switching away from your program, so as I mentioned, unless you explicitly tune your OS, you have this kind of pauses, no matter the language, even if it’s hand-written assembly. Regarding the non-normal language: with hard real-time you wouldn’t want to allocate willy-nilly and rust doesn’t yet have generics for allocators (correct me if I’m wrong on this, I am not up-to-date here), so careless usage of the standard lib, or other crates is a no-go. For illustrative purposes, this is the same with C++ and `noexcept`. > Some slippery definitions here I don’t see the slippery part - it is a slope, though. Depending on what’s the latency requirements and to what percentile should it happen, you can use Rust (and other low-level languages) on the lower end (audio processing), some managed languages in the middle (many kind of games are absolutely fine with that - a single drop of frame is more than fine, hence the soft rt), and pretty much any managed language on the high end.
      - hollerith 3y ago
        >You have 1ms pauses easily from simply the OS context-switching It is routine for Rust code to run without an OS (e.g., on microcontrollers).
        kaba0 3y ago
        A subset of Rust. You can’t just write ordinary Rust for microcontrollers.
        deleted 3y ago
        [deleted]
        estebank 3y ago
        It depends on what you call "ordinary Rust", I guess. You can use an allocator on embedded, but likely won't want to. There are static types that provide the same APIs as the allocating data structures you'd miss[1]. Granted, you're not gonna be able to take any random crate that isn't designed for such an environment, but that's a different problem, and there's a fledging ecosystem of no_std crates out there. Despite all those caveats, you can still write very high level code in embedded Rust, even async/await state machines![2] 1: https://docs.rust-embedded.org/book/collections/index.html https://docs.rust-embedded.org/book/collections/index.html 2: https://interrupt.memfault.com/blog/embedded-async-rust https://interrupt.memfault.com/blog/embedded-async-rust

worik 3y ago

> Popular languages typically have garbage collectors and are memory safe. I Yes And those languages are unsuitable for real time systems Where Rust, and it seems Ada, excell

kaba0 3y ago
For hard real-time normal Rust (and I guess also Ada) is insufficient. This is such a niche of a sub-niche, that you no longer write the same language as for everything else, most OSs already preclude hard real-time by their very existence, etc. Soft real-time is absolutely doable with a GC, depending on the required targets. Java’s low-lat GC (ZGC) has <1ms max pause times - you might not make the latest AAA game with it, but for the vast majority of popular games that is more than good enough.
- v9v 3y ago
  Ada has inbuilt features allowing you to restrict yourself to a safe subset of the language for real-time computing.[0] It can be argued that this is not "normal" Ada since you are restricting the use of the entire language, but the restriction profile itself is a feature of the language. [0]:https://learn.adacore.com/courses/Ada_For_The_Embedded_C_Developer/chapters/03_Concurrency.html#ada-for-embedded-c-dev-ravenscar https://learn.adacore.com/courses/Ada_For_The_Embedded_C_Dev...
- worik 3y ago
  > For hard real-time normal Rust (and I guess also Ada) is insufficient Really? Expand on that please. I did not think so > Soft real-time is absolutely doable with a GC Some slippery definitions here. Clearly there is a middle ground (where I live) where rust works. GC languages do not One GC pause, ever, is too many
  - kaba0 3y ago
    You have 1ms pauses easily from simply the OS context-switching away from your program, so as I mentioned, unless you explicitly tune your OS, you have this kind of pauses, no matter the language, even if it’s hand-written assembly. Regarding the non-normal language: with hard real-time you wouldn’t want to allocate willy-nilly and rust doesn’t yet have generics for allocators (correct me if I’m wrong on this, I am not up-to-date here), so careless usage of the standard lib, or other crates is a no-go. For illustrative purposes, this is the same with C++ and `noexcept`. > Some slippery definitions here I don’t see the slippery part - it is a slope, though. Depending on what’s the latency requirements and to what percentile should it happen, you can use Rust (and other low-level languages) on the lower end (audio processing), some managed languages in the middle (many kind of games are absolutely fine with that - a single drop of frame is more than fine, hence the soft rt), and pretty much any managed language on the high end.
    - hollerith 3y ago
      >You have 1ms pauses easily from simply the OS context-switching It is routine for Rust code to run without an OS (e.g., on microcontrollers).
      - kaba0 3y ago
        A subset of Rust. You can’t just write ordinary Rust for microcontrollers.
        deleted 3y ago
        [deleted]
        estebank 3y ago
        It depends on what you call "ordinary Rust", I guess. You can use an allocator on embedded, but likely won't want to. There are static types that provide the same APIs as the allocating data structures you'd miss[1]. Granted, you're not gonna be able to take any random crate that isn't designed for such an environment, but that's a different problem, and there's a fledging ecosystem of no_std crates out there. Despite all those caveats, you can still write very high level code in embedded Rust, even async/await state machines![2] 1: https://docs.rust-embedded.org/book/collections/index.html https://docs.rust-embedded.org/book/collections/index.html 2: https://interrupt.memfault.com/blog/embedded-async-rust https://interrupt.memfault.com/blog/embedded-async-rust