Very interesting presentation. From my perspective it was interesting that they used GitHub Enterprise with Drone for CI and Concourse and GoCD for CD. At GitLab we're planning a 'CI Only' mode <a href="http://bit.ly/2Aj70zv" rel="nofollow">http://bit.ly/2Aj70zv</a> because companies like Datadog are using GitHub Enterprise with GitLab for the CI. Based on this presentation I've asked the team to rename it to CI/CD only to stress that people are able to use one application for both CI and CD.<p>BTW I'm not sure if this comment is adding to the conversation or if it is too self promotional. If it gets down voted I'll delete it.
The go vendoring stuff and GOPATH sounds like a complete nightmare to me. Also the fact that imports are full git URLS sounds totally crazy. Is `dep` fixing all that stuff? Last time I checked out go a few years ago, I didn't continue because I found the story of actually installing dependencies and keeping track of versions very confusing. You couldn't even `go get` a specific git tag or something.<p>I'm happy that there seems to be some movement. But now we have godep, govendor, glide, dep. and every project uses one or the other. Are they all compatible? Or is it a minefield?
When I joined DO it was transitioning out of it's very Perlly beginnings - one of the engineers was pushing for rust. I guess Go won, and it's nice to see they have picked up such an awesome competency in building with it. <a href="https://github.com/digitalocean?language=go" rel="nofollow">https://github.com/digitalocean?language=go</a> (also Grumpy MacB reference who wrote the first go service at DO is one of the best engineers I've ever met, and also one of the nicest dudes: <a href="https://github.com/macb" rel="nofollow">https://github.com/macb</a>)
Am I alone in finding it unsurprising but unfortunate that all those addons to the official go toolchain are created by everyone to paper over the limitations of the Google Go implementation (which naturally reflects Google's development process and needs more than anything)?<p>EDIT: E.g moving .git/ back and forth or adding extra vetting/linting tools instead of extending `go vet`.
<i>Coffee and bag geek</i><p>I'm a coffee geek, but i'm intrigued at the idea of being a bag geek. How does one geek out over bags? What are the cool things bag geeks know that ordinary people don't?
Can someone explain slides 54-58, about how it takes many minutes to lowercase strings?<p>slide 55 reads: "each string operation takes 21 seconds" (an amount of time which I translate conservatively into tens of billions of operations or gigabytes of in-memory lookups).<p>How can performance be that bad - I would think it's trivial? Like, I'm not getting what lowercasing can possibly be doing that is so resource intensive. Any ideas?
I'm curious as to why they went with the monorepo approach. This might sound really stupid, but couldn't you just have a seperate repo for each team/service?<p>My approach is to shove everything in $GOPATH/src.
I really like Digital Ocean and use it for all my small to mid-sized projects. I agree with a lot of the other comments that languages like Rust (and I'll add Elixir) are far more interesting, fun to program in, and feature rich than Go, but I really don't care what DO choses to use, as long as their offerings continue to be great.