A small kernel written in Nim | Hacker News Reader

A small kernel written in Nim

github.com

111 pointsImmortalin13 comments

And if you're into using Nim for low level programming, I got the binary from yesterday down 1 more byte and made it work on x86: http://hookrace.net/blog/nim-binary-size/#addendum

Neato!

This is basically a line by line rewrite of http://wiki.osdev.org/Bare_Bones

Thank you for the link! OS development is very interesting, but I haven't seen this resource yet.

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.

Deleted comment

Because of some technical reasons language renames can't be handled by Github at all currently: https://github.com/github/linguist/pull/1936

Edit: The now deleted post was asking about whether Nim code could finally be identified as "Nim" instead of "Nimrod" by Github.

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

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.

I'd actually like to see someone do a Nim vs Rust. We've seen plenty of rust vs go and rust vs c++.

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://arthurtw.github.io/2015/01/12/quick-comparison-nim-v...

> 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.

You can use the noSideEffect pragma for that already.

Reply on news.ycombinator.com