5 ms·

Rust has lifetimes and ownership as language concepts so that you have to be explicit about who owns a resource, for example memory, but it does not give you a

Rust has lifetimes and ownership as language concepts so that you have to be explicit about who owns a resource, for example memory, but it does not give you a lot of control about what to do when an allocation fails. Zig is designed so that you can still peogrammatically deal with a failing allocation, as does well-written C, but it does not have a ownership system like Rust.

Yoric 8y ago
Ok, got it. Apparently, espeed was using an unusual definition of "memory safety", which made their comment a bit odd :)
- tom_mellior 8y ago
  What was unusual about that? Here is Wikipedia: "Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers.[1] For example, Java is said to be memory-safe because its runtime error detection checks array bounds and pointer dereferences." This is the mainstream definition. Do you think Zig doesn't have this, or Rust has more of this than Zig? What Rust does indeed have is freedom from race conditions, which can be viewed as a concurrent memory safety property. And what Rust also has is static checking of one of the above properties, namely dangling pointers (but not the other, namely buffer overflows). Do you think that if it's not statically checked, it's not safe? Because if you think that, you are wrong.
  - Yoric 8y ago
    I was referring to espeed's "Zig is similar to Rust, but with memory safety designed into the core, not bolted on as an afterthought", which he later explained with two examples, one of which actually justifies the words "bolted on as an afterthought", but refers to local handling of fallible allocation. While local handling of fallible allocation is a desirable feature for many applications, I confirm that neither me nor Wikipedia had never heard it classified as "memory safety" :)
    - tom_mellior 8y ago
      I agree that that aspect isn't relevant to what I would call memory safe. But how do you get from "espeed claimed something unreasonable" to "Rust looks more memory-safe than Zig"?
    - Yoric 8y ago
      > I agree that that aspect isn't relevant to what I would call memory safe. But how do you get from "espeed claimed something unreasonable" to "Rust looks more memory-safe than Zig"? Well, there are several reasons. For instance: - Rust tries very hard to prevent accidental mutations through aliases. In all the common cases and most of the uncommon ones, it works quite well. - Rust ensures that your memory can't be deallocated twice and that you can't dereference a dangling pointer. - Rust ensures that any object that needs to be accessed from several threads is either read-only or somehow protected. - Rust ensures that a context may not deallocate an object it does not own, nor mistakenly believe that it still has ownership of an object after it has transmitted this ownership to another context. At this (early) stage in the development of Zig, I have the impression that these aspects of memory safety do not exist in Zig, hence my comment. Now, I realize that Zig has at least one memory-safety check that `unsafe` Rust does not have, so it is entirely possible that both languages concentrate on different aspects of memory safety and/or different implementation techniques. I also believe that Zig is interesting and has lots of potential. But I suspect that Zig needs to grow a little before anyone can claim that Zig is more memory-safe than Rust (which is what I understand from the comment I was answering).
      - qop 8y ago
        I hate to say it, but this might be an instance where more jargon might help. "Memory safe" can have numerous implications because there are numerous methods for attacking memory of a program. As far as we know, there's no language that handles EVERYTHING, so maybe we need to start qualifying what these languages mean. Rust landing page does this well, "no race conditions, move semantics" but then rust users will parrot "it's memory safe, it's memory safe" and they can't explain how to deal with failed allocations in rust. Not that that's necessarily a big deal, but it's just bad terminology for what is a rather complex issue. It's almost like saying a language is "type safe". While reassuring, wtf does that actually mean? What kind of types? Is there polymorphism? Is there row types? Is there substructural typing? Type theorists generally have lots of terms to specify what flavor of types they're talking about, and that works well for them. Rust is kind of bringing a new generation of younger hackers to systems programming and you darned kids need to get off the grass and start being more specific about memory semantics in PLT! /s but kinda serious
  - steveklabnik 8y ago
    Rust does no have freedom from race conditions. It does have freedom from data races. They’re different things.
