4 ms·

Well when people say "Ada" they usually mean SPARK not old or feature limited version of Ada. -Spark do verify contract using static analysis and proof. -Whil

• okl 3y ago
  > Well when people say "Ada" they usually mean SPARK not old or feature limited version of Ada. Having worked on several Ada projects professionally I can tell you that this is definitely not true. DO-178C applies to the process and does not make assumptions about programming languages.
• pcwalton 3y ago
  > -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).