4 ms·

Sort of tangential, but I'd be interested in seeing an OS based on Go, where Go::Go-OS as C::Unix. (And you could call it "Goose".) Given Go's awesome features,

Sort of tangential, but I'd be interested in seeing an OS based on Go, where Go::Go-OS as C::Unix. (And you could call it "Goose".) Given Go's awesome features, I would imagine it could be pretty interesting.

amock 14y ago
What could you get from an OS written in Go that an OS written in C doesn't already provide? If you were writing a new OS then it might be easier to write it mostly in Go, but I don't think there is any kind of fundamental difference like there is between Linux and Squeak or a Lisp Machine.
- cgh 14y ago
  Perhaps a system api that is more amenable to concurrency? That's probably the biggest fundamental break from the C model of doing things.
- ericbb 14y ago
  If /usr/include were dropped and /usr/lib only contained Go packages, then you'd have an ecosystem where library namespaces are handled in a scalable way--that's a pretty big deal. You'd be working in a statically linked environment rather than a dynamically linked environment--another major change. Garbage collection for everything in user space. Potentially, the removal of select/poll? Drastic increase in memory safety (buffer overruns, etc). Based on the package naming, dependency management, and concurrency, it might even be argued that a Go user space is a bigger fundamental change than a Smalltalk or Lisp user space. Btw, one probably wouldn't write a kernel in Go so I take the parent to be speculating about a system where new OS features were provided by integrating them first into a Go standard library rather than by integrating them into the C standard libraries.
  - amock 14y ago
    Most of these things don't sound like they need OS support. Just writing Go libraries and using Go alongside the existing system can provide a statically linked environment, no need for the application write to use select/poll or worry about memory safety, and garbage collection. It doesn't have to be "Go all the way down" since you won't be modifying your environment at runtime.

amock 14y ago

What could you get from an OS written in Go that an OS written in C doesn't already provide? If you were writing a new OS then it might be easier to write it mostly in Go, but I don't think there is any kind of fundamental difference like there is between Linux and Squeak or a Lisp Machine.

cgh 14y ago
Perhaps a system api that is more amenable to concurrency? That's probably the biggest fundamental break from the C model of doing things.
ericbb 14y ago
If /usr/include were dropped and /usr/lib only contained Go packages, then you'd have an ecosystem where library namespaces are handled in a scalable way--that's a pretty big deal. You'd be working in a statically linked environment rather than a dynamically linked environment--another major change. Garbage collection for everything in user space. Potentially, the removal of select/poll? Drastic increase in memory safety (buffer overruns, etc). Based on the package naming, dependency management, and concurrency, it might even be argued that a Go user space is a bigger fundamental change than a Smalltalk or Lisp user space. Btw, one probably wouldn't write a kernel in Go so I take the parent to be speculating about a system where new OS features were provided by integrating them first into a Go standard library rather than by integrating them into the C standard libraries.
- amock 14y ago
  Most of these things don't sound like they need OS support. Just writing Go libraries and using Go alongside the existing system can provide a statically linked environment, no need for the application write to use select/poll or worry about memory safety, and garbage collection. It doesn't have to be "Go all the way down" since you won't be modifying your environment at runtime.