
Go Turns 10 - kevinconaway
https://blog.golang.org/10years
======
timothycrosley
And yet it still feels like a language out of the 60s or 70s. To me, Go feels
like the programming language equivalent of insisting that everyone
communicate just by grunting because it's less complex to teach people just
grunting than it is to teach them more effective forms of communication. And
in theory, they still can communicate all the same things with more grunting!
Some people refer to this as simplicity, and in a way it is, but it's
simplicity in the language constructs at the expense of more complexity in the
usage of the language to form more complex thoughts. There must be a golden
balance here, but I don't feel like Go is it for all the fanfare it has been
getting lately.

~~~
badrequest
Any specific complaints, or did you just feel like calling us all
cavedwellers?

~~~
srparish
\+ By declaring a field/variable []Thing vs []*Thing you get different for
loop semantics. Way to easy to think your mutating the array item, but only
mutating a local copy or vice versa. If you change the field/variable you need
to audit all your code to make sure you haven't broken things.

\+ gofmt feels way out of date. These days clang-format (c++), prettier
(typescript), black (python), scalafmt (scala) take care of
wrapping/unwrapping lines such as function definitions or function calls. They
basically cover all formatting needs so you never have to manually format
anything.

\+ Scope of element in for-range loop isn't right, so capturing that scope in
a lambda does the wrong thing with no warning.

\+ Encourages use of indexes; which is error prone, most modern languages
allow writing most code without needing indexes using map/filter/reduce or
comprehensions.

\+ No help from type-system for use of pointer without nil check.

\+ Very easy to get nils in places one would hope to be able to prohibit them
in. EG Using pointer as a poor man's unique_ptr<> means that I also get
optional<> symantics (without the type checking) when I don't want or expect
such. Also allows for aliasing when I don't want or expect such.

\+ Difference between '=' and ':=' is silly, especially since ':=' can be used
to reassign values. Even more frustrating that ':=' creates shadowing in
nested scopes, so doesn't always do what one would expect it would do, such as
accidentally creating a shadowed 'err' that doesn't get checked.

\+ if/switch should be allowed to be expressions, allowing much safer single-
expression initialization of variables, rather then requiring default
initialization and mutation, which is much easier to get wrong.

~~~
gameswithgo
I actually like Go's simplicity a lot, it was very easy for me to learn and
very easy to programming with it because of that. But I agree strongly with
some of your points. = vs := specifically feels like a plain mistake, and even
against Go philosophy of having just 1 way to do things.

I think any new language should be designed around options instead of nils.
F#, Rust, Zig show different ways to do this, and often any performance
penalty can be compiled away.

if/switch being expressions is a simple and helpful idea, languages should
allow this.

using map/filter/reduce as the idiomatic way to do things I am less sure
about. This can come in handy but also would add a lot of complexity to Go,
and in most languages these have a performance penalty.

its important to remember that not all programmers are interested in
languages, they just want to get their project done. So being able to hop into
a code base and have low cognitive overhead, because there are no mysterious
features they have to learn, having quick compile times, and explicit
semantics can be really helpful there. That can save you more time than typing
less because of generics and meta programming sometimes.

