12 ms·

Go 2016 Survey Results

119 points by stablemap 10y ago

tapirl 10y ago
most wanted: * generics * better package management * gui libraries * better documents
- golergka 10y ago
  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 10y ago
    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.
    - themihai 10y ago
      There is an experimental package manaent which most likely will become defaul in Go 1.9
    - geoka9 10y ago
      You can also "vendor", there's support in Go for it.
      - xienze 10y ago
        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.
        geoka9 10y ago
        For sure, I was just pointing out a workaround.
        prodigal_erik 10y ago
        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.
      - notheguyouthink 10y ago
        Vendor has some very basic problems though, and honestly i think it's unusable due to that. It's a ticking time bomb, imo. In short, types, especially interfaces in returns, are strictly bound to their location which might be a vendor. If two libraries are using vendors[1] then the types are inherently incompatible between the two libraries. My most common point of failure for this is running into Logging interfaces that return themselves. That interface is completely incompatible with the other package's vendored logger, and so you have to have two instances of a logger - one for each package. [1]: (ie, they both have a main package and a library package, so they both have vendors). It's to the point where if you have a main and a library, like many repos, you should simply move the main to another repo entirely.. which sucks, imo.
  - grey-area 10y ago
    It's referring to being able to pin dependencies easily so that you have a stable set of dependencies which is defined. At present go get, while convenient, fetches from head, so things can break when you move computer for example and refetch dependencies, or a new team member comes on board, or if you have an open source project.
skywhopper 10y ago
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 10y ago
  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.
grey-area 10y ago
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 10y ago
  What's wrong with struct tags?
  - grey-area 10y ago
    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.
