4 ms·

Yeah it's always great to see concepts implemented and working. My favorite similar project I would use as an argument to bring Nim into a legacy C codebase is

by Jach 9y ago

Yeah it's always great to see concepts implemented and working. My favorite similar project I would use as an argument to bring Nim into a legacy C codebase is https://github.com/ckkashyap/nimxv6 https://github.com/ckkashyap/nimxv6 which started off by taking the xv6 kernel and replacing uart.c with uart.nim. Every step of the way you can test your translation was correct, and once you have Nim in the build process you can start using it for new things too.

meditationapp 9y ago
Do you get anything with him? I was under the impression dereference safety wasn't a priority.
- kbenson 9y ago
  Debatedly, you get a better stdlib and some usability features.
- Jach 9y ago
  Nim or Rust might be appropriate depending on the project. To me the idea of replacing C with either of them comes down to a value-sell of how much you value Rust's safety guarantees and whether you're willing to make the investment of learning to use it or if you're just going to wrap everything in unsafe{}. Considering you're talking to C programmers, I don't think they value that safety very much. If they did, at least compared to other values, they'd have moved to a GC language like Java long ago, or at least a C++-subset-with-rules. So Nim has a lot of nice features that they might like and expect from modern higher level languages, a lot you can use even if you alloc() everywhere and avoid the GC, which you can do because it has an optional and implementation-swappable GC. And it's not like Nim is just as unsafe as C if you don't use the GC, the compiler stops you from shooting yourself in the foot for a lot of things plus there are some good (tunable) defaults on runtime behavior. Finally the ramp-up time to get productive in Nim, and ongoing development effort, is probably less than Rust, which will help the sell too.
  - devdoomari 9y ago
    pardon my ignorance, but wasn't "safe-and-performant" impossible before rust? Isn't choosing a GC-language some trading off performance for safety?
    - bonzini 9y ago
      There were other attempts to bridge safety and performance. C++11 already gets pretty close to that, but Microsoft's M# was used to write a research OS and is probably the closest.
      - moomin 9y ago
        C++, though, only works if you follow a bunch of coding guidelines (that I can tell you for free the last C++ team I worked on didn't) and don't interface with any library APIs that don't follow those guidelines. Don't get me wrong, C++ is coming on by leaps and bounds, but if you want to get to safe and performant without GC, it's not the place you should be starting. (Equally, I'm not saying Rust solves all the world's problems. Just that it's a better place to start.)
    - gorthol 9y ago
      I think it was "safe and performant without a GC" because both Nim and D have C++ level performance while being memory safe as any GCd language is.
      - rurban 9y ago
        You forgot about pony, which is memory safe plus concurrency safe plus faster than C/C++. Nim, D, Rust won't offer that. M# does because it followed the same principles.
    - Jach 9y ago
      It's a common misconception that GC languages must be slower than languages without one. Where that misconception probably comes from is that it's pretty easy to write performant code in C, and hard to write terribly slow code, whereas in languages with GC in some instances you can do as good or better but it's often harder. These days if you're comparing Java and C++, it's not unusual for the Java code to be faster. The bigger tradeoff for GC is more in the loss of determinism, some applications (like games) can't tolerate a random stop-the-world collection for n ms. This can be mitigated by pauseless/stoppable/real-time-guarantees GC implementations though so if your language lets you swap the GC you have options around this. (For something like a game, naive malloc/free aren't enough either. You're going to have to manage your memory intelligently regardless of if you have a GC or not.) As for Nim all I can say is run some benchmarks on C, Rust, and Nim. Compare the ease of implementation. Compare the relative safeties beyond memory ownership safety. Nim does very well.
