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

41–50 of 107 posts

Re: Go at Digital Ocean

#41

Post by js2 »

throwawaysml wrote: post #29
js2 wrote: post #27

Earlier quoted context omitted.

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?

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.

Gotcha. Perhaps REI? They carry a handful of brands and you can return anything you aren’t happy with.

Re: Go at Digital Ocean

#42

Post by weberc2 »

saghm wrote: post #38
carussell wrote: post #36

Earlier quoted context omitted.

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.

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.

Go and vim don't have "distributed package managers"; they just punt on package management altogether. The next step up from that is a centralized package management system, and if you care that much you'll probably build in some notion of versions (even if they're nondeterministic or otherwise broken, as in the case of pip, npm, and many Linux package managers). Building a distributed package manager is quite a lot more work.

Re: Go at Digital Ocean

#43

Post by closeparen »

weberc2 wrote: post #39
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…

GOPATH isn't a real problem; it's just a search directory like PATH or PYTHONPATH or CLASSPATH or NODEPATH, and it has a default value that makes it painless. Vendoring can be truly painful, but `dep` aims to fix that. Imports are not git URLs or indeed any kind of URLs; they're just directory paths into your GOPATH which the `go get` program can use if the directory path resembles the URL of a git (or hg/bzr/svn) re…

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.

Re: Go at Digital Ocean

#44

Post by throwawaysml »

iends wrote: post #40
throwawaysml wrote: post #23

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

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

Re: Go at Digital Ocean

#45

Post by imsofuture »

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…

Go vendoring gets such a bad rap undeservedly. In practice it's the simplest and most straightforward dependency system (since 1.4/5 added vendoring) I've used.

Step 1: Check out code that you want to use. That's actually the only step and you can do it by hand, or with one of a multitude of tools. All the tools differ slightly, and any metadata or manifests or things like that they do aren't compatible, but the code they put in your repository is, enabling anyone to clone a repository, and instantly build the exact version of all your dependencies.

Imports also aren't full git URLs, they can be as a convenience that tells you where to get a package. You can't `go get` a specific tag, but that's fine, because `go get` isn't a package or dependency manager, it's just a convenience to grab code to your system, not to freeze a version as a dependency into your project.

Frankly, the amount of people that put their nose in the air at go is just fine with me, just makes it more of a 'secret productivity tool' I guess.

Edit: not to say it wouldn't have been nice if `dep` had been the one blessed path at version 1. Still, I have extremely little to complain about with the language and tooling since 1.4/1.5.

Re: Go at Digital Ocean

#46

Post by type0 »

octalmage wrote: post #8
steveklabnik wrote: post #4

Earlier quoted context omitted.

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.

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.

Go has become pretty big in China, and it will only grow around from now on. I wish Rust will reach the same critical mass.

Re: Go at Digital Ocean

#47

Post by imsofuture »

closeparen wrote: post #43
weberc2 wrote: post #39

Earlier quoted context omitted.

GOPATH isn't a real problem; it's just a search directory like PATH or PYTHONPATH or CLASSPATH or NODEPATH, and it has a default value that makes it painless. Vendoring can be truly painful, but `dep` aims to fix that. Imports are not git URLs or indeed any kind of URLs; they're just directory paths into your GOPATH which the `go get` program can use if the directory path resembles the URL of a git (or hg/bzr/svn) re…

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

Re: Go at Digital Ocean

#48

Post by throwawaysml »

js2 wrote: post #41
throwawaysml wrote: post #29

Earlier quoted context omitted.

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.

Gotcha. Perhaps REI? They carry a handful of brands and you can return anything you aren’t happy with.

Thanks. Basically I want the sturdy laptop backpack you got from HP 10 years ago with a clever way to pack clothes and ideally waterproof bottom (rubber/plastic) so that I don't worry when having it sit on random floors at airports or train stations.

Having a subdivision of the main compartment bigger than 2 is also important. Laptop, papers, cloth, food maybe.

I'm in Germany and looking for a shop nearby where they have a diverse selection of bags to inspect. I'm kinda tired of ordering bags and having had to send them all back. Amazon is threatening a penalty for returning too often, so there's that :).

First world problems, right?

Re: Go at Digital Ocean

#49

Post by innocentoldguy »

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.

Re: Go at Digital Ocean

#50

Post by alain_gilbert »

imsofuture wrote: post #45
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…

Go vendoring gets such a bad rap undeservedly. In practice it's the simplest and most straightforward dependency system (since 1.4/5 added vendoring) I've used. Step 1: Check out code that you want to use. That's actually the only step and you can do it by hand, or with one of a multitude of tools. All the tools differ slightly, and any metadata or manifests or things like that they do aren't compatible, but the code…

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 about it.

But overall, I love go. I use it all the time anyway.

Post reply on HN