
Nine years of Go - guessmyname
https://blog.golang.org/9years
======
ilovecaching
I've written a _lot_ of Go, I started four years ago when my workplace at the
time wanted to ditch writing web services in Ruby. We were very deep into
containers, so the obvious choice to the team lead was to do what the Docker
folks were doing.

My take is that Go is a great language when you're working with incompetent
people. It's so limiting in the abstractions you can build with it, that it is
very difficult to write code that is not immediately obvious in its purpose.
Go is easy to teach, easy to review, and it's so syntactically deficient and
the tooling is good enough that it's hard to bikeshed. This ultimately
improves the experience of writing code at work, and its static type system
makes it easier to reason about large code bases for the folks who are used to
using Ruby and Python at scale.

But Go is also awful in so many ways, its such an obvious step backwards in
its design and the community is so dogmatic about Go and the Go authors.

On large code bases you almost invariably end up working around the
deficiencies with the empty interface, code gen tools that add non standard
syntax, and lots, and lots of copying code and code patterns over and over
again. Any common pattern you see emerge, that you'd like to create a generic
structure for, is probably impossible to encode without type variables. Go
also notoriously pushes many errors that would have been caught at compile
team to runtime because of its weak type system. With Sum types, it's
difficult to make improper states illegal, and default values lead to subtle
bugs because they essentially behave as predictable garbage.

Go honestly keeps me from having faith in software engineering as a craft.
It's the acceptable of the status quo, or worse, moving backwards in order to
fit the needs of the lowest common denominator.

~~~
codeslave3422
"My take is that Go is a great language when you're working with incompetent
people. It's so limiting in the abstractions you can build with it, that it is
very difficult to write code that is not immediately obvious in its purpose."

Do you think this is intentional? Similar to how java is incredibly
restrictive, and thus great for corporate programming environments?

~~~
pjmlp
“The key point here is our programmers are Googlers, they’re not researchers.
They’re typically, fairly young, fresh out of school, probably learned Java,
maybe learned C or C++, probably learned Python. They’re not capable of
understanding a brilliant language but we want to use them to build good
software. So, the language that we give them has to be easy for them to
understand and easy to adopt.”

\-- Rob Pike

~~~
AtomicOrbital
this philosophy really shines when my golang compile time is super fast -
especially compared to say c++ which is just an abomination

~~~
pjmlp
Yet Turbo Pascal for MS-DOS, with more features than Go has currently, did
already have faster compile times on those clunky 8086 CPUs, let alone on
modern 21st century hardware.

Fast compilation times in Go are only a surprise for a generation that never
used native programming languages with native support for modules.

As for C++ compilation times, yes they are an abomination when doing _make
world_ from scratch, including third party dependencies, with heavy template
code.

However modules are around the corner and they were just voted into C++20.

~~~
flavio81
>Fast compilation times in Go are only a surprise for a generation that never
used native programming languages with native support for modules.

This.

------
pcx
In the last 3 months, we have built the new version of our API in Golang, the
old one was in rails. The api serves a mobile app and a web app.

Despite taking longer to build, it's a treat to work on Golang. The explicit
error handling and static typing have made our code much more reliable, with a
lot less unit/integration tests required. Concurrency is dead easy to
understand and build over. We are OK with using dep, definitely miss a
debugger or an REPL. Having generics would make it much easier to write code.
But overall it was worth it. Our response times are much lower now with a lot
less server nodes required.

~~~
purple_ducks
> definitely miss a debugger or an REPL

Bizarre that a programming language designed by non first time language
designers, backed by a multi-billion dollar company and used extensively
throughout that company(by "new" engineers), doesn't have a world class debug
story.

~~~
wrycoder
The most effective debugging tool is still careful thought, coupled with
judiciously placed print statements.

    
    
            — Brian W. Kernighan, in the paper Unix for Beginners (1979)

~~~
oblio
And the most effective car crash prevention system (for now) is the human
brain, yet I still want a seatbelt, airbags and good brakes on a car.

Having a debugger available does not drop your IQ by 20 points.

~~~
comex
> Having a debugger available does not drop your IQ by 20 points.

Not necessarily, but it _can_ have that effect. Sometimes I spend a long time
in the debugger, following the chain from effects to causes to the causes’
causes and so on, getting a little dopamine hit every time I uncover a new
level – it’s exciting, like watching a detective show – and ultimately
discovering the root cause… only to have it be something dumb or obvious,
something I might have found in less time by just patiently rereading the
code.

~~~
oblio
You can just not use the debugger...

------
CSDude
I love Go, used it a lot for over 3 years. I love the simplicity, directness,
the inline structs, but I still cannot get out of the package management mess.
I can even tolerate `if err != nil, return err` and do not care enoguh of
generics, but I hope Go modules and Go 2 would fix, over the time, it has
really become a love-hate relationship for me. My daily driver at work is Java
and some Python, I really miss the tooling (of course, not runtime
classnotfound errors) and maturity. Not ignoring the success of projects with
Go, such a big one as Kubernetes, I think it is a whole different aspect, but
Go started to tear me out through the years, and it is hard to defend it.

