
Go 2016 Survey Results - stablemap
https://blog.golang.org/survey2016-results
======
xiaq
I like the fact that many people consider "reading source code" a way to get
Go answers. Go code, the standard library in particular, is really readable.

~~~
Clex
This is absolutely true, the standard library is very easy to read and this
makes using Go very pleasant. When you compare this with C and the libc, the
contrast is striking.

~~~
geoka9
C? Try comparing it with Scala.

~~~
tormeh
At least complicated Scala code is very in-your-face about how complicated it
is, as opposed to C.

The types also make it hard to change one small thing and make everything go
wrong. Sure, the standard library source looks like a trainwreck, but it has
structural strength. And it's easy to use.

------
zigzigzag
_Users are overwhelmingly happy with Go: they agree that they would recommend
Go to others by a ratio of 19:1, that they’d prefer to use Go for their next
project (14:1), and that Go is working well for their teams (18:1)._

Hmm. That's some great results, but is that survey representative of Go users
as a whole? The respondents are self-selected, right?

I can imagine such a survey is reliable for things like best/worst features,
how the language is used and other things that probably aren't correlated with
enthusiasm for the language. Simply asking people who already chose to do a
survey whether they like the language or not seems kind of pointless: if they
didn't they'd presumably not bother spending time to say they didn't.

It is however illuminating how many of Go's developers are attracted by
simplicity. The top adjectives for "like most" are: simplicity, easy,
concurrency, simple, fast.

So that's 3 of the top 5 things people name basically being "it is simple".

On the other hand, the top "improve the most" adjective is generics.

This appears to put Go in a somewhat awkward spot. There's clearly a large
population of developers who have been left behind by static typing and its
consequent complexity (generics in particular being a fertile source of
confusing error messages in most languages), and Go caters to these people,
hence its attraction to former dynamic language users.

But at the same time, people are saying they want more complexity in the form
of generics. If Go were to add good generics would it really be any simpler
than Java? I'd struggle to identify any major complexity gap between them
after that, unless you consider OOP to be too complex (unlikely given the
Python/JavaScript backgrounds of many Go users?).

I wonder if it's the same people giving the top answers. Are Go users split
into those who are happy with its current level of complexity and others who
chafe against it? If so, is it possible for them to satisfy both camps
simultaneously?

~~~
grey-area
This is an interesting idea, it is quite a heterogenous community, which means
there are definitely different schools of thought coming from entirely
different backgrounds. I'm quite happy with the slow progress/lack of changes,
to me that's a feature.

------
coldtea
> _When asked what changes would most improve Go, users most commonly
> mentioned generics, package versioning, and dependency management._

and:

> _What changes would improve Go most? (first: Generics)_

Number one issue mentioned.

So much for all those insisting that Go users have no issues with the missing
Generics and don't miss/need them in practice.

~~~
gtrubetskoy
FWIW, generics were added to Java in 2004, about 9 years after initial
release.

