golang.org/toolchain@v0.0.1-go1.9rc2.windows-amd64/blog/content/contributors-summit.article (about)

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