~~~
the_clarence
There is no better way to do errors imo, unless you're going the erlang way of
"let it fail". Errors can be passed to the caller the same way exceptions are,
and it becomes an endless pursuit of where the error is actually being handled
(if at all). I agree that some syntax sugar helps, see Rust, but it doesn't
completely fixes the problem.

~~~
nvarsj
It's baffling though that the compiler doesn't at least warn when you forget
to check the err. So many edge cases with that (especially due to `:=` vs `=`
if reassigning a prior err).

~~~
AlexCoventry
Try gometalinter. [https://stackoverflow.com/questions/43898074/is-there-a-
way-...](https://stackoverflow.com/questions/43898074/is-there-a-way-to-find-
not-handled-errors-in-go-code)

~~~
thegeekpirate
Specifically (if wanted standalone)
[https://github.com/kisielk/errcheck](https://github.com/kisielk/errcheck)

~~~
AlexCoventry
Personally, I like my linter output in the style of a furious fruit salad, so
I go for the kitchen sink.

------
germanyhater
I prefer to use .NET Core / C#. It is very fast, async, cross-platform, open
source and unlike GO, it is a high level programming language. One
disadvantage is that compilation time is not as fast as with GO, but it was
improved over the last years.

~~~
PunchTornado
> unlike GO, it is a high level programming language

what is high and low level depends very much on the context, but I don't see
GO to be lower level than C#...

~~~
pjmlp
Lack of support for generics, enumerations, dynamic, FFI marshalling,
expression trees, LINQ, exceptions, match expressions, ....

~~~
PunchTornado
some of these are not present in other high level languages like PHP,
javascript and you don't call them lower level...

~~~
tigershark
PHP and JavaScript are not statically typed. What would be the use of generics
in there? Obviously for the same reason you don’t need the dynamic keyword. As
for LINQ at least in JavaScript you have it, either integrated in the language
with map, filter, reduce or using some library like lodash or Ramda. You don’t
have expression trees but you don’t really need them given the highly dynamic
nature of the language, although not at the same level as ruby if I remember
correctly. JavaScript has exceptions, so here I’m really not sure what you are
speaking about. For FFI marshalling (that for sure I would not call high level
feature) there is webassembly. Match expressions are present in JavaScript and
obviously you can’t have exhaustive pattern matching like in typescript
because of the lack of types. Even in that way it’s pretty comparable to c#
switch case. So to me it seems that at least JavaScript has all the features
listed in the gp, why you are convinced of the contrary?

------
jungler
I'm in the process of evaluating Go-raylib for a fantasy console project in
lieu of Love2D. The basic rationale is:

* I only need inner loop high performance - it's a fantasy console, and intentionally limited. It will have some C code, but I don't want to write a lot of it.

* I want the project to be easy to build with few external dependencies(raylib is tops at getting this right)

* I want static types and zero-indexing for the "OS layer" part, at least, since I have to build some original data structures for IDE functionality(e.g. there will be a text editor).

It was the last part that made me switch away from Lua, and then it was the
first two that made me consider Go.

~~~
pasabagi
I think the problem is the ffi overhead to C from Go is really high, like, way
higher than any comparable language, because of the segmented stack thing. I
mean the nice thing about Love2d is that LuaJIT has the best ffi overhead when
calling C.

[https://github.com/dyu/ffi-overhead](https://github.com/dyu/ffi-overhead)

~~~
pjmlp
It always felt strange to me the CGO approach, instead of what many compiled
languages offer, e.g.:

    
    
        function exit(code: integer); external;  cdecl;
    

No need to have two phase compilation or run external tools.

------
auvi
just wondering, what are some well known Go projects? I know docker is one.

~~~
ainar-g
* Kubernetes: [https://kubernetes.io](https://kubernetes.io)

* Hugo, a static site generator: [https://gohugo.io](https://gohugo.io)

* Gogs, a git service: [https://gogs.io](https://gogs.io)

* Syncthing: [https://github.com/syncthing/syncthing](https://github.com/syncthing/syncthing)

* CockroachDB, a scalable SQL database: [https://www.cockroachlabs.com/](https://www.cockroachlabs.com/)

~~~
coder543
Gogs has been succeeded by Gitea[0], as I understand things.

[0]: [https://gitea.io/](https://gitea.io/)

~~~
KaoruAoiShiho
My last post on Gogs and Gitea:
[https://news.ycombinator.com/item?id=17006872](https://news.ycombinator.com/item?id=17006872)

~~~
coder543
There are a lot of conflicting opinions, even on that thread.

It would be nice if someone wrote an article that did a deep dive on the
current state of both of them.

Looking at Git activity, I can clearly see that Gitea is _more_ actively under
development by every metric.

However, since they are now divergent code bases, what does Gogs offer that
would make someone inclined to use it over Gitea?

------
the_clarence
What happened to the weird tire logo?

