Go 1.6 planning

[Russ Cox]

The Go 1.5 release candidate is looking good. Hopefully in a week or so it will be out, and we'll open the tree for Go 1.6 development. That makes now a good time to talk about what we want to do in Go 1.6.

Go 1.6 will be a shorter than usual cycle, because Go 1.5 ran long. The freeze is Nov 1 (2.5 months from now) and the release is scheduled for Feb 1. There are a few long-term things that have been in progress for a few cycles and may be ready for Go 1.6, most notably the new SSA-based compiler back end (at least for amd64) and transparent HTTP/2 support in net/http. 

Many of us, though, will be focusing on cleanup and polish during the Go 1.6 cycle. Go 1.5 introduced much new code, and the debugging during the freeze highlighted a number of ways we can make it cleaner, more flexible, and easier to maintain for the future. This is especially true in the runtime and the new all-Go toolchain.

There are also many lingering bugs that would be nice to finally fix. Marcel has a plan for #7363 (long-standing reflect issue), and we should try again to fix the encoding/json and encoding/xml issues whose fixes were rolled back late in Go 1.5 for compatibility reasons. There are probably many other lingering, not too important bugs that nonetheless add up to significant pain points for users. It would be nice if Go 1.6 work focused on closing these.

We are also going to try to make sure we stay focused on issues and pending CLs throughout the Go 1.6 cycle. Too many of both were left until the freeze during Go 1.5. The new Go1.6Early milestone in GitHub is meant to help, and I intend to set up a single automated weekly mail to golang-dev reminding us what's pending, summarizing CLs, issues, and proposals.

What are you planning to do in the Go 1.6 cycle? Or what GitHub issues do we not have marked with a Go 1.6 milestone yet but merit one, in your opinion?

Please reply to the thread and we'll make a high-level doc out of the responses.

Thanks.

Russ

[Dave Cheney]

Thanks for starting this discussion Russ.

For 1.6 I would like to work on

* Unifying the way auxv values are parsed,
https://github.com/golang/go/issues/9538. This was brought home to me
during the arm64 ports that there is a lot of duplication in the
syscall package for auxv parsing in linux, and as auxv will be
important for getting the page size, it sounds like a good time to
clean this up.

* Contribute arm and arm64 support for the ssa backends, or at least
do what I can so those ports do not lag so far behind they make it
problematic to switch over to the new backend when the time comes.

* finish/fix duffzero and duffcopy for ppc64 and arm64 (or remove it,
as Michael and I suspect it doesn't pay it's way on RISC)

* Remove the use of the NaCl sRPC namespace and get us off the
obsolete pepper_41, https://github.com/golang/go/issues/11961

* Address the duplication of Biobuf in the compiler,
https://github.com/golang/go/issues/10652

Thanks

Dave

> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Ian Lance Taylor]

I would like to do our best to address issues 12116 and 8310: document
how to safely pass pointers between C and Go.

This is not terribly important, but I would also like to clean up the
memory model to avoid the objections that memory model specialists
have about it. I don't know that we have an open issue about that,
but related to the memory model we have issues 9442, 7948, 5045.

Ian

[Michael Hudson-Doyle]

I'm still going to be working on shared libraries, polishing and
porting to the other architectures we support Ubuntu on.

There are some other toolchain cleanups and optimizations I'd like to
work on (a new .a file format, some codegen improvements on arm64,
maybe trying to reduce the number of integer conversions in
cmd/internal/obj...) but nothing really major.

It would be nice, although I don't know about realistic, to decide
whether to complete cmd/newlink, or try to incrementally improve
cmd/link to the point where newlink is no longer needed.

Cheers,
mwh

[brainman]

I had to look at linker code recently. In particular pe.go and ldpe.go. It looks like C code converted to Go by robot:

- no comments;

- many global variables with non descriptive names;

- code rely heavily on output file position to do all calculations;

- IO is too low level, I think we should just define appropriate structs and use binary.Read and binary.Write;