~~~
lostcolony
'and in most languages these have a performance penalty' \- pretty sure this
is due to either bad implementation or because of additional guarantees they
provide. Because fundamentally these constructs can be rewritten to be loops
by the compiler, except where you're wanting to violate the guarantees they
enforce (i.e., maybe you want to mutate every item in the array, rather than
treating it as immutable; these won't do that). For those few situations you
want to violate those guarantees, you wouldn't reach for these higher order
functions. There's not really any reason not to include them except for
language design ethos.

------
jahaja
Go is such a productive language. Well deserved cred to its authors and
community. Please, please hold firm against the inherent pressure from
language theoreticians to add more features that increases complexity.

~~~
jeffdavis
I think the tension is more between people writing executables and people
writing libraries.

If you want your language to be suitable for any purpose by using an intricate
web of libraries depending on each other, you need those language features and
deep theory. Think haskell, lisp, rust, etc.

If you kind of know what people will use your language for, and you build in
the most important functionality, you aren't nearly so dependent on libraries.
You just make the language accessible and as productive as possible. Think Go,
erlang, PHP, SQL, javascript, VB.

~~~
icholy
Yet the Go standard library is one of the best around ...

~~~
jeffdavis
It seems that you are agreeing with me.

A standard library for a language with a purpose (like Go) should include a
lot of stuff related to that purpose. That avoids the need for an intricate
web of dependencies and specialized third-oarty code, but ties the language to
its purpose a bit more.

A standard library for a use-for-anything-and-everything language (like rust)
might be smaller because it relies more on third-party libraries for the
specific purposes you have in mind.

------
ping_pong
If you compare Go to C++, Go has gotten more organized but still retains
understandability, and in my opinion, C++ has become unrecognizable. I did 10+
years of C++ until around 2012, and since then the changes have been so quick
and so drastic I would not call myself an experienced C++ programmer anymore.
It's a shame because I love C/C++ but not what I see today, because they have
lost what makes Go great: an opinion. They are trying very hard to be
everything and it has changed the language too quickly to keep up.

~~~
sedeki
Although I share similar experiences with what you're saying per se, I don't
understand why people compare Go to C++. Comparing Go to C makes sense; to
Rust or C++ does not.

~~~
ping_pong
I'm comparing it as a language that is evolving. Not as a point-to-point
comparison. I feel like Go has evolved properly and C++ is mutating too
quickly for its own good.

~~~
sedeki
Nah, C++ is hardly mutating, in the sense of being backwards-incompatible.
Rather, it is expanding incrementally (these days in big chunks). Anyway...
Would you compare Python and C++, then? The goals of the languages are clearly
different.

------
cyberpunk
Is modern go code still 50% "if err != nil" ?

When I last used it the error handling drove me a bit mad. I get the
reasoning, but the amount of identical error checking code for (almost) every
single call didn't make me feel terribly happy compared to my easy life in the
erlang/elixir 'let it crash' world :}

~~~
ainar-g
All points are like stale mantras by now, but still:

* Errors happen. All the time. And how you handle them matters. The err != nil path is _not_ unlikely.

* If your error processing code is repetitive, you're doing it wrong. Wrap your errors. Add context.

* Errors are values. Make them useful. Again, add context.

Honestly, while a lot of people look at Go code and think “this is 50% error
checking”, every time I read an under-handed piece of C or under-catched piece
of JavaScript, I think to myself “where _is_ the error checking?”

~~~
therealdrag0
In Java I feel like most of the time it's fine to just Throw (or let throw)
errors, and a parent can catch and log and move on with its life.

Go feels like making _all_ exceptions checked, whereas I usually try to only
use unchecked exceptions and it seems to work out fine :P

~~~
cle
Sure it works fine until you start multithreading, where handling an exception
doesn't end with unwinding the stack, because there are multiple stacks. So
then have to pass it _as a value_ to some other thread's stack, and remember
to catch it in every thread or else your thread will silently die. But then
you're right back to where Go is: treating errors as values.

~~~
lenkite
You simply have a _single_ uncaught-exception handler and that takes care of
the problem that you mention.

Instead of 500,000 if err != nil checks littering the source code and making
functions unreadable.

~~~
cle
I’m well aware of how to deal with the problems created by unchecked, stack-
unwinding exceptions. The thing is, when I’m reading Go code, I can look at a
call site and easily know if an error can occur and what happens to the error
(including if it’s sent to another goroutine), using very simple and
consistent mechanisms. The tradeoff is verbosity, but it is worthwhile
verbosity IMO because it’s simple, consistent, explicit, and does not create
the unnecessary coupling of checked exceptions. I appreciate this low
cognitive overhead when I go back to a codebase 6 months later, or when
onboarding a new hire.

