5 ms·

About safe/undefined etc I think it has been answered before (there are probably more places): https://news.ycombinator.com/item?id=9643690 https://news.ycombin

by gokr 11y ago

About safe/undefined etc I think it has been answered before (there are probably more places): https://news.ycombinator.com/item?id=9643690 https://news.ycombinator.com/item?id=9643690 Personally I am quite sick and tired of that particular "take" on Nim - why not for once criticize other parts of the language? :)

nickpsecurity 11y ago
Thanks for the link. The top comment's explanation, esp on GC, makes a lot of sense. Both specific keywords and a module-level declaration are rational ways of handling it. So long as it's clear to a person or program analyzing safety properties of a module then they can do what they need to do.
pcwalton 11y ago
> Personally I am quite sick and tired of that particular "take" on Nim - why not for once criticize other parts of the language? :) Because I'm not interested in criticizing languages as a whole—that would be language warring for no reason. Claims of memory safety are what are important to me, just as, for example, claims of correct crypto constructions are important to crypto people. Anyway, I see no reason to go further here, given that nobody has claimed anything is memory safe.
- gokr 11y ago
  Great! Thing is, Rust and Nim are very different. Just as I wouldn't put Rust down for not having GC (I love languages moving the art forward) I just wish we could look at Nim as a language with different design goals than Rust. I know several things in Nim worth discussing, it doesn't have to be warring.
  - masklinn 11y ago
    > I just wish we could look at Nim as a language with different design goals than Rust. Claims that Nim is memory-safe when it's not is not a difference of design goal though.
    - gokr 11y ago
      See my comment https://news.ycombinator.com/item?id=10992077 https://news.ycombinator.com/item?id=10992077 It seems to me that a) Nim is (or at least is meant to be, but bugs can sidestep it) memory safe if you stay within the rules for it, and b) Nim is not throwing around vague claims of safety that are not documented in the language manual.
      - masklinn 11y ago
        > It seems to me that a) Nim is (or at least is meant to be, but bugs can sidestep it) memory safe if you stay within the rules for it That's completely worthless. C is also memory-safe if you stay within the rules for memory safety. > Nim is not throwing around vague claims of safety that are not documented in the language manual. Of course not since nim is not posting on HN (as it's not a sentient being prone to procrastination) it's obviously nim supporters making claims about nim's safety.
        gokr 11y ago
        IMHO it's not worthless. Nim has ptr and addr, but they are explicitly described as unsafe and only used "when you have to", like interfacing with C/C++ etc. I have never used them outside of C/C++ integration. Rust also has unsafe, but I presume you don't think that invalidates safety.
        ben0x539 11y ago
        > That's completely worthless. C is also memory-safe if you stay within the rules for memory safety. It's really not any weaker of a guarantee than Rust makes, being memory-safe if you stay within the rules of not saying `unsafe`. Or opening /proc/self/mem for writing, anyway. I'd also feel a lot better about Rust's moral highground of memory safety if its undefined behavior was actually spelled out a bit more rather than just punting the hard parts to llvm docs. I don't think every Rust user knows how to avoid aliasing problems between `&mut` and `*mut` either.
        pcwalton 11y ago
Ygg2 11y ago
As far as I see the answers was: work-in-progress And you asked why this happens, and I answered, because Nim claims it is secure. Not more not less. It's like saying OpenSSL is perfectly (or as good as it gets) secure, and there aren't any known vulnerabilities. That statement is going to get a strong reaction from anyone that specializes in security and reads HN (for example tpatcek). I don't like or dislike Nim. I did like Nim's macro system, although I fear its too powerful (it seems like macros would be really easy solution in many cases).
- gokr 11y ago
  Just curious since I must have missed it - where is this claimed? On nim-lang.org? And yes, Nim is not 1.0 yet so some areas are still evolving. And no, I don't think I asked anything?
  - Ygg2 11y ago
    Generally across HN? Nim's forum? There isn't a single source, I've also found a bunch of Rust/Nim comparison that eventually state something along the lines of Rust is equally safe as Nim[1] and it then gets reiterated on HN. [1]http://forum.nim-lang.org/t/1961 http://forum.nim-lang.org/t/1961
    - gokr 11y ago
      I still don't see it. You wrote "Nim claims it's secure" and I wonder where Nim does that. What I do see is careful explanations in the language manual what is safe and what is not. I am not even remotely as sharp as pcwalton, Araq or Jehan/rbehrends when it comes to these things, but my perception of what "Nim says" is basically "if you use these things, you should be ok. If you use these other things, you are in C country." Then of course modulo bugs and wip stuff. It is perhaps a different philosophy at play. But I am genuinely interested in where this claim is made, perhaps we need to adjust some documentation or make things more clear - so do point us to it if you find it again.

