11 ms·

Go at Digital Ocean

189 points by dcu 9y ago

neom 9y ago
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. https://github.com/digitalocean?language=go https://github.com/digitalocean?language=go (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: https://github.com/macb https://github.com/macb)
- hardwaresofton 9y ago
  While rust is the safer, and more featureful language, I think Go is quite possibly the better pick for large corporations just due to it's simplicity. Rust to me is the more interesting language, but it definitely offers more power and more choice -- they probably did the right thing by going for Go IMO. Also really cool to see all the tooling they've built up -- all of the things mentioned seem really cool, "who's gonna clean up all the stale branches" is definitely a question that gets asked (and answered) at more companies that it probably should.
  - steveklabnik 9y ago
    Many big companies are shipping Rust. There's ones we know about, like Oracle, and there's ones we've only heard whispers of, like a poster on the Reddit who claims they are shipping Rust at a Fortune 500 company. That said, Go makes sense for a lot of the things DO does.
    - yjftsjthsd-h 9y ago
      What's Oracle doing with Rust?
      - steveklabnik 9y ago
        Writing container runtimes https://blogs.oracle.com/developers/building-a-container-runtime-in-rust https://blogs.oracle.com/developers/building-a-container-run... (Github link at the end there) and https://github.com/oracle/crashcart https://github.com/oracle/crashcart
        yjftsjthsd-h 9y ago
        Neat! Oracle, being the epitome of Enterprise, is the last company I would have expected to see using Rust and containers; nice to be proven wrong :) EDIT: typo
        geodel 9y ago
        Well Oracle was the last big company to join Cloud Native foundation. They have realized that Kubernetes, containers are becoming new standard layer of infrastructure. Combined with fact Oracle donated JavaEE to Eclipse foundation, effectively washing their hands of legacy tech.
    - octalmage 9y ago
      I also think Rust is the more interesting choice, but the company I work for went with Go. It does seem to be the more popular choice.
      - steveklabnik 9y ago
        Yeah, Go being stable earlier, plus being so simple is great for its adoption. That said, Rust and Go have some overlap, but also areas where each is clearly the better choice. There's no reason this needs to be a zero-sum thing!
        varunsaini 9y ago
        Yeah, they both have their use cases and they can both be popular equally. It's all about looking at the problem in hand and deciding what do you need to solve that problem.
      - throwawaysml 9y ago
        Go is becoming the new Java from what I can tell so it's good to know enough to find your way around and patch a Go project if needed. Being the new Java, despite being less expressive, explains the uptake in the enterprise and startups.
        pjmlp 9y ago
        Pity it is the new Java 1.0, instead of being the new Java 9.
        throwawaysml 9y ago
        If Java had good AOT and fast startup coupled with comparable initial GC heap sizes, it could have had a better chance at fighting off Go. Java will not go away and many teams that adopt Go also migrate to other languages at some point if their projects outgrow the capabilities of Go and the pain gets too strong. I'm partial to GHC's language extension model over a cornucopia of Go pre- and post-processing tools like Java had (e.g. AspectJ and all the tools making use of annotations? or Go processors using comments). It will be easier to improve GHC's GC or complete OCaml's multicore branch than bring Go to the current century of proven programming language features. Go has found a niche as a replacement for C and Python in network programming, which is great. It just doesn't scale as well with project and team size. OCaml's multicore project also introduces algebraic effects (comprehensive alternative to monadic programming) to the mainstream, so I can't wait for OCaml multicore to land in mainline.
  - yjftsjthsd-h 9y ago
    Another possible reason: my understanding is that Go works really well for web apps (including the standard library covering http and templates), while Rust isn't as strong there. But I might just have seen less web-focused Rust; are there any good frameworks for web apps in Rust?
    - rapsey 9y ago
      In my experience Rust works well as a C/C++ replacement. As a high level language much less so. Go is clearly the better choice for web apps and probably will remain so.
      - nicoburns 9y ago
        I'd definitely agree that Go is currently clearly the better choice for web apps. I'm not so sure it will stay that way though. Rust has some really powerful abstraction abilities, which can make for super nice apis. I reckon it will end up like the choice between python/js/php/ruby on the backend, where each have their strength and weaknesses, but none are universally better.
        hardwaresofton 9y ago
        I agree and disagree, for the reason you stated. I think Rust is a good language for web apps, with the caveat that you must understand the syntax and the power afforded first. That makes the language harder to learn, but for the purposes of webapps that makes it better. If you start from bare micro-framework (set a route, attach a handler), you're eventually going to write some generic function that fetches an entity from a data store. In Go, this becomes a bit of a kludge (interface{} + casting + etc), but in rust it's robustly supported (traits/generic functions). Of course, if you pick the right library for the database you wouldn't have that issue, but that's just the kind of abstraction/complexity-hiding problem you run into building webapps (from scratch at least) that I think rust is the better tool for. Like I mentoined in another post, basically all the micro-frameworks have the same shape to me at this point: add route(s), add handler function(s), and start the server.
    - 9y ago
  - killercup 9y ago
    I'm a big fan of doing fancy things on CI, so I'm always looking for cool ideas there. This talk seems to mostly be about tooling around dependencies, though, so your comparison to Rust is interesting: Rust's cargo is all-around wonderful IMHO and seems to support everything DO needed and built themselves (incl. multiple versions of dependencies, tooling for mono-repo workspaces, etc.).
    - hardwaresofton 9y ago
      Yeah my bet was that they decided on the language first then built the tooling afterwards. Rust person was probably saying the same thing as it was happening... Rust can be really daunting to look at, and if you compare the rust book to the go language tour, the easiest one to learn is pretty clear -- I get the feeling they won't even regret the choice because the things rust protects you from go sidesteps by giving you slow-but-safe-and-restrictive channels. Go's data race detector also is probably gonna be good-enough for a long time.
      - AYBABTME 9y ago
        Rust wasn't a stable language until much later, when we (DO) were already pretty far along in our Go practice.
