4 ms·

I think the point above was that once the binary is built you don’t have to worry about maintaining the exact same libraries on the server where they might be c

I think the point above was that once the binary is built you don’t have to worry about maintaining the exact same libraries on the server where they might be competing/mixing with various incompatible versions of shared libraries for Python or Ruby or whatever. That said, yes this is a shameful hole in the golang world (caused by the project leads’ inside-Google myopia) but I’m glad they are finally addressing it at this level of integration. And despite a few oddities it looks pretty solid.

jacques_chester 8y ago
> once the binary is built My view is that if it can't be built from scratch in a cleanroom environment -- ie, in CI or a buildpacks stager -- it can't be built. This goes for container images too. The amount of "works on my machine" and "where's Gerald? this module only builds on his laptop" I saw as a consultant was depressing. Speaking of containers, though: they solved the contending-interpreters problem quite handily. Cloud Foundry has used containerisation since before Docker existed and it really shines for buildpack usage. We started with Heroku's buildpacks, which had to deal with the nightmare of a pre-container world and showed all the pain of it. There was a great deal of stuff we just didn't have to care about and we later rewrote the bulk of the buildpacks to jettison all the stuff we didn't need. It's all come full circle: Heroku now use containerisation and both Heroku and Cloud Foundry will soon be adopting jointly-developed buildpacks-lifecycle code.
- vorg 8y ago
  > "where's Gerald? this module only builds on his laptop" Of course, "Gerald" is an anagram for "Gradle".
  - jacques_chester 8y ago
    I'm going to pretend, just this once, that I was clever enough to do it on purpose.