
Go 2017 Survey Results - JepZ
https://blog.golang.org/survey2017-results
======
kjksf
For me the big takeaway is: generics are pretty much guaranteed to happen
within a year or two.

> When asked about the biggest challenges to their own personal use of Go,
> users clearly conveyed that lack of dependency management and lack of
> generics were their two biggest issues, consistent with 2016. In 2017 we
> laid a foundation to be able to address these issues

> These two issues will continue to be a major focus of the project through
> 2018

~~~
deckarep
That’s a bold statement...I’m not holding my breath. We still haven’t seen a
solid proposal and the work required would likely be even more monumental
after the fact.

~~~
seanmcdirmid
Generics are well understood ATM. Once they decide on something, I don't think
the work required would be monumental, unless they try something crazy.

~~~
skybrian
Judging by package management, I wouldn't be surprised if it took another five
years to figure out a plan and they did something controversially different
from everyone else.

Which isn't a bad thing, necessarily.

~~~
xzi00s09f8098fd
Not sure what you mean by this.

rsc has recently blogged in much detail about the package management
situation, basing his work on existing solutions. He seems to specially eye
rust's cargo. The blogs have been on HN several times.

[https://news.ycombinator.com/item?id=16421966](https://news.ycombinator.com/item?id=16421966)
[https://news.ycombinator.com/item?id=16434973](https://news.ycombinator.com/item?id=16434973)

------
tvladeck
Tangential question: what was used to produce those charts? I _love_ the
simple formatting and how the data is laid out.

My company* uses ggplot exclusively for reports that don't look nearly this
well done. I love the information density, love the use of colors, love
everything about them!

Based on my inspection of the source, these are "native html" charts in the
sense that it's a mix of text and svg rect elements — not an "image" that is
included.

Does anyone know how these are produced? I would love to shamelessly imitate
if possible.

*tiny market research firm

~~~
tvladeck
Update: I asked the author!

The reply was discouraging in one sense and encouraging in another:

[https://twitter.com/spf13/status/968259340619698176](https://twitter.com/spf13/status/968259340619698176)

"Custom Go application that parses the raw XML data from Qualtrics and the
generates the SVGs"

~~~
Numberwang
Thanks for posting the reply back to this thread!

------
bonoetmalo
I have a feeling a survey hosted by the language maintainers is going to be
heavily skewed in favor of "used Go for a long time" and "prefer Go over other
languages"

~~~
obmelvin
Those questions won't be representative of the whole population, but it's good
to have a population of your users for things like this. I'm aware that Go is
a good language, but I've never had a reason to use it and my opinion about
other things related to Go shouldn't impact the development direction.

------
bradenb
This is great for Go and I'm happy for them. I feel like in my career many
people are extremely intimidated at the prospect of using Go for more than a
pet project. The best answer I can manage to get to the question of "why?" is
that it feels unfamiliar to them. I think this is an unfortunate hurdle.

Hopefully that is just how things are in my little bubble (as this survey
would indicate). I think Go is really cool and I will continue to lobby to
implement some mission-critical systems with it.

~~~
ptero
> I feel like in my career many people are extremely intimidated at the
> prospect of using Go for more than a pet project.

That has not been my experience. Go is a learner friendly language with plenty
of introductions and great, clean examples. If one has a basic familiarity
with other languages learning Go is just as easy (or easier) than learning
kotlin (python, tcl, java, c#, ...).

For me a bigger hurdle is the lack of some features: no generics is a pain. I
would love to use Go for scientific computing, but libraries are not there
yet. Writing my own I really miss operator overloading: operator and
matrix/function algebras are the only areas where I miss this, but there I
miss it _badly_ \-- (AB + BA)^2 is so much cleaner than Power(Add(Mult(A, B),
Mult(B, A), 2). Writing a simple Kalman gain formula becomes an involved magic
incantation.

Just a personal data point.

~~~
weberc2
I relate to both of you. Go is a tremendously easy language to learn in my
experience, but my peers are so jaded by other languages' grandiose promises
and subsequent failures that they refuse to even take the tour. This is
especially true for my friends coming from Python and JS who associate "static
typing" with C++, Java, Rust, or Haskell.

So it is both easy to learn and intimidating.

~~~
sjellis
"So it is both easy to learn and intimidating."

To be fair, the issues that you've cited don't seem specific to Go. Static
typing is actually being adopted in both Python and JavaScript (via
TypeScript), so people who keep up with the trends in those languages now have
relevant examples of it.

~~~
weberc2
Your first sentence confuses me. What issues did I cite? Why are you phrasing
this as a rebuttal to my post when your content seems to not contradict at
all?

In any case, it is good to see static typing support among dynamic languages.
Hopefully that will help more people try Go. I have yet to find another
programming language that makes application development so holistically easy.

------
dpflan
I would like to see how this particular question changes in the next year to
see if a wave of expertise hits or is about to hit:

"""

I've used Go for: (single choice)

\- 686 (11%) Less than 3 months

\- 1,588 (26%) 3 - 12 months

\- 1,338 (21%) 13 - 24 months

\- 1,678 (27%) 2 - 4 years

\- 809 (13%) 4+ years

\- 102 (2%) I've never used Go

\- 25 (0%) No response

"""

------
wlkr
There seems to be an issue with the last embedded SVG file in the 'Go usage'
section ([https://i.imgur.com/tAGJ9DX.png](https://i.imgur.com/tAGJ9DX.png) is
how it displays in Firefox).

~~~
chimeracoder
Which version and OS? It renders correctly for me on the Developer Edition on
OS X.

~~~
wlkr
Interesting, I thought it might be an SVG error but it appears fine in Chrome.
The screenshot is from Firefox version 58.0.2 (64-bit) on macOS High Sierra
10.13.3.

------
flavio81
Good. I'm ready to go deep into Go, as soon as Go supports:

a- Generics

b- True, elegant exception handling

c- Built-in metaprogramming, not that "Go Generate" joke.

Nice to have: Sum types.

Nice to have: Shorthand for interface{}.

Nice to have: Package manager that does not depend on Git as first-choice of
package repository.

Alternatively (c) can sort-of replace (a) as well.

------
myroon5
Surprised to see JavaScript so high in preferred languages

------
keymone
"lack" "generics" "lack of generics"

~~~
maxaf
At first I've avoided Go like the plague because it lacks generics.

A couple of years ago, I happened to pick up Go for a work project, and
managed to ship it despite the lack of generics in Go. I realized that this
was some of the most fun work I've ever done because of Go's various
properties. I decided to take what is given and kept Go-ing. (Pun intended...)

Having just passed my 2nd anniversary as a Gopher (a Gopherversary?) I still
manage to ship projects despite Go's glaring lack of generics.

Based on my own personal experience I can thus conclude that the
non/availability of generics has very little to do with how strongly a
programming language enables engineers to deliver projects.

~~~
thatswrong0
Ok so you can deliver projects. But what about the next guy that has to
maintain them?

At my work, we use Go extensively on the backend. Yes, it’s capable of being
used by engineers to ship projects - most languages are capable of that.

But I do know we write a lot of boilerplate, and repeat ourselves all the
time. We still see nil pointers occasionally (in 2018! Why are they still a
thing). Even though I work with a bunch of smart engineers, the language has
pressured us to write more code than we need to, which means more maintenance
will be required in the future. After having worked with it for 2+ years, I
wish we had just used Java or even JavaScript.

~~~
maxaf
Go's syntax and the patterns it encourages are both tailored to the harsh
reality that code is read a lot more than it's written. It turns out that the
verbosity of, for example, Go's error handling is actually simpler to
understand and easier to read than any monadic contraption I've seen in the
wild. It's also safer and lighter than Java's use of exceptions (checked or
otherwise) because of the non-exceptional nature of equality comparisons and
multi-valued returns.

Lastly, the idea that generics somehow remove the pain of null pointers is
simply false. I've done 8 years of Scala before defecting to Go, and still
have nightmares about an empty Option[T] that has caused some n-level-deep
monadic computation to return nothing. In this case, Go would at least blow up
with a helpful stack trace, while the Scala program would continue to run and
return erroneous results.

~~~
kasey_junk
I think the argument that ‘Scala is over complex’ is not a compelling argument
against the premise that ‘go is too simple’.

Frankly, I’ve seen as many golang error handling bugs in the wild as I ever
did with java or c# style exceptions. Don’t get me started on the golang
generics & concurrency problems.

I continue to use golang _in spite_ of their language decisions around these
items, not because of them.

~~~
sagichmal
> Frankly, I’ve seen as many golang error handling bugs in the wild as I ever
> did with java or c# style exceptions.

This has not been my experience. Idiomatic Go -- that is, not trying to do
obtuse, clever, or dumb things to avoid error handling -- results in very
clean and error-free code by default. I see unexpected runtime errors maybe a
few times a year. I haven't seen unexpected panics in years.

~~~
kasey_junk
Serious question, when you see non obtuse, clever or dumb things for error
handling how do you attribute language?

~~~
sagichmal
Attribute language? I'm not sure what you mean.

In Go there is typically a very restricted set of ways to idiomatically
accomplish a given task, often only one. Error management is a prime example.

    
    
        result, err := function()
    

What do you do with err? If it is recoverable, you should try to recover from
it.

    
    
        if err == ErrTryAgain {
            continue
        }
    

Generally errors aren't recoverable, and should be reported back up the stack
with some kind of contextual annotation.

    
    
        if err != nil {
            return fmt.Errorf("function failed: %v", err)
        }
    

If you want to provide more context to your caller, to enable a richer set of
responses to this error, you can use more structure.

    
    
        if err != nil {
            return FunctionError{Original: err, ...}
        }
    

That's really about it. Anything that tries to subvert the very simple/plain
`if` checking, or tries to perform some kind of monadic error chaining, or
builds an ersatz exception system with panic/recover, is what I mean when I
talk about "obtuse, clever, or dumb things". The language and its idioms form
these expectations.

~~~
tptacek
This is in fact _not_ idiomatic Go style. The Go error idiom is that errors
are values, and that if you want cleaner error abstractions, you just program
them yourself. People make trees of errors, or aggregate errors and check them
once, or have error stacks.

"continue" doesn't recover from an error, obviously. It is not hard to find
screwups in error recovery code in Go.

Your "fmt.Errorf" "idiom" (it unfortunately really is one) is one of the major
Go error handling warts. Since you (like everyone else) didn't create an error
variable or type to capture any of the meaning of the error, what you've
created is a _by-design_ unrecoverable error, one where your only hope of
responding in any way other than aborting the entire operation is to _parse
the string error message_ , which is something more than one Go program has
had to do.

I don't think this is a very strong rebuttal to "Go error handling kind of
sucks".

~~~
sagichmal
> This is in fact not idiomatic Go style.

This is absolutely idiomatic, with progressively increasing levels of opt-in
expressivity. "If you want [additional] error abstractions, you just program
them yourself" was clearly demonstrated: my "tree" of error-chaining was only
one level deep (FunctionError), but that's a nit.

> "continue" doesn't recover from an error, obviously.

ErrTryAgain clearly carries semantic meaning that "continue" acts upon.

> Your "fmt.Errorf" "idiom" (it unfortunately really is one) is one of the
> major Go error handling warts. Since you (like everyone else) didn't create
> an error variable or type to capture any of the meaning of the error, what
> you've created is a by-design unrecoverable error, one where your only hope
> of responding in any way other than aborting the entire operation is to
> parse the string error message, which is something more than one Go program
> has had to do.

I demonstrated an alternative for situations when clients might want to parse
and act on errors.

~~~
tptacek
And in doing that, you demonstrated that the idiomatic default in Go error
handling is _unhandleable errors_ , the sort that forces programmers to
pitifully parse strings to differentiate.

I kind of love Go. I'm a former professional C programmer and Go is now my
default language. But I don't feel a need to kid people about things Go gets
wrong.

~~~
sagichmal
If the user can do anything with the error, then it is idiomatic to return a
discrete, comparable error variable

    
    
        var ErrTryAgain = errors.New("...")
    

or an error type with additional contextual information

    
    
        type RetryError struct { ... }
    

These are both opt-in; if your users have no need to differentiate or act on
errors, fmt.Errorf("...") is totally sufficient.

You're acting as if this is some critical flaw in the language. It's nothing
like that.

