5 ms·

This analogy seems pretty disingenuous. Static memory safety isn't an unambiguous good like handwashing; it has tradeoffs. There are many projects where control

This analogy seems pretty disingenuous. Static memory safety isn't an unambiguous good like handwashing; it has tradeoffs. There are many projects where control over memory is critically important and using a language like Rust is a non-starter. Also, the implication that developers who don't switch to Rust are negligently harming people is unnecessarily moralistic and divisive.

iudqnolq 3y ago
You're right overall. But I don't think there's any project that needs control over memory that Rust can't provide. Maybe you mean it would be inconvenient and not provide significant benefit?
ykonstant 3y ago
>There are many projects where control over memory is critically important and using a language like Rust is a non-starter I am not very familiar with Rust, but I thought it permits full control over memory?
- edude03 3y ago
  Only if you use unsafe and even then three are restrictions. The general idea of rust is that it will only let you do things it can verify are safe otherwise it won't compile.
  - insanitybit 3y ago
    > Only if you use unsafe and even then three are restrictions. I can't think of any. The borrow checker still checks your code but you can forge, twiddle, and cast pointers, there's really nothing you can't do that I can think of.
    - edude03 3y ago
      From https://github.com/itfanr/rust-doc-en/blob/master/unsafe.md#unsafe-superpowers https://github.com/itfanr/rust-doc-en/blob/master/unsafe.md#... > In both unsafe functions and unsafe blocks, Rust will let you do three things that you normally can not do. Just three. Here they are: > Access or update a static mutable variable. Dereference a raw pointer. Call unsafe functions. This is the most powerful ability. That’s it. It’s important that unsafe does not, for example, ‘turn off the borrow checker’. Adding unsafe to some random Rust code doesn’t change its semantics, it won’t start accepting anything. But it will let you write things that do break some of the rules.
      - insanitybit 3y ago
        That doesn't change anything I said. Those unsafe functions include things like casting pointers. There's nothing you can't do through some composition of those 3 things.
- marcosdumay 3y ago
  Yes. It allows for more control over memory than C, where a lot of things are undefined behavior.
  - fasterik 3y ago
    "More control over memory than C" is nonsense. C allows you to do anything the machine's instruction set is capable of, all the way down to inline assembly. Undefined behavior is a completely separate conversation. UB is necessary to output performant code. If dereferencing a null pointer were defined behavior, then the compiler would need to insert a check for every dereference, which would slow down your code.
    - marcosdumay 3y ago
      > C allows you to do anything the machine's instruction set is capable of Hum, no, unless you count inline asm, it simply doesn't. And for more control over memory than C, Rust allows mapping high-level types into fixed memory, so the compiler can actually use the correct asm primitives and make your access fast. On C you either have to use a general purpose array abstraction or try to map your types over the memory and pray the compiler resolves all the UB the way you want. Most C developers do the later.
      - fasterik 3y ago
        I have no idea what you're talking about with "general purpose array abstraction" and "map your types over the memory". A struct in C is just a fixed size chunk of memory where the fields have a fixed offset. Access is a simple memory read/write. An array in C is also just a chunk of memory, where subscripting is some simple pointer math. There is no UB involved. If you could give a concrete example of what you're talking about and why it's better in Rust than in C, that might be helpful.
eternityforest 3y ago
Projects where you need to think about memory are a pretty small percentage of projects. Even on embedded systems, I wouldn't be surprised if there comes a time when nobody even knows what a register is. For projects where you do need rust, obviously "This is literally impossible to do any other way" takes precedence over "It's best practice to do it this way", but the rest of the time.... I'm not sure I see the tradeoffs unless you're doing some crazy hand optimized low level library, or you just have a strong preference for direct control. The existence of Redox OS in my mind is enough to prove that Rust can do just about anything and lower level stuff is needed less than people seem to think Then again, I haven't worked much with Rust, it's only just now supported on any platforms where I'd have a reason to use something lower than JS/Python.
- deleted 3y ago
  [deleted]
- fasterik 3y ago
  >Projects where you need to think about memory are a pretty small percentage of projects. Performance matters in every project, and the way you get performance on modern processors is by using the cache effectively. That requires a certain amount of control over memory layout and access. It's not so much about what's possible in a given language, it's about what features you're using and what features are getting in the way. Sure, you can write a bunch of unsafe Rust, but at what point are you fighting against the language and adding unnecessary friction?
  - eternityforest 3y ago
    The way you get performance on modern processors is to use libraries that use the cache effectively for the stuff that actually eats CPU. High level languages are good at enabling high level optimizations like caching and special case handling of things, which might be a bigger gain than anything to do with memory layouts except in a few inner loops. High performance and reasonably focused low complexity stuff might be a good fit for C, until compilers get even better. But in a web browser? I guess time will tell, but my guess is the ability to more effectively manage complexity will let people do more high level optimizations with less fear of buffer overflows from more code. Things like "In this specific case I can fall back to this very simple plaintext rendering for this one section" might save more CPU than "We made all rendering a bit faster" especially if you just keep doing the performance critical stuff in C.

