[HN Gopher] Go Developer Survey 2019 Results
___________________________________________________________________
Go Developer Survey 2019 Results
Author : ainar-g
Score : 98 points
Date : 2020-04-20 19:17 UTC (3 hours ago)
(HTM) web link (blog.golang.org)
(TXT) w3m dump (blog.golang.org)
| ayoisaiah wrote:
| Suprised to see Vim usage decreasing every year. Presumably most
| are defecting to Goland
| alrs wrote:
| I doubt anyone is defecting in any numbers, but that the unix
| die-hards are being diluted by an influx of developers who
| prefer an IDE.
| habosa wrote:
| Soon Go will have both generics and package management, two
| things the maintainers really didn't think it needed on Day One.
| I don't say this to insult anyone, Go has always been a great and
| unique language. I say this as a plea to any aspiring language
| designers out there: please don't try to make a modern general
| purpose language without these things. We really do need them.
| wgyn wrote:
| My hot takes...
|
| 1) Fast adoption of GoLand/IntelliJ (and death of Sublime/Atom)
|
| 2) Nearly complete adoption of modules (my company is behind!)
|
| 3) "I feel welcome in the Go community" dipped from 82% to 75%.
| Anecdotally most people in Go are really nice but some people are
| aggressively pedantic (don't call it the Golang community!)
| lawl wrote:
| I feel like the answer to "what prevents you from better
| debugging/profile" that's dominant, "lack of
| knowledge/experience" may be more of a catch-all than actually
| highlight a problem.
|
| Like, there's always something you can do better, most people
| don't want to claim they know everything. So in a survey I'd
| probably check that box/type that answer even if I didn't have an
| actual problem.
| swagonomixxx wrote:
| > Does your organization manage their own internal go
| documentation server (similar to godoc.org)? > No (85%)
|
| I would be very open to setting this up at my org - is there a
| canonical way to do this?
|
| > What is the biggest challenge you personally face using Go
| today? > Working with modules / vendoring / pkg mgmt 12%
|
| Go has come a long way since the solutions in the early days and
| is now supremely better than it every was. However, vendoring is
| still confusing, and it's unclear when one should commit vendor
| files (we did that at one of the places I used to work) and when
| one shouldn't. We kept getting afraid that one day some guy would
| just delete that repo off GitHub, or somebody would end up
| hacking it, then we can't get an important fix out into prod. I'm
| not sure if the Go team has any advice regarding this.
|
| > What is the biggest challenge you personally face using Go
| today? > Issues with tooling 12%
|
| I think Go in general has become very mature. From a tooling
| standpoint it's almost feature complete. The only thing I would
| like to see there is better autocomplete and tooling around
| calling C from Go but I know that's kind of hard to achieve. I
| frequently work with C libraries that I have to call from Go
| because Go is simply easier to write than C, but I don't think
| that Cgo has good integration with gopls at the moment (and I
| don't think it did in any other tooling that I've used).
| zachgersh wrote:
| RE: modules and vendoring, you should no longer have to worry
| about a package going away now that proxies have been
| introduced (the default proxy right now being
| proxy.golang.org).
|
| You should be able to pull all your modules from a proxy, minus
| any private repos you control (which you can either setup our
| own proxy for OR set The GOPROXY var to go direct to vcs for
| it).
|
| Also, not vendoring should give you a smaller repo and build
| speed shouldn't suffer too much (proxy caching and such).
| swagonomixxx wrote:
| Ah good point about GOPROXY.
|
| So if I have a mix of private and public dependencies that I
| pull in, can I specify a specific proxy for the private ones?
| Is it the GOPRIVATE env var?
| chairmanwow1 wrote:
| The proxy should maintain a copy of all dependencies
| (public and private), so only one should be necessary.
| zachgersh wrote:
| This should be clarified, if you setup YOUR OWN proxy it
| can handle both public and private modules (side note I
| haven't been able to verify this yet with artifactory).
|
| You can also just let your GOPROXY fallback go "direct"
| which will then go straight to vcs (you need to make sure
| you have a gitconfig setup to redirect https to ssh).
| xemdetia wrote:
| I'm really hoping that gopls gets to 1.0 soon. I feel like gopls
| is the elephant in the room that's taking a lot of air from some
| of the smaller tools, and I'm glad it's being called out as a
| priority in this report.
| adonese wrote:
| It has gotten more fixes in the last couple of releases. I now
| in situation where it works in vscode as it used to with
| gopath. But yeah that was very painful
| kris-s wrote:
| Between languages like Go, Rust, Swift, and others I feel pretty
| optimistic about these new players (and I very much prefer more
| language diversity).
|
| No surprise to see generics being so strongly pined for again.
| Very curious about how Go getting generics will change its
| position in the landscape.
| vardump wrote:
| > ...how Go getting generics will change its position in the
| landscape.
|
| I think it'll have a minimal immediate effect. It'll quieten
| the vocal ones, but being a pragmatic bunch of people, most
| golang users just won't care much, at least at first. No doubt
| libraries will adopt it over time. Other golang projects will
| slowly follow.
| jeremyjh wrote:
| I think this is right. Few people will say "oh Go has
| generics let me start using it now". But at the same time we
| shouldn't underestimate the benefit improved libraries could
| have on adoption in the long-run. I've heard several people
| say they just are not happy with any ORM in the Go ecosystem,
| for example and I think that situation would improve
| significantly with generics.
| c-cube wrote:
| That's hard to measure. If Go had sum types and generics
| I'd be more willing to give it a serious try , but in its
| current state I don't see myself writing complex
| algorithmic code in it. Maybe other people feel the same,
| especially among the crowd already used to static typing.
| swagonomixxx wrote:
| If Go ends up getting generics it will be a serious competitor
| to Java in the enterprise small-medium size application space,
| and perhaps make it viable for larger applications.
|
| So I think it will be a huge step up for Go. This is of course
| if they do it in such a way that does not increase language
| complexity by an order of magnitude (e.g C++ style templates).
| I think Java style generics is not as complex and something
| along those lines would be a huge win IMO.
| haolez wrote:
| What if "huge applications" is a bad pattern and Go is
| pushing forward in the right direction? :)
| hvs wrote:
| I'm probably not representative, but when I last really tried
| to use Go on a project seriously the lack of generics and the
| way that errors were handled became a real blocker for me.
| Which is unfortunate, because I really wanted to like the
| language and did for the most part. But those two things made
| development feel like a real chore.
|
| Again, I don't expect my personal preferences to dictate
| language development. Clearly many do not feel the way I do,
| but I do find it telling that those were the top two
| complaints. The pain is real, at least to a subset of us.
| enitihas wrote:
| Java is moving to complicated generics though, see project
| Valhalla, although not like C++ templates, but more about
| specialization for primitive types, which can be a huge
| performance win.
| swagonomixxx wrote:
| Interesting, I haven't heard of Valhalla (I haven't really
| used Java since around 2014). From their landing page it
| seems like their priorities are value types (which Go
| already has - you need to specify pointer types explicitly)
| and support value types as generic type parameters, which
| Go has to do, because it has value types.
|
| I guess it will complicate things a bit, you're right. I'm
| pretty happy I don't have to use Java anymore though :)
| jeremyjh wrote:
| > No surprise to see generics being so strongly pined for
| again. Very curious about how Go getting generics will change
| its position in the landscape.
|
| Well, only 25% of respondents said there were _any_ features
| blocking adoption; and of _that_ group yes the majority want
| generics. Since this is a survey of Go developers, it is not
| surprising to find out that a very solid majority find the
| language usable as it is. I think this also limits what this
| particular survey can tell us about the uptick in adoption you
| might see if that feature ever lands.
| rmdashrfstar wrote:
| I only read the tl;dr, but I expected some questions centered
| around most commonly identified missing features in Go (i.e.
| first class support for enumerations, generics, naked return,
| compiler generating similar code for named vs unnamed returns,
| etc.)
| throwawaygo wrote:
| ~60% of respondents have <2 years experience with the language.
|
| I'd really like to see this filtered to developers with >5 years
| go experience. What do the experienced go devs want from the
| language? How do they use it?
|
| I've got a little over 9 years of almost daily use and I have
| little in common with the devs in my org that are earlier in
| their career and coming to go with a head full of some other
| language.
| swagonomixxx wrote:
| Out of curiosity, at what point do you consider someone a
| seasoned Go developer? Is it 5 years or is it more?
|
| I've been using Go since 2015 and I still feel like I'm not as
| seasoned as I perhaps should be (I'm not really an enthusiast
| of the language, I just think it's the right tool to use for
| 95%+ of the stuff I'm working on right now).
| throwawaygo wrote:
| Hard to quantify. Time in language should roughly track.
| Maybe number of companies/projects developed.
|
| Any of the dimensions you could imagine would be good
| starting points.
___________________________________________________________________
(page generated 2020-04-20 23:00 UTC)