blob: 86e6d94fb378302a98c279ba317ea86b4deda2b5 [file] [log] [blame]
Russ Coxaf5018f2020-03-09 23:54:35 -04001# Contributors Summit
Steve Francia8d86d8a2017-07-19 14:16:17 -050023 Aug 2017
3Tags: community
Russ Coxfaf1e2d2020-03-14 09:44:01 -04004Summary: Reporting from the Go Contributor Summit at GopherCon 2017.
Steve Francia8d86d8a2017-07-19 14:16:17 -05005
6Sam Whited
7
Russ Coxaf5018f2020-03-09 23:54:35 -04008## Introduction
Steve Francia8d86d8a2017-07-19 14:16:17 -05009
10The day before GopherCon, a group of Go team members and contributors gathered
11in Denver to discuss and plan for the future of the Go project.
12This was the first ever event of its kind, a major milestone for the Go project.
13The event comprised a morning session revolving around focused discussions on a
14theme, and an afternoon session made up of round table discussions in small
15break-out groups.
16
Russ Coxaf5018f2020-03-09 23:54:35 -040017### Compiler and runtime
Steve Francia8d86d8a2017-07-19 14:16:17 -050018
19The compiler and runtime session started out with a discussion about refactoring
20`gc` and related tools into importable packages.
21This would reduce overhead in the core tools and in IDEs which could embed the
22compiler themselves to do quick syntax checking.
23Code could also be compiled entirely in memory, which is useful in environments
24that don't provide a filesystem, or to run tests continually while you develop
25to get a live report of breakages.
26More discussion about whether or not to pursue this line of work will most
27likely be brought up on the mailing lists in the future.
28
29There was also a great deal of discussion around bridging the gap between
30optimized assembly code and Go.
31Most crypto code in Go is written in assembly for performance reasons; this
32makes it hard to debug, maintain, and read.
33Furthermore, once you've ventured into writing assembly, you often can't call
34back into Go, limiting code reuse.
35A rewrite in Go would make maintenance easier.
36Adding processor intrinsics and better support for 128-bit math would improve
37Go's crypto performance.
38It was proposed that the new `math/bits` package coming in 1.9 could be expanded
39for this purpose.
40
41Not being all that familiar with the development of the compiler and runtime,
42this for me was one of the more interesting sessions of the day.
43I learned a lot about the current state of the world, the problems, and where
44people want to go from here.
45
Russ Coxaf5018f2020-03-09 23:54:35 -040046### Dependency management
Steve Francia8d86d8a2017-07-19 14:16:17 -050047
Russ Coxaf5018f2020-03-09 23:54:35 -040048After a quick update from the [dep](https://github.com/golang/dep) team on the
Steve Francia8d86d8a2017-07-19 14:16:17 -050049status of the project, the dependency management session gravitated towards how
50the Go world will work once dep (or something dep-like) becomes the primary
51means of package management.
52Work to make Go easier to get started with and make dep easier to use has
53already started.
54In Go 1.8, a default value for `GOPATH` was introduced, meaning users will only
55have to add Go's bin directory to their `$PATH` before they can get started
56with dep.
57
58Another future usability improvement that dep might enable, is allowing Go to
59work from any directory (not just a workspace in the GOPATH), so that people can
60use the directory structures and workflows they're used to using with other
61languages.
62It may also be possible to make `go install` easier in the future by guiding
63users through the process of adding the bin directory to their path, or even
64automating the process.
65There are many good options for making the Go tooling easier to use, and
66discussion will likely continue on the mailing lists.
67
Russ Coxaf5018f2020-03-09 23:54:35 -040068### The standard library
Steve Francia8d86d8a2017-07-19 14:16:17 -050069
70The discussions we had around the future of the Go language are mostly covered
Russ Coxaf5018f2020-03-09 23:54:35 -040071in Russ Cox's blog post: [Toward Go 2](https://blog.golang.org//toward-go2), so
Steve Francia8d86d8a2017-07-19 14:16:17 -050072let's move on to the standard library session.
73
74As a contributor to the standard library and subrepos, this session was
75particularly interesting to me.
76What goes in the standard library and subrepos, and how much it can change, is a
77topic that isn't well defined.
78It can be hard on the Go team to maintain a huge number of packages when they
79may or may not have anyone with specific expertise in the subject matter.
80To make critical fixes to packages in the standard library, one must wait 6
81months for a new version of Go to ship (or a point release has to be shipped in
82the case of security issues, which drains team resources).
83Better dependency management may facilitate the migration of some packages out
84of the standard library and into their own projects with their own release
85schedules.
86
87There was also some discussion about things that are difficult to achieve with
88the interfaces in the standard library.
89For instance, it would be nice if `io.Reader` accepted a context so that
90blocking read operations could be canceled.
91
Russ Coxaf5018f2020-03-09 23:54:35 -040092More [experience reports](https://golang.org/wiki/experiencereports) are
Steve Francia8d86d8a2017-07-19 14:16:17 -050093necessary before we can determine what will change in the standard library.
94
Russ Coxaf5018f2020-03-09 23:54:35 -040095### Tooling and editors
Steve Francia8d86d8a2017-07-19 14:16:17 -050096
97A language server for editors to use was a hot topic in the tooling session,
98with a number of people advocating for IDE and tool developers to adopt a common
99"Go Language Server" to index and display information about code and packages.
Russ Coxaf5018f2020-03-09 23:54:35 -0400100Microsoft's [Language Server Protocol](https://www.github.com/Microsoft/language-server-protocol)
Steve Francia8d86d8a2017-07-19 14:16:17 -0500101was suggested as a good starting point because of its wide support in editors
102and IDEs.
103
104Jaana Burcu Dogan also discussed her work on distributed tracing and how
105information about runtime events could be made easier to acquire and attached to
106traces.
107Having a standard "counter" API to report statistics was proposed, but specific
108experience reports from the community will be required before such an API can be
109designed.
110
Russ Coxaf5018f2020-03-09 23:54:35 -0400111### The contributor experience
Steve Francia8d86d8a2017-07-19 14:16:17 -0500112
113The final session of the day was on the contributor experience.
114The first discussion was all about how the current Gerrit workflow could be made
115easier for new contributors which has already resulted in improvements to the
116documentation for several repos, and influenced the new contributors workshop a
117few days later!
118
119Making it easier to find tasks to work on, empowering users to perform gardening
120tasks on the issue tracker, and making it easier to find reviewers were also
121considered.
122Hopefully we'll see improvements to these and many more areas of the
123contribution process in the coming weeks and months!
124
Russ Coxaf5018f2020-03-09 23:54:35 -0400125### Breakout sessions
Steve Francia8d86d8a2017-07-19 14:16:17 -0500126
127In the afternoon, participants broke out into smaller groups to have more
128in-depth discussions about some of the topics from the morning session.
129These discussions had more specific goals.
130For example, one group worked on identifying the useful parts of an experience
131report and a list of existing literature documenting Go user experiences,
132resulting in the experience report
Russ Coxaf5018f2020-03-09 23:54:35 -0400133[wiki page](https://golang.org/wiki/experiencereports).
Steve Francia8d86d8a2017-07-19 14:16:17 -0500134
135Another group considered the future of errors in Go.
136Many Go users are initially confused by, or don't understand the fact that
137`error` is an interface, and it can be difficult to attach more information to
138errors without masking sentinel errors such as `io.EOF`.
139The breakout session discussed specific ways it might be possible to fix some of
140these issues in upcoming Go releases, but also ways error handling could be
141improved in Go 2.
142
Russ Coxaf5018f2020-03-09 23:54:35 -0400143## Community
Steve Francia8d86d8a2017-07-19 14:16:17 -0500144
145Outside of the technical discussions, the summit also provided an opportunity
146for a group of people from all over the world who often talk and work together
147to meet in person, in many cases for the first time.
148There is no substitute for a little face-to-face time to build a sense of mutual
149respect and comradeship, which is critical when a diverse group with different
150backgrounds and ideas needs to come together to work in a single community.
151During the breaks, Go team members dispersed themselves among the contributors
152for discussions both about Go and a little general socialization, which really
153helped to put faces to the names that review our code every day.
154
Russ Coxaf5018f2020-03-09 23:54:35 -0400155As Russ discussed in [Toward Go 2](https://blog.golang.org//toward-go2),
Steve Francia8d86d8a2017-07-19 14:16:17 -0500156communicating effectively requires knowing your audience.
157Having a broad sample of Go contributors in a room together helped us all to
158understand the Go audience better and start many productive discussions about
159the future of Go.
160Going forward, we hope to do more frequent events like this to facilitate
161discourse and a sense of community.
162
163.image contributors-summit/IMG_20170712_145844.jpg
164.image contributors-summit/IMG_20170712_145854.jpg
165.image contributors-summit/IMG_20170712_145905.jpg
166.image contributors-summit/IMG_20170712_145911.jpg
167.image contributors-summit/IMG_20170712_145950.jpg
168
169Photos by Steve Francia