- farslan 9y ago
  Author here. Fun fact MacB is also my current manager. Indeed a great person and mentor.
sytse 9y ago
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 http://bit.ly/2Aj70zv http://bit.ly/2Aj70zv 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. 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.
- twic 9y ago
  Conversely, i'd be interested to know how and why they're using Concourse for CD but not CI. My experience with Concourse taught me that it's model deals much better with CI, which is isolated from the rest of the world, than CD, which isn't. For CD it just became a very complicated way to run shell scripts.
  - ukoki 9y ago
    Personally I find Concourse to be better at CD than CI. We've been using it for a couple of years now to deploy Cloud Foundry which has a complex dependency graph of deployment steps. Concourse pipelines are great at modelling this, and resources like Terraform[1], Docker and S3 save you writing what would otherwise be a hell of a lot of Bash. Disclosure: I run a company that sells hosted Concourse. 1: https://github.com/ljfranklin/terraform-resource https://github.com/ljfranklin/terraform-resource
- testb 9y ago
  Any way to get notice when CI/CD Only mode comes out? My org would definitely be interested in using GitLab for CI while keeping our repos on GitHub
  - sytse 9y ago
    Thanks for being interested. We don’t have a set date. The issues that are linked from the presentation give an indication. You can follow them.
innocentoldguy 9y ago
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.
- innocentoldguy 9y ago
  Hmm. Must have made sensitive Go programmers cry. Go is a boring language, and it isn't as good at concurrency as other, better designed languages. I'm sorry, but that is a fact.
  - deleted 9y ago
    [deleted]
  - Thaxll 9y ago
    Maybe but better designed language doesn't mean better language overall. Also anything Erlang based is slower than Go.
    - innocentoldguy 9y ago
      And anything Erlang based is going to be more stable/scalable than Go because Go takes 10 times the memory to spawn a process, uses shared memory to store processes, and doesn't guarantee a process will relinquish control. Package/dependency control in Elixir and Erlang are better than the mess that Go started out with, and is still struggling with, apparently. Hot deploys are also much nicer in Elixir than they are in . . . oh wait. Go doesn't do hot deploys. I'd rather lose a couple milliseconds, especially when language speed is not the bottleneck, and code in something better designed.
      - Thaxll 9y ago
        Anything Erlang is doing for deployment is moot since Kubernetes / Docker and the like where you have a platform to do that better than Erlang does and it's language agnostic. No one cares about hot deploy tbh.
