
Eight years of Go - spacey
https://blog.golang.org/8years
======
nine_k
Go is an example of how to be extremely successful by catering to the needs of
the project's core audience (well-rounded stdlib, extremely fast GC, short
build times, trivial deployment, etc) while paying much less attention to the
vocal minority's complaints (generics, package system, etc).

~~~
hood_syntax
Are the complaints about lack of generics really a minority thing? Writing
separate functions to sort different types just strikes me as ridiculous.

EDIT: My original tone was a bit nasty in retrospect. Did a little research
and while I still am on the generics side, the current situation seems at
least workable for a good number of use cases.

~~~
ori_b
But you don't need to do that. It's a bit clunkier than generics, but it's
usable: [https://golang.org/pkg/sort/](https://golang.org/pkg/sort/)

~~~
pcwalton
You're still writing separate functions (implementations of sort.Interface) to
sort different types.

~~~
ori_b
But this is something you often need to do for any non-trivial type, even with
generics. There's a reason that C++ std::sort<> takes a comparator, or why
Rust requires you to implement the 'Ord' interface.

Again, it's a little clunkier in Go, but not unusably so.

~~~
pcwalton
You need to define how to order things in other languages (though not in
languages where you can automatically derive implementations like Haskell or
languages with built-in polymorphic comparison like OCaml) but you don't need
to define how to swap elements over and over.

~~~
ori_b
Yes, I'm aware. That's the clunky part that I was referring to (although, you
can still avoid it for slices, and simply pass a single compare function.)

Go is far from my favorite language, but the sheer amount of bad criticism by
people that clearly don't use the language annoys me.

------
brian-armstrong
Go is woefully missing some really key features, which you encounter when
tuning it for high performance. My list of grievances:

\- Dep handling was never considered. Makes sense given Google's monorepo but
thats not how the world works.

\- Stdlib just loosely wraps posix features with many C flags copied verbatim.
These APIs are old and could use a refresh but Go never bothered.

\- No easy way to construct arenas/pools. Once you go down this route you have
a great headache of releasing in the right places. The GC doesn't cut it, you
need pools sometimes

\- Debugging basically doesn't work on some OSes. No easy way to attach gdb
and see what's happening. Doubly so if you use Cgo

\- Similarly, Go doesnt bother to hide the differences of different OSes. Up
to you as the programmer. Again not surprising for Google's all Linux world.
If everything is Linux then OS difference doesnt matter. But even Python does
a better job here.

\- Logging is poorly thought out as evidenced by multitude of third-party log
packages. Anemic compiler means you can't get verbose logging without paying a
performance penalty.

\- No RAII. Defers are a lazy attempt at this, but they're not even close to
being as good as RAII. This is probably the biggest point where you realize Go
can't dethrone C++

\- Tricky Close() semantics force you to architect entire program around who
will close() things at end of their lifetime. Lots of terrible hacks ensue
when people build something that works but realize close ownership is
ambiguous and rightfully don't want to rebuild it all

\- Channels don't have a good way to deal with errors. You're forced to come
up with an ad hoc solution to deal with your graph of goroutines/channels when
one node errors

\- No supervision tree. Erlang existed far before Go but they didn't learn
from this key feature. But it would greatly enhance Go to have it

\- Hacky reflection semantics that cause subtle runtime bugs when a JSON
struct field's name starts with a lowercase letter. And of course, there are
no generics, the larger issue here.

I was hopeful that Go would fix some of these things before it went 1.0 and
locked in its syntax. Sadly that didn't happen as it was likely already locked
in at Google. Go is ultimately kind of brain dead, useful for some very
particular features but not so compelling that it can replace any other
language.

~~~
cube2222
Why would you want a supervision tree?

This would suggest using an actor-like model, which is pretty senseless for
single-machine usage. It's totally understandable for Erlang, where the VM
spans multiple machines, so everything is unreliable, but in Go, I take it for
granted, that my goroutines won't "just crash".

I'm not sure, but I think this also ends up being good for modelling
interactions with good performance, as you know where you do network calls,
where you have reliability, and where you have instant local calls. Though not
to say that Erlang applications aren't blazingly fast too.

~~~
dozzie
> It's totally understandable for Erlang, where the VM spans multiple
> machines, so everything is unreliable, but in Go, I take it for granted,
> that my goroutines won't "just crash".

Supervision tree gives a structure to put whole subsystems somewhere,
including their boot initialization and shutdown (not just restarting it at
crash), allows to spawn workers while keeping usual logging/crash monitoring
_for free_ , gives a way to inspect the system _at runtime_ (much easier
debugging), and allows to run several different applications in the same VM
space, which is a flexible way of combining code. I can, for instance, run a
CouchDB instance with bolted on my own HTTP server that exposes monitoring
data or an administrative interface. It cannot be done in Go (or any other
language, barring maybe Lisps) _without modifying source code_.

And no, none of this "spans multiple machines", it all works and helps on just
one single node. Maybe except for debugger, where you spawn a shell node from
which you operate.

And yes, your goroutines will "just crash" in situations you haven't expected,
as every non-trivial daemon experiences crashes on transient bugs. Though in
Erlang transient bugs don't bring the whole daemon down. Saying `my goroutines
won't "just crash"' means `my code and code I use as libraries doesn't have
bugs, ever'.

~~~
cube2222
No, it's saying: if my goroutines crash it's the same as if my main thread
crashed, which means: game over, application down.

Which gets handled by the container scheduler

~~~
dozzie
So every unrelated request that happened to be currently processed is thrown
away because of a rare corner case, and with no way to intercept shutdown and
save state, flush buffers, or anything. Yes, totally right granulation.

Not to mention that you have just introduced a very complicated piece of
software to run a single daemon.

~~~
Vendan
Or, you just catch the panic in a defer up the call chain, log the error, and
then exit that goroutine. Like:
[https://golang.org/src/net/http/server.go#L1694](https://golang.org/src/net/http/server.go#L1694)

------
noncoml
Things I love about go:

1\. Probably the best ecosystem out there.

2\. Go routines

3\. (Enabled by (2) actually) `defer`

4\. That I can add interfaces implementations to structs I don’t own

5\. No exceptions.

Actually (5) is one of the few things I don’t like about Haskell.

If Go had ADTs and generics it would easily be my favorite language.

Edit: and of course the channels.

Edit2: yeah, i have no idea why i connected (2) and (3). Had just woken up. No
idea what I was thinking.

~~~
solox3
Novice here. Why is having no exceptions a good thing, in your opinion?

~~~
nine_k
For exceptional, unforeseen situations you do have exceptions, aka "panic".

For signaling error conditions that the caller _has_ to expect and handle, you
have the `result, err = func(...)` idiom, and a compiler that would warn you
if you forget to use the value of `err`.

If Rob Pike's opinion on this is not enough, here's Martin Fowler saying
essentially the same thing:
[https://martinfowler.com/articles/replaceThrowWithNotificati...](https://martinfowler.com/articles/replaceThrowWithNotification.html)

In general:
[http://wiki.c2.com/?DontUseExceptionsForFlowControl](http://wiki.c2.com/?DontUseExceptionsForFlowControl)

~~~
pcwalton
Go does not warn you if you forget to handle an error. It only does so if the
function in question also returned a value that you're using. There exist
important functions that don't return non-error values and report errors that
you very much would like to avoid dropping on the floor: os.Chdir() for
example.

~~~
garfij
While this is technically true, I've considered `errcheck` to be standard
tooling for what feels like forever now, and it does exactly this; make sure
you're checking your errors.

------
kown223
For me Go is amazing, is my first language where I don't need a virtual
machine or interpreter to compile to machine code, C++ is OK but not for day
to day web.

Changing something then having to wait 40 seconds for java to recompile drive
me crazy, also same for tests. Yes would love to have a package system, but is
coming.

~~~
MrBuddyCasino
Java has some flaws, but slow compilation is not one of them. Incremental
compilers are available and pretty much eliminate pauses.

~~~
dilap
Really? I've recently been recruited to pitch in on a Java project, they're
using maven, and the compiles sure aren't incremental.

What should we be using instead?

~~~
therealdrag0
Eclipse or IntelliJ IDEs will compile while you code (like C#). Depends on the
project setup and dependencies. But I've found that this works for most
development until I need to produce an artifact. Then I run maven which does a
lot more than just compile code and usually is longer than 40s.

~~~
dilap
Yeah, having to run a whole IDE just to get incremental compilation is pretty
annoying tho. Perhaps I should just bite the Java bullet and try to use
IntelliJ.

------
indescions_2017
> every single cloud company has critical components of their cloud
> infrastructure implemented in Go

And this is how the "network effect" propagates. As the customers of cloud
services also begin to experiment in Golang. And discover the holistic
ecosystem of distributed systems packages.

Even Blizzard with its massive C++ codebase is gaining converts

[https://youtu.be/Az5F4lwSljI?t=23m50s](https://youtu.be/Az5F4lwSljI?t=23m50s)

~~~
mrep
That source just mentioned a few popular open source projects and provided no
sources citing actual cloud providers using it in their backend
infrastructure.

------
mfrw
Simplicity is the Ultimate form of sophistication -- Leonardo da Vinci

The quote fits perfectly for the design of go.

~~~
nv-vn
I think it fits better for Scheme or Forth. I would not describe Go as simple
at all relative to those languages.

------
mtgx
Can you do something about Golang's performance on Arm servers? It seems to be
terrible compared to x86 performance:

[https://blog.cloudflare.com/arm-takes-wing/](https://blog.cloudflare.com/arm-
takes-wing/)

This would have a positive impact on Google, too, as the more server chip
competition there is, the cheaper it will be for Google to buy those chips for
its cloud services.

------
davidkuhta
way to go, Go!

Just to accentuate some of the neat things you can do with Go, watch: 'Can you
write an OS Kernel in Go?' from the Golang UK Conf.
[https://www.youtube.com/watch?v=8T3VxGrrJwc](https://www.youtube.com/watch?v=8T3VxGrrJwc)

~~~
bitmapbrother
That was seriously impressive.

------
hellofunk
I find myself wondering how important the "fun facts" are in this fascinating
thread about Go:

[https://twitter.com/pasiphae_goals/status/923820615022399488](https://twitter.com/pasiphae_goals/status/923820615022399488)

~~~
spraak
Some of those things are true and annoying, while others are exaggerations,
and the rest are just wrong. That thread is poor taste.

~~~
vvanders
Yeah, they are (and the author admits as much) but I found

> Fact #38: go is supposedly a garbage collected language, but it has not once
> deleted itself nor any of my code.

pretty hilarious.

~~~
spraak
Yeah actually that's really funny.

------
stablemap
A post earlier this year by Rob Pike, celebrating ten years of Go:

[https://commandcenter.blogspot.com/2017/09/go-ten-years-
and-...](https://commandcenter.blogspot.com/2017/09/go-ten-years-and-
climbing.html)

~~~
weberc2
This blog post is 8 years since Go was an open source project. Rob's post was
probably something like "10 years since we began work on Go".

~~~
stablemap
Yes, I didn’t mean to imply a contradiction. Just two articles that go well
together.

------
dogruck
In honor of the exponential, I wish the conclusion was “Thank you, and here’s
to sixteen more years!” :-)

------
fithisux
I use golang since 2010. My only complaint is that they dropped gxui. So I use
golang mainly for cli utilities. The other options (I do not like javascript)
are ill-maintained. For me it is more important than generics.

------
KarlAuer
eight years a-go? :)

------
shkkmo
Go's biggest issues still seems to be the lack of a standard mature dependency
management system.

~~~
cturner
Could it be a strange mindset of our time that we look to language ecosystems
to provide this? What if we could manage dependencies without being locked
into language?

Conda goes some way. Think of something like virtualenv, but not specific to
python. I would be happier with something that had fewer features than conda,
but where critical features were easier. Example: setting up a package server
should be trivial.

I think we do not yet have the git of dependency systems, with the gravity to
draw in the community and for people to regard it a solved problem. Maybe the
most efficient route would be: find a way to get Linus pissed off about it.

~~~
hikarudo
How about Nix, could it be the 'virtualenv, but not specific to python' you
mentioned? I've never used it, but from what I understand that would be an
appropriate description of Nix.

