4 ms·

If Nim doesn't change the major safety problems with C, why bother? I'd rather see more kernel development in Rust.

Dewie3 11y ago
> If Nim doesn't change the major safety problems with C, why bother? Probably for all the myriad of reasons that don't have to do with safety, and in which Nim is arguably better than Rust, C++, Python, or whatever language is most relevant to compare to.
- davorb 11y ago
  I'd actually like to see someone do a Nim vs Rust. We've seen plenty of rust vs go and rust vs c++.
  - def- 11y ago
    In my opinion Rust and Nim would make a nice team as complementary languages: Use Rust for everything that needs high safety and high performance at the same time, Nim for everything else. https://andreaferretti.github.io/on-rust-and-nim/ https://andreaferretti.github.io/on-rust-and-nim/ https://arthurtw.github.io/2015/01/12/quick-comparison-nim-vs-rust.html https://arthurtw.github.io/2015/01/12/quick-comparison-nim-v...
    - progman 11y ago
      > In my opinion Rust and Nim would make a nice team as complementary languages I don't think so because the syntax is very different. You would have to learn two languages, and if you know Rust and you need it for safety reasons -- then why not code everything in Rust? Nim is very practical by design. I think some practical additional security features in Nim (pre- and post conditions for instance) make more sense than interaction with Rust or Haskell. Somewhere I read that the Nim developers plan to add pure functions (like Haskell). This would be the first step in that direction.
      - def- 11y ago
        You can use the noSideEffect pragma for that already.
progman 11y ago
Actually Nim solves some of the major safety problems with C -- with string garbage collection and array index checks (avoiding buffer overflows) for instance. And fiddling with pointers which is typical for C is generally a bad programming style (imho). Nim translates to C, so you get plain C source code without fear of the dangers which can happen by direct coding in C.

> If Nim doesn't change the major safety problems with C, why bother? Probably for all the myriad of reasons that don't have to do with safety, and in which Nim is arguably better than Rust, C++, Python, or whatever language is most relevant to compare to.

davorb 11y ago
I'd actually like to see someone do a Nim vs Rust. We've seen plenty of rust vs go and rust vs c++.
- def- 11y ago
  In my opinion Rust and Nim would make a nice team as complementary languages: Use Rust for everything that needs high safety and high performance at the same time, Nim for everything else. https://andreaferretti.github.io/on-rust-and-nim/ https://andreaferretti.github.io/on-rust-and-nim/ https://arthurtw.github.io/2015/01/12/quick-comparison-nim-vs-rust.html https://arthurtw.github.io/2015/01/12/quick-comparison-nim-v...
  - progman 11y ago
    > In my opinion Rust and Nim would make a nice team as complementary languages I don't think so because the syntax is very different. You would have to learn two languages, and if you know Rust and you need it for safety reasons -- then why not code everything in Rust? Nim is very practical by design. I think some practical additional security features in Nim (pre- and post conditions for instance) make more sense than interaction with Rust or Haskell. Somewhere I read that the Nim developers plan to add pure functions (like Haskell). This would be the first step in that direction.
    - def- 11y ago
      You can use the noSideEffect pragma for that already.

progman 11y ago

Actually Nim solves some of the major safety problems with C -- with string garbage collection and array index checks (avoiding buffer overflows) for instance. And fiddling with pointers which is typical for C is generally a bad programming style (imho). Nim translates to C, so you get plain C source code without fear of the dangers which can happen by direct coding in C.