iudqnolq 3y ago

You're right overall. But I don't think there's any project that needs control over memory that Rust can't provide. Maybe you mean it would be inconvenient and not provide significant benefit?

ykonstant 3y ago

>There are many projects where control over memory is critically important and using a language like Rust is a non-starter I am not very familiar with Rust, but I thought it permits full control over memory?

edude03 3y ago
Only if you use unsafe and even then three are restrictions. The general idea of rust is that it will only let you do things it can verify are safe otherwise it won't compile.
- insanitybit 3y ago
  > Only if you use unsafe and even then three are restrictions. I can't think of any. The borrow checker still checks your code but you can forge, twiddle, and cast pointers, there's really nothing you can't do that I can think of.
  - edude03 3y ago
    From https://github.com/itfanr/rust-doc-en/blob/master/unsafe.md#unsafe-superpowers https://github.com/itfanr/rust-doc-en/blob/master/unsafe.md#... > In both unsafe functions and unsafe blocks, Rust will let you do three things that you normally can not do. Just three. Here they are: > Access or update a static mutable variable. Dereference a raw pointer. Call unsafe functions. This is the most powerful ability. That’s it. It’s important that unsafe does not, for example, ‘turn off the borrow checker’. Adding unsafe to some random Rust code doesn’t change its semantics, it won’t start accepting anything. But it will let you write things that do break some of the rules.
    - insanitybit 3y ago
      That doesn't change anything I said. Those unsafe functions include things like casting pointers. There's nothing you can't do through some composition of those 3 things.
marcosdumay 3y ago
Yes. It allows for more control over memory than C, where a lot of things are undefined behavior.
- fasterik 3y ago
  "More control over memory than C" is nonsense. C allows you to do anything the machine's instruction set is capable of, all the way down to inline assembly. Undefined behavior is a completely separate conversation. UB is necessary to output performant code. If dereferencing a null pointer were defined behavior, then the compiler would need to insert a check for every dereference, which would slow down your code.
  - marcosdumay 3y ago
    > C allows you to do anything the machine's instruction set is capable of Hum, no, unless you count inline asm, it simply doesn't. And for more control over memory than C, Rust allows mapping high-level types into fixed memory, so the compiler can actually use the correct asm primitives and make your access fast. On C you either have to use a general purpose array abstraction or try to map your types over the memory and pray the compiler resolves all the UB the way you want. Most C developers do the later.
    - fasterik 3y ago
      I have no idea what you're talking about with "general purpose array abstraction" and "map your types over the memory". A struct in C is just a fixed size chunk of memory where the fields have a fixed offset. Access is a simple memory read/write. An array in C is also just a chunk of memory, where subscripting is some simple pointer math. There is no UB involved. If you could give a concrete example of what you're talking about and why it's better in Rust than in C, that might be helpful.

eternityforest 3y ago

Projects where you need to think about memory are a pretty small percentage of projects. Even on embedded systems, I wouldn't be surprised if there comes a time when nobody even knows what a register is. For projects where you do need rust, obviously "This is literally impossible to do any other way" takes precedence over "It's best practice to do it this way", but the rest of the time.... I'm not sure I see the tradeoffs unless you're doing some crazy hand optimized low level library, or you just have a strong preference for direct control. The existence of Redox OS in my mind is enough to prove that Rust can do just about anything and lower level stuff is needed less than people seem to think Then again, I haven't worked much with Rust, it's only just now supported on any platforms where I'd have a reason to use something lower than JS/Python.

deleted 3y ago
[deleted]
fasterik 3y ago
>Projects where you need to think about memory are a pretty small percentage of projects. Performance matters in every project, and the way you get performance on modern processors is by using the cache effectively. That requires a certain amount of control over memory layout and access. It's not so much about what's possible in a given language, it's about what features you're using and what features are getting in the way. Sure, you can write a bunch of unsafe Rust, but at what point are you fighting against the language and adding unnecessary friction?
- eternityforest 3y ago
  The way you get performance on modern processors is to use libraries that use the cache effectively for the stuff that actually eats CPU. High level languages are good at enabling high level optimizations like caching and special case handling of things, which might be a bigger gain than anything to do with memory layouts except in a few inner loops. High performance and reasonably focused low complexity stuff might be a good fit for C, until compilers get even better. But in a web browser? I guess time will tell, but my guess is the ability to more effectively manage complexity will let people do more high level optimizations with less fear of buffer overflows from more code. Things like "In this specific case I can fall back to this very simple plaintext rendering for this one section" might save more CPU than "We made all rendering a bit faster" especially if you just keep doing the performance critical stuff in C.