- nickpsecurity 9y ago
  People tell me it's as readable as Python, has macros, compiles to efficient C (among others), and is easier to learn than Rust esp since it's GC'd. These are good reasons to use it for many apps. I put it in Go's category mostly. However, I think affine types (Rust's advantage) could be added to it or a safety-critical subset.
nimmer 9y ago
Progressively writing parts of the kernel in Nim sounds more practical. Perhaps Nim can be used to write kernel modules already.
vvanders 9y ago
I ended up doing that for the netcode.io port of Rust and it worked out really well. Both in stubbing out implementations and in calling C API from Rust until I had 100% Rust implementation.
geezerjay 9y ago
> Yeah it's always great to see concepts implemented and working. I agree. It's easy to criticize ideas that may seem futile at first, but there is nothing like a working implementation to take the wind out of the critics' proverbial sail.

by Jach 9y ago

meditationapp 9y ago

Do you get anything with him? I was under the impression dereference safety wasn't a priority.

kbenson 9y ago
Debatedly, you get a better stdlib and some usability features.
Jach 9y ago
Nim or Rust might be appropriate depending on the project. To me the idea of replacing C with either of them comes down to a value-sell of how much you value Rust's safety guarantees and whether you're willing to make the investment of learning to use it or if you're just going to wrap everything in unsafe{}. Considering you're talking to C programmers, I don't think they value that safety very much. If they did, at least compared to other values, they'd have moved to a GC language like Java long ago, or at least a C++-subset-with-rules. So Nim has a lot of nice features that they might like and expect from modern higher level languages, a lot you can use even if you alloc() everywhere and avoid the GC, which you can do because it has an optional and implementation-swappable GC. And it's not like Nim is just as unsafe as C if you don't use the GC, the compiler stops you from shooting yourself in the foot for a lot of things plus there are some good (tunable) defaults on runtime behavior. Finally the ramp-up time to get productive in Nim, and ongoing development effort, is probably less than Rust, which will help the sell too.
- devdoomari 9y ago
  pardon my ignorance, but wasn't "safe-and-performant" impossible before rust? Isn't choosing a GC-language some trading off performance for safety?
  - bonzini 9y ago
    There were other attempts to bridge safety and performance. C++11 already gets pretty close to that, but Microsoft's M# was used to write a research OS and is probably the closest.
    - moomin 9y ago
      C++, though, only works if you follow a bunch of coding guidelines (that I can tell you for free the last C++ team I worked on didn't) and don't interface with any library APIs that don't follow those guidelines. Don't get me wrong, C++ is coming on by leaps and bounds, but if you want to get to safe and performant without GC, it's not the place you should be starting. (Equally, I'm not saying Rust solves all the world's problems. Just that it's a better place to start.)
  - gorthol 9y ago
    I think it was "safe and performant without a GC" because both Nim and D have C++ level performance while being memory safe as any GCd language is.
    - rurban 9y ago
      You forgot about pony, which is memory safe plus concurrency safe plus faster than C/C++. Nim, D, Rust won't offer that. M# does because it followed the same principles.
  - Jach 9y ago
    It's a common misconception that GC languages must be slower than languages without one. Where that misconception probably comes from is that it's pretty easy to write performant code in C, and hard to write terribly slow code, whereas in languages with GC in some instances you can do as good or better but it's often harder. These days if you're comparing Java and C++, it's not unusual for the Java code to be faster. The bigger tradeoff for GC is more in the loss of determinism, some applications (like games) can't tolerate a random stop-the-world collection for n ms. This can be mitigated by pauseless/stoppable/real-time-guarantees GC implementations though so if your language lets you swap the GC you have options around this. (For something like a game, naive malloc/free aren't enough either. You're going to have to manage your memory intelligently regardless of if you have a GC or not.) As for Nim all I can say is run some benchmarks on C, Rust, and Nim. Compare the ease of implementation. Compare the relative safeties beyond memory ownership safety. Nim does very well.
nickpsecurity 9y ago
People tell me it's as readable as Python, has macros, compiles to efficient C (among others), and is easier to learn than Rust esp since it's GC'd. These are good reasons to use it for many apps. I put it in Go's category mostly. However, I think affine types (Rust's advantage) could be added to it or a safety-critical subset.

nimmer 9y ago

Progressively writing parts of the kernel in Nim sounds more practical. Perhaps Nim can be used to write kernel modules already.

vvanders 9y ago

I ended up doing that for the netcode.io port of Rust and it worked out really well. Both in stubbing out implementations and in calling C API from Rust until I had 100% Rust implementation.

geezerjay 9y ago

> Yeah it's always great to see concepts implemented and working. I agree. It's easy to criticize ideas that may seem futile at first, but there is nothing like a working implementation to take the wind out of the critics' proverbial sail.