▲ 39 ▼ Go Survey 2016 results
This post summarises the result of the December 2016 Go User Survey along with our commentary and insights. We are grateful to everyone who provided their feedback through the survey to help shape the future of Go.
Register to comment or vote on this story
On the subject of generics in Go, this is useful reading as it lays out all the possible solutions/pitfalls: https://github.com/golang/proposal/blob/master/design/15292-generics.md
There is some great data in here, I love the detailed presentation of results rather than just presenting a summary. Some interesting questions and responses here:
What changes would most improve the Go documentation?
Collectively examples gets 26% and docs gets 6% - would be nice to see the data cleaned up a bit here, as there are multiple examples entries.
What Go libraries do you need that aren't available today?
Interesting to see such demand for UI support and mobile support - these are the two hardest parts to crack, given that cross platform UIs typically please no-one. I'd like to see the go team take a radically different approach here playing to Go's strengths - define some framework for presenting web UIs with a Go backend on Android and iOS.
What changes would improve Go most?
The G word makes an entrance as the top request. 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/better containers.
Everyone is reasonably happy with editing it seems.
And finally golangnews is somewhere in the middle as a news source for gophers - thanks to all the readers!
Splitting the write-in responses into individual keywords is a little confusing - it's weird for example to see words like 'great' without seeing the context they were used in (e.g. docs need a great deal of work, docs are great already etc).. It'd be great to see the data available from this (in anonymised form if necc.) so that others can also look at the responses.
> I'd like to see the go team take a radically different approach here playing to Go's strengths - define some framework for presenting web UIs with a Go backend on Android and iOS.
That would be cool, essentially server side rendering of the UI. A number of big players do this, Facebook for one but Spotify too, they've even open sourced the associated iOS framework: https://github.com/spotify/HubFramework. There's also Jasonette, http://jasonette.com, which is actually a lot of fun to experiment with. I've written a few iOS apps for home automation things thanks to Jasonette.
> 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/better containers.
What is it you don't like about struct tags? I've found those to be rather useful when converting between data representations. The comments as directives I assume you mean things like the build tags and generate directives? I like what they enable you to do but I'm not a fan of having those in comments indeed.
You can use limited html like blockquote in comments, WYSIWYG editor coming soon...
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.
They're pragmatic in a way, and in small doses useful, but I just think they're adding unstructured informal data attributes to structs and fields which is better specified formally in code. Take for example an xml field, it might over time have name,attr,chardata,innerxml,omitempty,cdata attributes added (and more in future), and then on top of that is piled any json representation and the db representation and whatever other dsl library authors choose to require in future.
I would prefer instead that types define functions to Marshal/Unmarshal, and that be the standard way to get data in and out of the type, it's clearer and extensible - when a new data format is required just write another function. So I avoid struct tags myself and use this approach for database mapping, and am much happier with it. By the time you're adding things like omitempty for xml it's just so much better if the code itself specifies this with a simple if condition in a function mapping from struct to xml.
Yes I think those are just in comments because they didn't want to change the language spec, but really something like generate should be clearly specified in the language rather than hidden in magic comments.
Ha, I had no idea. I've tried a few Markdown inspired things that usually work. Is there a doc somewhere that details what can and can't be used?
Do you have an example of what that would end up looking like? I like the idea but it also sounds that you'd end up maintaining a lot more code if you don't use struct tags. How do you deal with JSON in this case? Do you keep using struct tags for those? And also, how do you deal with naming/remapping the fields in XML/JSON or db to the struct members?
I like the idea in general and especially once you mix in XML this gets unpleasant in struct tags. Just trying to get a feel for what this would look like and how it would work :).
This was an interesting titbit, there's a need for more and better documentation and tutorials:
*"When asked about the biggest challenges to their own personal use of Go, users mentioned many of the technical changes suggested in the previous question. The most common themes in the non-technical challenges were convincing others to use Go and communicating the value of Go to others, including management. Another common theme was learning Go or helping others learn, including finding documentation like getting-started walkthroughs, tutorials, examples, and best practices....The documentation is not clear enough for beginners. It needs more examples and often assumes experience with other languages and various computer science topics.”*
This is confirmed by my recent experience. As a relatively experienced Go programmer in certain domains (lower-level networking; simulation and scientific computing) I recently started a project in a different area (interfacing with a web API) and was surprised at how difficult it was to find simple--and reliably correct--examples for things like the proper way to construct an HTTP PUT request or how to use the oauth2 library.
Yes definitely a lack of good trustworthy resources for specific topics. Perhaps this is something the Go team could look at building out on their website separately from the docs. There is so much in the standard library and I think a lot of it gets missed by people learning Go.
Wow, that was comprehensive. Definitely worth reading if you're interested in who uses Go and why. Thanks to the go team for putting it all together!