ShabbosGoy 9y ago
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? My approach is to shove everything in $GOPATH/src.
- farslan 9y ago
  Author here. The approach of a single repository for each project has its downsides, which I’ve tried to explain in the beginning of the slides already.
twic 9y ago
Coffee and bag geek 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?
- throwawaysml 9y ago
  I'm not a bag geek, but I know firsthand how hard it is to find the right bag, if you care about functionality more than form. For instance, I still haven't found the right carry on backpack that's sturdy, doesn't cost $200+, allows me to take clothes for a couple days and a laptop. It's either too big, too expensive, too heavy, too fragile, take your pick. So I can understand how someone can become a bag geek if they have to travel professionally on their own (without assistants who carry your baggage). Bonus points if I can detach a small laptop bag to take with me in order not to leave it at the hotel with the rest of the bag. So far I've always had to carry around the backpack and leave clothes in the hotel room. Pack, arrive, unpack, carry laptop, repack, go home.
  - js2 9y ago
    I don’t understand the objection to price if it fulfills all your other requirements. A quality bag will have a lifetime warranty. Have you looked at Go Ruck?
    - throwawaysml 9y ago
      Past experience makes me wary to risk spending that much and be disappointed two trips later. Lifetime doesn't mean they give money back if unsatisfied, except one or two companies. Also, upping my budget didn't magically reveal viable options either. So I could have skipped the price tag mention and conclude that it's just hard to find the perfect bag. I've seen the Go Ruck GR2 and it doesn't fit my requirements.
      - js2 9y ago
        Gotcha. Perhaps REI? They carry a handful of brands and you can return anything you aren’t happy with.
throwawaysml 9y ago
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)? EDIT: E.g moving .git/ back and forth or adding extra vetting/linting tools instead of extending `go vet`.
- iends 9y ago
  The most painful parts of the Go ecosystem are directly tied to the fact that the Google is making Go for themselves first and foremost and the community is an afterthought.
  - throwawaysml 9y ago
    True and the more surprising aspect is that to land a develop position at Google you need to be on top of all CS theory and fresh in memory, just to unlearn everything and use Go for unspectacular business/enterprise projects, unless you're on certain teams like V8 or DeepMind for example. I think Go is meant to replace Google's Java coders with Go coders and have a language that fits exactly into the mold of their coding guides and rules for their monorepo and all the business/enterprise code written by the hordes of the rest of their developers. Google's also opensourced Abseil, their C++ standard library (not meant to completely replact STL, to be clear), which contains all kinds of classes which were copied into many existing Google C++ projects in some form or fashion and sometimes incompatibly (e.g. Google's StringPiece found in several projects). Either way I applaud them for doing a lot to open source projects. It's not something we can take for granted.
    - throwawaysml 9y ago
      I suspected this might get downvoted and wanted to make clear I'm not demeaning the 90% of Google developers, but I failed, so I deserved the downvote. Just to make it clear I'm aware of where my comment failed to express what I was trying to communicate. Will try to be less lazy next time. It's hard to explain the purpose Google built Go for without considering where it's not used, and I failed to write a good comment.
