6 ms·

Nim compiles to very efficient C or C++ (or js) and most benchmarks shows Nim programs performance being almost the exact same as C/C++ - and often better than

by gokr 11y ago

Nim compiles to very efficient C or C++ (or js) and most benchmarks shows Nim programs performance being almost the exact same as C/C++ - and often better than Rust. So... why not using it to replace C and C++? Since I have worked with Nim (and I use it to implement my own language) I would say "hell yes"! It is such an immensely better language and it integrates perfectly with those eco systems. The GC is a good one (or well, there are 5 to choose from) and it is for many, many applications not an issue. And before pcwalton drops in with his endless spamming about Nim not being safe, Nim being undefined etc etc (it's getting quite annoying), please spare us this time.

Ygg2 11y ago
> And before pcwalton drops in with his endless spamming about Nim not being safe, Nim being undefined Well, it is, isn't it? Is he wrong about Nim not being safe when not using Boehm GC? Does it not segfault when sending GC pointers between threads? He only jumps in, when someone claims Nim is safe or the sweet spot, or something equally wrong. Nim's pretty syntax comes with a price, just like Rust's safety comes with a different kind of price.
- 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.
  - 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.
- rbehrends 11y ago
  > Is he wrong about Nim not being safe when not using Boehm GC? Does it not segfault when sending GC pointers between threads? If he has said that, yes, then that would be wrong [1, 2] in that you cannot send GCed references between threads in the first place. For example, the following code results in an error: var s = "foo" proc foo {.thread.} = echo s createThread(foo) Compiling this results in: test.nim(3, 6) Error: 'foo' is not GC-safe as it accesses 's' which is a global using GC'ed memory The problem here is one of expressiveness in that it is difficult for threads to share data (outside the limited and still experimental `parallel` construct). I've proposed a mechanism (shared, individually lockable heaps) modeled after Eiffel's SCOOP approach to remedy this, but so far this is just a proposal. [1] Modulo any remaining compiler bugs, of course, or using explicitly unsafe features. [2] Also, are you maybe confusing this with Go, which does have such a problem?
  - pcwalton 11y ago
    Does Nim deep copy messages between threads now (i.e. serializes entire object graphs)? If so I'm glad to see it and yes, it would of course be safe, as it would basically be Erlang. (It wasn't thread-safe when I last looked a year-plus ago.)
    - rbehrends 11y ago
      It has always done that [1]. You can only send refs through channels or via the spawn primitive where they are serialized/deep copied (or as arguments to threads upon creation, where that happens implicitly). [1] It may have been that using global variables to share refs between threads did only trigger a warning at some point, not an error. I'm not 100% sure about that. But the serialization has been there since the early days of multi-threading support in 2011.
      - gokr 11y ago
        Thank you for clearing that up - I have always been confused when pcwalton has written (a bunch of times) that "Nim's GC isn't thread safe" - since... I knew about the deep serialization and couldn't for my life understand why it wouldn't be safe then. But how could the segfaults then happen? Aha, you mean the test code perhaps shared via globals?
EugeneOZ 11y ago
Insulting people before they even had chance to say something, is very rude.
- gokr 11y ago
  Sure, and I can apologize for my wording in advance too! But I do stand by my opinion that he doesn't have to drop that in every single time Nim is mentioned. Evidently Go-people feel the same I noticed.
  - deleted 11y ago
    [deleted]
- nickpsecurity 11y ago
  It didn't come off as an insult to me. Anyone saying C++ or Nim tends to result in a counter from pcwalton. He usually says similar things as he has a consistent stance. Countering such a stance before they speak is OK given you already know what it is. In in a moral sense anyway. However, that he stopped in his own comment to bring it up and drop a counter says more about him than pcwalton. Shows a strong bias for and protectiveness of Nim while also disregarding the entire reliability or security aspects of the language. That's really something for a C++ alternative given its safety focus. ;)

by gokr 11y ago

Ygg2 11y ago

> And before pcwalton drops in with his endless spamming about Nim not being safe, Nim being undefined Well, it is, isn't it? Is he wrong about Nim not being safe when not using Boehm GC? Does it not segfault when sending GC pointers between threads? He only jumps in, when someone claims Nim is safe or the sweet spot, or something equally wrong. Nim's pretty syntax comes with a price, just like Rust's safety comes with a different kind of price.

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.
- 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.
rbehrends 11y ago
> Is he wrong about Nim not being safe when not using Boehm GC? Does it not segfault when sending GC pointers between threads? If he has said that, yes, then that would be wrong [1, 2] in that you cannot send GCed references between threads in the first place. For example, the following code results in an error: var s = "foo" proc foo {.thread.} = echo s createThread(foo) Compiling this results in: test.nim(3, 6) Error: 'foo' is not GC-safe as it accesses 's' which is a global using GC'ed memory The problem here is one of expressiveness in that it is difficult for threads to share data (outside the limited and still experimental `parallel` construct). I've proposed a mechanism (shared, individually lockable heaps) modeled after Eiffel's SCOOP approach to remedy this, but so far this is just a proposal. [1] Modulo any remaining compiler bugs, of course, or using explicitly unsafe features. [2] Also, are you maybe confusing this with Go, which does have such a problem?
- pcwalton 11y ago
  Does Nim deep copy messages between threads now (i.e. serializes entire object graphs)? If so I'm glad to see it and yes, it would of course be safe, as it would basically be Erlang. (It wasn't thread-safe when I last looked a year-plus ago.)
  - rbehrends 11y ago
    It has always done that [1]. You can only send refs through channels or via the spawn primitive where they are serialized/deep copied (or as arguments to threads upon creation, where that happens implicitly). [1] It may have been that using global variables to share refs between threads did only trigger a warning at some point, not an error. I'm not 100% sure about that. But the serialization has been there since the early days of multi-threading support in 2011.
    - gokr 11y ago
      Thank you for clearing that up - I have always been confused when pcwalton has written (a bunch of times) that "Nim's GC isn't thread safe" - since... I knew about the deep serialization and couldn't for my life understand why it wouldn't be safe then. But how could the segfaults then happen? Aha, you mean the test code perhaps shared via globals?

EugeneOZ 11y ago

Insulting people before they even had chance to say something, is very rude.

gokr 11y ago
Sure, and I can apologize for my wording in advance too! But I do stand by my opinion that he doesn't have to drop that in every single time Nim is mentioned. Evidently Go-people feel the same I noticed.
- deleted 11y ago
  [deleted]
nickpsecurity 11y ago
It didn't come off as an insult to me. Anyone saying C++ or Nim tends to result in a counter from pcwalton. He usually says similar things as he has a consistent stance. Countering such a stance before they speak is OK given you already know what it is. In in a moral sense anyway. However, that he stopped in his own comment to bring it up and drop a counter says more about him than pcwalton. Shows a strong bias for and protectiveness of Nim while also disregarding the entire reliability or security aspects of the language. That's really something for a C++ alternative given its safety focus. ;)