4 ms·

> Rust is the first (yes, first) mainstream language that offered reasonable and composable memory safety, without compromising on speed. Is that true, though?

by 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?
        tcfhgj 2y ago
        > It's not because it is written in Rust that it is efficient, is it? no, but 1) Rust significantly raises the boundary and on average it's probably more likely too
        palata 2y ago
        As I said, the one example I have is a very popular TUI library and it's a lot less efficient than the popular alternative in at least 2 other memory-safe languages I tried.
        tcfhgj 2y ago
        that's why I wrote on avg
        palata 2y ago
        Well you threw as a belief that because Rust is advertised as fast, people implementing Rust libraries probably care about speed on average. I don't see why they would care more, and in my experience they don't, on average.
  - IshKebab 2y ago
    No, for systems programming it means nobody needs it to be faster. You're welcome to use Python for whatever slow scripting you personally need, but it's not suitable for writing an OS and libraries because it's going to make every program slower, and while that might be ok for you, it's not going to be ok for a lot of people.
    - palata 2y ago
      I explicitly said "for the vast majority of use-cases". Of course you can pick one that is not part of it and pretend I included it in that majority, but then... what's the point of even trying to communicate?
      - IshKebab 2y ago
        The comments you're replying to aren't claiming that Rust is the only language that is fast enough for any use case. They're pointing out that Rust is the only language that is memory safe > without compromising on speed I was just trying to explain why that matters to you. Nobody is saying you have to use Rust for everything.
        palata 2y ago
        What? I am answering by quoting it: > Rust is the first (yes, first) mainstream language that offered reasonable and composable memory safety, without compromising on speed. My point is that I am not completely sure if we can say that Rust is the first (yes, first) at that.
        IshKebab 2y ago
        What mainstream language was before it that offered reasonable and composable memory safety without compromising on speed? I've never heard of one.
        palata 2y ago
        Well, Java is memory safe, and the JVM is fast enough for tons of use-cases. Before you get at me for "fast enough", let me say that "without compromising on speed" doesn't mean anything either. I can write super slow code in Rust, it's not like the language prevents me from doing it. My point is that in many cases, the speed is really not the problem with the JVM.
pdimitar 2y ago
"Fast enough" is doing a lot of lifting in your argument. I've met plenty of embedded devs that said they'll only code either C or Rust and that nothing else comes close in terms of tooling / dev UX and speed. For all my 23 years of work a language like Elixir (or even Ruby) was "fast enough" but there exist a ton of other world out there that needs more.
- palata 2y ago
  > I've met plenty of embedded devs Because when I said "for the vast majority of use-cases", I expected people to understand that I agree that some use-cases can't run e.g. a garbage collector.
  - pdimitar 2y ago
    And I did understand you. Point was that "fast enough" is definitely not good enough for a lot of other use cases, nothing else. If anything, that's kind of reinforcing your point. :)
    - palata 2y ago
      Right. Yeah then we agree :-). As I said, I do like Rust, and I think it makes sense in many cases. I just feel like I read a lot of "Rust is the only worthwhile language our there", and actually there are many languages that are a better fit in their use-case.
      - pdimitar 2y ago
        > I just feel like I read a lot of "Rust is the only worthwhile language our there" Pay no attention to zealots. Every community has them. I love Rust beyond what's rational and I still am sensible enough to reject it for projects where it would only prolong development time for not much gain (the projects in question do not need the super-duper speed or to use much less memory than you would get with my favorite Elixir, for example). And for a lot of script-ish / one-off / I-want-to-finish-it-quickly projects I just opt for Golang. IMO projects like rewriting the UNIX userland utilities in Rust makes perfect sense; the originals are super old and nobody wants to seriously find security bugs in them and since they are written in C you can bet your neck they absolutely do have buffer over-/under-flow bugs that can likely lead to escalation of privileges. Is anybody fuzzing those tools 24/7 for years? They are the buildings blocks of at least 90% of all servers out there! Rust makes sense in embedded as well, in financial trading, or in any system that has to squeeze every last drop of its hardware in general. But web applications / API endpoints / API gateways and such? Meh, a compiled language in a VM like Elixir is plenty enough and always will be. "Right tool for the job" should be the first catechism of the future Tech Priests and their cult to the Omnissiah (insert "Warhammer 40,0000" reference here ㋡).