by gokr 11y ago

nickpsecurity 11y ago

Thanks for the link. The top comment's explanation, esp on GC, makes a lot of sense. Both specific keywords and a module-level declaration are rational ways of handling it. So long as it's clear to a person or program analyzing safety properties of a module then they can do what they need to do.

pcwalton 11y ago

> Personally I am quite sick and tired of that particular "take" on Nim - why not for once criticize other parts of the language? :) Because I'm not interested in criticizing languages as a whole—that would be language warring for no reason. Claims of memory safety are what are important to me, just as, for example, claims of correct crypto constructions are important to crypto people. Anyway, I see no reason to go further here, given that nobody has claimed anything is memory safe.

gokr 11y ago
Great! Thing is, Rust and Nim are very different. Just as I wouldn't put Rust down for not having GC (I love languages moving the art forward) I just wish we could look at Nim as a language with different design goals than Rust. I know several things in Nim worth discussing, it doesn't have to be warring.
- masklinn 11y ago
  > I just wish we could look at Nim as a language with different design goals than Rust. Claims that Nim is memory-safe when it's not is not a difference of design goal though.
  - gokr 11y ago
    See my comment https://news.ycombinator.com/item?id=10992077 https://news.ycombinator.com/item?id=10992077 It seems to me that a) Nim is (or at least is meant to be, but bugs can sidestep it) memory safe if you stay within the rules for it, and b) Nim is not throwing around vague claims of safety that are not documented in the language manual.
    - masklinn 11y ago
      > It seems to me that a) Nim is (or at least is meant to be, but bugs can sidestep it) memory safe if you stay within the rules for it That's completely worthless. C is also memory-safe if you stay within the rules for memory safety. > Nim is not throwing around vague claims of safety that are not documented in the language manual. Of course not since nim is not posting on HN (as it's not a sentient being prone to procrastination) it's obviously nim supporters making claims about nim's safety.
      - gokr 11y ago
        IMHO it's not worthless. Nim has ptr and addr, but they are explicitly described as unsafe and only used "when you have to", like interfacing with C/C++ etc. I have never used them outside of C/C++ integration. Rust also has unsafe, but I presume you don't think that invalidates safety.
      - ben0x539 11y ago
        > That's completely worthless. C is also memory-safe if you stay within the rules for memory safety. It's really not any weaker of a guarantee than Rust makes, being memory-safe if you stay within the rules of not saying `unsafe`. Or opening /proc/self/mem for writing, anyway. I'd also feel a lot better about Rust's moral highground of memory safety if its undefined behavior was actually spelled out a bit more rather than just punting the hard parts to llvm docs. I don't think every Rust user knows how to avoid aliasing problems between `&mut` and `*mut` either.
        pcwalton 11y ago

Ygg2 11y ago

As far as I see the answers was: work-in-progress And you asked why this happens, and I answered, because Nim claims it is secure. Not more not less. It's like saying OpenSSL is perfectly (or as good as it gets) secure, and there aren't any known vulnerabilities. That statement is going to get a strong reaction from anyone that specializes in security and reads HN (for example tpatcek). I don't like or dislike Nim. I did like Nim's macro system, although I fear its too powerful (it seems like macros would be really easy solution in many cases).

gokr 11y ago
Just curious since I must have missed it - where is this claimed? On nim-lang.org? And yes, Nim is not 1.0 yet so some areas are still evolving. And no, I don't think I asked anything?
- Ygg2 11y ago
  Generally across HN? Nim's forum? There isn't a single source, I've also found a bunch of Rust/Nim comparison that eventually state something along the lines of Rust is equally safe as Nim[1] and it then gets reiterated on HN. [1]http://forum.nim-lang.org/t/1961 http://forum.nim-lang.org/t/1961
  - gokr 11y ago
    I still don't see it. You wrote "Nim claims it's secure" and I wonder where Nim does that. What I do see is careful explanations in the language manual what is safe and what is not. I am not even remotely as sharp as pcwalton, Araq or Jehan/rbehrends when it comes to these things, but my perception of what "Nim says" is basically "if you use these things, you should be ok. If you use these other things, you are in C country." Then of course modulo bugs and wip stuff. It is perhaps a different philosophy at play. But I am genuinely interested in where this claim is made, perhaps we need to adjust some documentation or make things more clear - so do point us to it if you find it again.