{"action":"created","issue":{"url":"https://api.github.com/repos/jbenet/random-ideas/issues/29","labels_url":"https://api.github.com/repos/jbenet/random-ideas/issues/29/labels{/name}","comments_url":"https://api.github.com/repos/jbenet/random-ideas/issues/29/comments","events_url":"https://api.github.com/repos/jbenet/random-ideas/issues/29/events","html_url":"https://github.com/jbenet/random-ideas/issues/29","id":46055167,"number":29,"title":"JRFC 29 - Go Node","user":{"login":"jbenet","id":138401,"avatar_url":"https://avatars.githubusercontent.com/u/138401?v=3","gravatar_id":"","url":"https://api.github.com/users/jbenet","html_url":"https://github.com/jbenet","followers_url":"https://api.github.com/users/jbenet/followers","following_url":"https://api.github.com/users/jbenet/following{/other_user}","gists_url":"https://api.github.com/users/jbenet/gists{/gist_id}","starred_url":"https://api.github.com/users/jbenet/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jbenet/subscriptions","organizations_url":"https://api.github.com/users/jbenet/orgs","repos_url":"https://api.github.com/users/jbenet/repos","events_url":"https://api.github.com/users/jbenet/events{/privacy}","received_events_url":"https://api.github.com/users/jbenet/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":11,"created_at":"2014-10-17T01:46:24Z","updated_at":"2015-12-01T03:23:30Z","closed_at":null,"body":"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.\r\n\r\n> # Make Go more like Node\r\n\r\nThere 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]\r\n\r\nHere is a shortlist of related features or principles I'd like to add to Go:\r\n- sane package management (npm + ipfs, as in #27)\r\n- ipfs pm instead of in-repo vendoring\r\n- every file is a module\r\n- sane versioning of code\r\n- abandoning the `package` keyword\r\n- require explicit, named imports (`import foo \"<path>\"`)\r\n- sane importing of multiple versions of the same module\r\n- dealing with `init` (source of side-effect issues)\r\n- reducing export surface area\r\n- maximizing code reusability (minimizing \"import friction\")\r\n- a node-like shell\r\n\r\nPerhaps I could summarize this idea as:\r\n\r\n> ## Go with Modules, not Packages\r\n\r\n### to be continued\r\n**Note: this is just planting a flag. I will be growing this document over time.**\r\n\r\n---\r\n\r\n[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. "},"comment":{"url":"https://api.github.com/repos/jbenet/random-ideas/issues/comments/160837869","html_url":"https://github.com/jbenet/random-ideas/issues/29#issuecomment-160837869","issue_url":"https://api.github.com/repos/jbenet/random-ideas/issues/29","id":160837869,"user":{"login":"jbenet","id":138401,"avatar_url":"https://avatars.githubusercontent.com/u/138401?v=3","gravatar_id":"","url":"https://api.github.com/users/jbenet","html_url":"https://github.com/jbenet","followers_url":"https://api.github.com/users/jbenet/followers","following_url":"https://api.github.com/users/jbenet/following{/other_user}","gists_url":"https://api.github.com/users/jbenet/gists{/gist_id}","starred_url":"https://api.github.com/users/jbenet/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jbenet/subscriptions","organizations_url":"https://api.github.com/users/jbenet/orgs","repos_url":"https://api.github.com/users/jbenet/repos","events_url":"https://api.github.com/users/jbenet/events{/privacy}","received_events_url":"https://api.github.com/users/jbenet/received_events","type":"User","site_admin":false},"created_at":"2015-12-01T03:23:30Z","updated_at":"2015-12-01T03:23:30Z","body":"> Is this different than require('name/any/sub/file')\r\n\r\nno, precisely the same.\r\n\r\n> Does this mean rename package.json to something else?\r\n\r\nno, the `package` keyword in Go.\r\n\r\n> You mean, importing the same module at different versions into another module?\r\n\r\nyes. \r\n\r\n---\r\n\r\nsince writing this, i believe a strict golang subset could be written to support most of this, armed with a strict preprocessor that fails compilation if any of the subset rules are violated."}}