You can look at OSkit as one attempt to do this. I think the overwhelming reason its not common is that no one wants to build an OS. If they do it's for the educational experience not practical use. This means hobbyists aren't interested in just using a framework.

I am not sure what exactly is meant by "Ruby on Rails of kernel". Probably "an opinionated framework to build your own kernel". In this case OSkit is probably the best answer to the question. Maybe look at micro- and exokernels.

I think another problem is that an OS is not analagous to a website, it's more analagous to a web framework. And it's not like there are any framework building frameworks floating around

I've recently spend some time playing around with the xv6 kernel (more specifically a 64bit port of it), one problem is that the amount of work necessary to get a reasonable clean hardware abstraction for a x86 system is fairly complicated. For example for a full acpi implementation, you either have to write ~50 admittedly short glue functions for ACPICA or implement acpi table reading and an AML interpreter yourself. Unfortunately if you want to use modern features of PCI, there is no way around using acpi.

That being said, there are several such "modular" kernels implemented on top of Xen. For example Mirage is a framework for creating free standing Ocaml applications on top of Xen.

You can using the NetBSD rump kernel[1].

You get all the NetBSD drivers, IP stack etc that you can use, just add memory management, setup and so on, which is not much work, and link your application in to it. It is still under development but the basic stuff is all working well.

[1[ http://rumpkernel.org/

Even if you just want one platform, there is a lot of machinery you need even to boot up, load something from disk, access a USB keyboard and mouse, and display some text. ACPI and UEFI add considerably to this.

Then there's bugs and debugging. If you have a bug in your disk driver you can slowly lose data without noticing. Quite a lot of other bugs will lock your system and you need to debug painfully from whatever logs you can find. Building in a non-C language might make this a bit easier but won't save you from the hardware locking up.

Once you've done this, what have you gained? You have an OS with no userland and no applications. What bits of Linux/BSD do you actually want to replace with something else? The code is fairly modular and OSKit exists to help with this.

The nearest to what you describe is probably retrocomputing; people building their own considerably simpler systems from the ground up. If you want a simpler platform to start on without having to first build the platform, consider Raspberry Pi; the bootloader there effectively just pulls an ARM ELF executable off the SD card and starts executing it. Have a look at https://github.com/dwelch67/raspberrypi

I used to hang on some hobby osdev boards many years ago (losethos was there, when it was still called losethosOS). I never got much further than loading the kernel, setting up protected mode, printing some text and so on, but it was an interesting crowd. The long story short is, building a day-to-day usable general purpose kernel from scratch, alone, is next to impossible.

First have to decouple Go from its runtime before you could build a kernel in it, not to mention everything else that goes w/ writing a kernel. Similarly, you can't use significant parts of C++ when building a kernel w/ it.

It seems like a lot of people are looking at Rust as a system programming language, though... (google rust kernel)

Writing OS's is hard and there are no shortcuts. You should take a look at microkernels and the work Andrew Tanenbaum did with Minix 3 [1] and his modular design as this is the sort of direction you're probably looking for with customisable OS's.

[1] https://www.youtube.com/watch?v=bx3KuE7UjGA

Because building a custom kernel is like building a custom implementation of a language and a runtime.

Even though you can easily implement custom HTTP server you cannot easily implement full custom Go runtime.