arianvanp 9y ago
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. 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?
- kbar13 9y ago
  i believe dep and glide allow you to pin to specific versions. i actually really like that imports are URLs, makes it really obvious where packages come from, and it's a better system imo than a centralized package manager like pypi / rubygem where names need to be unique.
  - saghm 9y ago
    > it's a better system imo than a centralized package manager like pypi / rubygem where names need to be unique I'll have to disagree there; while having namespaced packages gives some advantages, having a centralized repository gives you things like proper versioning, which is worth all the terrible package names in the world to me.
    - carussell 9y ago
      A central repository doesn't automatically give you versioning, and URLs as package IDs doesn't take it away. These are orthogonal issues. It just happens that Go has chosen an approach for now that results in a lot of pain.
      - saghm 9y ago
        I don't think they're completely orthogonal; I think it's much easier to enforce versioning with a central repository than URLs as package IDs. It's not a coincidence that the most common centralized package managers (e.g. Ruby, Python, NodeJS, Rust, Linux distro package managers, and brew) all enforce versioning and things like Go and Vim packaging don't.
gtaylor 9y ago
If anyone over at DO is reading this, we've got some technical and conceptual overlap at Reddit. Would love to compare notes.
logicallee 9y ago
Can someone explain slides 54-58, about how it takes many minutes to lowercase strings? 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). 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?
- golangnews 9y ago
  Looks like the output of pprof, so perhaps the slide means all calls to this function (when run 10000 times say during checking dependencies over a very large codebase), take 21 second in total, reduced to 4 seconds by storing the results of comparisons in a map and using that instead. Go strings are immutable so calling ToLower repeateadly would copy them each time.
deleted 9y ago
[deleted]
alphaalpha101 9y ago
This seems like an enormous amount of tooling complexity to simply have a few dependencies for your program.
- farslan 9y ago
  Author here. It’s not by any means a few dependencies. There are over 2 million lines of vendored packages, you can imagine how much effort it’s needed to upgrade them, be sure each team uses the corrext version, has no security exposures, etc...
cristaloleg 9y ago
Are there any chances to see `gta` tool in open source?

189 points by dcu 9y ago

neom 9y ago

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. https://github.com/digitalocean?language=go https://github.com/digitalocean?language=go (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: https://github.com/macb https://github.com/macb)

hardwaresofton 9y ago
While rust is the safer, and more featureful language, I think Go is quite possibly the better pick for large corporations just due to it's simplicity. Rust to me is the more interesting language, but it definitely offers more power and more choice -- they probably did the right thing by going for Go IMO. Also really cool to see all the tooling they've built up -- all of the things mentioned seem really cool, "who's gonna clean up all the stale branches" is definitely a question that gets asked (and answered) at more companies that it probably should.
- steveklabnik 9y ago
  Many big companies are shipping Rust. There's ones we know about, like Oracle, and there's ones we've only heard whispers of, like a poster on the Reddit who claims they are shipping Rust at a Fortune 500 company. That said, Go makes sense for a lot of the things DO does.
  - yjftsjthsd-h 9y ago
    What's Oracle doing with Rust?
    - steveklabnik 9y ago
      Writing container runtimes https://blogs.oracle.com/developers/building-a-container-runtime-in-rust https://blogs.oracle.com/developers/building-a-container-run... (Github link at the end there) and https://github.com/oracle/crashcart https://github.com/oracle/crashcart
      - yjftsjthsd-h 9y ago
        Neat! Oracle, being the epitome of Enterprise, is the last company I would have expected to see using Rust and containers; nice to be proven wrong :) EDIT: typo
        geodel 9y ago
        Well Oracle was the last big company to join Cloud Native foundation. They have realized that Kubernetes, containers are becoming new standard layer of infrastructure. Combined with fact Oracle donated JavaEE to Eclipse foundation, effectively washing their hands of legacy tech.
  - octalmage 9y ago
    I also think Rust is the more interesting choice, but the company I work for went with Go. It does seem to be the more popular choice.
    - steveklabnik 9y ago
      Yeah, Go being stable earlier, plus being so simple is great for its adoption. That said, Rust and Go have some overlap, but also areas where each is clearly the better choice. There's no reason this needs to be a zero-sum thing!
      - varunsaini 9y ago
        Yeah, they both have their use cases and they can both be popular equally. It's all about looking at the problem in hand and deciding what do you need to solve that problem.
    - throwawaysml 9y ago
      Go is becoming the new Java from what I can tell so it's good to know enough to find your way around and patch a Go project if needed. Being the new Java, despite being less expressive, explains the uptake in the enterprise and startups.
      - pjmlp 9y ago
        Pity it is the new Java 1.0, instead of being the new Java 9.
        throwawaysml 9y ago
        If Java had good AOT and fast startup coupled with comparable initial GC heap sizes, it could have had a better chance at fighting off Go. Java will not go away and many teams that adopt Go also migrate to other languages at some point if their projects outgrow the capabilities of Go and the pain gets too strong. I'm partial to GHC's language extension model over a cornucopia of Go pre- and post-processing tools like Java had (e.g. AspectJ and all the tools making use of annotations? or Go processors using comments). It will be easier to improve GHC's GC or complete OCaml's multicore branch than bring Go to the current century of proven programming language features. Go has found a niche as a replacement for C and Python in network programming, which is great. It just doesn't scale as well with project and team size. OCaml's multicore project also introduces algebraic effects (comprehensive alternative to monadic programming) to the mainstream, so I can't wait for OCaml multicore to land in mainline.
