| I think the the "100% Go" stuff is appealing in that you just have one file that works across OSes, with minimal screwing around. For things that become part of the OS, yes, I'd rather they come via some install approach that includes the necessary integration. But for anything else, I think a lot of our packaging approaches are dedicated to saving disk space and RAM, which is something that matters way less to me now than it did 15-20 years ago when CPAN and APT were designed. In 2000, disk prices were circa $10/GB [1]; now we're looking at $0.50/GB of zippy SSD [2] or $0.03/GB of spinning rust [3]. RAM is similarly about 2 orders of magnitude cheaper. [4] Given that, it makes a lot more sense to burn space to minimize the chance of a library version conflict or other packaging issue. Another thing that has changed greatly is the pace of updates. 15-20 years ago, weekly releases sounded impossible to most. Now it's common, and some places are releasing hourly or faster. [5] Thanks to things like GitHub, the whole notion of a release is getting hazy: I see plenty of things where you just install from the latest; every merge to master is in effect a new release. Given that, I think both Go and Docker are pioneering approaches that are much more in sync with the current computing environment. I'm excited to see where they get to. [1] http://www.mkomo.com/cost-per-gigabyte-update [2] http://techreport.com/review/27824/crucial-bx100-and-mx200-s... [3]http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&Is... [4] http://www.jcmit.com/mem2015.htm [5] www.slideshare.net/InfoQ/managing-experimentation-in-a-continuously-deployed-environment slide 27 |