@iximiuz @rumpl @Docker @solomonstre @crosbymichael The actual switch from python to Go happened before I joined the project, and I'm not sure if much of that has been documented (publicly).

I did write down some things a while back, describing why Go was a good fit for the project;

https://twitter.com/thajeztah/status/1225008991941644288

@iximiuz @rumpl @Docker @solomonstre @crosbymichael As to the move from "single binary" to splitting into multiple projects (runc, containerd), there were various reasons (some of those may have been captured in the blogposts linked elsewhere in this thread);

The deprecation of docker-shim (and Docker Engine as runtime) marks the completion of a long-term commitment to provide a modern runtime for Kubernetes 1/15 When the kubernetes project was started, it chose the Docker Engine as runtime (a logical choice, as at the time, the Docker Engine was about the "only" runtime) 2/15

I noticed this some time ago; happy to see this little gem being added to the @github UI

A thread on what it is, and why it's really, really useful 1/15 Perhaps you have never ran into this yourself, but if you're maintaining an (open source) project on GitHub that has forks, chances are you have been "confused", or had the scare of your life because of this 2/15

I saw I was mentioned, and yes, I have many thoughts about go modules. As @tiborvass mentioned; they're great... in an ideal world.

Let me write up some of them (sorry, it's gonna be loooooong, so perhaps I should post somewhere else as well). 1/40

https://twitter.com/solomonstre/status/1310063935530258433

First of all, "vendoring".

I see vendoring mentioned as "not the right solution" for dependency management. I agree that vendoring in itself was not the solution for dependency management, but this should be somewhat nuanced.

2/40

Completed surgery on this beauty. Power switch broke down, and (argh!) required a full dismantle.

Managed to repair the switch using contacts from a donor switch to replace the burned out ones.

Now close up the patient🤞🤞(this may take a while, *tons* of screws😞) "lots of screws"

Pro-top (and reminding myself) that in SemVer:

v1.0.0-rc10 < v1.0.0-rc2 < v1.0.0-rc9

whereas:

v1.0.0-rc.2 < v1.0.0-rc.9 < v1.0.0-rc.10 Both are valid SemVer, but have different meanings: the "pre-release suffix" (coming after "-") is a dot-separated identifier.

Without a dot, "rc9" and "rc10" are different pre-releases, so they are not compared numerically, but alphabetically

Docker adopted Go before it reached 1.0. Go helped us as an open source project, because the language was fairly easy to learn (I didn't know the language before I started to contribute to Docker, and learned along the way, mostly from looking at pull requests) 1/6

https://twitter.com/rakyll/status/1220165797928034304

At the time, Docker was a single static binary, which made it easy for us to ship it (there were no .deb or .rpm package repositories yet), and for users to install.

Go certainly helped us getting that done 2/6

So, today could be described as "entertaining". Huge change for the company, as well as me personally. Mirantis gained an amazingly skilled team, which will help lifting their enterprise solutions to the next level.

Docker will be focusing on the things that put it on the map in the first place: the best possible experience for developers.

Lazyweb @golang users; perhaps someone knows if this exists (let me try to describe)

I'm wondering if there's a way to get "code coverage" of @golang dependencies. Not from a "testing" perspective, but what's used at runtime. 1/4 A way to see what parts of a dependency are used. Not with package-level granularity, but at the file/line level.

Something that allow analyzing the dependency graph, and pin-point packages that would not be needed with a refactor (in the dependency or code using it 2/4

💯❗️ Also; there's no shame in trying and failing; there's shame in not trying.

https://twitter.com/estesp/status/1139305086188949507

I have the deepest respect for contributors in the (open source) projects I work on that gave things a try. You may get stuck at some point, and need help getting it over the finish line.

This is where others can help/mentor.

Want to contribute to open source, but don't know where to start? If you maintain a product, you likely have a lot of dependencies.

Go through that list; there's probably be this tiny library that you've been using for years, and always took for granted.

I was active in the Docker open source community, when @sam_alba reached out to me; he asked me if I wanted to join the company.

https://twitter.com/jessfraz/status/1114750863615119360

I was really excited, but had concerns; I cared about the project and community a LOT; I wasn't shy to voice my opinions, which may not always be in line with (what I assumed) Docker Inc.'s goals. If I would join Docker (the company), there could be conflicts of interest there?