- yjftsjthsd-h 9y ago
  Another possible reason: my understanding is that Go works really well for web apps (including the standard library covering http and templates), while Rust isn't as strong there. But I might just have seen less web-focused Rust; are there any good frameworks for web apps in Rust?
  - rapsey 9y ago
    In my experience Rust works well as a C/C++ replacement. As a high level language much less so. Go is clearly the better choice for web apps and probably will remain so.
    - nicoburns 9y ago
      I'd definitely agree that Go is currently clearly the better choice for web apps. I'm not so sure it will stay that way though. Rust has some really powerful abstraction abilities, which can make for super nice apis. I reckon it will end up like the choice between python/js/php/ruby on the backend, where each have their strength and weaknesses, but none are universally better.
      - hardwaresofton 9y ago
        I agree and disagree, for the reason you stated. I think Rust is a good language for web apps, with the caveat that you must understand the syntax and the power afforded first. That makes the language harder to learn, but for the purposes of webapps that makes it better. If you start from bare micro-framework (set a route, attach a handler), you're eventually going to write some generic function that fetches an entity from a data store. In Go, this becomes a bit of a kludge (interface{} + casting + etc), but in rust it's robustly supported (traits/generic functions). Of course, if you pick the right library for the database you wouldn't have that issue, but that's just the kind of abstraction/complexity-hiding problem you run into building webapps (from scratch at least) that I think rust is the better tool for. Like I mentoined in another post, basically all the micro-frameworks have the same shape to me at this point: add route(s), add handler function(s), and start the server.
  - 9y ago
- killercup 9y ago
  I'm a big fan of doing fancy things on CI, so I'm always looking for cool ideas there. This talk seems to mostly be about tooling around dependencies, though, so your comparison to Rust is interesting: Rust's cargo is all-around wonderful IMHO and seems to support everything DO needed and built themselves (incl. multiple versions of dependencies, tooling for mono-repo workspaces, etc.).
  - hardwaresofton 9y ago
    Yeah my bet was that they decided on the language first then built the tooling afterwards. Rust person was probably saying the same thing as it was happening... Rust can be really daunting to look at, and if you compare the rust book to the go language tour, the easiest one to learn is pretty clear -- I get the feeling they won't even regret the choice because the things rust protects you from go sidesteps by giving you slow-but-safe-and-restrictive channels. Go's data race detector also is probably gonna be good-enough for a long time.
    - AYBABTME 9y ago
      Rust wasn't a stable language until much later, when we (DO) were already pretty far along in our Go practice.
