Russ Cox's 2017-year Go development program

This is a creation in Article, where the information may have evolved or changed.

Note: Russ Cox is currently the leader of Go team

My goal is to help developers. I want to make sure that the work that our go team does has a significant positive impact on go developers. This sounds easy, but there are many problems, such as spending too much time cleaning up or optimizing unwanted code, responding to the most common or recent complaints or requests, or focusing too much on short-term improvements. It is important to ensure that our development efforts are focused on the most effective places.

This article outlines some of my priorities this year. It's just a personal view, not a go team.

One reason for publishing this article is to collect feedback. If you have any ideas or suggestions, please feel free to comment or create a new GitHub issue.

Another reason is to make people understand that we know these issues are important. People often think that the go team lacks action because we think everything is perfect, and actually we have other higher priority work to do.

Type aliases Alias

There is a duplicate problem when moving a type from one package to another during a large code base refactoring. We tried to fix it with a generic alias, which introduced at least two issues: we didn't explain the problem with the change, we didn't deliver it in time, so we didn't release the feature in 1.8. Nevermore, future, I made a speech and wrote an article about the basic question of type aliases, and started a discussion about the solution on Go issue tracker. Now it seems that the more limited type aliases is the right choice. I want to make sure that type aliases can be released with Go 1.9 smoothly.

Package Management Management

I designed the Goinstall (it becomes a "go get") tool. Many changes have taken place since then. In particular, other language ecosystems have really raised expectations for package management, and most people in the open source world agree with the semantic version, which provides the basis for inferring version compatibility. Go needs to do a better job here, and a group of code contributors have been trying to solve the problem. I want to make sure that these ideas are well integrated into the standard go toolchain and make package management a reason why people like go.

Build Improvement

The design of Go build system has some shortcomings that should be repaired. Here are three representative examples, and I intend to redesign the go command to solve these problems.

The build speed is too slow because the GO command does not actively cache the build result. Many people do not realize that using go install can save build results, and go build is not. So they run the duplicate go Build command to slow down the build process. When modifying dependencies, the same happens in go test (should use Go test-i).

The test results should also be cached: If the input of the test does not change, then it is usually not necessary to rerun the test. This will reduce the overhead of running "all tests" when there is little or no change.

Outside the Gopath should be the same as in the Gopath work. In particular, you can git clone a repo, run the Go command, and make them work properly. Package management only makes this more important: you need to be able to work on different versions of packages, such as V1 and V2, without having to assign them a completely separate gopath.

Code Corpus

The actual use of many corpora can be seen from the articles and lectures mentioned in the previous type aliases section. We also define VET plug-ins that must address the problems that often occur in real-world programs. I would like to see an analysis of practical practices as a standard way for us to discuss and evaluate go changes.

Now that there is no agreed code corpus for these analyses (everyone must first create their own), this is a much too heavy work for each person. I want to open a separate, self-contained git repo, which includes our official benchmark corpus for analysis. One possible starting point might be the top 100 go language libraries on GitHub.

Automatic Vet

Go comes with the powerful tool of Go vet. When the vet has output, you should check the vet output. Everyone has to run it. In particular, I think we can run vet during go testing without slowing down the compile-edit-test cycle. If we can do this, and we enable the vet check to be limited to 100% accurate, we can make pass vet a precondition for running the test. Developers don't need to remember to run go vet. They run go test.

Errors & Best Practices

Part of Go error is the function that is called and the relevant available context, including the operation being attempted (for example, the function name and its arguments). For example, this program:

err: = OS. remove   "/tmp/nonexist" ) 
   FMT. println   (err)    

The output is as follows:

remove /tmp/nonexist:nofileor directory

However, not all go codes are like OS. Remove to join the context, most of the code is like this:

iferr != nil {    
    returnerr
}

Along the call stack, discard useful context (like remove/tmp/nonexist, etc.). I want to try to understand whether our expectations of containing the context are wrong, or we can do something to help write code that returns a more friendly error.

There are also various discussions about the context interface for peeling errors in the community. I want to try to understand when it is meaningful and whether it should be adopted.

Context & Best Practices

We added a new context package to go 1.7 to hold information about the request, such as timeout, cancellation status, and authentication information. A separate context is immutable (like a single string or int): It can only export a new, updated context, and pass that context to the call stack or (less common) back to the caller. The context is now used in APIs such as Database/sql and net/http, primarily to stop processing requests when the caller is no longer interested in the results. The timeout information is appropriate for saving in the context, but the database option is not, because it is unlikely that all possible database operations will be performed during the request. What about the current clock source or log sink? Is it appropriate to store in context? I want to try to understand and describe scenarios that are appropriate for the context.

Memory model

The Go memory model requires more compilers to work with than other languages. I think the core compiler and runtime developers agree that these atomic behaviors should be roughly the same as C + + SEQCST Atomics or Java volitiles, and we still need to carefully write down the memory model or write a long blog.

Immutability

Race detector is one of the most popular features of go. But it would be better without race. If there are reasonable ways to integrate immutability into go, then programmers can make explicit checks to assert what can and cannot be written, thereby eliminating certain competition at compile time. Go already has an immutable type-string (string is immutable []byte type). Although I don't think this will be introduced this year, I want to get a better understanding of the solution. Javari,midori,pony and Rust have made interesting points in the solution discussion, and there are a number of research papers in addition.

In the long run, if we can eliminate the competition statically, it will eliminate the need for most of the memory models. This may be an impossible dream, but I want to get to know the solution better.

Generic type

There is nothing more than a question of whether go should support generics (or what should have happened a few years ago), which can be a more contentious issue for go and non-go developers. I don't believe the go team once said "go doesn't need generics." What we're talking about is the higher priority that go faces. For example, better package management support will have a much more direct positive impact on most go developers than increasing generics. But we do understand that the lack of parametric polymorphism for Go is a significant hurdle.

Personally, I would like to be able to write general channel processing functions such as:

//Join makes all messages received on the input channels
//available for receiving from the returned channel.
 func Join(Inputs ... <-chan T) <-chanT
//Dup duplicates messages received on C to both C1 and C2.
 func Dup(C <-chan T) (C1, C2 <-chanT)

I also want go to support advanced data processing abstractions (similar to Flumejava or C # LINQ), which catch type errors at compile time rather than at run time. Generics also take on the possibility of increasing the implementation of general-purpose data structures or algorithms, but I personally feel that a wide range of applications are more compelling.

In order to find the right way to add generics to go, we've been working hard for years. Some people recommend suspending the design of generic parameter polymorphism (such as Chan T) as well as string and []byte. If the latter is handled with invariance parameterization (as described in the previous section), it may simplify the need for generic design.

When I started thinking about the generics of Go in 2008, the main examples of learning were c#,java,haskell and ML. There is no one way to be perfect. Now, there are newer attempts, including Dart,midori,rust and Swift.

This is the design space we explored over the years. Given the understanding of immutability and the realization of other languages, this may be the time to revisit generics. I don't think generics will be introduced this year, but I would like to say that I can better understand the relevant solutions.