Writing an OS in a garbage collected language sounds quixotic but it’s been done; Sun had a JavaOS circa 1998 that ran on their JavaStation hardware. (It was a flop. It had far too little RAM and stopped the world very frequently, which meant even the mouse cursor froze. Even given more RAM, the price/performance was miserable.)
(I guess you can count Xerox’s Smalltalk-80, although the low level stuff like the graphics primitive and basic I/O was implemented in either microcode or Mesa, a Pascal-like language.)
But yeah, this person has their work cut out for them, especially if they abjure C entirely. Where do the library functions and syscalls needed by the Go runtime come from?
Although UEFI is super nice and all, I don’t want to completely neglect older hardware.
…
Both only support 64bit higher-half kernels which are completely okay with me. I don’t plan on supporting any older CPUs anyways.
make up your mind. XD x86_64 has been everywhere since… eeeeh, 2006 or so? While UEFI has been everywhere since 2012. Seems like a lot of work for 6 years of hardware. Though I originally thought it was more like 3 years, so maybe it’s worth doing.
This is a pretty good rundown though, including all the horrible build-chain issues you will encounter.
I would definitely not pick Go for a kernel (except maybe for the lulz), but you probably can get better results than java; at least with pointers being explicit you have much more control over memory layout.
Re: dropping C: the runtime is itself written in Go, so no libc is no problem (syscalls, yes, but that doesn’t really set it apart much I think).
Writing an OS in a garbage collected language sounds quixotic but it’s been done; Sun had a JavaOS circa 1998 that ran on their JavaStation hardware. (It was a flop. It had far too little RAM and stopped the world very frequently, which meant even the mouse cursor froze. Even given more RAM, the price/performance was miserable.)
(I guess you can count Xerox’s Smalltalk-80, although the low level stuff like the graphics primitive and basic I/O was implemented in either microcode or Mesa, a Pascal-like language.)
But yeah, this person has their work cut out for them, especially if they abjure C entirely. Where do the library functions and syscalls needed by the Go runtime come from?
It’s been done many times! There’s been OS’s in Haskell, C#, and many other languages you wouldn’t expect.
make up your mind. XD x86_64 has been everywhere since… eeeeh, 2006 or so? While UEFI has been everywhere since 2012. Seems like a lot of work for 6 years of hardware. Though I originally thought it was more like 3 years, so maybe it’s worth doing.
This is a pretty good rundown though, including all the horrible build-chain issues you will encounter.
Go is famous for implementing those entirely in pure go.
I would definitely not pick Go for a kernel (except maybe for the lulz), but you probably can get better results than java; at least with pointers being explicit you have much more control over memory layout.
Re: dropping C: the runtime is itself written in Go, so no libc is no problem (syscalls, yes, but that doesn’t really set it apart much I think).
Why?
Why not?