> 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.
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.
> 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.
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.
I was curious if anybody is trying to merge the ideas of alternative hobbyist kernels in language X or Y (for X or Y enthusiasts, like this nim one) and building a compability layer that allows you to do what I had read, maybe incorrectly, with NetBSD rump kernels: allowing one OS to properly connect into or out of another to use its hardware drivers for example.
I loved the Erlang on Xen concept, by way of example. But could you imagine in the future if you had a full Common Lisp or OCaml or Python or Ruby OS that could leverage a liblinux.so of sorts and control a webcam or wireless card with your language of choice thanks to pluggable OS driver backends? I know this requires work in each language, but it would be crazy if this is the future.
Do the OS as a language VM on Xen packages handle anything more than basic user input and/or network? Are peolpe working on these Xen stuff taking it further like what I want?
Sorry for the questions. It is a lot to ask at once but this idea has been in the back of my head while reading similar HN articles for a few months now.
13 comments
[ 3.2 ms ] story [ 42.5 ms ] threadThis is basically a line by line rewrite of http://wiki.osdev.org/Bare_Bones
Edit: The now deleted post was asking about whether Nim code could finally be identified as "Nim" instead of "Nimrod" by Github.
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.
https://andreaferretti.github.io/on-rust-and-nim/
https://arthurtw.github.io/2015/01/12/quick-comparison-nim-v...
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.
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.
I loved the Erlang on Xen concept, by way of example. But could you imagine in the future if you had a full Common Lisp or OCaml or Python or Ruby OS that could leverage a liblinux.so of sorts and control a webcam or wireless card with your language of choice thanks to pluggable OS driver backends? I know this requires work in each language, but it would be crazy if this is the future.
Do the OS as a language VM on Xen packages handle anything more than basic user input and/or network? Are peolpe working on these Xen stuff taking it further like what I want?
Sorry for the questions. It is a lot to ask at once but this idea has been in the back of my head while reading similar HN articles for a few months now.