PowerNex: A Kernel Written In The D Programming Language

[Michael_S]

On the highly popular C++ vs D debate, D2.0 came out in in 2007 and most of the language features that currently exist were in place in 2010, comfortably before C++11 and C++14. The comparison between D and C++17 with all of the latest C++ language features and recommended coding practices is tough. I still maintain that D is a better language, but C++11 and newer is good enough that when you weigh in all of the existing C++ code you can use with it, D is a hard sell.

As an aside, I don't give any weight to the argument that D is only borrowing ideas from older languages. Everything in C++ was in Lisp, C, or both before it and if you can dump D because it's unoriginal then you can dump C++ too for the same reason.

D has these nice features:
-- nested function definitions
-- pure keyword, that guarantees a function does not rely on any state outside its input parameters
-- nothrow keywoard, that guarantees a function doesn't throw any but a small class of runtime errors (like out-of-memory)
-- scope guard operator, which is a simpler way to express the kinds of guards you would use with try/catch/finally blocks (which D also has) and make it more convenient to do manual memory management
-- const and immutable keywords. "const" works the same was in D as in C++. "immutable" is transitive, so immutable auto a = getFoo(); a.getBar().getBaz().setQuux(5); would fail to compile.
-- file-level variables are thread-local by default and need additional modifiers to be true globals.
-- @safe function keyword, which blocks pointer arithmetic, most kinds of type casts
-- Uniform Function Call Syntax, which is a compiler-supplied convenience for method chaining that can make for very terse code without sacrificing readability ( https://dlang.org/spec/function.html#pseudo-member ), instead of (quux(baz(bar(foo(x, y)), z), ax, ay) you can do x.foo(y).bar().baz(z).quux(ax,ay).
-- lambda functions (added to C++ in C++11) for inline function definitions
-- auto keyword (added to C++ in C++11) for compiler type inference
-- default function parameters (also in C++)
-- convenient syntax for including unit tests right in the same source file as the code they test.
-- @property modifier for fields. As anyone who worked with Java long enough knows, it's common practice to declare everything instance variable in Java with private SomeClass x; public SomeClass getX() { return x }; public void setX(SomeClass inX) { this.x = inX; } because if you ever need to add intercept behavior in your "get" or "set", it's simpler. If you just declare public SomeClass x; and then need to add the interceptor later, you have to go to every place that accesses it and modify the code to use your new intercepting get and set methods. With @property in D, you can add intercept behavior without modifying existing call syntax.
-- "static if" provides compile-time evaluation of D code in place of the C/C++ preprocessor.
-- unicode strings are built in to the language. UTF8 is the basic, but there's also UTF16 and UTF32 forms of all of the string-manipulation functions.
-- convenient array slicing, resizing, and copying syntax

Now again, I think you can argue we're moving towards a world where C++(some number) offers every developer convenience available in D, and all you have to do is not write code like it's 1995. And also again, C++ has the overwhelming advantage of millions upon millions of lines of existing code available for use. But D is a damn good language.

[starshipeleven]

Never thought about it like this. But since I've only ever seen libraries use the "POSIX" nomer, you're probably right.
Guess I'll need to come up with another name then.

Just looked it up, it's a trademark of these guys. http://www.unix.org/trademark.html

Node OS is mainly targetting developers/devops. Mine is a graphical, network transparent OS targetting interested software development newbies.
In that way it's more like OS.js, minus the node/webkit part.

Mh, that can be useful. Good ways to teach coding skills, we need that.

[unixfan2001]

protip: "unix" is a trademark afaik (Novell? others?) so it's better if your thing does not use it if you plan to show it to others someday.

Never thought about it like this. But since I've only ever seen libraries use the "POSIX" nomer, you're probably right.
Guess I'll need to come up with another name then.

Since we are on it, and that I know little of these matters, how does your project differ from node-os?

Node OS is mainly targetting developers/devops. Mine is a graphical, network transparent OS targetting interested software development newbies.
In that way it's more like OS.js, minus the node/webkit part.

[starshipeleven]

It kind of is. But it's also kind of awesome. Currently, I'm working on a simple wrapper API I've dubbed "UNIX.js", that seeks to bring things like stdlib to js in any easily (by newbies) consumable way.

i. e. "unix.exit(0)" would close a js application with exit code 0, for one.

protip: "unix" is a trademark afaik (Novell? others?) so it's better if your thing does not use it if you plan to show it to others someday.

Since we are on it, and that I know little of these matters, how does your project differ from node-os?

[unixfan2001]

Sounds like mad science to me...

It kind of is. But it's also kind of awesome. Currently, I'm working on a simple wrapper API I've dubbed "UNIX.js", that seeks to bring things like stdlib to js in any easily (by newbies) consumable way.

i. e. "unix.exit(0)" would close a js application with exit code 0, for one.

[Delgarde]

So I guess that means you won't be a fan of my javascript userspace (XUL + JS + ctypes) based hobby OS (backed by the Linux kernel, because I don't have the manpower to write a kernel from scratch) then?

