Well, with the exception of the BSD-like systems, none of the systems being written will actually run software people want to run unless they target those kerne

Well, with the exception of the BSD-like systems, none of the systems being written will actually run software people want to run unless they target those kernels. By definition, none of these kernels will therefore likely see widespread use. You can see a microcosm of this with Linux: popular commercial software like games often doesn't come to linux. To make an operating system that sees popular use, you'd likely need to emulate the API of an existing system. This is actually fine. These systems aren't really trying to do that because they're created for other reasons. Maybe it is to learn about building operating systems and the author picked a not-C language? Maybe it is an academic research project like seL4 and the question being asked is "can we formally verify a whole kernel?" Maybe the kernel will use some esoteric feature of the processor, like i386's hardware threads or POWER's hypervisor? Maybe it is to produce a security kernel like GEMSOS or a separation kernel like Windriver's vxworks or Muen (which is written in Ada). Or it could be to build a different design of kernel, like a microkernel or unikernel. There are many reasons, and some of these are sold commercially and used in critical environments, albeit not on the scale of say Windows or Linux. I don't think there's anything wrong with trying to build a kernel in a new language for many of the reasons other commenters have suggested. Perhaps it is simply to see if the language is suitable for kernel development? Maybe it is just to learn, and the developer in question picked their favourite language? I do agree with you though that doing some research is absolutely necessary. Writing a kernel is not a small project and it helps to decide what your aims are :)