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

61–70 of 107 posts

Re: Go at Digital Ocean

#61

Post by [deleted] »

innocentoldguy wrote: post #49
innocentoldguy wrote: post #13

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.

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]

Re: Go at Digital Ocean

#62

Post by testb »

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…

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

Re: Go at Digital Ocean

#63

Post by Thaxll »

innocentoldguy wrote: post #49
innocentoldguy wrote: post #13

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.

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.

Re: Go at Digital Ocean

#64

Post by KallDrexx »

imsofuture wrote: post #47
closeparen wrote: post #43

Earlier quoted context omitted.

The existence of the GOPATH environment variable is not a problem. The fact that the toolchain is violently opinionated about where you locate your working copies, and goes out of its way to fight you if you try to fake it with symlinks, is. The GOPATH issue will be solved when I can clone a project to anywhere in $HOME and build it without issue.

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 completely rearranging how I organize my code, which I have zero desire to do for one language, especially one that's not my main.

Re: Go at Digital Ocean

#65

Post by alain_gilbert »

imsofuture wrote: post #52
alain_gilbert wrote: post #50

Earlier quoted context omitted.

The fact that the full url is used to import packages make it impossible to fork a repository. Once you forked it, you have to change all the imports across the repo, and then it's kinda either very hard to make Pull Requests, or pull the new commits from the original repo. This is one thing I really dislike about go dependencies. If you have a solution for this, let me know, I would be very interested to know more a…

You don't have to change the package name just because it's forked. I threw together an example of doing this with `dep`. I forked Fatih's color package, and am using it as `github.com/fatih/color` no problem: https://github.com/sofuture/colortest (forked dep here: https://github.com/sofuture/color )

As I said in my other comment (https://news.ycombinator.com/item?id=15632049)

It works for you because it's a small project and you are not actually importing other of your own packages inside it.

But if you look at "echo", it import some other "echo" packages inside of it.

Re: Go at Digital Ocean

#66

Post by throwawaysml »

throwawaysml wrote: post #44
iends wrote: post #40

Earlier quoted context omitted.

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.

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

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.

Re: Go at Digital Ocean

#67

Post by sytse »

testb wrote: post #62
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…

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

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.

Re: Go at Digital Ocean

#68

Post by imsofuture »

alain_gilbert wrote: post #65
imsofuture wrote: post #52

Earlier quoted context omitted.

You don't have to change the package name just because it's forked. I threw together an example of doing this with `dep`. I forked Fatih's color package, and am using it as `github.com/fatih/color` no problem: https://github.com/sofuture/colortest (forked dep here: https://github.com/sofuture/color )

As I said in my other comment ( https://news.ycombinator.com/item?id=15632049 ) It works for you because it's a small project and you are not actually importing other of your own packages inside it. But if you look at "echo", it import some other "echo" packages inside of it.

That doesn't matter is what I'm saying :) The package name of my fork isn't changed, and doesn't need to be, regardless of what else uses it. The only thing I had to do was specify 'use my fork's repo' in the Gopkg.toml file.

Edit: I'll fork echo in my example and show you.

Re: Go at Digital Ocean

#69

Post by slrz »

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…

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

Re: Go at Digital Ocean

#70

Post by hasenj »

arianvanp wrote: post #24

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

What's wrong with vendoring? You put the package you want inside the vendors/ directory. I think it's much better than a package manager that tries to download some version that satisfies some version specification in a file that declares dependencies.
Post reply on HN