Docker and Go: why did we decide to write Docker in Go?

Docker and Go: why did we decide to write Docker in Go? | Hacker News https://news.ycombinator.com/item?id=6709517

Docker and Go: why did we decide to write Docker in Go? (slideshare.net)
		129 points by sylvainkalache on Nov 11, 2013 | hide | past | web | favorite | 62 comments

rdtsc on Nov 11, 2013 [-] For me it is Go vs Erlang. I see both solving similar set of problems (for me!). The slides said Go is easier than Erlang. That is true in some aspects, namely syntax (Elixir to the rescue here!). Go is also easier because of static typing. Speed of compilation is awesome. Building to an executable that only depends on libc -- yes please! love that about Go. I am scared about safety and fault tolerance. Ability to share memory is good for performance but a shared heap in a large concurrent application is scary to me. Not sure what I think about multiple channels and running select over them. Then it pseudo-randomly choosing one channel among those that can receive. Erlang's focus on processes/actors vs channel and each actor having a single mailbox somehow makes more sense to me. Having a shared heap mean faster data processing but GC cannot be fully concurrent. Now passing channels inside other channels is cool, but also kind of scary to me. You can pass channels, inside channels, inside channels, can make some kind of a lazy computation chain. Also I have been wondering, but couldn't find it by doing a quick search, is it possible to build supervision trees out of goroutines like one builds supervision trees in Erlang's OTP. Say I want to have a chat client goroutine to keep the chat up. But I want to monitor it in case it crashes (panics?) then then spawn another one perhaps. Is that possible?