grabcocque 10y ago
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.
- rem7 10y ago
  Well they're listening... at least in the next couple of versions there should be an official dependency manager coming out. IMHO it's meh. They need to get rid of the damn gopath.
  - chimeracoder 10y ago
    Between the new default GOPATH and the support for vendoring, I'm not sure I know what getting rid of the GOPATH would even mean anymore. As a Go programmer since the 1.0 days, the concept of the GOPATH that existed when I started using the language is long gone.
    - rem7 10y ago
      vendor still doesn't work if your project is outside of GOPATH. The only thing the vendor folder is doing right now is precedence. Dep, the pre-alpha tool that is lining up to be the official dependency manager still doesn't work outside the GOPATH, hopefully they change that. The only thing that Go 1.8 did was add a default to GOPATH to $HOME/go. In my ideal world, I should be able to clone a go project anywhere on my system, fetch the dependencies from the internet, yes the internet, because its 2017. (if you're that concerned with security fine, include them in your repo) but I should be able to call go build in that directory wherever it is.
  - sagichmal 10y ago
    Everyone involved in the technical decisionmaking agrees that, long term, the GOPATH will be deprecated and removed. The question is just about getting from here to there without fucking people's workflows too badly. It will probably be 2 or 3 more release cycles, at least, before that's a reality.
zigzigzag 10y ago
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 10y ago
  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.
themihai 10y ago
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.
xiaq 10y ago
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.
- k__ 10y ago
  I also switched from SO to reading source in GitHub for my JS problems. Life became less ambiguous
  - eduren 10y ago
    I feel like whenever I'm forced to dig into my node_modules folder I come out with a greater understanding (and a headache or two for my troubles).
- Clex 10y ago
  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 10y ago
    C? Try comparing it with Scala.
    - tormeh 10y ago
      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.
- tonyedgecombe 10y ago
  That could be a reflection on the rather thin documentation around the standard library.
coldtea 10y ago
>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.
- bla2 10y ago
  But, also, number one liked issue: simplicity. The go team doesn't say they don't want generics, they say they haven't found a non-complicated way to implement generics.
  - coldtea 10y ago
    Well, I don't think there's some magic way. There are just the N ways PL research has found for implementing generics. Either they implement them, and tackle the complication one of those N ways entails, or they don't. Besides, has anyone seen much experiments, with actual coding or at least design, for finding this "non-complicated" way anyway? Not just some post once in a blue moon re-iterating the basic well known tradeoffs.
    - gribbly 10y ago
      >Besides, has anyone seen much experiments, with actual coding or at least design, for finding this "non-complicated" way anyway? Proposal from Ian Lance Taylor, Go developer at Google https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-... View of Russ Cox, Go developer at Google https://research.swtch.com/go2017#generics https://research.swtch.com/go2017#generics
      - coldtea 10y ago
        Yeah, I've read both -- and more. None of this is what I described: either actual code, even if in some experimental compiler branch/fork, or at least a concrete design. Ian's just reiterates the various options (Rob Pike has already written similar things), and Russ Cox is just several vague ideas for future additions to the language.
octref 10y ago
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.
- SonicSoul 10y ago
  good point. i brushed over this fact since the charts were not especially pretty, but your comment helped me focus on how they're inline with content you don't need to jump between graph and description. it reminds me of how sparklines[0] can be used to visualize data in line. [0] https://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR https://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=...
- mikepurvis 10y ago
  I like the multi-colour bars in particular— very information dense. The fact that it's all HTML and not an embedded image is so much the better.
- tomtheelder 10y ago
  Agreed, except for the survey answers. The data presented there is essentially impenetrable, and I am extremely suspicious of the methodology.
  - rsc 10y ago
    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.
rodionos 10y ago
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.
nindalf 10y ago
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 10y ago
  >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 10y ago
    >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.
vvanders 10y ago
VSCode seems to be making strong inroads. 2nd only to VIM(13%) at 9%.
- Aissen 10y ago
  Yes, it has seen very strong adoption in the Go community.
- tonyedgecombe 10y ago
  The Go plugin does seem to work reasonably well although I may well switch once the JetBrains offering is ready.
eternalban 10y ago
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.
noisy_boy 10y ago
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 10y ago
  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 10y ago
    I agree. Error handling in Go can be very cumbersome. I like the explicitness of it, but it can definitely be smoother.
    - vetinari 10y ago
      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.
      - szemet 10y ago
        I guess many people don't have problem with the 'errors are values' concept, just would like to handle them with much less boilerplate: like in Rust or Haskell...
      - 10y ago
camus2 10y ago
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.
thewhitetulip 10y ago
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-textbook https://github.com/thewhitetulip/web-dev-golang-anti-textboo...
tracker1 10y ago
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 10y ago
  JS as a secondary language to Go is absolutely not surprising, given Go's focus on web applications.
  - tracker1 10y ago
    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.
zeveb 10y ago
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!

119 points by stablemap 10y ago

tapirl 10y ago

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

golergka 10y ago
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 10y ago
  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.
  - themihai 10y ago
    There is an experimental package manaent which most likely will become defaul in Go 1.9
  - geoka9 10y ago
    You can also "vendor", there's support in Go for it.
    - xienze 10y ago
      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.
      - geoka9 10y ago
        For sure, I was just pointing out a workaround.
      - prodigal_erik 10y ago
        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.
    - notheguyouthink 10y ago
      Vendor has some very basic problems though, and honestly i think it's unusable due to that. It's a ticking time bomb, imo. In short, types, especially interfaces in returns, are strictly bound to their location which might be a vendor. If two libraries are using vendors[1] then the types are inherently incompatible between the two libraries. My most common point of failure for this is running into Logging interfaces that return themselves. That interface is completely incompatible with the other package's vendored logger, and so you have to have two instances of a logger - one for each package. [1]: (ie, they both have a main package and a library package, so they both have vendors). It's to the point where if you have a main and a library, like many repos, you should simply move the main to another repo entirely.. which sucks, imo.
- grey-area 10y ago
  It's referring to being able to pin dependencies easily so that you have a stable set of dependencies which is defined. At present go get, while convenient, fetches from head, so things can break when you move computer for example and refetch dependencies, or a new team member comes on board, or if you have an open source project.

skywhopper 10y ago

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 10y ago
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.

grey-area 10y ago

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 10y ago
What's wrong with struct tags?
- grey-area 10y ago
  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.

grabcocque 10y ago

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.

rem7 10y ago
Well they're listening... at least in the next couple of versions there should be an official dependency manager coming out. IMHO it's meh. They need to get rid of the damn gopath.
- chimeracoder 10y ago
  Between the new default GOPATH and the support for vendoring, I'm not sure I know what getting rid of the GOPATH would even mean anymore. As a Go programmer since the 1.0 days, the concept of the GOPATH that existed when I started using the language is long gone.
  - rem7 10y ago
    vendor still doesn't work if your project is outside of GOPATH. The only thing the vendor folder is doing right now is precedence. Dep, the pre-alpha tool that is lining up to be the official dependency manager still doesn't work outside the GOPATH, hopefully they change that. The only thing that Go 1.8 did was add a default to GOPATH to $HOME/go. In my ideal world, I should be able to clone a go project anywhere on my system, fetch the dependencies from the internet, yes the internet, because its 2017. (if you're that concerned with security fine, include them in your repo) but I should be able to call go build in that directory wherever it is.
- sagichmal 10y ago
  Everyone involved in the technical decisionmaking agrees that, long term, the GOPATH will be deprecated and removed. The question is just about getting from here to there without fucking people's workflows too badly. It will probably be 2 or 3 more release cycles, at least, before that's a reality.

zigzigzag 10y ago

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 10y ago
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.

themihai 10y ago

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.

xiaq 10y ago

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.

k__ 10y ago
I also switched from SO to reading source in GitHub for my JS problems. Life became less ambiguous
- eduren 10y ago
  I feel like whenever I'm forced to dig into my node_modules folder I come out with a greater understanding (and a headache or two for my troubles).
Clex 10y ago
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 10y ago
  C? Try comparing it with Scala.
  - tormeh 10y ago
    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.
tonyedgecombe 10y ago
That could be a reflection on the rather thin documentation around the standard library.

coldtea 10y ago

>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.

bla2 10y ago
But, also, number one liked issue: simplicity. The go team doesn't say they don't want generics, they say they haven't found a non-complicated way to implement generics.
- coldtea 10y ago
  Well, I don't think there's some magic way. There are just the N ways PL research has found for implementing generics. Either they implement them, and tackle the complication one of those N ways entails, or they don't. Besides, has anyone seen much experiments, with actual coding or at least design, for finding this "non-complicated" way anyway? Not just some post once in a blue moon re-iterating the basic well known tradeoffs.
  - gribbly 10y ago
    >Besides, has anyone seen much experiments, with actual coding or at least design, for finding this "non-complicated" way anyway? Proposal from Ian Lance Taylor, Go developer at Google https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-... View of Russ Cox, Go developer at Google https://research.swtch.com/go2017#generics https://research.swtch.com/go2017#generics
    - coldtea 10y ago
      Yeah, I've read both -- and more. None of this is what I described: either actual code, even if in some experimental compiler branch/fork, or at least a concrete design. Ian's just reiterates the various options (Rob Pike has already written similar things), and Russ Cox is just several vague ideas for future additions to the language.

octref 10y ago

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.

SonicSoul 10y ago
good point. i brushed over this fact since the charts were not especially pretty, but your comment helped me focus on how they're inline with content you don't need to jump between graph and description. it reminds me of how sparklines[0] can be used to visualize data in line. [0] https://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR https://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=...
mikepurvis 10y ago
I like the multi-colour bars in particular— very information dense. The fact that it's all HTML and not an embedded image is so much the better.
tomtheelder 10y ago
Agreed, except for the survey answers. The data presented there is essentially impenetrable, and I am extremely suspicious of the methodology.
- rsc 10y ago
  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.

rodionos 10y ago

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.

nindalf 10y ago

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 10y ago
>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 10y ago
  >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.

vvanders 10y ago

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

Aissen 10y ago
Yes, it has seen very strong adoption in the Go community.
tonyedgecombe 10y ago
The Go plugin does seem to work reasonably well although I may well switch once the JetBrains offering is ready.

eternalban 10y ago

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.

noisy_boy 10y ago

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 10y ago
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 10y ago
  I agree. Error handling in Go can be very cumbersome. I like the explicitness of it, but it can definitely be smoother.
  - vetinari 10y ago
    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.
    - szemet 10y ago
      I guess many people don't have problem with the 'errors are values' concept, just would like to handle them with much less boilerplate: like in Rust or Haskell...
    - 10y ago

camus2 10y ago

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.

thewhitetulip 10y ago

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-textbook https://github.com/thewhitetulip/web-dev-golang-anti-textboo...

tracker1 10y ago

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 10y ago
JS as a secondary language to Go is absolutely not surprising, given Go's focus on web applications.
- tracker1 10y ago
  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.

zeveb 10y ago

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!