For me it is Go vs Erlang. I see both solving similar set of problems (for me!).<p>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.<p>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.<p>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.<p>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?
I love Go and want to see it succeed, but as long as "why I wrote X in Go" is a novel thing, Go maybe hasn't made it yet. There are probably thousands of wonderful Python libraries and sure sometimes people decide to talk about why those chose Python, but all of these "Why Go?" posts feel a bit like a forced explanation to the question "Why did you write X in some new language that almost nobody else is using?"<p>But that isn't true anymore. Lots of people and teams are using Go. You don't need to explain yourself. Just write stuff in Go. Maybe even write about the process of how you wrote your app in Go, but stop making it about the language. It's there, it works. No need to apologize, evangelize or explain yourself.
Wouldn't it be great if audio of a presentation were also available and the slides were played in sync with it?<p>Imagine if presentation software generated a coded tone for each transition that could be used later on to merge the recorded audio of the speaker and the slides into an audio slideshow.<p>Then having a video of your presentation would just be a side effect of your presentation. And it would focus on the material you wanted to present, not your image.<p>Although videos of speakers are nice, often the material the speaker is referring to isn't visible. It really should be the visual focus.
Comments on slide 28:<p>"go get, can't pin a particular revision"<p>- There's an elegant solution by now, see <a href="https://github.com/kr/godep" rel="nofollow">https://github.com/kr/godep</a><p>"must deal with private repos manually"<p>- go get can get them via ssh using key auth, just do <a href="https://gist.github.com/shurcooL/6927554" rel="nofollow">https://gist.github.com/shurcooL/6927554</a>
if you are running latest versions of Ubuntu or Linux kernels, it is a PITA to get Docker running because of its dependence on AUFS - which is deprecated on the kernel side.<p>The better (but unknown) way of running it is to install Docker 0.7-RC4 through <i>curl <a href="http://test.docker.io" rel="nofollow">http://test.docker.io</a> | sudo sh</i>.<p>Just FYI.
Devs not aware of where and how is their software running, while ops are not aware what they're running? That sound like a recipe for a disaster. You don't need to know everything, that's why there are separate teams... but the way it's described in the slides is slightly scary to me. I've seen people caring only about their own area and lobbing things over the wall for other teams to take out over. It never ended well.
The solution I've found to the "package main" problem is to put the "main" as a <i>sub</i> package.<p><pre><code> -src-myapp-main1
\shared_code
\main2
</code></pre>
That way main can import "myapp/shared_code". Yes, the packaging standard is being broken for the main programs, but that's ok, nothing needs to import them.
Slide 24 says "Why Go? Multi-arch build without preprocessors."<p>My understanding is that Docker is strongly tied to Linux by virtue of using Linux containers. So how does Docker benefit from the multi-arch build facilities of Go, if it only runs on Linux?
I notice that "security" doesn't figure in the devops slide at all. Bundling a whole load of untracked, old libraries together and then exposing it on the web might not be the best idea in the world.