- some duplicate code that also lives (or should live) in debug/pe;

- all code in one big file (pe - 1254 lines, ldpe.go - 534 lines);

- use of linked lists instead of arrays and slices;

- functionality is spread around different funcs, files and even packages and different arch and binary file formats - it is difficult to follow how program progress;

- probably others I cannot remember.

Of course it could be just me.

I am happy to try and clean up that code. But I am not sure if you have time to review my changes. Also I suspect other parts of cmd/link are in a similar situation - elf and macho and dwarf code. Unfortunately I don't know anything about those. Maybe you have bigger picture.

Alex

[Aram Hăvărneanu]

I will be primarily working on the SPARC64 port. The target operating
system will be Solaris, it will be trivial (for someone else) to
add Linux too.

I will also help with arm64 issues, like conversion to SSA, etc.

--
Aram Hăvărneanu

[David du Colombier]

I'd like to implement asynchronous cancelable i/o on Plan 9.
(issues #7237, #8908, #9554, #11454 and #11932).

--
David du Colombier

[Taru Karttunen]

On 12.08 19:38, Russ Cox wrote:
> The Go 1.5 release candidate is looking good. Hopefully in a week or so it
> will be out, and we'll open the tree for Go 1.6 development. That makes now
> a good time to talk about what we want to do in Go 1.6.

Hello

I was working on using fstatat in package os under the hood
in the 1.5 frame and it got delayed, and I'd like to get
it in 1.6.

However I would like to ask for someone more knowledgeable
with the infrastructure to handle initializing
internal/syscall/unix

I think that it was wanted to have scripts there like syscall
has for generating files. If anyone can help with that I would
be very thankful.

- Taru Karttunen

[C Cirello]

Hi Russ,

Nice topic.

Although I am not a core member, I plan to keep improving the documentation, namely reusable examples.

The idea is to serve more the beginners while not polluting for the long time Gophers.

Two examples of what I have in mind: CL1273, CL13450

-ccf

[Austin Clements]

Rick and I have also been planning out garbage collector work for the 1.6 cycle. Sticking with the theme of 1.6, we'll be focusing on polish and performance. We're going to postpone major algorithmic changes until 1.7, but nevertheless we have plans across the board that should make the garbage collector faster and even more solid for 1.6.

We've detailed our plans in a Google Doc, which we hope to keep at least somewhat up-to-date:

https://docs.google.com/document/d/1kBx98ulj5V5M9Zdeamy7v6ofZXX3yPziAf0V27A64Mo/edit?usp=sharing

--

[David Crawshaw]

My high priority work is in x/mobile or google internal, but for 1.6 I
intend to work on:

- oversized c-shared libraries on android/arm, #11663
- frame pointer support on darwin/arm64, #12100
- deadlock detector interaction with foreign threads, #10268
- PIE on android, part of #6940
- if I can get a builder (which depends on PIE): android/arm64
- minor work: #10477, other assigned issues

On Wed, Aug 12, 2015 at 7:38 PM, Russ Cox <r...@golang.org> wrote:

[Hyang-Ah Hana Kim]

I intend to work on android/x86 support (#9327) for 1.6 to make x/mobile users happy.

--

__

[David Chase]

In the short run, help with SSA coverage and correctness so it is all there.

Beyond that, attempt to use it to improve the generated code.

Bounds check elimination is the first item on that list, nil check elimination

is already done by other people, but the analysis to do bounds check elim

might allow is to pick up "all" the unnecessary nil checks at no additional cost.

There are some escape analysis issues to look at also:

- watch out for late heap conversions of big things, #10936.

- making pointers stored in ... args not automatically escape, #12006

- we could do a better job with escape analysis of recursive functions,

- which would be an efficient-implementation enabler for #10526 .

[aro...@gmail.com]

I'd like to extend the json encoder/decoder to handle non-string keys on the Go side, as described in this conversation.  I intend to submit an issue to track this.

- Augusto

[Joe Shaw]

Hi,

I'd like to extend omitempty support to structs, allowing empty time.Time values (among others) to be omitted from JSON and XML serializations without needing to resort to pointers.

I posted a proposal in #11939.

Joe

[Oleku Konko]

Hello Russ & Dmitry ,

Do you think any of #8899 , #8898, #8903  can make it to 1.6 ?

Thanks

[Chris Hines]

I have a vested interest in seeing #11264 fixed and I am interested in working on it unless a core member (bradfitz perhaps?) already has plans to work on it.

Chris

On Wednesday, August 12, 2015 at 7:38:47 PM UTC-4, rsc wrote:

[Didier Spezia]

I would like to give another try to issue 9037 (decoding of JSON null values),

but I will probably need guidance to understand what the expected behavior is.

I also have some minor code factorization/cleaning in the standard library.

Regards,

Didier.

[Michael Hudson-Doyle]

A bit belated, but prepping a shared library branch has reminded me
that I really want to sort out the mess around thread local storage on
some platforms (the magical "tlsg" symbol, the way we decide whether
to use platform TLS support or not, the number of 'goos == "android"
conditionals in the linker...).

Cheers,
mwh

On 13 August 2015 at 11:38, Russ Cox <r...@golang.org> wrote:

[minux]

A mips64le port has been done, with all.bash nearly passing.

The only remaining parts are cgo, external linking, and the

disassembler.

I propose to add mips64 ports (be and le) to Go 1.6. They'll

be still based on the old (non-ssa) compiler. SSA conversion

will come later.

This port is done by cherry (cc'ed). Announcement will be

posted shortly.

32-bit mips support is also important as using Go on low-end

routers is always one of my goal. But that will come after the

SSA conversion.

The port is designed with 32-bit/64-bit hybrid support in mind,

so I think supporting 32-bit mips only requires a new 32-bit

gc backend.

[Chris Hines]

On Wednesday, August 12, 2015 at 7:38:47 PM UTC-4, rsc wrote:

What are you planning to do in the Go 1.6 cycle? Or what GitHub issues do we not have marked with a Go 1.6 milestone yet but merit one, in your opinion?

I would like to see #10886 added to the list for 1.6.

Chris

[Ian Lance Taylor]

I set it to the 1.6 milestone, although that is not a promise that
anybody will actually work on it.

Ian

[Chris Hines]

Thanks, Ian. I think we have a couple people willing to work on a CL. What do you recommend when it comes to getting a reviewer? I have submitted another CL this cycle without specifying a reviewer. I am inexperienced with the Go contribution process and would appreciate guidance in that respect.

Thanks,

Chris

[Ian Lance Taylor]

On Wed, Sep 2, 2015 at 12:53 PM, Chris Hines <ggr...@cs-guy.com> wrote:
>
> Thanks, Ian. I think we have a couple people willing to work on a CL. What
> do you recommend when it comes to getting a reviewer? I have submitted
> another CL this cycle without specifying a reviewer. I am inexperienced with
> the Go contribution process and would appreciate guidance in that respect.

Specifying a reviewer, but it is not necessary. We will look at it.

Feel free to ping the CLs after a week if you don't hear anything.

Ian

[Ralf Schülke]

Hi,

i missed a Painter package in Image/Draw with:

- rect, line, dot, circle, ...

- fill

- fonts

i miss a nativ window/view/canvas package, i like drawterm and RIO this make go more complete and goes more to nativ system lang, at time we can make apps for CLI and Web and GUI only with 3rd Party packages this are wraper bindings to qt/gtk etc. so ints nice when have go a nativ standard package. 

I miss svg and pdf for a output format amd a base bitmap

Image

  /png

  /gif

  /svg

  /jpg

  /bitmap

  /pdf 

Draw

   /Image/...

   /Painter/...

   /Window/

                /View

                /Canvas

                /...

In the tool section can we have a drawterm app he used the new draw stuff, like Window(), View(), Canvas() etc...

The most odears are came from pan9 rio, drawing and are minimal, the ruels are:

- cross platform

- nativ

- without driver injects

- stable

- fast and low memeory

- (later-> its works over the network)  

the citiclas are the GUI Server for all Plattform and comming Plattforms, but i think we have good Display standards in 2D, 3D are comming with Vulcan.

also this are more nativ then a wrapping to a toolkit.

i can live with edit the name Window to Page, an drop View and make Canvas only the canvas are a dobble buffering bitmap or better a extra gc runtime in the go gc runtime. 

Why we need this?

Simple, to visualation data, graph, pdf, text, images outside a webbrowser and outside a terminal, this close some missing developer and bring golang to a system language back.

So can we write apps for CLI, WEB, Desktop and later can we drawterm make ready for network via http, p9, socket, and create a cluster nodes, this make eg:  raytracing simple an power full and bring more place for new tools eg. debuging visualitations.

-ralf

[Nigel Tao]

On Mon, Sep 7, 2015 at 4:05 PM, Ralf Schülke <ralf.s...@gmail.com> wrote:
> i missed a Painter package in Image/Draw with:
> - rect, line, dot, circle, ...
> - fill
> - fonts

I think that this mail thread is for people to announce what they are
working on for 1.6, not what they would like other people to work on.

In any case, those things you request are all useful, but I don't
think any of them have to live in the standard library per se, and
thus be tied to the 1.6 release cycle. For example, support for the
Plan 9 font file format already exists and is as simple as "go get
golang.org/x/image/font/plan9font".

I'm not sure what you mean exactly by "a base bitmap", but
"golang.org/x/image/bmp" implements the BMP file format.

[davitadz...@gmail.com]

I'd like to see a native GUI programming capabilities. It'll be cool and I can't wait for it. by this option usage of go will rise 100% extra on market. I like Gui, OpenGL and Directx programming in visual C++ and I want to switch on go. cause I like this language.....

On Thursday, August 13, 2015 at 3:38:47 AM UTC+4, rsc wrote:

The Go 1.5 release candidate is looking good. Hopefully in a week or so it will be out, and we'll open the tree for Go 1.6 development. That makes now a good time to talk about what we want to do in Go 1.6.

Go 1.6 will be a shorter than usual cycle, because Go 1.5 ran long. The freeze is Nov 1 (2.5 months from now) and the release is scheduled for Feb 1. There are a few long-term things that have been in progress for a few cycles and may be ready for Go 1.6, most notably the new SSA-based compiler back end (at least for amd64) and transparent HTTP/2 support in net/http. 

Many of us, though, will be focusing on cleanup and polish during the Go 1.6 cycle. Go 1.5 introduced much new code, and the debugging during the freeze highlighted a number of ways we can make it cleaner, more flexible, and easier to maintain for the future. This is especially true in the runtime and the new all-Go toolchain.

There are also many lingering bugs that would be nice to finally fix. Marcel has a plan for #7363 (long-standing reflect issue), and we should try again to fix the encoding/json and encoding/xml issues whose fixes were rolled back late in Go 1.5 for compatibility reasons. There are probably many other lingering, not too important bugs that nonetheless add up to significant pain points for users. It would be nice if Go 1.6 work focused on closing these.

We are also going to try to make sure we stay focused on issues and pending CLs throughout the Go 1.6 cycle. Too many of both were left until the freeze during Go 1.5. The new Go1.6Early milestone in GitHub is meant to help, and I intend to set up a single automated weekly mail to golang-dev reminding us what's pending, summarizing CLs, issues, and proposals.

What are you planning to do in the Go 1.6 cycle? Or what GitHub issues do we not have marked with a Go 1.6 milestone yet but merit one, in your opinion?

[Brad Fitzpatrick]

Btw, this thread is about what people plan to work on and not what people want.

--