steveklabnik 8y ago
Rust’s standard library types do not give you that control. The language doesn’t know abou allocation, and you can build whatever you want on top of it.
- qop 8y ago
  #-#-# for Steve only "you can build whatever want on top of it" is a flashy way to say that "rust can't do that" in this instance. I suspect rust adoption would be much more effective if it wasn't presented as a panacea-like solution (it isnt) that the entirety of computer science has always dreamed of (it hasn't) and is ready to be used to write literally everything on earth in. The hubris of the rust team empowers projects like zig, which are clearly communicating what their offering can and cannot do. You're influential in the rust microcosm, why not communicate this? Why not build a campaign directly from the utility rust is actually presenting and not the pseudo-philosophical utility that mozilla erroneously assigns to rust? For a team that hacks bits and registers all day, I'm shocked how far rust evangelism has deviated from just the simple truth of the code. I wanted to share this with you privately, but I couldn't find you on any platform I feel comfortable using, and for some reason the best tech news aggregator in the world still doesn't do privmsg yet, so I hope I can ask you to take the perspective if what I'm trying to communicate here and not the "why you talking so loud?!" perspective. I see these little rust-isms where a defect or some aspect of rust is manipulated in a way as to empower it rather than illustrate the technical reality of it. Rust not having the ability to deal with failed allocation is or will be a show stopper for somebody, somewhere, eventually. It should be portrayed as such (or fixed and loudly announced) rather than saying, "oh, build whatever you want on top of that behavior" as if it's some brilliant idea. Disclaimer: I'm not a rust contributor. Disdisclaimer: there's love in my heart for rust but the marketing is reaching counterintelligence levels of euphemism and misdirextion and I'm confident that you have the influence and awareness to begin to fix this in the rustverse
  - dbaupp 8y ago
    > "you can build whatever want on top of it" is a flashy way to say that "rust can't do that" in this instance. It most definitely is not. "It" in "on top of it" refers to the language itself and the "core" subset of "std", which designed to cater for situations without any OS-level allocation at all, not the "std"s library's handling of OOM. Given that Rust can work without allocation, it can work with custom allocation-failure handling too: as a minimal proof, start with core only (no std) and create custom Box and Vec types (this probably isn't the best path, but it shows it is possible). > I suspect rust adoption would be much more effective if it wasn't presented as a panacea-like solution (it isnt) that the entirety of computer science has always dreamed of (it hasn't) and is ready to be used to write literally everything on earth in. > The hubris of the rust team empowers projects like zig, which are clearly communicating what their offering can and cannot do. The Rust team is good at clearly communicating the boundaries of Rust. Others may misinterpret that/be over-enthusiastic, but they're often called out (even by members of the Rust team) when it is noticed.

Yoric 8y ago

Ok, got it. Apparently, espeed was using an unusual definition of "memory safety", which made their comment a bit odd :)

tom_mellior 8y ago
What was unusual about that? Here is Wikipedia: "Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers.[1] For example, Java is said to be memory-safe because its runtime error detection checks array bounds and pointer dereferences." This is the mainstream definition. Do you think Zig doesn't have this, or Rust has more of this than Zig? What Rust does indeed have is freedom from race conditions, which can be viewed as a concurrent memory safety property. And what Rust also has is static checking of one of the above properties, namely dangling pointers (but not the other, namely buffer overflows). Do you think that if it's not statically checked, it's not safe? Because if you think that, you are wrong.
- Yoric 8y ago
  I was referring to espeed's "Zig is similar to Rust, but with memory safety designed into the core, not bolted on as an afterthought", which he later explained with two examples, one of which actually justifies the words "bolted on as an afterthought", but refers to local handling of fallible allocation. While local handling of fallible allocation is a desirable feature for many applications, I confirm that neither me nor Wikipedia had never heard it classified as "memory safety" :)
  - tom_mellior 8y ago
    I agree that that aspect isn't relevant to what I would call memory safe. But how do you get from "espeed claimed something unreasonable" to "Rust looks more memory-safe than Zig"?
  - Yoric 8y ago
    > I agree that that aspect isn't relevant to what I would call memory safe. But how do you get from "espeed claimed something unreasonable" to "Rust looks more memory-safe than Zig"? Well, there are several reasons. For instance: - Rust tries very hard to prevent accidental mutations through aliases. In all the common cases and most of the uncommon ones, it works quite well. - Rust ensures that your memory can't be deallocated twice and that you can't dereference a dangling pointer. - Rust ensures that any object that needs to be accessed from several threads is either read-only or somehow protected. - Rust ensures that a context may not deallocate an object it does not own, nor mistakenly believe that it still has ownership of an object after it has transmitted this ownership to another context. At this (early) stage in the development of Zig, I have the impression that these aspects of memory safety do not exist in Zig, hence my comment. Now, I realize that Zig has at least one memory-safety check that `unsafe` Rust does not have, so it is entirely possible that both languages concentrate on different aspects of memory safety and/or different implementation techniques. I also believe that Zig is interesting and has lots of potential. But I suspect that Zig needs to grow a little before anyone can claim that Zig is more memory-safe than Rust (which is what I understand from the comment I was answering).
    - qop 8y ago
      I hate to say it, but this might be an instance where more jargon might help. "Memory safe" can have numerous implications because there are numerous methods for attacking memory of a program. As far as we know, there's no language that handles EVERYTHING, so maybe we need to start qualifying what these languages mean. Rust landing page does this well, "no race conditions, move semantics" but then rust users will parrot "it's memory safe, it's memory safe" and they can't explain how to deal with failed allocations in rust. Not that that's necessarily a big deal, but it's just bad terminology for what is a rather complex issue. It's almost like saying a language is "type safe". While reassuring, wtf does that actually mean? What kind of types? Is there polymorphism? Is there row types? Is there substructural typing? Type theorists generally have lots of terms to specify what flavor of types they're talking about, and that works well for them. Rust is kind of bringing a new generation of younger hackers to systems programming and you darned kids need to get off the grass and start being more specific about memory semantics in PLT! /s but kinda serious