farslan 9y ago
Author here. Fun fact MacB is also my current manager. Indeed a great person and mentor.

sytse 9y ago

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 http://bit.ly/2Aj70zv http://bit.ly/2Aj70zv 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. 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.

twic 9y ago
Conversely, i'd be interested to know how and why they're using Concourse for CD but not CI. My experience with Concourse taught me that it's model deals much better with CI, which is isolated from the rest of the world, than CD, which isn't. For CD it just became a very complicated way to run shell scripts.
- ukoki 9y ago
  Personally I find Concourse to be better at CD than CI. We've been using it for a couple of years now to deploy Cloud Foundry which has a complex dependency graph of deployment steps. Concourse pipelines are great at modelling this, and resources like Terraform[1], Docker and S3 save you writing what would otherwise be a hell of a lot of Bash. Disclosure: I run a company that sells hosted Concourse. 1: https://github.com/ljfranklin/terraform-resource https://github.com/ljfranklin/terraform-resource
testb 9y ago
Any way to get notice when CI/CD Only mode comes out? My org would definitely be interested in using GitLab for CI while keeping our repos on GitHub
- sytse 9y ago
  Thanks for being interested. We don’t have a set date. The issues that are linked from the presentation give an indication. You can follow them.

innocentoldguy 9y ago

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.

innocentoldguy 9y ago
Hmm. Must have made sensitive Go programmers cry. Go is a boring language, and it isn't as good at concurrency as other, better designed languages. I'm sorry, but that is a fact.
- deleted 9y ago
  [deleted]
- Thaxll 9y ago
  Maybe but better designed language doesn't mean better language overall. Also anything Erlang based is slower than Go.
  - innocentoldguy 9y ago
    And anything Erlang based is going to be more stable/scalable than Go because Go takes 10 times the memory to spawn a process, uses shared memory to store processes, and doesn't guarantee a process will relinquish control. Package/dependency control in Elixir and Erlang are better than the mess that Go started out with, and is still struggling with, apparently. Hot deploys are also much nicer in Elixir than they are in . . . oh wait. Go doesn't do hot deploys. I'd rather lose a couple milliseconds, especially when language speed is not the bottleneck, and code in something better designed.
    - Thaxll 9y ago
      Anything Erlang is doing for deployment is moot since Kubernetes / Docker and the like where you have a platform to do that better than Erlang does and it's language agnostic. No one cares about hot deploy tbh.

ShabbosGoy 9y ago

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? My approach is to shove everything in $GOPATH/src.

farslan 9y ago
Author here. The approach of a single repository for each project has its downsides, which I’ve tried to explain in the beginning of the slides already.

twic 9y ago

Coffee and bag geek 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?

throwawaysml 9y ago
I'm not a bag geek, but I know firsthand how hard it is to find the right bag, if you care about functionality more than form. For instance, I still haven't found the right carry on backpack that's sturdy, doesn't cost $200+, allows me to take clothes for a couple days and a laptop. It's either too big, too expensive, too heavy, too fragile, take your pick. So I can understand how someone can become a bag geek if they have to travel professionally on their own (without assistants who carry your baggage). Bonus points if I can detach a small laptop bag to take with me in order not to leave it at the hotel with the rest of the bag. So far I've always had to carry around the backpack and leave clothes in the hotel room. Pack, arrive, unpack, carry laptop, repack, go home.
- js2 9y ago
  I don’t understand the objection to price if it fulfills all your other requirements. A quality bag will have a lifetime warranty. Have you looked at Go Ruck?
  - throwawaysml 9y ago
    Past experience makes me wary to risk spending that much and be disappointed two trips later. Lifetime doesn't mean they give money back if unsatisfied, except one or two companies. Also, upping my budget didn't magically reveal viable options either. So I could have skipped the price tag mention and conclude that it's just hard to find the perfect bag. I've seen the Go Ruck GR2 and it doesn't fit my requirements.
    - js2 9y ago
      Gotcha. Perhaps REI? They carry a handful of brands and you can return anything you aren’t happy with.

