ToaruOS 2.0 | Hacker News Reader

ToaruOS 2.0

github.com

94 pointscrawshaw24 comments

I've always been amazed by the technical ability of klange to create this and kuroko-lang

Adding an interpreted language seems like a really nice touch. Is it possible to build UIs and a full application with it?

Definitely one of the more complete hobby OSs out there. Well done!

misaka is kernel, kuroko is a programming language. Now I want to know what touma is?

Fukou da.

Maybe this is because the quote "Any sufficiently advanced technology is indistinguishable from magic." would imply that the computer would stop working ? (This was only intended as a pun, as the reason is most likely the author prefers the other set of characters, but having the kernel panic handling module be named Touma would add to the spirit)

For those that would (most understandably) not get the reference in those names, there is a novel saga called "To Aru Majutsu no Index"/"a certain magical index", which the name references (to aru == "a certain"), and Misaka/Kuroko are characters from it.

By the way, is Yutani a reference to something ?

Congrats Klange!

It seems odd to write a new OS in C at this late date.

SerenityOS is in modern C++, and benefits enormously.

2011 is late? Or are you referring to OSes in general?

Any C program, including an OS kernel and its apparatus, can be transitioned seamlessly to C++ in a day, and then modernized at leisure. Ten years is plenty of time for that.

From an old FAQ page[1] for TauruOS:

> I wrote ToaruOS at a time when I was much more competent at C than C++. I still think that's true. At this point, the effort of rewriting datastructures to make use of C++ functionality would not be a good use of time - and writing userspace code in C++ in ToaruOS-NIH is not yet possible as I have yet to get a C++ standard library set up.

1: https://github.com/klange/toaru-nih/wiki/FAQs

This is sooooo not true. It might compile with a C++ compiler but they're two entirely different langs and the best code looks very different between the two.

Plus, C++ requires extra setup at the kernel level given the init code. It also requires manually designing your vtables.

Also, verifying C (if you ever go that route) is many times easier than verifying C++.

Also C compiles faster in many cases, easing development.

Plus C doesn't bark at you about certain ASM-isms that are frequently found in kernel code.

Plus C is arguably easier to reason about.

Plus C++ standard library can't be used anyway and auto pointers aren't really that much of a concern at the kernel level

Plus you're doing a lot of init work that never returns thus automatic destructors aren't as useful.

Also C is just fun, and perfectly suited for the task.

> Plus C++ standard library can't be used anyway and auto pointers aren't really that much of a concern at the kernel level

https://github.com/microsoft/wil

"Ah, but that isn't used on the Windows kernel" would be the expected reply, well

https://community.osr.com/discussion/291326/the-new-wil-libr...

"Microsoft's toolchain does not ship a copy of the STL that works in kernel mode. Partly this is because the kernel's CRT doesn't support C++ exceptions. (And partly this is because I/O is wildly different in kernel, so you'd have to rewrite the implementation of all the I/O libraries.)

But for kernel developers, wil ships a subset of an STL implementation. To avoid conflicting with the real STL, it's available under the wistd namespace. The rule of thumb is that wistd::foo is a drop-in replacement for std::foo."

That's not practical in every case, and that's not the standard library. It's a subset of it. I never said you couldn't do your own.

No language uses the standard library on the kernel, not even C.

Modern C++ is something nebulous. What is Modern C++ now would be obsolete few years down the line. So clearly maintenance of such a project wouldn’t be much fun, I suppose.

C doesn’t suffer from this for one. You have more time to focus on the task than on managing the myriad ways of doing the same thing.

Modern C++ is whatever is standardized and implemented. Obviously, as new Standards are published, new features become available, and any workarounds for their lack become redundant. But that has not inconvenienced SerenityOS even a little bit.

It can be reduced to actually writing proper C++ instead of C with a C++ compiler, already that basic change is quite modern for many folks.

http://harmful.cat-v.org/software/c++/linus

First, C++ has changed SIGNIFICANTLY since then. Second, Linus is wrong.

C++ did not, strictly speaking, exist at that time. I.e., there was no Standard defining it, and most of what makes it useful was not implemented in compilers.

About all proto-C++ had that was actually useful and usable, beyond C, was destructors. That changed by around 2003.

So it was much less mature than even Rust is today.

Yes, when Linus first tried C++ in 1992 this is true. But the linked comments were done in early 2000s which by then C++ was very mature. So by early 2000s, C++ was already 20 years old. Rust is only 11 right now.

Yes, Linus is just full of crap, on that topic.

But Rust is more mature now than C++ was in 2007. Fully self-contained projects can move fast.

The irony is that many of the complaints apply to Rust as well, even if in another way.

Just wait when the first set of monadic libraries full of macros start landing on Linux drivers.

I am quite sure Linus won't be amused, but hey at least it isn't C++. /s

Reply on news.ycombinator.com