The latest Go Developer Survey investigated the take up of three features introduced in Go 1.18 - Generics, Fuzzing and Go Workspaces, probing developers' opinions and the barriers to adoption.

We recently reported on the release of Go 1.19, see Vulnerability Management Added To Go, but before that version reached the Go user base it a survey was conducted to look into developers' experience working of the new features in Go 1.18, specifically generics, security tooling, and workspaces.

A total of 5,752 people participated in the survey of whom around a third were "randomly sampled". While the other two thirds of survey takers, referred to as "self-selected" had found it via Twitter or the Go blog this group responded to the survey after seeing a prompt for it in VS Code. Everyone using the VS Code Go plugin between June 1 - June 21st 2022 had a 10% of receiving this random prompt and the number of respondents, around 2000, is considered large enough to generalize these findings to the larger community of Go developers.

Reporting the results of this survey, Todd Kulesza, UX research lead for the Go programming language at Google, noted:

Most survey questions showed no meaningful difference between these groups, but in the few cases with important differences, readers will see charts that break down responses into “Random sample” and “Self-selected” groups.

One such question related to Go's support for multi-module workpaces:

Fewer than 10% of respondents had used Go workspaces, 9% of the "self-selected" group and 8% of the "randomly-sampled" group. However while the main reason why not among the former group was having no immediate need for the feature, in the case of the latter group it was simply not knowing the facility was available.  Over half (53%) of randomly sampled respondents reported that they had been unaware of workspaces prior to taking the survey they had not been aware of it. This compared to  33% of self-selecting respondents, i.e. those following Golang and or reading the go.dev blog where new features are promoted. 

In the case of generics, the vast majority of survey respondents (86%) were already aware generics shipped as part of the Go 1.18 release. Again the self-selected group was better informed with 93% knowing this fact compared to 688% of randomly sampled respondents.

Over a quarter of respondents had already started to use Go generics and only 6% had no intention of using the feature and the most common response (54%) was lack of a specific need to do so.

The survey revealed that 8% of respondents wanted to use generics in Go, but were currently blocked by something and an open-ended question, answered by 533 respondents, was included to provide information about the difficulties encountered. The report states:

A majority of respondents fell into one of two categories. First, 30% of respondents said they hit a limit of the current implementation of generics, such as wanting parameterized methods, improved type inference, or switching on types. Respondents said these issues limited the potential use cases for generics or felt they made generic code unnecessarily verbose. The second category involved depending on something that didn’t (yet) support generics—linters were the most common tool preventing adoption, but this list also included things like organizations remaining on an earlier Go release or depending on a Linux distribution that did not yet provide Go 1.18 packages (26%)

Among the 406 survey participant who responded to a request for additional feedback, 43% provided a general "thank you" or positive sentiment and 10% reported that generics had already simplified their code, or resulted in less code duplication. Only 6% expressed negativity, although 31% referred to a limitation of Go’s current implementation of generics, feedback that the Go team intends to use going forward. 

After the inclusion of built-in fuzzing tools in Go 1.18 several question about security testing practices were included in this survey. The overall conclusion in the report was:

Awareness of Go’s built-in fuzz testing was much lower than generics, and respondents had much more uncertainty around why or when they might consider using fuzz testing.

Only 5% of respondents has already started to use these tools and a further 4% had wanted to but had encountered obstacles to doing so. Probing this with an open ended follow-up question, with 146 responses, the main reasons for fuzzing being difficult to use were not technical issues. The top three responses to emerge were:

• not understanding how to use fuzz testing (23%)
• lack of time to devote to fuzzing/security in general (22%)
• understanding why and when developers might want to use fuzz testing (14%).

In his report, Todd Kulesza commented:

These findings indicate that we still have work to do in terms of communicating the value of fuzz testing, what should be fuzz tested, and how to apply it to a variety of different code bases.

More Information

Go Developer Survey 2022 Q2 Results

Related Articles

Go Survey 2021

Vulnerability Management Added To Go 1.19

Go 1.18 Released With Generics And Fuzzing

Go Adopts Generics

Insights Into Where Go Is Going

Go Survey Shows Show Continuing Preference For Go

Go Survey Revelations

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info