
Go: Ten years and climbing - stablemap
https://commandcenter.blogspot.com/2017/09/go-ten-years-and-climbing.html
======
Karrot_Kream
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 also benefit by getting a better handle on their fundamentals and taking
a moment to design their codebase more. As a simple language to wire pieces
together, Golang is fine, but it really doesn't give you the tools (imo) to be
productive for anything more complex than simple apps. It's a great
alternative to JS (again imo), but not something I'd like to write.

We shouldn't need to treat the developer like a toddler to get them to write
safe code. I'm a much bigger proponent of languages such as Rust or Haskell
which give the developer the _tools_ to ensure their own data integrity, but I
guess that says something about me as a developer and why I don't like Golang.

~~~
why-el
> As a simple language to wire pieces together, Golang is fine, but it really
> doesn't give you the tools (imo) to be productive for anything more complex
> than simple apps. It's a great alternative to JS (again imo), but not
> something I'd like to write.

How do you address its popularity in the field of cloud computing then (which
I presume you would agree is pretty complex)? This was mentioned in ample
detail by Rob in the article. Is Kubernetes not a "productive" system by your
definition?

~~~
kenhwang
The language that appeals to the masses with low barrier to entry in a niche
always wins the popularity contest in that domain. I attribute it to herd
mentality; assuming skill has a standard distribution, the average developer
herd gets a massive head start.

You can see the idiot friendly language eclipse in popularity in other domains
too even though "better" alternatives exist:

\- elegant general purpose: python over ruby

\- web: php over python/rails

\- SQL databases: MySQL over Postgres

\- NoSQL: MongoDB over CouchDB/Postgres

Go's just the first mass appeal language in the concurrency performance domain
and it just opened the door to a lot of developers who before wouldn't dare
play in the space.

~~~
Can_Not
PHP has some unique design considerations that make it better suited for web.
PHP's main significant weaknesses for that domain would be the lack of a
strong type system, lack of strong event based server ecosystem (what reactphp
does, nodejs, golang, etc.), and it's slower than Java. It has multiple
popular long supported rails alternatives. Python and Ruby have nothing over
PHP for web development. PHP has the absolute best first class support for
isolated http request handling, live updating only challenged by erlang,
standard library designed entirely around webdev, great tooling for building c
extensions, widespread cpanel hosting, and composer (pip is garbage compared
to composer).

So while you might like ruby/python because it's prettier or because PHP 4 was
awful, the idea that one of them is a better web language is totally
laughable. If you asked me to define a language better than PHP for web
applications, I would have you a long list not even considering python and
ruby.

------
staunch
One of Larry Wall's slogans for Perl is _" Easy things should be easy, and
hard things should be possible."_ In its own way, that's what has made Go the
kind of success that Perl once was.

Perl was the glue language of the web and Go is the production language of the
cloud.

I'm actually a bit scared to imagine a world in which Go was not created,
given how much success I've personally had with it.

Thanks to the entire Go team.

~~~
kod
This is a bad comparison.

Core philosophy of Perl is to empower programmers with more than one way to do
it.

Core philosophy of Go is your coworkers are too stupid to be allowed to have
nice things.

~~~
aaron-lebo
Seems like the core philosophy of Go is the end result of Python's "there's
one way to do it".

The "Go's design and users are dumb" meme needs to die. It's not even a
constructive criticism. It's dishonest, insulting, and it's too bad grown
adults and professionals can't see beyond it.