------
nicodjimenez
Go is so good for web servers. Performs extremely well "out of the box", easy
to learn, and easy to deploy due to static linking.

Here's how I usually look at programming languages vs use cases in back end
development:

\- Go for back end API's with high performance requirements

\- Typescript for IO bound API's that can easily be modified and understood by
front end developers who use typescript for front end work

\- Python for scripting and IO bound API's

------
marcus_holmes
Go saved me from EntityFramework.

About 8 years ago, I was writing some app in C#, and the recognised way of
doing things was EntityFramework. I duly wrote a bunch of code around EF, only
to notice that sometimes it wasn't populating with the data correctly. Digging
into the documentation, I found that EF didn't actually do lazy loading
properly, and that if you really wanted to be sure that the data was
populated, you should call a method to check that the property you wanted had
been populated, and if not, call another method to populate it.

I threw Windows in the bin after that. I uninstalled Windows, installed Linux,
and started looking around for another language to code in. I found Go. It's
total lack of magic, utter transparency and attitude of simplicity made
complete sense to me.

<10 years later I'm still happily coding in Go. Thanks guys, this is awesome!

~~~
Scarbutt
How does Go solves your EF issue? Or, what would you use to write that app
today in Go?

~~~
apta
Sounds like throwing the baby out with the bathwater.

~~~
marcus_holmes
Today I have to write the SQL, and pull the results of the query into a
struct, which implements relevant interfaces. It's more code to write, but
it's simple, and straightforward, and it does exactly what it says it does,
and no more. It's easier to write and understand, and trust. Most of all,
trust.

~~~
0xcoffee
Entity Framework is just an ORM. Every ORM has their quirks. It's unclear why
you ditch a whole language, and even the OS just because you didn't enjoy
using an ORM.

If you want to write pure SQL and pull the results into a struct with
interfaces, you could do that in C# also.

~~~
marcus_holmes
It became a symbol for the entire C# coding attitude/worldview/paradigm at the
time. I lost it with EF because it just didn't do what it said it did, and all
the documentation lied about what it was actually doing. It became the straw
that broke the camel's back, the poster child for everything that was wrong
with .Net and C# (at the time - I gather things have got better since).

Go became the antidote, the "way things should be", and moving from Win/C# to
Linux/Go was eye-opening and very healing.

YMMV. I'm totally happy I found Go right then, when I needed it

------
kgraves
That's great, amazing and all good, but at my company I am looking for people
with at least 10 years (or more) experience with Go. :)

/s

~~~
sedeki
That's not my view of the market for Go devs. A few decent Go projects in your
GitHub profile perhaps? Sounds like you're being filtered by HR. Just mention
a few extra buzzwords.

------
mikece
"This pattern repeated for almost every language I looked at: it seems to take
roughly a decade of quiet, steady improvement and dissemination before a new
language really takes off."

It does help when the company who created the language is Google and they
start using it in significant products like Kubernetes. :-)

~~~
bradfitz
Kubernetes was almost written in Java. That it was written in Go instead was
motivated in part by Docker choosing Go, which Google wasn't part of.

