<p>I read about Goose and Bootgo today. It turns out that cross-compilation was one of the hindrance in writing an OS. So that requirement goes away with Go 1.5</p>
<p>Then what are remaining reasons why some OS written in Go would not be usable? </p>
<hr/>**评论：**<br/><br/>twotwotwo: <pre><p>Wow, bootgo (<a href="https://github.com/jjyr/bootgo">https://github.com/jjyr/bootgo</a>) is a neat hack.</p>
<p>It gets harder when you try to go further, though. A big difficulty is that much of Go's runtime relies on operating system calls, but when you <em>are</em> the operating system you can't do that the same way. Go requests pages of RAM from the OS, but when you're writing the OS you have to use the raw memory space you're handed by the processor or hypervisor. You can't ask the OS to write to a file or socket; you have to implement a filesystem and networking stack. You can't ask the OS to start a thread per core; you have to implement a scheduler to coordinate them first. Your code only gets to talk to hardware (real or virtualized). So you have to implement all these concepts on bare metal (or the hypervisor and/or very limited abstractions provided by system firmware), and hack the Go runtime to call your implementations rather than make syscalls.</p>
<p>Julia Evans wrote a series of blog posts about writing a minimal kernel using Rust: <a href="http://jvns.ca/blog/2013/11/29/writing-an-os-using-rustboot-and-rust-core/">http://jvns.ca/blog/2013/11/29/writing-an-os-using-rustboot-and-rust-core/</a> which is great for getting a feel for what it's like to work in kernel-land. Rust has the minor advantage that it's built from the start so that you don't have to include any runtime your program doesn't use, but there's still the unbridled joy (read: pain) of working without the things we're used to in userspace.</p>
<p>Even in languages like OCaml, teams have built "unikernels" -- single applications compiled to run on bare hardware, in effect -- which is, practical or not, a pretty cool hack. MirageOS (<a href="http://www.cl.cam.ac.uk/projects/ocamllabs/tasks/mirage.html">http://www.cl.cam.ac.uk/projects/ocamllabs/tasks/mirage.html</a>) is the name of the project here.</p>
<p>I think OSes are tempting because it feels like a very advanced space. For my part, I'd be impressed if someone could make a substantial contribution to the practice of Go-y Web app development--how can I stand up a basic CRUD site more quickly without taking on all the ills of mega-Web-frameworks?--or static analysis to catch more of my bugs or any number of other things. We have OSes that we get by with, but there is a lot else that we still don't have. :)</p></pre>TheMerovius: <pre><blockquote>
<p>It turns out that cross-compilation was one of the hindrance in writing an OS.</p>
</blockquote>
<p>As others have pointed out, that's not true.</p>
<blockquote>
<p>So that requirement goes away with Go 1.5</p>
</blockquote>
<p>Go 1.5 doesn't make cross compilation easier, does it?</p>
<blockquote>
<p>Then what are remaining reasons why some OS written in Go would not be usable?</p>
</blockquote>
<p>Because you would need to first implement the complete runtime in go. It turns out, that is a fairly non-trivial task (you have to implement large parts of an actual OS, like memory management and multitasking). You also probably need to rewrite/change some of the stdlib packages (because you will have a fairly limited syscall package). And lastly, you will need a lot of insight into how the compiler structures memory and how the linker works.</p>
<p>Everything that's needed is someone who is both really intimate with the details of the inner workings of go and knows a lot about kernel programming and even then you will only end up with a toy kernel unless you spend a <em>lot</em> of time and effort making it a usable system. So far, no one with all these has tried their hands at it, as far as I can tell and I think it would be a pretty humongous waste of time for very little benefit.</p></pre>YEPHENAS: <pre><blockquote>
<p>Because you would need to first implement the complete runtime in go.</p>
</blockquote>
<p>The complete runtime is implemented in Go.</p></pre>TheMerovius: <pre><blockquote>
<p>The complete runtime is implemented in Go.</p>
</blockquote>
<p>I apparently wasn't very clear :) You would need to <em>re</em>implement the complete runtime and (in particular) everything it needs in go. "Go" wasn't the emphasized part of that sentence. :)</p></pre>drwiggly: <pre><p>A full hosting os, probably would be a lot of work and then your hosted apps would be subjected to the garbage collector. Now something like a lib on top of the XEN hyper-visor where you run native on a tiny image would probably be useful. Very much like mirage. Would be more targeted but still relevant and you'd let XEN deal with the real hardware.</p></pre>1Gijs: <pre><blockquote>
<p>It turns out that cross-compilation was one of the hindrance in writing an OS</p>
</blockquote>
<p>How did you get to that conclusion ?</p>
<p>From the Goose readme:</p>
<blockquote>
<p>Go's lack of pointer arithmetic means you remain fairly dependant on asm to do things that would otherwise be trivial in C.</p>
</blockquote></pre>boomshroom: <pre><pre><code>import "unsafe"
</code></pre>
<p>Go now has pointer arithmetic. ;)</p></pre>funny_falcon: <pre><p>it always had.</p></pre>SteveMcQwark: <pre><p>I'm pretty sure they meant that Go has pointer arithmetic when you import "unsafe", not that it's been recently added.</p></pre>Crast: <pre><p>This isn't actually a factor of Go vs non-Go, and admittedly I see writing an OS in Go could be really cool due to Go's really nice syntax, trivial concurrency, but the real simple issue is, writing a non-toy OS is -hard-.</p>
<p>Sure, you could write a really cool OS, and it would likely run Go applications fairly easily, but what happens when you get to talking to the world? device drivers for hundreds or thousands of video cards and network cards? </p>
<p>And then there's the question, do you go down the laborious path of POSIX(ish) compatibility? The advantage of doing so is you can then see a clean path to supporting all your favorite software, like bash, your favorite text editor, web browser, etc; but wow that has killed many OSes that weren't supported by mega-corporations.</p>
<p>I think the main issue that would hinder Go though is in the fact that it's a garbage-collected language. System kernels need to deal with memory very carefully, especially in obscure architecture details, even presuming you could set up specific register and memory addresses by dropping to asm, the Go side would require writing some very careful Go to minimize heap usage or defining a mode where some code can prevent the garbage collector from stopping the world. Plus, OSes are dealing with interrupts, etc. Consider that keyboard keystrokes are interrupts, mouse movement is interrupts, most if not all IO is interrupts; imagine mouse lag because an interrupt handler allocated memory that triggered the garbage collector, and you'll see what I mean.</p></pre>xlab_is: <pre><blockquote>
<p>imagine mouse lag because an interrupt handler allocated memory that triggered the garbage collector</p>
</blockquote>
<p>Offtopic, but still worth to mention here - earlier versions of OS X were adding a 32ms lag to the mouse input.
<a href="http://iaintnoextra.tumblr.com/post/31374405045/john-carmack-and-osx-mouse-lag" rel="nofollow">http://iaintnoextra.tumblr.com/post/31374405045/john-carmack-and-osx-mouse-lag</a></p></pre>