~~~
peoplewindow
That meme isn't going to die because one of the creators of Go himself said it
was created for dumb users (sorry, Googlers "who can't handle a brilliant
language"). There wasn't any constructive criticism coming out of the Go team
towards these other languages, rather, they were simply "too complex" in a
general sense.

The creators have also strongly resisted adding features others consider basic
for a decade now, with a variety of nonsensical justifications.

It's a stretch to even claim Go was designed at all. From the very blog post
this thread is about, we find this statement:

 _Russ discovered—that 's the right word—that the generality of Go's methods
meant that a function could have methods, leading to the http.HandlerFunc
idea, which was an unexpected result for all of us._

Go is not exactly a complicated language to begin with, yet the designers
"discovered" things about it whilst building it.

Go gets a lot of criticism because it's an empirically very poor language and
its designers routinely say absurd things that invite ridicule, like "Go is
the language of the cloud" or "We have invented a GC for the next 20 years" or
"Go was designed for interns and students who can't handle brilliant
languages".

------
jff
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
      GOFILES=main.go
      
      include $(GOROOT)/src/Make.cmd
    

The thing I miss most is the netchan. I understand the reasons they got rid of
it ([https://groups.google.com/forum/#!topic/golang-
nuts/Er3Tetnt...](https://groups.google.com/forum/#!topic/golang-
nuts/Er3TetntSmg)) but when it worked, it was fantastic.

~~~
rjammala
Did you find any alternative implementation of netchan that you like?

~~~
gtirloni
Not OP but here's a recent discussion with some pointers:
[https://news.ycombinator.com/item?id=14878244](https://news.ycombinator.com/item?id=14878244)

------
chimeracoder
I've been writing Go professionally, full-time, for the past five years.

I'm a polyglot, so before Go, I loved exploring every new language I could get
my hands on[0]. I still do, for fun, but Go is the one language that has kept
me hooked all this time. It's not for any single feature, or for the community
(though that's a great part of it). It's because it's the only language which
I feel gets out of the way for me and lets me write powerful, robust, and
maintainable software quickly without having to think or struggle against the
tools.

For me, Go is like trying to do surgery wearing latex surgical gloves, instead
of wearing thick woolen mittens.

[0] Seriously: if you can name it, and there's a working Linux x86_64
compiler/interpreter for it, I've probably tried it.

~~~
smnplk
Out of curiosity, what is your take on clojure then ?

~~~
chimeracoder
> Out of curiosity, what is your take on clojure then ?

I have a lot of respect for Clojure, though I don't have much of a use case
for it.

At the time I tried it, I was annoyed its semantics for '() and nil - they're
sort of a hybrid between how Common Lisp does it and how Java does it. Which
makes sense - the Common Lisp approach would be a nightmare to implement on
top of the JVM while maintaining interoperability, but as someone whose
primary language before that _was_ Lisp, it was a bit weird to try and get
used to.

I love functional programming - before Go, Lisp did pay a number of my bills,
after all! - but to me it feels more like art than work. It's fun to figure
out the most elegant, Lisp-like way to approach a problem. It's fun to convert
an arbitrary task into a language-recognition problem and then write the
compiler to recognize that language as the implementation to the solution. I
get the same feeling from it that I do when I finish a drawing and stand back
to look at it. I don't want to touch it, lest I smudge it - I just want to sit
back and appreciate the finished result.

But it's a completely different kind of satisfaction that I get from writing
Go - there, the fun is in how quickly I can solve a problem, and how confident
I am in the reliability, robustness, and long-term maintainability of my
initial effort. That's where Go really shines for me, and it's not like the
joy of having created an beautiful work of art. It's more like the
satisfaction of having built a solid American Colonial house for yourself to
live in.

I like them both, but for my professional work, I'll choose Go every time.

~~~
sbov
So would you say this is more about your mindset when programming in LISPs? I
like to use Clojure for my side projects and don't seem to feel the same way
about my programs as you do. Even as a long time primarily imperative/OO
programmer (but who has tried pretty much every language out there, too),
Clojure actually feels like one of the most pragmatic languages I've used.

~~~
smnplk
It's the same with me. I didn't have any lisp experience before learning
Clojure. I see it as very pragmatic language, the kind that lets you get shit
done, it doesn't get in your way. But that said, I can understand why parent
compares lisp to art. I would say functional design is art, because you need
to put in a lot of effort to learn it.

------
Goopplesoft
> Russ discovered—that's the right word—that the generality of Go's methods
> meant that a function could have methods, leading to the http.HandlerFunc
> idea...more general ideas too, like the the io.Reader and io.Writer
> interfaces, which informed the structure of all the I/O libraries.

Big testament to great interfaces being hugely impactful. For me, the IO and
HTTP interfaces are a big part of why Go is so nice to use; the libraries
(including std) that emerged around those interfaces and their subsequent
interoperability makes everything so coherent.

Congrats to the Go team and their amazing work!

------
aomix
I appreciate the ruthless design choices behind Go. Crafting a language so
there are as few ways as possible, and preferably one, to solve a problem must
be beautiful at a large scale organization. In my experience java codebases in
big companies are nightmare factories because of the freedom you get from more
similar languages. The Go dream of having a single decent solution to a
problem instead of 20 that range from bizarre to really clever sounds like
heaven.

I wish I had more time to take a serious stab at learning it.

~~~
flavio81
>because of the freedom you get from more similar languages.

Is this lack of freedom a good thing?

~~~
ashark
The size of the language and the (more or less) one-way-to-do-things style
mean that reading someone else’s go—say, from a library you’re depending on—is
really easy. The chance you’ll run into language features you aren’t familiar
with (which can happen even to long-time writers of some larger languages) or
one of several competing and possibly now-deprecated 3rd party bolted-on
features making up for painful deficiencies in the base language (ahem,
JavaScript) or some nutty flow-obscuring “helpful” nonsense is low.

------
shrumm
My introduction to Go was pretty recent about 2 years ago and we went all in.
We had an internal tool that started out as a test MVP written in python.
Demand was growing fast so a year later it was an absolute mess of tech debt.
We knew a significant refactoring was needed and figured the best thing to do
was to just redesign and build from scratch. One of the guys had played with
Go in his spare time so convinced all of us to just try it. Best decision
ever, at least for this use case where we needed speed and stablilty. Go's
native concurrency features were an absolute joy. It's really opinionated too
so it ended up very convenient to use as a team with different coding styles.
Thank you Go team!

~~~
pointytrees
I sometimes feel crummy to force my preferences on other developers I bring on
board. For example, most of my work is PHP, so all of our repo's use spaces,
and braces on newlines. When a new dev comes on board, they must follow that
format. Funny thing is with GO, I don't mind in the slightest that go fmt . is
tabs and braces on the same line. What is so much more important to me is
consistency. Go has done a stellar job at providing consistency. As I read
when I was getting started, no one loves gofmt's formatting, but everyone
loves gofmt.

~~~
mathw
I have mixed feelings about the language itself, and some of its tooling
(GOPATH just makes no sense to me whatsoever, and I've not spent enough time
hacking Go projects to understand why it wouldn't be better to just have
something like Cargo to handle dependencies), but I firmly believe that go fmt
might be the biggest contribution to the language tooling world I've seen for
a long time.

We've had autoformatters before, but they were always customisable things,
sparsely used. Go shipping a formatter with the core distribution? Go projects
routinely adopting it as a requirement for contributors? One standard format
defined from the start?

Knockdown stuff. All those pointless arguments about coding style, gone. All
that worrying about how to lay things out, gone. Just run go fmt and move on.

I have now become entirely reliant on rustfmt when I'm writing Rust, and I
love it. I just write a total horrible mess, press save and it magically
becomes neat and lovely.

I wish I had something that powerful operating in my C# environment at work.

Admittedly, at the moment I also wish my C# environment at work wasn't laden
with iron-clad layout rules that the tooling isn't capable of fixing for me.
All private members must be after the public ones, but static private ones
need to be before the instance ones, and all properties go first regardless of
accessibility (although remember the private properties have to go after the
public properties). And usings must go inside the namespace definition, in
alphabetical order except System.whatever, which all come first (in
alphabetical order). And you can't split a function argument across multiple
lines unless it's a lambda. Microsoft's C# style guide? What's that and why
would we care and no it's not prescriptive enough anyway.

It's enough to make your head spin. Good thing I'm only there for six more
days.

Give every language a formatter, as standard, and let's just be done with it.

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

~~~
DelightOne
Completely separate = dont allow dependencies between or one is base and
second auguments and depends on base or dont allow changes to one of them?

How would your ideal system look like? What is your use case?

Sidenote if it helps there is a default gopath location if its not defined:
[https://golang.org/doc/go1.8#gopath](https://golang.org/doc/go1.8#gopath)

~~~
ubercow
My ideal system is: clone a repo, run `go restore` to fetch dependencies and
then `go build` to spit out a binary or `go run` to quickly start the main
function.

Nothing from outside the repo can effect that build. Likewise anything inside
the repo can’t effect the outside.

Compartmentalizing each project makes builds more reproducible and more
obvious. If anyone else clones the same repo and runs the same commands, they
should get the same result.

~~~
jff
We actually do this at work; our repository is a full GOPATH layout with
subdirectories for src/, test/, doc/, etc. We vendor our dependencies. To
build, we have scripts at the top-level that compile all of our components (we
ship a whole suite of tools in a single repo), run go vet, run tests, etc. The
user never needs to set GOPATH. It's not a perfect system, but we've been
using it for 3+ years without too much trouble.

------
artursapek
I wrote my first fibonacci sequence test program in Go about four years ago.
Now I am full-time admin of a large real-time cryptocurrency charting website
that pushes 30MM+ messages to clients per minute, written entirely in Go.

I've learned a ton about programming from Go and I'm not sure I would have
managed to build the system at all with another language. Go gets a lot of
flak for its simplicity, but what it does it does very well. The concurrency
model, networking packages, tooling, and simple deployment make it a joy to
work with and I owe a lot to the Golang team. Happy birthday!

------
yumaikas
I've been using Go on the side since mid-late 2013, so not nearly as long as
some here, but I was heavily impressed by both Goroutines and channels as
ideas, and by the net/http library.

The general portability and simplicity of the language has made it nice for
side-project work.

I've since used go to write a blog engine, several APIs for school projects,
and have been working on a scripting language (pisc.junglecoder.com).

------
baby
I love Golang, but I'll just comment on that:

> It's worth stating that the language is called Go; "golang" comes from the
> web site address (go.com was already a Disney web site) but is not the
> proper name of the language.)

You already have a hugely popular game called Go (WeiQi/Baiduk). It just adds
confusion to queries to call the language Go instead of Golang. Even the #go
channel on freenode has a disclaimer that it's not about the language. It's
like calling your language football.

~~~
IshKebab
To be fair many simple names are overloaded. Amazon, Rust, C, Python, ... even
football. It's normal.

~~~
jff
Don't forget Java, Pascal, Ada, Lisp, Algol, Basic, Ruby, Awk...

By this metric, the best programming languages are Perl and Fortran.

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

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

~~~
ecnahc515
But you could argue ruby dominates the DSL space, which is effectively what
Vagrant is. A DSL around creating VMs. Same for chef and puppet , but more so.

------
gramakri
Not a Go programmer myself but I am very grateful for Go. Some of the best
software I use everyday uses Go - rclone, gitlab, gogs, gosu, docker to name a
few.

~~~
camus2
> gitlab

is written in Ruby.

~~~
gramakri
Gitlab's reverse proxy is written in go - [https://gitlab.com/gitlab-
org/gitlab-workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse)

~~~
camus2
And Gitlab server, the actual app, is written in Ruby.

------
christophilus
I evaluated Go a few months ago for a web project, but it seemed as if there
was a lot of manual work involved in mapping objects in and out of a MySQL
database and in and out of JSON (basically, 50% of my day-to-day back end
work). It just seemed too arduous.

The second thing that bothered me was that an edge-case bug in one of my HTTP
handlers paniced the app. If that had happened in production while under load,
many users would have gotten an error due to a bug in one user's request.

So, serious questions:

\- What is the best way to map objects to/from JSON? \- What is the best way
to map objects to/from a database? \- What is the best way to prevent a
request from crashing the server and killing a bunch of unrelated requests?

~~~
pbohun
Here's an example I wrote up for to/from json:
[https://gist.github.com/anonymous/8487446a2fd908910c66a2aafb...](https://gist.github.com/anonymous/8487446a2fd908910c66a2aafbe7b1ef)

Admittedly, mapping objects to/from database entries is a bit more
complicated. There are several ORMs out there or you can role your own.

~~~
christophilus
Yeah. The repeating the field, only camelCased, in JSON annotations feels
needlessly painful to me. Subjective, I know, but that kind of painfulness
seems pervasive in my (brief) dabbling with Go, and is one of the main reasons
I moved on.

~~~
pbohun
The json annotation is optional, but very powerful since it allows you to set
the mapped name of the field to any name you like, allowing you to map json
fields with snake_case, CamelCase, kebab-case, etc.

------
cutler
For a language that's been around for 10 years Golang's adoption rate is still
pretty low. Searching Indeed.co.uk's API by job title there are currently 25
Golang jobs in London compared with 29 Perl, 188 Ruby and 511 Python. For the
UK as a whole it's 34 Golang, 57 Perl, 276 Ruby and 821 Python. Golang has a
long way to go yet IMHO.

~~~
kayoone
Which language released in the last 10 years is more popular then ? Golang is
arguably niche and does not offer the huge flexibility and ecosystem of say
Python, so i am pretty sure it will never come close to that, but there are a
good number of usescases where it arguably is the best choice.

~~~
cutler
Scala, with 164 jobs in London and 225 nationwide, has been around for about
the same time as a production-quality release. I raised the point because I
think Golang's coverage on HN is disproportionate to its significance in the
job market.

~~~
snaky
London is about 'fintech', so Scala is in great demand. SF Bay Area is about
'webscale' so Go is popular, as it established as The Cloud Automation
language. And HN crowd is mostly leaning to SF. OTOH you wouldn't find a great
demand for Oracle DBA or C# skills in The Valley, and that's not because they
are not in great demand somewhere else - maybe even basically everywhere else
like C#.

Places lean to some niche or other, and vice versa. Apple places its growing
hardware teams in Texas despite new campus in The Valley and all that. Why?
Because Austin is very much hardware place.

------
lucidone
Maybe I'm spoiled, but I've had a hard time dipping my toes into Go due to the
lack of batteries included frameworks (like Rails or Laravel). Can anyone
recommend some resources to give it another shot?

~~~
m_sahaf
It's been a while since I used it, but Revel[0] is almost within the same
family as Rails. The developers of Revel say they're inspired by the Play
Framework.

Another option that looks nice is the Buffalo[1]. It's a collection of
libraries that are built to play nice with each other, but you don't have to
use all of them as a bundle. You can use only the layers you want.

[0] [https://revel.github.io/](https://revel.github.io/)

[1] [https://gobuffalo.io/docs/getting-
started](https://gobuffalo.io/docs/getting-started)

~~~
lucidone
Exactly what I was looking for. Thanks!

------
fowl2
Woah! How time flies!

Somehow still no one I know knows what Go is!

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

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

~~~
choward
A rock with ".NET" written on the side of it.

~~~
pmarreck
ah, "microsoft people." Left that rigorously-walled garden a long time ago
without looking back... it was the right move for me.

------
throw2016
No other social or professional setting tolerates this kind of brazen self
importance and posturing seen here without mockery.

This site doesn't allow satire but looks the other way when snarky claims are
made without evidence. Blanket assertions must be backed up. At least show the
problem you were trying to solve and the new solution in your favoured
language/tool/framework so it can be judged.

This is how bad ideas and complexity gain traction without scrutiny and push
back. People become vested in Ruby and run down php, people become vested in
Rust and run down Go, people become vested in React and run down jquery. How
comes tools people were using happily just yesterday are suddenly 'completely
unacceptable'?

No one who befitted from these tools and languages is going to run them down
publicly because they found something better. This is self serving ecosystem
marketing at work that HN seems to ignore. It's as if every self
congratulatory commentator often seen here was born an expert and short
circuited the process of learning, and can use this platform to run down
everyone else and their choices.

------
didibus
Go is the new Java, and I think everyone will have to come to terms with it.

~~~
pjmlp
Not until it catches up with Java regarding language features, UI toolkits, DB
drivers, graphical debuggers, clustering monitoring tools.

Meanwhile most commercial JDKs do actually offer AOT compilation, with OpenJDK
9 intoducing it as well.

------
gilbetron
Holy hell, Go is ten years old. 2007 was ten years ago. I'm so happy I have
some Buffalo Trace whiskey sitting next to me :/

~~~
gilbetron
Downvotes? Because I'm old? This wasn't a dis on Go, just that I think of it
as brand new, and it is 10 years old :/

------
iainmerrick
It's funny that the very first thing discussed is the name. "Go" always seemed
like a bad idea, being hard to google for -- and while they were employed by
Google, no less!

It fits with the love-it-or-hate-it nature of the whole language.

~~~
pointytrees
I find searching for things with go quite often brings up what I need anyways.
When I'm unsure or hit a snag, I'll include the term golang. Have not had many
problems searching for stuff.

------
real-hacker
I remembered my experience learning Go: reading Go language spec for about 2
hours and start being productive. That is not quite possible with other
languages, I am afraid.

------
cpfohl
My favorite line: "Go is huge in China". My first thought: don't they mean
Weiqi!?

~~~
spraak
Too bad for the downvotes, that's a good joke

~~~
cpfohl
It wasn't even a joke . But meh, fake internet points don't do it for me. A
change in points is how I know to look for responses to my comments.

------
hanselot
To apply for this position you require 12 years of Senior Experience in Go and
Cobol.

------
kmicklas
Go is actually 50 years old in terms of design insight.

~~~
mdanger007
Success in technology means someone posting on a forum how it's not actually
new. (May all our products be so successful!)

------
evolighting
Google is there and that why Go is there. Trust me,you could never go against
google's will