cyberax 2y ago
Before Rust, the only way to achieve memory safety was to use a garbage collector. Or static allocations. Experiments with region inference like in Cyclone were impractical, because they often led to accidental memory explosions. And adding a GC is a hugely impactful step.
- palata 2y ago
  Well I agree that it is impactful. My point is that it's not necessarily impacting the speed.

IshKebab 2y ago
"without compromising on speed" absolutely does mean something, and it doesn't mean "fast enough". It means you couldn't write faster code if you did it by hand in assembly. In C++ they call it "zero-cost abstraction" (you can Google that). Adding GC adds all sorts of overheads that you can avoid in C and Rust. Obviously in some cases you can beat the compiler, but in general it means there aren't any systematic overheads.
- palata 2y ago
  > "without compromising on speed" absolutely does mean something, and it doesn't mean "fast enough". I Googled "without compromising on speed" and didn't find a formal definition. Would you mind helping me there? "Zero-cost abstraction" is a concept I understand. But... are you sure that it would be impossible to write faster code (even if you did it perfectly in assembly) than what Rust generates when you use `RefCell`? Feels like it is compromising on speed, to some extent. > but in general it means there aren't any systematic overheads Or maybe I am wrong and there are absolutely no systematic overheads in any concept similar to `RefCell` in Rust? Is `RefCell` zero-cost? That's not my understanding.
  - IshKebab 2y ago
    > I Googled "without compromising on speed" and didn't find a formal definition. Would you mind helping me there? It's not a formal term. The meaning was clear though. > But... are you sure that it would be impossible to write faster code (even if you did it perfectly in assembly) than what Rust generates when you use `RefCell`? Absolutely! https://godbolt.org/z/aMPfqz396 https://godbolt.org/z/aMPfqz396 The second example is what you'd do if you were writing C or assembly. Rust takes the safer option by default. > Is `RefCell` zero-cost? That's not my understanding. I think you are misunderstanding what "zero-cost" means. Or maybe what RefCell does. RefCell checks are runtime if a value is borrowed by some other code. It's kind of like a single-threaded mutex. You can't implement that in assembly any better, so it is zero cost. You are probably thinking "but in C you don't need to use RefCell at all!", and that is true but unsafe. You can avoid that in Rust, but nobody does because it's 2 instructions (which will be perfectly branch predicted) so it essentially costs nothing. It's kind of like how `std::vector::at()` is still a zero-cost abstraction in C++. The thing you are abstracting is "array access with bounds check". You can't perform that function any better with hand-written assembly. Saying "aha, but in C we never bother with bounds checks!" doesn't invalidate that.
    - palata 2y ago
      > The meaning was clear though. Was it? You are telling me that it is actually possible to write faster code if it is unsafe, but for some reason it doesn't count as faster in your book, and therefore it's not compromising on speed ("just ignore the faster solutions"). With that kind of definition, all the code I ever wrote is provably optimal: if you ignore all the solutions that are more efficient than my code, then my code is the fastest.
      - IshKebab 2y ago
        Yes it was clear. Unsafe Rust is still Rust. I already explained that in some cases you can beat the compiler but there aren't any systematic overheads. I think you understand at this point and are just nitpicking to avoid admitting it, so goodbye.
        palata 2y ago
        I started by saying "hmm, it's not exactly not compromising on speed, but it's better for some use-cases indeed". You said "you're wrong, it is optimal". Now you say "it is not optimal, but it is very good, and I think you are nitpicking when you say it is not optimal". Sure, I'm nitpicking. I was nitpicking from the beginning on, I'm not sure what you were trying to say now.