Hacker News new | ask | show | jobs
by eggestad 3175 days ago
Let me be the contrarian to make the case for NOT writing a new kernel at all (no matter what language)

Many a year ago (1997-2000) I was working on banking and finance software. I was a part of that breed of programmers that loath cobol and wanted everything to be in an object oriented language. (C++ was the poison of choice at the time.) The was a particular evangelical group of us in this company.

With this group I found my self in a meeting with one of the old timers, business graduate, his jobs was to explain to us CS diaper babies how banking and finance actually worked when we wrote the software. (surprisingly NOT we're actually clueless about the bigger purpose of what a core banking system is fore (other than the obvious)).

After patently listening to us with the facial expression that we're all diaper babies, he asked a rather pointed question:

OK, supposed we did this, write a new system from scratch using OO programming and all the other industry standard components as of today, what new features to the end user can you build? Translated, when he was going to walk over to the bank to sell it, what would be his pitch?

I got the message, what new pitch would the bank get to get new customers? Or simplified, when was the last time you went in to a prospecting new bank and asked 'What programming language or paradigm is your core banking system written in?'

I don't give a shit about what language a kernel is written in, only what the system calls do. Please tell me what system call you can write in RUST that you can't write in C.

The first time the problem arose when it was necessary to translate one HW assembly to a new CPU, the people at the time took a look at the problem and asked the question. What is easier, write an assembler A to assembler B translator, or write the kernel in the most minimal language possible that then can be compiled for an infinite HW architectures. The answer was simple; C.

The answer is equally easy now. There is no system call you can implement in RUST that you can't implement in C.

Just like core banking, finance and insurance systems are still in COBOL, the OS kernels will be for the foreseeable future in C.

The case for writing a kernel in RUST should be because a need a fun hobby. The thing is that a proof of concept kernel is done when you've doen 10% of the work. The remaining 90% is just mind numbingly boring shit that you'll never complete. Even if you do, what's the end user's justification to switch?

On the issue of micro kernel vs monolithic kernel, I'll most humbly refer to Linus Torvalds previous statements.

TJ

2 comments

I find it interesting that even though your story is about banking and finance software, you did not once mention safety or security. That doesn't magically make it a good idea to start from scratch, but unless you have a perfect security record, it should definitely be part of the deciding criteria. For something like the kernel, well they are still dealing with problems in C today. [1]

1: https://www.exploit-db.com/search/?action=search&q=kernel&g-... (answer the captcha and search again)

> Please tell me what system call you can write in RUST that you can't write in C.

One that doesn't suffer from context switch penalty, but still provides separation of the kernel and the process?