throwawaysml 9y ago

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)? EDIT: E.g moving .git/ back and forth or adding extra vetting/linting tools instead of extending `go vet`.

iends 9y ago
The most painful parts of the Go ecosystem are directly tied to the fact that the Google is making Go for themselves first and foremost and the community is an afterthought.
- throwawaysml 9y ago
  True and the more surprising aspect is that to land a develop position at Google you need to be on top of all CS theory and fresh in memory, just to unlearn everything and use Go for unspectacular business/enterprise projects, unless you're on certain teams like V8 or DeepMind for example. I think Go is meant to replace Google's Java coders with Go coders and have a language that fits exactly into the mold of their coding guides and rules for their monorepo and all the business/enterprise code written by the hordes of the rest of their developers. Google's also opensourced Abseil, their C++ standard library (not meant to completely replact STL, to be clear), which contains all kinds of classes which were copied into many existing Google C++ projects in some form or fashion and sometimes incompatibly (e.g. Google's StringPiece found in several projects). Either way I applaud them for doing a lot to open source projects. It's not something we can take for granted.
  - throwawaysml 9y ago
    I suspected this might get downvoted and wanted to make clear I'm not demeaning the 90% of Google developers, but I failed, so I deserved the downvote. Just to make it clear I'm aware of where my comment failed to express what I was trying to communicate. Will try to be less lazy next time. It's hard to explain the purpose Google built Go for without considering where it's not used, and I failed to write a good comment.

arianvanp 9y ago

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. 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?

kbar13 9y ago
i believe dep and glide allow you to pin to specific versions. i actually really like that imports are URLs, makes it really obvious where packages come from, and it's a better system imo than a centralized package manager like pypi / rubygem where names need to be unique.
- saghm 9y ago
  > it's a better system imo than a centralized package manager like pypi / rubygem where names need to be unique I'll have to disagree there; while having namespaced packages gives some advantages, having a centralized repository gives you things like proper versioning, which is worth all the terrible package names in the world to me.
  - carussell 9y ago
    A central repository doesn't automatically give you versioning, and URLs as package IDs doesn't take it away. These are orthogonal issues. It just happens that Go has chosen an approach for now that results in a lot of pain.
    - saghm 9y ago
      I don't think they're completely orthogonal; I think it's much easier to enforce versioning with a central repository than URLs as package IDs. It's not a coincidence that the most common centralized package managers (e.g. Ruby, Python, NodeJS, Rust, Linux distro package managers, and brew) all enforce versioning and things like Go and Vim packaging don't.

gtaylor 9y ago

If anyone over at DO is reading this, we've got some technical and conceptual overlap at Reddit. Would love to compare notes.

logicallee 9y ago

Can someone explain slides 54-58, about how it takes many minutes to lowercase strings? 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). 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?

golangnews 9y ago
Looks like the output of pprof, so perhaps the slide means all calls to this function (when run 10000 times say during checking dependencies over a very large codebase), take 21 second in total, reduced to 4 seconds by storing the results of comparisons in a map and using that instead. Go strings are immutable so calling ToLower repeateadly would copy them each time.

deleted 9y ago

[deleted]

alphaalpha101 9y ago

This seems like an enormous amount of tooling complexity to simply have a few dependencies for your program.

farslan 9y ago
Author here. It’s not by any means a few dependencies. There are over 2 million lines of vendored packages, you can imagine how much effort it’s needed to upgrade them, be sure each team uses the corrext version, has no security exposures, etc...

cristaloleg 9y ago

Are there any chances to see `gta` tool in open source?