Sounds like mad science to me...

[starshipeleven]

So I guess that means you won't be a fan of my javascript userspace (XUL + JS + ctypes) based hobby OS (backed by the Linux kernel, because I don't have the manpower to write a kernel from scratch) then?

Joke detected.
Unless you build a hardware js interpreter there is no way in hell you can run a kernel (and display manager and sound server and so on) written in js, and you are smart enough to know this already.

That said for most GUI-centric systems I personally do support ChromeOS-like OS where there is a kernel and then the rest is all run on a browser.
I still cry all nights because FirefoxOS was never really ported to desktops and it basically died in crappy low-end phones.

God, I would have loved buying a ChromeBook and then hack it to run FirefoxOS (and replace the sticker on the casing).

But on a headless system or a backend it's nonsense. There are a gazillion scripting languages that don't suck and run faster that can be used for backends.

[unixfan2001]

javascript is a (unbelievably shitty) scripting language, it needs an interpreter program to read it, it does not run on its own like compiled languages.

So unless the hardware itself is the interpreter (i.e. custom-made new-architecture hardware), there is no way in hell they can.

Still, with a FPGA they can surely try making a soft-processor that reads their javascript shit in hardware, and can have their own little shitty hardware js interpreter.
Would probably be the only way javascript can run at a decent speed.

And would cross the boundaries to the "everyone starts making their CPU" stage.

I'd approve that.

So I guess that means you won't be a fan of my javascript userspace (XUL + JS + ctypes) based hobby OS (backed by the Linux kernel, because I don't have the manpower to write a kernel from scratch) then?

[Delgarde]

I guess if you find it fun then sure, go for it. I have no problem with coding for fun, but I don't understand the purpose of coding something that will likely never go beyond a proof of concept. To me, it's more fun to code something "for fun" that I can actually complete. I don't understand how it would be fun to create something that would be roughly as limited as DOS.

I've never written an OS, but I've written basic window managers, email clients, web servers, and other such things. Why? Because I enjoy learning things, and the best way to learn is to do. I've started hundreds of such dead-end projects that do nothing that hasn't been done better many times before. Why? Because it makes me better at what I do... it helps me understand how such things work, and the challenges of working with different technologies and problems.

[starshipeleven]

d language is still good choice for kernel. on the other hand there is https://node-os.com/ with userspace writen in javascript. I'm waiting for them to reimplement kernel in js. this will be total brainfuck.

javascript is a (unbelievably shitty) scripting language, it needs an interpreter program to read it, it does not run on its own like compiled languages.

So unless the hardware itself is the interpreter (i.e. custom-made new-architecture hardware), there is no way in hell they can.

Still, with a FPGA they can surely try making a soft-processor that reads their javascript shit in hardware, and can have their own little shitty hardware js interpreter.
Would probably be the only way javascript can run at a decent speed.

And would cross the boundaries to the "everyone starts making their CPU" stage.

I'd approve that.