Live data from Hacker News

Go: Ten years and climbing

commandcenter.blogspot.com

41–50 of 193 posts

Re: Go: Ten years and climbing

#41

Having dealt with enough spaghetti code over the years (just a few of industry experience, and some more years of academia), I understand what Go's strengths are. It's an opinionated language that stops users from being too clever or writing code that's too complex. That said, I've always hated the trends that have brought Golang into popularity. The engineers I've felt who could benefit from Golang the most could al…

Developer productivity is overrated, or at least we have no concrete ways of achieving it. The person who approaches everything with a for loop and doesn't have to even consider whether to use a list comprehension, map and filter, or loop is going to be very productive simply because there is no choice to be made. This is only exacerbated in teams.

You're absolutely correct on basics, and those can't really be worked on unless devs are stripped of everything but basic constructs like the function. Rust and Haskell are too much for the average dev and maybe even good devs

Re: Go: Ten years and climbing

#42
I love Go for the concurrency and awesome cross platform support, but my biggest complaint about Go is still the forced GOPATH.

I know this is super nitpicky, but I like to keep work and personal code completely separate and changing GOPATHs is very frustrating.

With the introduction of `vendor` and software like glide and dep tool, you no longer have to store your sources in `$GOPATH/src`.

Since dep/glide are also required for sane dependency version management, there seems to be no benefit of using `src` over `vendor`.

Without `src`, is there any reason `GOPATH` is still required?

Re: Go: Ten years and climbing

#43
post #36
post #33

> Today, Go is the language of the cloud [...] Is that true? First time I hear of a dominance of Go in the cloud. (And what does it mean anyway -- any distributed app that runs on the cloud, or cloud infrastructure... such as?)

Infrastructure. Some example projects of the top of my head: Kubernetes, etcd, Docker, terraform, ...

They don't dominate anything though. And only half of those are for cloud infrastructure.

Re: Go: Ten years and climbing

#44
post #9
post #7

Earlier quoted context omitted.

At work we have recently started using Go. When I told one of my developer friends that I was doing some Go projects, he was confused and thought I meant "Pokemon Go". So yeah, you might have a point, sadly.

a developer who hasn’t heard of Go must live under some special kind of rock

Don't underestimate the echo chamber here in regards to language popularity.

I manage servers for an awful lot of developers and, from my conversations with them, I'd be surprised if I could say more than single digit percentage have ever heard of Go.

Re: Go: Ten years and climbing

#45
post #33

> Today, Go is the language of the cloud [...] Is that true? First time I hear of a dominance of Go in the cloud. (And what does it mean anyway -- any distributed app that runs on the cloud, or cloud infrastructure... such as?)

> Is that true? First time I hear of a dominance of Go in the cloud. (And what does it mean anyway -- any distributed app that runs on the cloud, or cloud infrastructure... such as?)

It isn't. It's like saying Ruby dominates the VM space because Vagrant uses Ruby. Sure there are a lot of orchestration tools written in Go, but look at the actual apps running in the cloud, how many efficient RDBMS written in Go widely deployed? worker queues? full text search engines? ETL solutions? streaming servers? or just actual apps users interact directly with?

It's the "Go is a system language" all over again. It's at best misleading.

Re: Go: Ten years and climbing

#46

Having dealt with enough spaghetti code over the years (just a few of industry experience, and some more years of academia), I understand what Go's strengths are. It's an opinionated language that stops users from being too clever or writing code that's too complex. That said, I've always hated the trends that have brought Golang into popularity. The engineers I've felt who could benefit from Golang the most could al…

Nobody is treating developers like toddlers. In corporate environment developers are paid to do what management wants. In more free environments developers can use what they want and if they are not using Rust/Haskell may be they do not find use for it.

Re: Go: Ten years and climbing

#48
post #42

I love Go for the concurrency and awesome cross platform support, but my biggest complaint about Go is still the forced GOPATH. I know this is super nitpicky, but I like to keep work and personal code completely separate and changing GOPATHs is very frustrating. With the introduction of `vendor` and software like glide and dep tool, you no longer have to store your sources in `$GOPATH/src`. Since dep/glide are also r…

I’m trying to not rely on GOPATH too, but how do you import sub packages? Are you supposed to put them in vendor too?

Re: Go: Ten years and climbing

#49

Earlier quoted context omitted.

Developers may not need the sophistication that you describing. In that case it's just wasted effort learning something that is more complicated. Are Docker and InfluxDB simple apps? What do you consider simple and what do you consider complex?

> Are Docker and InfluxDB simple apps? What do you consider simple and what do you consider complex? Docker and InfluxDB are investor funded organizations that contribute to open source. I'd argue that their success has more to do with the monetary input than anything to do with the language itself.

I don't understand your argument. You can't develop complicated GoLang apps unless you have tons of money? But you can develop complicated Rust apps without tons of money?

Re: Go: Ten years and climbing

#50
post #2

I took a seminar class in Go in my final year of school, in the spring of 2010. I was hooked pretty early. It was a very chaotic time to be writing Go; the language would change from week to week, so if we did a pull from the Go repo, there was no guarantee last week's assignment would still compile! At the time, the canonical way to compile code was by makefile: include $(GOROOT)/src/Make.$(GOARCH) TARG=bin/command…

I remember reading the netchan and thinking it would be so cool but it was gone by the time I started working Go. I figured I must have been imagining things.
Post reply on HN