5 ms·

> new generations never heard of those languages and think C was the very first systems programming language. That's just it. Rust looks enough like C++ to cat

> new generations never heard of those languages and think C was the very first systems programming language. That's just it. Rust looks enough like C++ to catch on. This was not an accident though I can't say I'm jazzed about it. Rust brings a lot to the table with its type system too. I would rather be using Rust tomorrow than having had the benefits of say Pascal derivatives for the past 45 years. I'm not saying this just for effect: after the obvious ML influence, the parts of Rust I like most are the nuances. > Instead, many Rust users seem to sprinkle it everywhere. Is that true? You will necessarily see it in bindings, or to implement certain essential features that can't be implemented otherwise. Beyond that there is the motivation to use unsafe code for speed, hopefully this is mostly restricted to modules. Are you complaining that people are using when they could reasonably avoid it or that it is too often necessary?

pjmlp 11y ago
> Are you complaining that people are using when they could reasonably avoid it or that it is too often necessary? They are abusing it, specially as workarounds for constraints that cannot be expressed in the type system. While in the languages I mentioned, unsafe constructs are related any operation that might lead to memory corruption, some Rust devs are using it for anything they assume isn't logical safe. So you then get talks like the Session Types one at ICFP, that uses unsafe to control functions being called outside the protocol Traits that are being defined. Which lead to discussions like this one: https://github.com/rust-lang/rfcs/pull/1236#issuecomment-136875613 https://github.com/rust-lang/rfcs/pull/1236#issuecomment-136...
- kinghajj 11y ago
  So your objection is to how certain users (notably not the core dev team) utilize "unsafe", now with the language itself. It seems like the easiest way to mitigate this is with better documentation; surely, those other languages' equivalents of "unsafe" could also have been abused similarly, no?
  - pjmlp 11y ago
    No, because on those languages unsafe is only related to memory integrity.
- smosher_ 11y ago
  > They are abusing it, specially as workarounds for constraints that cannot be expressed in the type system. That doesn't sound like abuse to me, as long as the exposed interface remains safe. > some Rust devs are using it for anything they assume isn't logical safe. That sounds like an objection to the scope of what Rust defines as safe. Unless you mean to imply there are reasonable, Rust-safe ways to rewrite the transgressions. In the former case I have to disagree. It would be nice if we could prove more. But you can't prove everything. I haven't seen the ICFP talk but I might watch it later if you can link to a video. I've skimmed that discussion before but you will need to point out your objections—IMO it is great that Rust devs are having that discussion.
  - pjmlp 11y ago
    My objection is that I see unsafe just for memory integrity. For everything else something like contracts should be used, from my point of view. As for voicing my objections to the Rust community, being a language geek is one of my hobbies, but it doesn't mean I will ever use those languages at work. So I would only contribute noise to the discussions, which why I eventually moved away from Go and D forum discussions as well. My time is already quite filled following the JVM, .NET and C++ eco-systems, the ones I get payed to be an expert on.
    - smosher_ 11y ago
      > My objection is that I see unsafe just for memory integrity. Either you think this way because of a sense of orthodoxy or because you think memory safety is important in a way the other kinds of safety aren't. I disagree, especially since "memory safety" may or may not imply protection against aliasing of mutable data. Those nuances I like about Rust probably wouldn't exist without the broader scope of safety concerns. > As for voicing my objections to the Rust community, About the discussion you linked? I meant to me, in the service of explaining your objections. > My time is already quite filled following the JVM, .NET and C++ eco-systems, the ones I get payed to be an expert on. Well, that was important information. Thanks for making the time to share!
      - 11y ago

pjmlp 11y ago

> Are you complaining that people are using when they could reasonably avoid it or that it is too often necessary? They are abusing it, specially as workarounds for constraints that cannot be expressed in the type system. While in the languages I mentioned, unsafe constructs are related any operation that might lead to memory corruption, some Rust devs are using it for anything they assume isn't logical safe. So you then get talks like the Session Types one at ICFP, that uses unsafe to control functions being called outside the protocol Traits that are being defined. Which lead to discussions like this one: https://github.com/rust-lang/rfcs/pull/1236#issuecomment-136875613 https://github.com/rust-lang/rfcs/pull/1236#issuecomment-136...

kinghajj 11y ago
So your objection is to how certain users (notably not the core dev team) utilize "unsafe", now with the language itself. It seems like the easiest way to mitigate this is with better documentation; surely, those other languages' equivalents of "unsafe" could also have been abused similarly, no?
- pjmlp 11y ago
  No, because on those languages unsafe is only related to memory integrity.
smosher_ 11y ago
> They are abusing it, specially as workarounds for constraints that cannot be expressed in the type system. That doesn't sound like abuse to me, as long as the exposed interface remains safe. > some Rust devs are using it for anything they assume isn't logical safe. That sounds like an objection to the scope of what Rust defines as safe. Unless you mean to imply there are reasonable, Rust-safe ways to rewrite the transgressions. In the former case I have to disagree. It would be nice if we could prove more. But you can't prove everything. I haven't seen the ICFP talk but I might watch it later if you can link to a video. I've skimmed that discussion before but you will need to point out your objections—IMO it is great that Rust devs are having that discussion.
- pjmlp 11y ago
  My objection is that I see unsafe just for memory integrity. For everything else something like contracts should be used, from my point of view. As for voicing my objections to the Rust community, being a language geek is one of my hobbies, but it doesn't mean I will ever use those languages at work. So I would only contribute noise to the discussions, which why I eventually moved away from Go and D forum discussions as well. My time is already quite filled following the JVM, .NET and C++ eco-systems, the ones I get payed to be an expert on.
  - smosher_ 11y ago
    > My objection is that I see unsafe just for memory integrity. Either you think this way because of a sense of orthodoxy or because you think memory safety is important in a way the other kinds of safety aren't. I disagree, especially since "memory safety" may or may not imply protection against aliasing of mutable data. Those nuances I like about Rust probably wouldn't exist without the broader scope of safety concerns. > As for voicing my objections to the Rust community, About the discussion you linked? I meant to me, in the service of explaining your objections. > My time is already quite filled following the JVM, .NET and C++ eco-systems, the ones I get payed to be an expert on. Well, that was important information. Thanks for making the time to share!
    - 11y ago