~~~
yegle
Found this video
[https://archive.fosdem.org/2019/schedule/event/kubernetesclu...](https://archive.fosdem.org/2019/schedule/event/kubernetesclusterfuck/)

------
preommr
I really like go, it's a wonderful language in many ways.

But I really wish we got official answers on things like the code duplication.
Either something like generics or code generics and just establish we're not
going to get generics and put an end to the discussion.

~~~
isof4ult
Have you seen Contracts?

[https://go.googlesource.com/proposal/+/master/design/go2draf...](https://go.googlesource.com/proposal/+/master/design/go2draft-
contracts.md)

------
misiti3780
Python : Django === Go : ??

If I want a nice ORM and built in migrations, what framework should I be using
10 years later?

~~~
conroy
I wasn't happy with the current database access packages
([https://github.com/jmoiron/sqlx](https://github.com/jmoiron/sqlx),
[https://gorm.io](https://gorm.io)), so I wrote my own for PostgreSQL. It
takes existing queries and generates type-safe Go methods
([https://github.com/kyleconroy/sqlc](https://github.com/kyleconroy/sqlc)). I
enjoy using it and thought others might too.

As for migrations, I've had success with
[https://github.com/pressly/goose](https://github.com/pressly/goose). It's
lightweight and is also just SQL.

~~~
erik_seaberg
Nice, much like people would use Pro*C to generate C to talk to Oracle. I
think converting a DSL to boilerplate (which should rarely be read and never
edited) is key to living with a language that isn't good at reusable
abstractions.

------
djhworld
It's really interesting to have seen a language launch, develop and evolve
over the last 10 years. Back in 2009 I'd just started my career, and while
I've been mostly doing Java development professionally, I do a lot of Go stuff
in my side projects.

Long may it continue!

------
K0SM0S
Happy birthday to a wonderfully refreshing language.

> Go has also found adoption well beyond its original cloud target, with uses
> ranging from controlling tiny embedded systems with GoBot and TinyGo to
> detecting cancer with massive big data analysis and machine learning at
> GRAIL, and everything in between.

I've often thought of this, but I'm not qualified enough to answer my own
questions.

While a very expressive and extendable language like Python seems well suited
to researching the desired abstractions when designing neural nets and ML
paradigms, it seems to me that a production phase would benefit from
translating it to a 'sleek' language like Go — which forces you to think
closer to the machine, and opens boulevards to safe performance.

I wonder what people fluent in Go and other languages, experienced with ML,
think of this. (it's a minor concern overall, but the future of Go in ML is of
interest to me)

> especially the community working together.

I have to say this is one of the nicest things for a Go programmer, a 'Gopher'
as they say. I've been online since the late 1990's (teenager back then), in
all sorts of communities, and being quite civil and empathic myself I tend to
have strong opinions about the 'mindset' or 'culture' on a very down-to-earth
human level.

The Go community is among the very best. Period. One telling sign is how
welcoming, respectful and elevating they are with newcomers, to Go or
programming in general. It's a trainee's paradise, even if material is still
relatively scarce compared to longer-established big names.

> In fact, people often tell us that learning Go helped them get their first
> jobs in the tech industry.

This should not go unnoticed. Few languages are able to move that needle —
remember that for now, we increasingly need more developers than we can
produce at a worldwide scale. It's both a matter of a language and its
paradigm being in demand by employers, by clients projets; it's also a matter
of said paradigm and implementation/spec to be _conducive to the making of
programmers_.

We know the names. C. Java. PHP. Python. COBOL before that (and I hear, today
still). It's the big ones that consistently do it forever regardless of
'project / tech buzz flavor of the year or even decade'. I have every belief
that Go is destined to join this select club of industry norms. Lots of
reasons why but among the most fundamental are ticking all the right boxes at
a low level — ease of programming, stellar readability and portability of
others' code, really cross-platform target, self-documenting, etc. etc.

Anyhow. Here's to a masterpiece.

~~~
dodobirdlord
> While a very expressive and extendable language like Python seems well
> suited to researching the desired abstractions when designing neural nets
> and ML paradigms, it seems to me that a production phase would benefit from
> translating it to a 'sleek' language like Go — which forces you to think
> closer to the machine, and opens boulevards to safe performance.

This is a common perspective from outside of the ML field that arises usually
from missing knowledge about the ML technology stack. Underneath the layer of
expressive and exploratory Python lies a bedrock of optimized and domain-aware
numerical libraries written in a combination of Fortran, C, C++, handwritten
assembly and some HDLs. HPC resources are not cheap, so there is no software
stack that provides a meaningful performance advantage over the one currently
in use.

~~~
K0SM0S
OK, I understand better. I was indeed thinking of whatever piece of code hits
the metal last before kernel (including kernel actually), I see now that was
badly worded in GP.

This does strikes me as an interesting perspective though:

> a bedrock of optimized and domain-aware numerical libraries written in a
> combination of Fortran, C, C++, handwritten assembly and some HDLs

So, we're talking lower level, from the kernel and above but below TensorFlow
and Keras etc. I take it?

If yes, we're into systems by that point; it just so happens that this is Go's
domain. Think of shrinking a 1000-brains 10-year cycle to a 100-brains 5-year
or less (you may actually DevOps/CI-CD and sprint that stuff with Go like you
would with most high-level's like Python or Js; a general "no-can-do" with
low-level concurrent C++).

I may be wrong or totally out of my depth here, but I'm speaking of the
library layer where e.g. in compute you'd see a CUDA-based industry versus
whatever else (OpenCL...) take about a decade to unfold (and as much to move
back); same in graphics, you'd see DirectX / OpenGL/Vulkan market penetration
play over the entire lifetime of a GPU architecture (not 'gen', the core
design like e.g. GCN).

I'm lacking the experience with ML workflows for sure; however the general
hardware cycles and industrial market profiling seem to hold there as well
(from GPU / TPU / FPGA / whatever fabrication, and the economics thereof; up
to high-level software libraries and 'engineering muscle' that proponents of
tech XYZ can push beyond marketing).

Where Go fits in that landscape is not so much versus a data scientist's
Python but rather against infrastructure / Ops people's C++. Like Go is
currently a strong candidate to refactor (parts of) the COBOL space, because
it's basically 10x faster than in C++ or Java.

I'm thinking out loud. Don't quote me on any of this!

~~~
lossolo
> So, we're talking lower level, from the kernel and above but below
> TensorFlow and Keras etc. I take it?

Tensorflow/Keras are frameworks built on:

> a bedrock of optimized and domain-aware numerical libraries written in a
> combination of...

You are not making any calculations in Python (if you do you are using native
numerical libraries via FFI mostly), you only setup your workflow, prepare
data etc. Heavy lifting is done in low level libraries used by ML frameworks.
That's why Go will not make it drastically more performant/better.
Additionally most people doing ML knows Python, almost none know Go. 99% of
tutorials, ML libraries etc are in Python. Not enough benefits to leave such
an rich ecosystem in favor of Go. I write a lot of Go but even I would prefer
Python over Go for any ML work.

~~~
chewxy
> 99% of tutorials, ML libraries etc are in Python. Not enough benefits to
> leave such an rich ecosystem in favor of Go. I write a lot of Go but even I
> would prefer Python over Go for any ML work

I can give you one reason: Most of the ML tutorials online work on toy
problems. Full stop. When it comes time to deploy the models, good luck, you
need to move heaven and earth with devops stuff. Dockerize all your programs,
add more heft.

Not so when using Go directly. There's a reason why data engineers are more in
demand now than data scientists. With Scikit learn, keras etc it's easy to
build models. It's not easy to deploy models to production. Half the tutorials
don't teach the important bits: that your model needs to live in production.

Now, if you write your programs using Gonum or Gorgonia, you need to think a
lot deeper about what your model is doing, about memory about things that
software engineers think about. It's not easier, but it's the only sustainable
way forwards.

~~~
lossolo
> I can give you one reason: Most of the ML tutorials online work on toy
> problems. Full stop.

And most libraries and implementations are also in Python because they work on
toy problems?

> There's a reason why data engineers are more in demand now than data
> scientists. With Scikit learn, keras etc it's easy to build models. It's not
> easy to deploy models to production. Half the tutorials don't teach the
> important bits: that your model needs to live in production.

There is also a reason why you employ full stack web developer instead of
frontend developer. I can tell you what is the reason - it's cheaper than
employing frontend developer and backend developer. And for _toy problems_ you
can hire fullstack developer.

> Now, if you write your programs using Gonum or Gorgonia, you need to think a
> lot deeper about what your model is doing, about memory about things that
> software engineers think about. It's not easier, but it's the only
> sustainable way forwards.

So you are implying that whole industry, researchers and ML practitioners got
that wrong and they should use Go now? I know a lot of people working on ML
related problems and none of them use Go for their ML work. Some of them have
Go in their stacks, sure, but it's not used for ML directly. And they solve
practical business problems.

I've also worked before with two ML researchers respected in the industry and
I can assure you, they are not working on toy problems and they do not know
Go. And this is coming from Go user and enthusiast. Programming languages are
just tools, not a religion.

~~~
chewxy
Perhaps "toy problem" is the wrong term to use. "Deploy unfriendly" is perhaps
the term I should have used.

Programming languages are tools indeed. Some tools make life easy in one way,
some tools make life easy in other ways.

~~~
lossolo
> Some tools make life easy in one way, some tools make life easy in other
> ways.

Exactly, you always choose between different set of trade-offs.

------
Insanity
Happy birthday to Go :) I've been using it for a couple of years both
professionally and on the OSS side of things and I'm absolutely loving it!

------
dharmjit
I am recently introduced to golang. I really like the simplicity,
expressiveness and standard library. I am also a fan that developer need not
to deal with every nitty gritty details about the language, os etc.

------
kerng
10 years old and still very immature and a pain to work with... it's all so
backwards and I am not sure how many unnecessary lines of error code handling
I had to write. Its horrible to read, my takeaway, pick either Java for
business problems or Rust if you wanna do native stuff. Python is also much
better compared to Go. I feel like I became less skilled in coding the last
year and a half... Switching jobs soon, moving to a go free world. :)

------
iaabtpbtpnn
Ten years old and still basically Java 1.4...

------
sfg
This makes me feel even older than the XKCDs that point out its longer from
now to not-that-long-ago-seeming _X_ from your youth than it is from _X_ since
very-ancient-seeming _Y_ from your father's days.

~~~
omani
can you share that xkcd pls?

~~~
nindalf
He really loves his "want to feel old" jokes.

Also, want to feel old? The 'want to feel old?' factoid meme dates back to
around 2011, closer to the Bush/Kerry election than to today.

[https://xkcd.com/1686/](https://xkcd.com/1686/)

[https://xkcd.com/1757/](https://xkcd.com/1757/)

[https://xkcd.com/1624/](https://xkcd.com/1624/)

[https://xkcd.com/1995/](https://xkcd.com/1995/)

[https://xkcd.com/1898/](https://xkcd.com/1898/)

[https://xkcd.com/1959/](https://xkcd.com/1959/)

[https://xkcd.com/1981/](https://xkcd.com/1981/)

------
Koshkin
Congrats! When a man's gotta Go, he's gotta Go!

------
baalimago
if err != nil { panic() } on virtually every single function call gets a bit
tedious.

~~~
ngngngng
I'll still take that over having no idea what errors could be thrown at which
point in my code. Treating errors as values is very verbose, but it's the
easiest error handling I've ever tried to wrap my head around.

------
Koshkin
C++ within 10 years had conquered the world. Go, on the other hand...

~~~
SuddsMcDuff
C++ was invented in 1979.

In 1989 the most popular programming languages, in order of popularity, were:

1\. C

2\. Ada

3\. Pascal

4\. Lisp

5\. Fortran

6\. C++

7\. Assembly

8\. COBOL

9\. BASIC

10\. APL

Source -
[https://youtu.be/Og847HVwRSI?t=120](https://youtu.be/Og847HVwRSI?t=120)

~~~
Koshkin
More accurately, "In 1982, Stroustrup started to develop a successor to C with
Classes, which he named C++". (Source - Wikipedia.)

As far as Go's popularity, see e.g. [https://fossbytes.com/most-popular-
programming-languages/](https://fossbytes.com/most-popular-programming-
languages/).

~~~
SuddsMcDuff
True enough, one could name any year between 1979 and 1985 as the "invention"
year of C++, and the claim would have some merit.
[http://www.cplusplus.com/info/history/](http://www.cplusplus.com/info/history/)

