4 ms·

Rust is the first (yes, first) mainstream language that offered reasonable and composable memory safety, without compromising on speed. Ada does not offer anyt

Rust is the first (yes, first) mainstream language that offered reasonable and composable memory safety, without compromising on speed. Ada does not offer anything similar. It's designed for programs that are mostly static. It also does not compose well, as you can't dynamically allocate without losing most of Ada touted advantages. To be fair, they recognized it. Their plan is to adopt a borrow-checker.

tubs 2y ago
In rust dynamic allocations usually just end up with runtime asserts from your ref counting gc implementation though.
- IshKebab 2y ago
  No they don't. Most programs are full of dynamic allocations (String, Vec, etc.) with only rare use of RefCell (I assume that's what you're talking about).
  - Galanwe 2y ago
    Most non trivial programs I've seen in Rust just end up with Arc<> and copies all over the place, because getting lifetimes right becomes borderline insanity.
    - IshKebab 2y ago
      It totally depends on the program. Sometimes you need to use Arc, sometimes you don't. Arc doesn't involve any runtime asserts though and it's not a crime to use it. For example I just ripgrep. Arc is used 29 times, compared to 185 uses of Vec.
palata 2y ago
> Rust is the first (yes, first) mainstream language that offered reasonable and composable memory safety, without compromising on speed. Is that true, though? Many memory-safe languages are very fast (fast enough for the vast majority of use-cases). Feels like mostly they compromise on memory, don't they? Rust seems to be a good replacement for those use-cases where C++ is needed. But given the popularity of Rust, it seems to me that many people use Rust where they don't actually need it. (Disclaimer: I do like Rust)
- maleldil 2y ago
  > Many memory-safe languages are very fast (fast enough for the vast majority of use-cases). That depends on what "fast enough" means. A better way would be to say "memory-safe with (near) zero overhead".
  - palata 2y ago
    Well, fast enough means that you don't need it to be faster, and therefore it is not a reason to use Rust :-).
    - tcfhgj 2y ago
      It is. Faster means less CPU cycles, means people use less power and throw their devices away less often
      - palata 2y ago
        Except if you write code that wastes CPU cycles. It's not like Rust optimises your code, is it? I would think that the main cause for wasted CPU cycles is the code written by the developer, not the language.
        tcfhgj 2y ago
        If you don't write it in Rust, it's compiler won't optimize anything, will it?
        palata 2y ago
        Not sure if that's bad faith, but I will assume you did not understand my point. My point was that it's not enough to say "If you use Rust, your code will run faster", because the language does not do it all. Most code out there is largely inefficient. The tendency is to pile up dependencies and frameworks to be more productive. No need for Rust to make an ElectronJS app vastly more efficient. Similarly, I recently wrote a TUI with a popular Rust TUI library, and it takes up to 10% CPU just by refreshing the view when typing a text. It's not my code, it's the (again, popular) library that explicitly doesn't consider that a problem. It's not because it is written in Rust that it is efficient, is it?

tubs 2y ago

In rust dynamic allocations usually just end up with runtime asserts from your ref counting gc implementation though.

IshKebab 2y ago
No they don't. Most programs are full of dynamic allocations (String, Vec, etc.) with only rare use of RefCell (I assume that's what you're talking about).
- Galanwe 2y ago
  Most non trivial programs I've seen in Rust just end up with Arc<> and copies all over the place, because getting lifetimes right becomes borderline insanity.
  - IshKebab 2y ago
    It totally depends on the program. Sometimes you need to use Arc, sometimes you don't. Arc doesn't involve any runtime asserts though and it's not a crime to use it. For example I just ripgrep. Arc is used 29 times, compared to 185 uses of Vec.

palata 2y ago

> Rust is the first (yes, first) mainstream language that offered reasonable and composable memory safety, without compromising on speed. Is that true, though? Many memory-safe languages are very fast (fast enough for the vast majority of use-cases). Feels like mostly they compromise on memory, don't they? Rust seems to be a good replacement for those use-cases where C++ is needed. But given the popularity of Rust, it seems to me that many people use Rust where they don't actually need it. (Disclaimer: I do like Rust)

maleldil 2y ago
> Many memory-safe languages are very fast (fast enough for the vast majority of use-cases). That depends on what "fast enough" means. A better way would be to say "memory-safe with (near) zero overhead".
- palata 2y ago
  Well, fast enough means that you don't need it to be faster, and therefore it is not a reason to use Rust :-).
  - tcfhgj 2y ago
    It is. Faster means less CPU cycles, means people use less power and throw their devices away less often
    - palata 2y ago
      Except if you write code that wastes CPU cycles. It's not like Rust optimises your code, is it? I would think that the main cause for wasted CPU cycles is the code written by the developer, not the language.
      - tcfhgj 2y ago
        If you don't write it in Rust, it's compiler won't optimize anything, will it?
        palata 2y ago
        Not sure if that's bad faith, but I will assume you did not understand my point. My point was that it's not enough to say "If you use Rust, your code will run faster", because the language does not do it all. Most code out there is largely inefficient. The tendency is to pile up dependencies and frameworks to be more productive. No need for Rust to make an ElectronJS app vastly more efficient. Similarly, I recently wrote a TUI with a popular Rust TUI library, and it takes up to 10% CPU just by refreshing the view when typing a text. It's not my code, it's the (again, popular) library that explicitly doesn't consider that a problem. It's not because it is written in Rust that it is efficient, is it?