ref:
[https://en.wikipedia.org/wiki/Generics_in_Java](https://en.wikipedia.org/wiki/Generics_in_Java)

~~~
whatever_dude
And one could say it was too early. Under the hood, generics are pretty bad in
Java [0]. Type information is mostly lost; it's a compiler time only feature.
They're much better implemented in C#, even if they look the same on the
surface, probably because it came later and they took it seriously.

So I applaud the Go architects with being conservative about it. More
languages should take their time thinking about implementing features, no
matter how needed they seem to be initially. You only get one chance, and then
if it's a bad choice you live with the consequences.

[0]
[http://www.jprl.com/Blog/archive/development/2007/Aug-31.htm...](http://www.jprl.com/Blog/archive/development/2007/Aug-31.html)

~~~
sreque
Just about every programming language expert I've seen who's talked about Java
generics says Java did a better job than C#. In fact, of all language runtimes
that do generics, the .NET runtime is the only one that specializes. Examples
of runtimes that do not specialize or reify generics:

* JVM

* Haskell runtime

* ML family of languages

* Modula-3

* Ada

The problem with specialized generics in the runtime is that they bake the
type system of the language into the runtime itself, making the runtime more
difficult to work with. Type erasure, for instance, makes it much easier to
implement alternative languages on the JVM such as JRuby, Clojure, Scala, or
Kotlin, than on .NET.

As another example, C# in 4.0 added the concept of generic type variance,
which is completely at odds with specialized generics. To implement this
feature, the C# language designers had to modify the underlying runtime itself
and add special bytecode instructions for the feature. The feature itself is
also incompatible with specialized generics, so when you use it you silently
lose specialization. In contrast, thanks to type erasure, the Scala language
designers could easily add the same feature on top of the JVM as-is without
needing Oracle to add special bytecode instructions.

Specialization has advantages for performance when doing number crunching with
data structures and algorithms operating directly on integral or floating
point data types. At the end of the day, though, if you really need
performance for this very narrow field of use cases, you're probably not going
to be using generic data structures and algorithms anyways. It takes an
incredible amount of effort to build a data structure or algorithm that is
both generic and also performant in all possible usage scenarios. It is
however, much easier to build a data structure or algorithm that is specific
and performant relative to your use case alone.

Case in point: when I was in college doing a NLP assignment that needed to be
fast, my data structures were arrays of doubles because that was the easiest
way to reason about and ensure performance.

~~~
MichaelGG
Generics just bake a little bit more into the runtime; there's already a lot
of the type system there. And it increases interop potential. I don't
understand your point about Scala - they could always choose to use type
erasure instead of any runtime-provided generics. F# implemented generics with
erasure on the 1.x CLR, and used the runtime when on CLR 2.

And this is the first time I've heard that the JVM is easier to target for
non-Java languages. .NET has had multi-language support an official design
goal, the JVM is just for Java. Even simple stuff like pointers, so you can do
ref/out parameters. Or unverified instructions. The CLR is simply more all-
around capable.

I am pretty sure the CLR always supported variance, it was just unused up
until C# 4.0. AFAIK, there haven't been any changes to the runtime bytecode
since CLR 2.0, when generics were added.

The performance benefits of specialization are pretty nifty. The Mono guys
ported Android to C# and got quite the performance improvement on some code:
[https://blog.xamarin.com/android-in-c-
sharp/](https://blog.xamarin.com/android-in-c-sharp/) \- so that's existing
code that got a perf benefit "for free" due to not using type erasure.

Edit: A quick skim of the specialization proposal for Java[1] makes no mention
of other languages. Just the general pain of integrating it in a compatible
way.

1:
[http://cr.openjdk.java.net/~briangoetz/valhalla/specializati...](http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html)

~~~
pjmlp
Brian Goetz sometimes refers to it on his presentations.

As for multi-language support on the CLR, compared with the old 1.x days,
there seems to be less focus on it.

With C# getting most of the focus, followed by VB.NET and F# playing catchup.

Also outside MSR, most researchers focus on the JVM, in spite of its caveats,
and nowadays LLVM as well.

ETHZ is the only one I am aware that also designs languages with CLR in mind.
The Active Oberon successors, like Zonnon.

There are some companies selling compilers for .NET, like Cobol, Eiffel and
Pascal. Not sure how well they are doing it.

Clojure also targets the CLR, but they don't seem to have a story for .NET
Core.

~~~
MichaelGG
Isn't that more a function of MS's hostility to other platforms, not technical
reasons? If MS had been more open and friendly 15 years ago things might be
different.

~~~
pjmlp
I don't see that as hostility, rather political decisions, including on
Microsoft's own languages, with the usual issues between language departments.

For example, if everyone played the ball into the same direction, probably
Longhorn could have been what UWP is becoming.

------
octref
Just want to point out this is a terrific display of data. Easy to read, grasp
and scan through. Much better than some so-called data visualizations that
confuse rather than present and clarify.

~~~
tomtheelder
Agreed, except for the survey answers. The data presented there is essentially
impenetrable, and I am extremely suspicious of the methodology.

~~~
rsc
To be clear, the discussion of survey free-text answers is based on us (mainly
Steve) reading all the text. The goal in the free-text presentations was to
show raw data in a useful way for others to look for details.

As I noted in a comment elsewhere on this page, if you have suggestions for
how to summarize free-response text in a way that lets the data speak rather
than lend itself to cherry-picking, please let us know. I'm certainly open to
improved analysis next time.

------
noisy_boy
Everyone is talking about Generics but the thing that I found tiring in Go is
having to do the "err != nil" thing all over the place (I admit that I spent
couple of days learning Go so I'm not familiar with best practices/idioms in
Go about error handling). Seems like the error handling in Go is another point
the survey brought out:

> Other popular responses were GUIs, debugging, and error handling.

I really like the ease of defining Exceptions and just being able to "raise"
them in Python - provides an easy early exit and the caller can handle them
nicely in "except" clauses.

Edit: grammer

~~~
noisy_boy
Interesting. I mentioned something I don't like, gave an example of what I
like, some Go users in the survey have also mentioned their dissatisfaction
with error handling and I got downvoted? Did I break any rules/etiquettes?

~~~
misterbowfinger
I agree. Error handling in Go can be very cumbersome. I like the explicitness
of it, but it can definitely be smoother.

~~~
vetinari
I like Go error handling.

Instead of getting some abstract exception and stack trace over several pages,
the error message is usually pretty specific. Yes, it forces to handle errors
locally, but that is a good thing, because locally you know what can go wrong.
Your user, who is going to be separated by several layers, won't know that and
the specificity is a godsend to him.

~~~
noisy_boy
One use case where this is a bit of an problem for me is with a user facing
api. Say a web request calls a top level method/subroutine which calls more
and so on. Now if there is an error in the the lower level subroutine and I
wish to expose it to the user gracefully (say a json response), in Go, I need
to handle it explicitly and pass it as part of my return statement (along with
the actual results which may be empty/null due to the error). Doing this with
each of the nested methods becomes tedious. Please correct me if I'm wrong
about this understanding as my knowledge of Go is limited.

If I could raise an exception, taking example of Python, I can choose not to
worry about handling it in the intermediate methods and it'll float right to
the top level subroutine with error message etc and I can handle it there
anyway I wish.

------
vvanders
VSCode seems to be making strong inroads. 2nd only to VIM(13%) at 9%.

~~~
tonyedgecombe
The Go plugin does seem to work reasonably well although I may well switch
once the JetBrains offering is ready.

------
grey-area
Lots of great info here, thanks to the Go team and Steve Francia in particular
for taking the time to compile all this data into something intelligible. Some
interesting data about what improvements users would like:

 _What changes would most improve the Go documentation?_

Collectively examples gets 26%

 _What Go libraries do you need that aren 't available today?_

Lots of demand for UI libraries and mobile support - both very hard to get
right and would really require corporate backing. Sometimes I suspect large
corporations (MS/Apple/Google) churn their OS APIs/languages simply to keep
devs busy learning their one platform. This would be hard to do and hard to
support long term.

 _What changes would improve Go most?_

The G word comes first (not being worked on), and then package management
(being worked on), also library discovery is highlighted as an issue. I'd
prefer if they took a step back and prepared a Go 2.0 which removed some of
the inevitable cruft (comments as directives, struct tags), and rethought some
other features - mostly taking things out rather than adding things, though it
would be nice also to see a solution to generics and better containers built-
in.

And [https://golangnews.com](https://golangnews.com) makes an entry in news
sources, even if it is near the bottom :)

It'd be nice to see the raw data too (some of the data points require a bit of
tidying up (mostly the write in responses for which 1-2 word breakdowns don't
really help much and split up similar responses like example/more
examples/examples/code examples/tutorials) and words like 'great' are not
really helpful without context. Now that they have the data presumably they
could merge some of those categories or if they released it others could look
at this sort of thing for them.

~~~
icholy
What's wrong with struct tags?

~~~
grey-area
I think I'm the only go user who doesn't like them :) IMO they mix up separate
concerns, use an ad-hoc syntax and end up a mess in complex apps, it's like a
whole other language stuffed into a string and defined by random lib authors.
A field might have json, xml, db tags all in one string. But there's no chance
they'll be removed.

~~~
cypher543
I don't like them either, so you're not alone. Nor do I like comments as
compiler directives. Go needs a proper attribute syntax that works with the
package system (so attributes don't collide) and can be applied to everything,
including struct fields.

------
rodionos
Stack Overflow ranks first as a Q&A resource.

Here's a chart that shows the number of new golang questions created on SO
each month:
[https://apps.axibase.com/chartlab/c1acecc0/5/](https://apps.axibase.com/chartlab/c1acecc0/5/)

golang is trending up, 20% increase year on year.

------
tapirl
most wanted: * generics * better package management * gui libraries * better
documents

~~~
golergka
I haven't used Go a lot (couple of hobby projects), but found package
management to be pretty good. The only thing I could think of is the $GOROOT
structure, is this it?

~~~
diggan
What package management? AFAIK, there is no package management at all in Go,
unless you use a third-party tool for doing that. The only thing you can do is
fetching the latest revision of some package.

~~~
geoka9
You can also "vendor", there's support in Go for it.

~~~
xienze
Which is a poor solution since it involves checking all your dependencies into
source control. There's no reason why you shouldn't be able to have a file
that lists all your dependencies and versions and lets you pull them down on-
demand.

~~~
prodigal_erik
If you can't build and deploy your own system without a piece of code, you
should not be relying on the goodwill of any third party to keep it available
for you with no SLA. A good build system is a deterministic function of its
input (a commit from your repo) and can run offline.

------
camus2
It extremely hard to deduce anything from most of the data, especially the
open handed questions.

Obviously despite what some people kept on suggesting for years on HN, the 2
main concerns regarding the language are 1 - dependency management and 2 -
lack of generics.

------
eternalban
Grep'd for "meta", "annotation" returns no results. Elsewhere in this thread
someone mentioned "struct tags".

Strings and comments as band-aid meta-data is one of Go's glaring weaknesses.

------
skywhopper
The stat that jumped out at me the most, among respondents to the survey,
twice as many identified as LGBTQ* as identified themselves as women. Self-
identified women respondants to the survey rounded to 1%.

~~~
zigzigzag
That's not what the question asks. It asks "do you identify as part of an
under-represented group" with an option for "I identify as a woman".

That's not the same as a straight gender m/f question. I can imagine that some
women felt they weren't under-represented and didn't primarily "identify as a
woman" even if they were one. Consider the reverse question with s/woman/man/
\- how many men would pick "I identify as a man" vs "I do not identify as part
of an underrepresented group". It's a leading question. Bear in mind on that
question the vast majority of respondents were just a shrug: either no
response, explicitly saying they didn't want to answer, or not identifying as
part of such a group.

------
zeveb
I'm glad to see that 63% develop on Linux; IME there really is no substitute.

I think it's a real shame that vi, VSCode, Atom, IntelliJ & Sublime Text come
in ahead of emacs — emacs & go-mode are a wonderful way to write Go,
particularly if one's using projectile or spacemacs. It's really worth a shot!

------
thewhitetulip
One major issue is the lack of good easy to understand guides, shameless self
promotion, I faced this issue so wrote an easy to understand guide about
webdev, [https://github.com/thewhitetulip/web-dev-golang-anti-
textboo...](https://github.com/thewhitetulip/web-dev-golang-anti-textbook)

------
tracker1
I'm surprised how high/well JS and Python rank as secondary/preferred
languages. I'm a fan of modern JS myself, but surprised to see this carry over
into another environment considering how many outside the current JS culture
tend to reject the changes as complexity.

~~~
majewsky
JS as a secondary language to Go is absolutely not surprising, given Go's
focus on web applications.

~~~
tracker1
I guess so... And as it seems at least to me, that _most_ development these
days has some sort of browser interface (not all software used, or even most,
just that there are more developers working on something with a web front end)
it shouldn't surprise me that much.

------
themihai
The GUI issue could be fixed once Go gets WASM support(along with DOM access).
Developing entirely new GUI libs is quite laborious considering the
expectations.

------
nindalf
This is not true. No one says generics aren't required, and it's more about
finding the implementation that makes sense for go. For at least a year
several people on the Go team have acknowledged the demand for generics. Ian
Lance-Taylor even added a doc to the go repo which summarised the entire
discussion on the various possible implementations and their pros and cons.
For instance, most of what's required could come from a nice implementation of
macros.

As usual you, coldtea, have posted an uninformed, polarising comment with the
intent to provoke. Not surprised.

~~~
coldtea
> _This is not true. No one says generics aren 't required_

Actually many have maintained exactly that, here on HN. Do you want me to post
excerpts of such comments?

Heck, from this very thread: "I admit that I missed generics for the first
several weeks but then just moved forward. Nowadays I don't really think I
actually need them anymore."

> _For at least a year several people on the Go team have acknowledged the
> demand for generics. Ian Lance-Taylor even added a doc to the go repo which
> summarised the entire discussion on the various possible implementations and
> their pros and cons._

I've read the summary, and most of the related blog posts. It has been close
to a decade of Golang now. At which point can no practical progress in an area
finally be considered as a neglect of indifference? After 7-10 more years?

Besides, regarding the acknowledgement I've posted sometime ago that I
consider the standard "Generics are difficult, we just want to make sure we
create them perfect before we attempt at adding them" position of the team as
a discussion-stopper more than anything else. Perhaps you have some reason why
I should be disallowed to be of and express that opinion? Because you don't
seem satisfied to point that you consider it wrong.

> _As usual you, coldtea, have posted an uninformed, polarising comment with
> the intent to provoke. Not surprised._

My intent is to express my position on the issue. Which is more or less the
same, all these years, and I'm not sure why you'd expect that it should
change, or that people who disagree with you should just shut up or something.

Plus, I don't care for your ad hominem.

~~~
gribbly
>It has been close to a decade of Golang now.

It's been ~7 years, so there's still two more years before it reaches the
amount of time it took Java to get generics.

I'm confident generics will come to Go (I sure hope so), but even if it
doesn't, Go's impressive uptake shows that it's not something it desperately
needs in order to be a successful language.

~~~
pjmlp
How much uptake would Go had if it was done at company XYZ?

Or Docker guys hadn't used it?

~~~
gribbly
Impossible to answer, how much would uptake would C# have had without
Microsoft behind it pushing it HARD (MUCH more than Google has promoted Go),
how much would Swift have had without being pushed hard by Apple as the new
native language to replace ObjectiveC etc ?

~~~
pjmlp
That is exactly my point, it would have been probably a footnote in
programming languages compendium.

Case in point, how interested were people in using Limbo?

~~~
gribbly
>That is exactly my point

The point being that unless you have a huge rich company behind you, you will
remain a footnote ?

~~~
pjmlp
Without that or a kind of killer application, e.g. Rails, yes.

------
grabcocque
Are the Go devs finally starting to wake up to the realisation that maybe a
better generics story, or less verbose and primitive error handling, is
something people do, actually, want?

I get the impression the Go devs have been stoking the flames a bit by
refusing to countenance the extension of the language even into areas where it
was clearly lacking.

~~~
tptacek
"Finally". The Go devs have been talking about generics and the demand for
generics for years. It's nobody's contention that people don't want them.

~~~
coldtea
Every second comment in discussions on the matter on HN ever is about how
"people don't want them" and how those asking for them haven't really used Go
to see how it doesn't need them in practice, and other such inanities.

~~~
tptacek
It can obviously be simultaneously true that people don't find themselves
needing generics in practice, but still want them in the language. Also,
there's nothing "inane" about that.

~~~
pcwalton
Why would you want generics if you don't need them in practice?

~~~
tedunangst
Come on. You don't know the difference between needs and wants?

~~~
pcwalton
Discussing what you "need" isn't remotely interesting in the context of
programming languages. You don't _need_ anything more than assembly language
to get anything done.

~~~
tedunangst
Redefining need as nice to have isn't interesting either. It should be
possible for there to exist a set of features which are convenient if present,
but the absence of which does not substantially impede the development of
solutions.

~~~
wolf550e
You described a feature that good engineering practice says should be
eliminated. Features have costs (the most significant of which IMO is learning
an unfamiliar feature when you read other people's code), thus only features
that allow better (less error prone, more maintainable, faster) implementation
of applications should be included in any language.

