Planning the 1.4 release

[Rob Pike]

Go 1.3 is on the exit ramp. We're in the quiet period now, and we hope
to ship the release within a couple of weeks.

The 1.3 release is the second one we've run within this new, regular
schedule[1]. Our ship date slipped a little, for a number of minor
reasons, but not by much. We expect 1.4 to happen, as normal, on
December 1, 2014.

So now it's time to plan what's next. What will be in 1.4?

The biggest component will be entirely under the covers, as the
toolchain and runtime move from C towards Go [2]. It's unlikely all C
code will be gone by 1.4, but much of it will, including - and most
exciting - the compiler. Compiler development in the C version is
likely to be dialed back, to free up more resources for the
transition. (Note that "rsc" appears nicely distributed in
"resources".) Similar conditions apply to the runtime.

Once the 1.3 release is live, we'll be open to new CLs but want to
concentrate on these fundamental changes, even scheduling them so the
code can move gracefully without introducing merge conflicts and other
complexities. If anyone else has other wide-ranging, core work like
this that would make sense for 1.4, please say so now so it can be
scheduled as well.

Over the next few weeks we'll work with you to sketch out the
large-scale priorities for 1.4 and pencil in the sequence of changes
to satisfy them.

Please remember that the open source community is vital to the Go
ecosystem. We can't thank you enough for your contributions.

-rob, for the Go team

[1] http://golang.org/s/releasesched
[2] http://golang.org/s/go13compiler

[Nathan Youngman]

I hope to see os/fsnotify in Go 1.4.

https://code.google.com/p/go-wiki/wiki/DesignDocuments

There is still a fair bit of experimentation needed before we settle on the API. 

We left off with: https://groups.google.com/d/msg/golang-dev/bShm2sqbrTY/IR8eI20Su8EJ

~

As well, I'd like to reopen the "locking down vanity import paths" conversation:

https://groups.google.com/forum/#!msg/golang-dev/RgHGBXROeAw/yCD6bpGq4R8J

Improving search results on GoDoc.org may be able to make use of a "canonical import path" of sorts:
https://github.com/golang/gddo/issues/172

- nathan

[Elias Naur]

I'd like to bring android Dalvik and iOS to the table again, as well as cgo shared libraries (perhaps using https://docs.google.com/document/d/1tU_yNmwu1raKZm9atHJ8THiQizkYTKykdWraIb15TSE/edit?usp=docslist_api as a starting point)

- elias

[Dave Cheney]

I would like to have a discussion about additional build tags for the
various arm variants now that instruction selection is handled at
compile time.

https://groups.google.com/d/topic/golang-dev/1EERkkWgbrM/discussion

The people who also want to do something similar for SSE2/3/4/AVX may
want to chime in.

Cheers

Dave

On Wed, Jun 4, 2014 at 3:24 PM, Elias Naur <elias...@gmail.com> wrote:
> I'd like to bring android Dalvik and iOS to the table again, as well as cgo shared libraries (perhaps using https://docs.google.com/document/d/1tU_yNmwu1raKZm9atHJ8THiQizkYTKykdWraIb15TSE/edit?usp=docslist_api as a starting point)
>
> - elias
>

> --
> 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.

[Aram Hăvărneanu]

My main priority this cycle is writing 7g, the arm64 compiler. I
hope to get it working in time to get it in 1.4. The first target
is plan9/arm64 and the principal target (but done second) is
linux/arm64. This is solitary work, I expect no clash with other
work, so it doesn't require any special scheduling.

There are other things I want to do, for which I might or I might
not have time to do. The first would be plan9/amd64 support. It
took me a single day to get to a semi-working go tool, so I expect
to finish that (mostly because I use the amd64 Plan 9 kernel these
days). plan9/arm is also on the table but rather unlikely for this
cycle.

Another thing I want to do is better DTrace support for Go. This
is not so much work, although I might wait until we have the linker
written in Go.

