top | item 30313022

Benefits and costs of writing a Posix kernel in a high-level language (2018) [pdf]

42 points| Decabytes | 4 years ago |pdos.csail.mit.edu | reply

9 comments

order
[+] KerrAvon|4 years ago|reply
The problem with this is as I understand it is that if GC turns out to be a problem for your particular application, you can’t get rid of it. You can only change GC strategies (language/runtime permitting). You can’t fully optimize away GC overhead.
[+] p_l|4 years ago|reply
You can avoid GC programming in GC'd language (we have over 40 years of data on how to do that!), but you can't retrofit GC onto non-GC language and get full benefit (though Boehm GC is still going to make your C/C++ program better for all parts that use naive malloc/free scheme)
[+] dang|4 years ago|reply
Discussed at the time:

The benefits and costs of writing a POSIX kernel in a high-level language - https://news.ycombinator.com/item?id=18171447 - Oct 2018 (96 comments)

[+] bigcat123|4 years ago|reply
> manages to get within 5-15% of a traditional kernel for the things they measured. That is impressive.

Top comment from the linked thread.

This is a bit out of context. 5-15% in any measurements to mainstream software is too easy. Even if it's operating system. We all know that.

This is why almost any papers that compare a research project's products with a mainstream production one in terms of performance is usually just for establishing context than actually comparison.

[+] ncmncm|4 years ago|reply
Tl;dr: We coded a kernel mostly in Go. It worked OK for what we tried.

Calling Go "high-level" is absurd. Apparently the authors are using the word in place of "garbage-collected", as if that had anything to do with a level. Go is by quite a margin the lowest-level obligate-GC language I know of. (That does not, by the way, mean I think it is "bad".)

[+] 0xTJ|4 years ago|reply
Personally, I'd definitely call Go high-level.

Some people go as far as to say that C is a high-level language, but I find that ridiculous.