Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go at Digital Ocean

speakerdeck.com

Post reply on HN
Print view View original

91–100 of 107 posts

Re: Go at Digital Ocean

#91

Post by hasenj »

stubish wrote: post #88
hasenj wrote: post #87

Earlier quoted context omitted.

I find the opposite to be true. If you casually add dependencies without understanding the dependency tree, you have a lot of problems waiting to happen. I prefer to be conservative about adding dependencies, and to always manually include them into the project.

You can be conservative about adding dependencies and still end up with hundreds. Database driver, database utilities, gRPC framework, monitoring & metrics, CLI & configuration tools, /x/ packages such as crypto or net, logging, linters, libraries to talk to other moving parts like Rabbit or Vault, and then all the transitive dependencies like yaml, toml, websockets, and the various 'standard' helpers the authors of…

That's the definition of not being conservative about adding dependencies.

Re: Go at Digital Ocean

#92

Post by AYBABTME »

hardwaresofton wrote: post #73
killercup wrote: post #10

Earlier quoted context omitted.

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

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…

Rust wasn't a stable language until much later, when we (DO) were already pretty far along in our Go practice.

Re: Go at Digital Ocean

#93

Post by weberc2 »

golangnews wrote: post #89
slrz wrote: post #69

Earlier quoted context omitted.

Go doesn't insist that your code lives in ~/go/src. It can live anywhere beneath a directory of your choice. Note that there's no requirement that GOPATH contains only Go source code. You can put your scripts and resources, as well as other source code, right next to the Go sources. So you just put your code into ~/src/project/a.go and ~/src/project/b.foo (assuming a GOPATH=$HOME).

Note src vs source in the original comment. Go forces you to change everything else to conform to gopath. I use go a lot and am used to it now but IMO that is a Bad Thing.

Put Go stuff in $GOPATH/src and Foo stuff in ~/foo/source. Problem solved. Go doesn't dictate where non-Go code lives...

This is the least of all problems.

Re: Go at Digital Ocean

#94

Post by petecoop »

sytse wrote: post #12

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 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 appli…

This looks great, I've worked with teams that have their code on GitHub and don't want to move but would benefit from using GitLab for CI/CD.

Re: Go at Digital Ocean

#95

Post by golangnews »

weberc2 wrote: post #93
golangnews wrote: post #89

Earlier quoted context omitted.

Note src vs source in the original comment. Go forces you to change everything else to conform to gopath. I use go a lot and am used to it now but IMO that is a Bad Thing.

Put Go stuff in $GOPATH/src and Foo stuff in ~/foo/source. Problem solved. Go doesn't dictate where non-Go code lives... This is the least of all problems.

So now your go stuff and foo stuff lives in different dirs based on which programming language it happens to use, not which project it is for. To you perhaps this is a non-problem, to others it appears to be and it is a recurring cause of grief for newcomers to go.

Re: Go at Digital Ocean

#96

Post by ukoki »

twic wrote: post #20
sytse wrote: post #12

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 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 appli…

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.

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

Re: Go at Digital Ocean

#97

Post by zaarn »

KallDrexx wrote: post #64
imsofuture wrote: post #47

Earlier quoted context omitted.

This is how I felt when I started using go, but I was unable to rationalize why beyond 'it's different'. What's the real difference between `cd ~/dev` and `cd $MYGO` (~/dev/go/src/github.com/myusername)?

The difference is the Go tooling is dictating your whole code layout that may not match your personal preference. I work in a multitude of languages and I organize my code in ~/code/work for work/contracting code bases, ~/code/personal for my code bases and ~/code/third-party for source code I want to look at and maybe contribute casually to. I have never figured out a good way to fit GOPATH into this without complet…

You can specify multiple GOPATHs which will be searched in order for packages;

Your GOPATH could be set to "~/libs/go:~/code/work for work/contracting/go:~code/personal:~/code/third-party"

which would put any go-get libaries into ~/libs/go and allow using packages from the other folders. Keep in mind that Go will still use these Gopaths like any other Gopath repository; create a src/pkg/bin folder set for use with the compiler

Re: Go at Digital Ocean

#98

Post by zaarn »

golangnews wrote: post #58
imsofuture wrote: post #47

Earlier quoted context omitted.

This is how I felt when I started using go, but I was unable to rationalize why beyond 'it's different'. What's the real difference between `cd ~/dev` and `cd $MYGO` (~/dev/go/src/github.com/myusername)?

Well imagine you use language foo, bar and go. Go insists all code lives in ~/go/src and foo insists it all lives in ~/foo/source. Neither likes symlinks, which one wins? Also people like to keep other artefacts alongside source code like scripts, resources, templates, tools etc and often have an existing elaborate project structure in order to accommodate that. Go forces them to throw that out and use something unde…

    export GOPATH="~/go:~/foo"
GOPATH will use ~/go as default for go get and importing and fall back to any further folders specified.

Re: Go at Digital Ocean

#99

Post by KallDrexx »

zaarn wrote: post #97
KallDrexx wrote: post #64

Earlier quoted context omitted.

The difference is the Go tooling is dictating your whole code layout that may not match your personal preference. I work in a multitude of languages and I organize my code in ~/code/work for work/contracting code bases, ~/code/personal for my code bases and ~/code/third-party for source code I want to look at and maybe contribute casually to. I have never figured out a good way to fit GOPATH into this without complet…

You can specify multiple GOPATHs which will be searched in order for packages; Your GOPATH could be set to "~/libs/go:~/code/work for work/contracting/go:~code/personal:~/code/third-party" which would put any go-get libaries into ~/libs/go and allow using packages from the other folders. Keep in mind that Go will still use these Gopaths like any other Gopath repository; create a src/pkg/bin folder set for use with th…

That's good to know, I had never come across that! Thanks.

Re: Go at Digital Ocean

#100

Post by innocentoldguy »

Thaxll wrote: post #63
innocentoldguy wrote: post #49

Earlier quoted context omitted.

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.

Maybe but better designed language doesn't mean better language overall. Also anything Erlang based is slower than Go.

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.
Post reply on HN