Another thing I will most certainly do very soon is cgo support for
the solaris/amd64 port (I've actually done it a few months ago and
it's working perfectly, 95% of the time).

I expect most of these things not to clash with other people's work,
even if some of thsese things are large. Or if there's a clash, it
would be minimal.

--
Aram Hăvărneanu

[Yukinari Toyota]

In my personal matter, I want to build generic runtime poller API like [Issue 6222: runtime: poller should be used for file system operations]

 but not for filesystem/AIO, just for file descriptors those support poll to enhance some device driver/device file operation supports.

2014年6月4日水曜日 7時44分53秒 UTC+9 Rob Pike:

[tracey....@gmail.com]

It would be a huge boon to the numerical community to have support for multi-dimensional slices (issue 6282). I think my proposal (linked in the issue) integrates well within the language. It would be useful to have some input on the proposal from the lead developers; so far there as only been one Go contributor that has commented on the proposal (aside from the proposal authors). It is my opinion that this set of changes, along with Dan’s suggested range syntax, constitutes a sufficient set of changes to make Go an excellent language for numeric computing.

I understand that even if the proposal is accepted a full implementation may add too much complexity for 1.4. In that case, a partial implementation (type definition, access, assignment, and slicing) would be of great help as we build a standard library for numeric/scientific computing in Go.

[Mikio Hara]

On Wed, Jun 4, 2014 at 7:44 AM, Rob Pike <r...@golang.org> wrote:

> So now it's time to plan what's next. What will be in 1.4?

I'd like to see netio or similar package that exposes both Poller and
Mutex primitives of the runtime-integrated network poller. A simple
motivation: we'll be able to implement featured network connection
endpoints which satisfy net.Conn interface without churning out the
runtime and net packages if we get some fancy network attachment that
implements some programmable protocol offload engine or net package
unsupported address families.

The replumbing work would not be tough; simply from runtime<-net to
runtime<-netio<-net (https://codereview.appspot.com/99510043/).

[Mikio Hara]

On Wed, Jun 4, 2014 at 1:34 PM, Nathan Youngman <n...@nathany.com> wrote:

> I hope to see os/fsnotify in Go 1.4.
> https://code.google.com/p/go-wiki/wiki/DesignDocuments

Hope so too. After it lands, net package uses os/fsnotify for
capturing local configuration file changes.

[Taru Karttunen]

On 04.06 20:40, Dave Cheney wrote:
> I would like to have a discussion about additional build tags for the
> various arm variants now that instruction selection is handled at
> compile time.
>
> https://groups.google.com/d/topic/golang-dev/1EERkkWgbrM/discussion

I would like to get the armv4 code in, which requires a solution to
this (the code contains a separate patch which implements build flags
armv4/armv5/armv6/armv7).

- Taru Karttunen

[Dave Cheney]

I would prefer not to see that. I've looked into arm4t boards and none
of them would be capable of running a builder so don't qualify as a
port.

[chen...@126.com]

Can map support upper_bound like c++?

在 2014年6月4日星期三UTC+8上午6时44分53秒，Rob Pike写道：

[Lucio De Re]

But by the same criterion, nor does NaCl, right?

[Aram Hăvărneanu]

> But by the same criterion, nor does NaCl, right?

No, NaCl has a builder (actually two), which is active and mostly
passes: http://build.golang.org.

--
Aram Hăvărneanu

[Brad Fitzpatrick]

Mostly? It actually passes. And when it breaks we've fix it. (See recent case)

Builders: they work.

[Aram Hăvărneanu]

> Mostly? It actually passes. And when it breaks we've fix it. (See recent
> case)

Yes, the builder always passes, 90% of the time.

--
Aram Hăvărneanu

[Dmitry Vyukov]

It makes no sense.

[Ian Lance Taylor]

On Thu, Jun 5, 2014 at 2:14 AM, <chen...@126.com> wrote:
>
> Can map support upper_bound like c++?

Not really, maps in Go are not sorted. They are like the C++
std::unordered_map, not the C++ std::map.

Ian

[Lucio De Re]

OK, but the issue was that there is no hardware to run arm<7 and I
presume that the NaCl builder runs as a VM, so I assumed that one
could run arm builders on emulators, like for NaCl?

Maybe a bad assumption?

[Brad Fitzpatrick]

Nacl doesn't require a VM. I mean, it IS one. But runs on any OS on that native arch.

[Aram Hăvărneanu]

> OK, but the issue was that there is no hardware to run arm<7 and I
> presume that the NaCl builder runs as a VM, so I assumed that one
> could run arm builders on emulators, like for NaCl?

There is a lot of armv4 hardware. The alleged problem is that is bad
(not enough memory?). Emulating it would only make it slower and
worse.

--
Aram Hăvărneanu

[Dave Cheney]

We have real arm hardware builders for arm v5, v6 and v7. The build
requires more than 256mb of ram to run to completion, and it was
difficult to find an arm v5 device that could fit those requirements.

In my research the largest armv4t device has a 400mhz cpu and a 64mb
of ram, they simply aren't capable of hosting a builder. Emulation may
be faster in that case if someone is prepared to host and maintain a
qemu builder.

I don't see the cost of supporting armv4t devices as worthwhile. There
are other devices that Go does not support, like the Intel Galileo,
and that's just the way it turned out.

[Dave Cheney]

On a different note I would like to have a discussion about how to
make the cmd/go tool available to platforms that don't/can't use the
gc toolchain.

The goal would be to support passing the contents of cmd/go to gccgo
unmodified and getting a linkable result. Right now that involves some
modification of the cmd/go sources to work with gccgo's 1.2 spec
standard library[1]. In theory this would be solvable with some build
tags.

Thoughts ?

1. http://go-talks.appspot.com/github.com/davecheney/gosyd/gccgo.slide#1

[Ian Lance Taylor]

On Thu, Jun 5, 2014 at 2:06 PM, Dave Cheney <da...@cheney.net> wrote:
>
> I don't see the cost of supporting armv4t devices as worthwhile. There
> are other devices that Go does not support, like the Intel Galileo,
> and that's just the way it turned out.

For oddball processors there is always the gccgo compiler.

Ian

[Ian Lance Taylor]

On Thu, Jun 5, 2014 at 2:30 PM, Dave Cheney <da...@cheney.net> wrote:
>
> On a different note I would like to have a discussion about how to
> make the cmd/go tool available to platforms that don't/can't use the
> gc toolchain.
>
> The goal would be to support passing the contents of cmd/go to gccgo
> unmodified and getting a linkable result. Right now that involves some
> modification of the cmd/go sources to work with gccgo's 1.2 spec
> standard library[1]. In theory this would be solvable with some build
> tags.

I would like to have gccgo build the go tool itself. This is mostly a
matter of getting the configury right. The go tool needs to be built
using a build-x-host Go compiler, but I only have build-x-target Go
compiler. (To be clear in a normal default build of gccgo these are
the same compiler, but GCC and hence gccgo are routinely built both as
and using cross-compilers.) If I can get that done that will address
your problem. But I don't know when I will work on it. But somebody
else could do it--patches welcome!

Also, I am currently in the process of updating gccgo's runtime
library to the 1.3 library.

All that aside, yes, I think that any general modifications needed to
make the go tool build and work with gccgo should be committed.

But I'm not entirely sure whether we want to worry about making the go
tool in the master tree buildable with older versions of gccgo. That
seems like a bit of a struggle. If that is desirable I think we
should make a fork of the go tool hosted elsewhere.

Ian

[Michael Hudson-Doyle]

Aram Hăvărneanu <ara...@mgk.ro> writes:

> My main priority this cycle is writing 7g, the arm64 compiler. I
> hope to get it working in time to get it in 1.4. The first target
> is plan9/arm64 and the principal target (but done second) is
> linux/arm64. This is solitary work, I expect no clash with other
> work, so it doesn't require any special scheduling.

Awesome! Let me know if Linaro can help in any way.

Cheers,
mwh

[Michael Hudson-Doyle]

Dave Cheney <da...@cheney.net> writes:

> On a different note I would like to have a discussion about how to
> make the cmd/go tool available to platforms that don't/can't use the
> gc toolchain.
>
> The goal would be to support passing the contents of cmd/go to gccgo
> unmodified and getting a linkable result. Right now that involves some
> modification of the cmd/go sources to work with gccgo's 1.2 spec
> standard library[1]. In theory this would be solvable with some build
> tags.

There is also that hard coded list of std libary package paths in the
gccgo-go source; I think that could/should be replaced with searching
gccgo's linker path for .gox files (gccgoimporter has code for this). I
think anyway! It's been a while since I thought about this.

Cheers,
mwh

[Taru Karttunen]

On 06.06 07:06, Dave Cheney wrote:
> We have real arm hardware builders for arm v5, v6 and v7. The build
> requires more than 256mb of ram to run to completion, and it was
> difficult to find an arm v5 device that could fit those requirements.
>
> In my research the largest armv4t device has a 400mhz cpu and a 64mb
> of ram, they simply aren't capable of hosting a builder. Emulation may
> be faster in that case if someone is prepared to host and maintain a
> qemu builder.
>
> I don't see the cost of supporting armv4t devices as worthwhile. There
> are other devices that Go does not support, like the Intel Galileo,
> and that's just the way it turned out.

Is this a general direction that it is not worthwhile to support e.g.
embedded systems in future if they are not usable as builders?

Typically when using a low end ARM system with Go the easiest way is
to use a higher-end ARM machine with an explicit GOARM setting and do
judicious testing on the target device.

What specs would you require for a builder (virtual) machine?

Is there a general good practice for maintaining out-of-tree ports?

- Taru Karttunen

[Aram Hăvărneanu]

FWIW I run Go on "small" machines, and I would be happy if I could run
it on even smaller machines. We can test ARMv4 code on newer ARM
machines; that's no guarantee it will run on ARMv4, but we don't use a
Pentium 2 to test GO386=387 either, so it's neither better or worse.

We can also reduce the scope of the tests for that platform, is native
testing is required.

Where there's a will, there's a way.

--
Aram Hăvărneanu

[Gustavo Niemeyer]

On Tue, Jun 3, 2014 at 7:44 PM, Rob Pike <r...@golang.org> wrote:
> The biggest component will be entirely under the covers, as the
> toolchain and runtime move from C towards Go [2]. It's unlikely all C
> code will be gone by 1.4, but much of it will, including - and most
> exciting - the compiler. Compiler development in the C version is
> likely to be dialed back, to free up more resources for the
> transition. (Note that "rsc" appears nicely distributed in
> "resources".) Similar conditions apply to the runtime.

We discussed the idea of having shared libraries of Go code a few
times over the last few months, to enable Linux distributions to
upgrade parts of Go applications across the whole system when there
are security incidents. Over a casual conversation with Russ at
GopherCon, we talked a bit about the potential granularity of that,
possibly having "bundles" of packages together in a single shared
object.

Given the comments above, I'm wondering if there's any chance this
might see some preliminary attention.


gustavo @ http://niemeyer.net

[John Waycott]

Has there been any discussion or interest in other specialized processors? My interest is the Tilera Gx which seems would be a good fit with Go since it is aimed at Go original server/system market space.

[snes...@gmail.com]

Support methods written in assembly.

Support all SIMD x86 instructions in 6a and 8a, if possible also other current non-SIMD instructions.

[Dave Cheney]

On Mon, Jun 9, 2014 at 5:56 AM, <snes...@gmail.com> wrote:

Support methods written in assembly.

Support all SIMD x86 instructions in 6a and 8a, if possible also other current non-SIMD instructions.

This has been requested before. Can you please make sure an issue detailing the instructions that you would like to see added is filed.

[Dmitry Vyukov]

On Wed, Jun 4, 2014 at 2:44 AM, Rob Pike <r...@golang.org> wrote:
> Go 1.3 is on the exit ramp. We're in the quiet period now, and we hope
> to ship the release within a couple of weeks.
>
> The 1.3 release is the second one we've run within this new, regular
> schedule[1]. Our ship date slipped a little, for a number of minor
> reasons, but not by much. We expect 1.4 to happen, as normal, on
> December 1, 2014.
>
> So now it's time to plan what's next. What will be in 1.4?
>

> The biggest component will be entirely under the covers, as the
> toolchain and runtime move from C towards Go [2]. It's unlikely all C
> code will be gone by 1.4, but much of it will, including - and most
> exciting - the compiler. Compiler development in the C version is
> likely to be dialed back, to free up more resources for the
> transition. (Note that "rsc" appears nicely distributed in
> "resources".) Similar conditions apply to the runtime.
>

> Once the 1.3 release is live, we'll be open to new CLs but want to
> concentrate on these fundamental changes, even scheduling them so the
> code can move gracefully without introducing merge conflicts and other
> complexities. If anyone else has other wide-ranging, core work like
> this that would make sense for 1.4, please say so now so it can be
> scheduled as well.
>
> Over the next few weeks we'll work with you to sketch out the
> large-scale priorities for 1.4 and pencil in the sequence of changes
> to satisfy them.
>
> Please remember that the open source community is vital to the Go
> ecosystem. We can't thank you enough for your contributions.

Hi!

My plans are:
- faster/better GC/malloc, mainly based on
https://docs.google.com/document/d/1HCPu3WKyCX3ZRYxmIMKTk0Ik1dePxKW1p02k3uhcft4/edit
but to be discussed (not sure if I will be able to do it all, but it
would be great)

- faster buffered channels
(https://docs.google.com/document/d/1yIAYmbvL3JxOKOjuCyon7JhW4cSv1wy5hC0ApeGMV9s/edit#heading=h.h23m1dwm0wep)
this must synchronize with Keith C->Go chan.goc transformation

- faster unbuffered channels [stretch]

- faster timers [stretch^2]

- better race detector (this should not conflict with other work, as
most changes will be in the race runtime):
- update to tip runtime
- output heap block allocation stack
- detect races between atomic and non-atomic accesses
- describe mutexes hold around racy accesses
- detect deadlocks [stretch]

[Erwin]

On 10 June 2014 03:27, Dave Cheney <da...@cheney.net> wrote:

On Mon, Jun 9, 2014 at 5:56 AM, <snes...@gmail.com> wrote:

Support methods written in assembly.

Support all SIMD x86 instructions in 6a and 8a, if possible also other current non-SIMD instructions.

This has been requested before. Can you please make sure an issue detailing the instructions that you would like to see added is filed.

 

Issue 4978 is about methods in assembly.

I could not find specific issues about the lack of some SSE instructions in 6a and 8a.

[Ed Swierk]

On Thursday, June 5, 2014 2:47:18 PM UTC-7, Ian Lance Taylor wrote:

All that aside, yes, I think that any general modifications needed to
make the go tool build and work with gccgo should be committed.

I'd like to be able to use a single instance of the go tool with both gc and gccgo backends, rather than needing a specially-built go tool just for gccgo. I posted patches a few weeks ago:

https://groups.google.com/forum/#!topic/golang-dev/AGGMtWHpXi0

--Ed

[Ian Lance Taylor]

To contribute patches, please follow the process described at
http://golang.org/doc/contribute.html . Thanks.

Ian

[Michael Jones]

I use methods in assembly all the time. The patch is tiny and well understood. The only holdup last time was Rob being cautious about committing publicly to the method calling sequence and stack expectations. If things have settled a bit then maybe it is time...

--
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.

--

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

[minux]

On Wed, Jun 11, 2014 at 5:35 PM, 'Michael Jones' via golang-dev <golan...@googlegroups.com> wrote:

I use methods in assembly all the time. The patch is tiny and well understood. The only holdup last time was Rob being cautious about committing publicly to the method calling sequence and stack expectations. If things have settled a bit then maybe it is time...

I think what we really need is the ability to inline assembly functions. 

[Ingo Oeser]

I would prefer inline assembler, too. This allows the compiler to keep more optimizations,reorder those blocks and allows to change prologue and epilogue at will.

[Michael Jones]

yes!

On Thu, Jun 12, 2014 at 12:08 AM, Ingo Oeser <night...@googlemail.com> wrote:

I would prefer inline assembler, too. This allows the compiler to keep more optimizations,reorder those blocks and allows to change prologue and epilogue at will.

--
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.

[Aram Hăvărneanu]

I want Go 1.4 to have generics, and monads, and be integrated with
the JRE using a dynamically linked module. I also wish the playground
would start coloring words, use emacs[1] key bindings and feature
Spin integration[2].

Oh, wait, sorry; did I confuse this thread with a feature request
thread? I'm dreadfully sorry. In my defense, it looks like I wasn't
the first.

[1] http://plan9.bell-labs.com/magic/man2html/1/emacs
[2] http://spinroot.com/spin/whatispin.html

PS: Spin integration would actually be nice.

--
Aram Hăvărneanu

[Dmitri Shuralyov]

Hello,

I would like to make a proposal for 1.4 and gather feedback on it.

I think it would absolutely great if cmd/go and cmd/gofmt followed suit after cmd/goimports, cmd/oracle, nsqlookupd, etc. and became refactored into an importable library plus a thin command-line wrapper.

Here is the motivation.

Currently, if one is building development tools around Go and would like to be able to run cmd/go programmatically, they have two options:

- Either shell out,

- Or duplicate the private code of cmd/go.

However, with the Go compiler itself potentially becoming rewritten in Go for 1.4, it would be incredible if the functionality of cmd/go and cmd/gofmt were available as importable go code (which is free to change in similar ways as cmd/go is free to change).

The main benefit would be the ability for Go programs to compile Go code while skipping filesystem, and eventually maybe even skipping Go printing/parsing. Currently, one would need to generate temporary files, print Go code to those files, then invoke cmd/go which would in turn read said files, then remove the files afterwards; all while being aware of GOPATH workspace boundaries and potentially compiling with stale code due to https://groups.google.com/forum/#!topic/golang-dev/svxuGkGJTD8.

It would be possible to rewrite Go code as done by the cover tool, execute it and get coverage results faster than currently possible. It would be possible to do what's currently possible in a more efficient manner (potentially skipping printing ASTs and then parsing ASTs), and perhaps enable new kinds of tools and interfaces that aren't possible now. Finally, less code duplication and bugs that arise from that, easier to maintain.

I am very interested in both the expected and unexpected consequences that arise as a result.

Similarly, I would love to see go/format becoming a full featured go formatting library, and cmd/gofmt being a simple wrapper of it. That would require fixing issue https://code.google.com/p/go/issues/detail?id=5551, which remains unfixed since go1.1. (It should be quite easy to test the refactored go/gofmt to ensure it produces the same output as original version.)

Now that go1.4 tree is open for changes, I would love to help out in making this possible, but only if there's consensus that this is indeed the way to go.

Thank you for your consideration.

[David Symonds]

On 16 June 2014 10:03, Dmitri Shuralyov <shur...@gmail.com> wrote:

> I think it would absolutely great if cmd/go and cmd/gofmt followed suit
> after cmd/goimports, cmd/oracle, nsqlookupd, etc. and became refactored into
> an importable library plus a thin command-line wrapper.

Half of that is done: http://golang.org/pkg/go/format/

[yxw.2...@gmail.com]

I have waited go 1.3 for a long time,

I hope golang support GUI programming, with the official GUI package,

I hope it supports Android development,

I hope it supports Generic type,

I hope it support function default parameters,

...

And  I think  golang need a official  IDE.

Maybe only in this way, there will be more people know it, use it, it will pop up.

^_^

在 2014年6月4日星期三UTC+8上午6时44分53秒，Rob Pike写道：

-rob, for the Go team

[1] http://golang.org/s/releasesched
[2] http://golang.org/s/go13compiler

[elit...@gmail.com]

Exposing http.ResponseWriter's underlying buffer size as per https://groups.google.com/forum/m/#!topic/golang-dev/OuFtcKEyGrg

[necl...@gmail.com]

I don't like the idea of default parameters, but I'd like generics very much!

[jeff...@gmail.com]

I'm also interested in programming for Android and shared libraries. For Android though, isn't Dalvik on its way out? I don't understand the details but perhaps Go should target ART?

On Tuesday, June 3, 2014 10:24:43 PM UTC-7, Elias Naur wrote:

I'd like to bring android Dalvik and iOS to the table again, as well as cgo shared libraries (perhaps using https://docs.google.com/document/d/1tU_yNmwu1raKZm9atHJ8THiQizkYTKykdWraIb15TSE/edit?usp=docslist_api as a starting point)

 - elias

[mwsh...@gmail.com]

How about a tool that analyzes how much, and what parts, of external packages are actually used by the current package. Idea being, a programmer would like to know if they are only using 5% of an imported package, and maybe they should reconsider?

Functionally, perhaps this would work like the cover tool -- revealing what paths in the external package one actually hits. Report dead (source) code across dependencies, in other words.

Further fantasy, a go fix-ish thing that would automagically inline those select bits, allowing one to drop the dependency.

[小菜]

I  think in Golang， Array， Slice， and Map ， all of them are very difficult to use。

For example, I want to check whether an element in the array, get all the map key, or the map value into slice,

With two slice,  intersection or union, the Slice sort, map sort, I found that the operation has no official function support, there is no official  package, so it is very difficult to use, not a standard, efficient way.

Perhaps Golang should like PHP/Python built-in some common operations，  Programming language is used to solve practical problems。

Reference resources.

Http://us1.php.net/manual/en/ref.array.php

 

[Kevin Gillette]

It'd be nice to see some rekindled interest in slice -> array conversion, and slice -> *array conversion.

[Henrik Johansson]

Yes, I would like that as well.

--

[james4k]

That would be great, especially slice to *array conversion.

[Russ Cox]

This thread was a call for Go contributors to say what they were planning to work on this cycle (not a call for feature requests). I have collected that information at golang.org/s/go14todo. As always, this is a list of what we're thinking about, not a promise that it will all happen.

Russ

[Dave Cheney]

Did merging the performance dashboard and the main build dashboard
make it onto the 1.4 schedule ?

[Dmitry Vyukov]

I don't think it needs to be tied to Go releases. We can do it during
the freeze as well. But I would like to do as soon as possible.

[vinhth...@gmail.com]

Can we remove the 1GB limit on enconding/gob?

Thank you.

VP

[el.rey....@gmail.com]

i'd guess not until the dependency on unsafe is removed.

[minux]

On Fri, Jul 25, 2014 at 8:23 AM, <el.rey....@gmail.com> wrote:

i'd guess not until the dependency on unsafe is removed.

FYI, encoding/gob on tip has already get rid of dependency on unsafe.