JRFC 29 - Go Node

I've been formulating ideas for a mad science experiment, and recently I've heard friends want to do this too, so let's do it.

> # Make Go more like Node

There are tons of subtleties that will go into this, but the basic idea is to re-imagine the Node programming system (#15, #27) with Go as a language (instead of javascript). Conversely, it can be seen as bringing sane package management and massive code reuse to Go -- a principle significantly undervalued in the mainstream Go ethos.[1]

Here is a shortlist of related features or principles I'd like to add to Go:
- sane package management (npm + ipfs, as in #27)
- ipfs pm instead of in-repo vendoring
- every file is a module
- sane versioning of code
- abandoning the `package` keyword
- require explicit, named imports (`import foo ""`)
- sane importing of multiple versions of the same module
- dealing with `init` (source of side-effect issues)
- reducing export surface area
- maximizing code reusability (minimizing "import friction")
- a node-like shell

Perhaps I could summarize this idea as:

> ## Go with Modules, not Packages
### to be continued

**Note: this is just planting a flag. I will be growing this document over time.**

---

[1] I should note that I (think I) understand _why_ this is undervalued. It has more to do with how the Go team works (and how software engineering at Google works) than what makes a good programming system in the abstract. One of the guiding principles of Go is to focus on what works in practice, not on abstract ideals -- so it makes perfect sense. But, unlike software development inside Google, the open source world is a very messy place where code gets designed, written, maintained, abandoned, and forked by many different people. Package Management and Maximizing Code Reuse have become important staples of would-be open source hackers with big goals, little time, and the absence of a software engineer army.