- steveklabnik 8y ago
  Rust does no have freedom from race conditions. It does have freedom from data races. They’re different things.

steveklabnik 8y ago

Rust’s standard library types do not give you that control. The language doesn’t know abou allocation, and you can build whatever you want on top of it.

qop 8y ago
#-#-# for Steve only "you can build whatever want on top of it" is a flashy way to say that "rust can't do that" in this instance. I suspect rust adoption would be much more effective if it wasn't presented as a panacea-like solution (it isnt) that the entirety of computer science has always dreamed of (it hasn't) and is ready to be used to write literally everything on earth in. The hubris of the rust team empowers projects like zig, which are clearly communicating what their offering can and cannot do. You're influential in the rust microcosm, why not communicate this? Why not build a campaign directly from the utility rust is actually presenting and not the pseudo-philosophical utility that mozilla erroneously assigns to rust? For a team that hacks bits and registers all day, I'm shocked how far rust evangelism has deviated from just the simple truth of the code. I wanted to share this with you privately, but I couldn't find you on any platform I feel comfortable using, and for some reason the best tech news aggregator in the world still doesn't do privmsg yet, so I hope I can ask you to take the perspective if what I'm trying to communicate here and not the "why you talking so loud?!" perspective. I see these little rust-isms where a defect or some aspect of rust is manipulated in a way as to empower it rather than illustrate the technical reality of it. Rust not having the ability to deal with failed allocation is or will be a show stopper for somebody, somewhere, eventually. It should be portrayed as such (or fixed and loudly announced) rather than saying, "oh, build whatever you want on top of that behavior" as if it's some brilliant idea. Disclaimer: I'm not a rust contributor. Disdisclaimer: there's love in my heart for rust but the marketing is reaching counterintelligence levels of euphemism and misdirextion and I'm confident that you have the influence and awareness to begin to fix this in the rustverse
- dbaupp 8y ago
  > "you can build whatever want on top of it" is a flashy way to say that "rust can't do that" in this instance. It most definitely is not. "It" in "on top of it" refers to the language itself and the "core" subset of "std", which designed to cater for situations without any OS-level allocation at all, not the "std"s library's handling of OOM. Given that Rust can work without allocation, it can work with custom allocation-failure handling too: as a minimal proof, start with core only (no std) and create custom Box and Vec types (this probably isn't the best path, but it shows it is possible). > I suspect rust adoption would be much more effective if it wasn't presented as a panacea-like solution (it isnt) that the entirety of computer science has always dreamed of (it hasn't) and is ready to be used to write literally everything on earth in. > The hubris of the rust team empowers projects like zig, which are clearly communicating what their offering can and cannot do. The Rust team is good at clearly communicating the boundaries of Rust. Others may misinterpret that/be over-enthusiastic, but they're often called out (even by members of the Rust team) when it is noticed.