Go 1

3178 views
Skip to first unread message

Russ Cox

unread,
Oct 6, 2011, 9:08:39 AM10/6/11
to golang-nuts
See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
Please post comments in this thread. Thanks.

André Moraes

unread,
Oct 6, 2011, 9:41:58 AM10/6/11
to golang-nuts
The new "Go" tool will have more features than goinstall + make
Or will only replace those?

If it will only replace why not keep goinstall as the tool name?


--
André Moraes
http://andredevchannel.blogspot.com/

André Moraes

unread,
Oct 6, 2011, 9:43:48 AM10/6/11
to golang-nuts
Another thing I forgot to put in the last post:

The exp package will still live in the tip and will be removed only on
the "Go N" versions?

Brian Ketelsen

unread,
Oct 6, 2011, 9:44:18 AM10/6/11
to golang-nuts

On Oct 6, 2011, at 9:08 AM, Russ Cox wrote:

> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread. Thanks.


Is the plan to incrementally change the current tree to meet these goals? How many releases (weekly/monthly or otherwise) do you envision between now and Go 1? The most invasive changes from my perspective[1] are the package rearrangements and the move to error.Value from os.Error. I think it would be beneficial to make these structural changes as soon as possible. The other changes are more subtle.

Brian


Brandon Mercer

unread,
Oct 6, 2011, 9:46:32 AM10/6/11
to golang-nuts
Doesn't gofix solve most of these issues for users even if they're
following a short term release cycle? I've not seen any issue in
things being maintained the way they are now.

J.L.vanderZwan

unread,
Oct 6, 2011, 9:48:49 AM10/6/11
to golang-nuts
In the document there's a minor typo at "multiple assignment": the x
should be an m.

Reliability is important, so this is a good development. Other than
that, I know that I don't know enough about programming to weigh in on
the discussion as to what should be in Go 1 - I'll just keep watching
on the sidelines.

On Oct 6, 3:08 pm, Russ Cox <r...@golang.org> wrote:
> Seehttp://blog.golang.org/2011/10/preview-of-go-version-1.html.

roger peppe

unread,
Oct 6, 2011, 10:02:12 AM10/6/11
to r...@golang.org, golang-nuts
On 6 October 2011 14:08, Russ Cox <r...@golang.org> wrote:
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread.  Thanks.

LGTM

particular +1s to: composite literals, map deletion, no function equality,
composite map keys, package renaming.

not sure about: error.Value as a name, go/types noncompletion,

i'll miss gotry, although i doubt anyone else will.

Vincent Vanackere

unread,
Oct 6, 2011, 10:02:08 AM10/6/11
to r...@golang.org, golang-nuts
On Thu, Oct 6, 2011 at 15:08, Russ Cox <r...@golang.org> wrote:
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread.  Thanks.
>

equality

The current language does not define equality on struct and array values.  It does define equality on function and map values.  Function equality is problematic in some contexts and map equality compares pointers, not the maps’ content.  Only types with defined equality can be used as map keys.

Go 1 will define equality on struct and array values composed from fields on which equality is also defined (element-wise comparison).

This one will be a great improvement. If I understand the implication correctly, it will make mappings much more powerful and in most cases remove the need to use an encoding scheme (typically to a string value) for complex keys.  :-)
 
 It will remove equality on function and map values except for comparison with nil.

However this particular change seems a bit drastic... Isn't it possible to keep the possibility to compare function and map values for equality while disallowing their usage as a part of map keys ? Could you elaborate on the potential problems with function equality ?

Vincent

Florian Weimer

unread,
Oct 6, 2011, 10:14:38 AM10/6/11
to golang-nuts
* Russ Cox:

> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread. Thanks.

Regarding composite literals, can they used for unnamed parameters, as
in:

type Entry struct {
Name string
Value float64
}

var f func(*Entry)

...
f({Name: "pi", 3.14})

?

I still think it would make sense to aim for more consistent error
handling (callers always have to check the error return).

yy

unread,
Oct 6, 2011, 11:00:49 AM10/6/11
to r...@golang.org, golang-nuts
I'd like to know what is the reason to add the "delete" builtin
instead of the syntax which has been proposed before: m[k] = _

I just think the number of builtins should be minimized, but I may be
missing something. (By the way, the same syntax could be applied to
closing channels too: c <- _, then the restriction to close
receive-only channels would be evident.)

Also, I don't really like error.Value, but I don't have a better
proposal and I agree os.Error was not right.

Anyway, I'd like to say that in general terms I like very much the
suggested changes and the idea of a stable release. In particular, I
find the go command very nice and the solution to shadowing return
values quite original.


--
- yiyus || JGL .

Message has been deleted

Eleanor McHugh

unread,
Oct 6, 2011, 11:11:15 AM10/6/11
to golang-nuts
On 6 Oct 2011, at 14:08, Russ Cox wrote:
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread. Thanks.

My main disappointment is that Go 1 won't include a succinct literal form for user-defined function types as the current need to type cast anonymous functions is ugly, ugly, ugly, ugly, ugly.


Ellie

Eleanor McHugh
Games With Brains
http://feyeleanor.tel
----
if _, ok := reality.(Reasonable); !ok { panic(reality) }

unread,
Oct 6, 2011, 11:11:29 AM10/6/11
to golang-nuts
On Oct 6, 3:08 pm, Russ Cox <r...@golang.org> wrote:
> Seehttp://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread.  Thanks.

The Go 1 preview document says:

"Go 1 will continue to exclude equality for slices. (In the general
case it is infeasible.)"

I don't understand the reasoning behind this. Is the reason
performance, or complexity of implementation, or something else?

Paulo Pinto

unread,
Oct 6, 2011, 11:22:08 AM10/6/11
to golang-nuts
Not to raise a big discussion about it, but I miss generics on the Go
1 list.

Having them added afterwards might create issues, assuming that they
will "eventually"
be in Go.

--
Paulo

Peter Bourgon

unread,
Oct 6, 2011, 11:24:21 AM10/6/11
to r...@golang.org, golang-nuts
> The Go 1 release will include a new tool “go” that will replace both goinstall and make.

For me, this is by far the most exciting part of the proposal. I'd
love to hear as much detail as possible about this new tool.
Specifically, I'm interested in how the authors propose to address
dependencies of packages on both runtimes and other packages. Also, it
would be great to see a clear definition of where "go"-installed
packages can possibly reside (if that would differ from the current
implementation).

Mateusz Czapliński

unread,
Oct 6, 2011, 11:31:34 AM10/6/11
to golang-nuts
On Oct 6, 3:41 pm, André Moraes <andr...@gmail.com> wrote:
> The new "Go" tool will have more features than goinstall + make
> Or will only replace those?
> If it will only replace why not keep goinstall as the tool name?

At least for the Windows port, this is a fairly fortunate change, as
it will effectively work around the special treatment Windows gives to
executables containing 'install' or 'setup' in name. (Really funny
thing, this.)

As of the rest, it's an interesting reading. I enjoy especially
'deletion from map', 'return with named arguments', 'Go tool' and
'official Windows binaries'. Also the fact that some pretty big
changes are planned at all, and Go 1 is to emerge soon.
I pity lack of announced plans for a solution to the problem with :=
assignment.

regards
/Mateusz Czaplinski.

Gustavo Niemeyer

unread,
Oct 6, 2011, 11:32:37 AM10/6/11
to r...@golang.org, golang-nuts
> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
> Please post comments in this thread.  Thanks.

Fantastic news there. Exciting times.

As a detail, for the append improvement it'd be nicer to see a fix for
issue 2204 instead, since it's a generic desire to be able to handle
an underlying string byte-by-byte without incurring in gratuitous
allocation. The issue describes a few different cases in addition to
the append support that come from the same problem.

--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I never filed a patent.

tux21b

unread,
Oct 6, 2011, 11:44:24 AM10/6/11
to golan...@googlegroups.com, r...@golang.org
> A later version of Go will change rune to be an alias for int32, which will make it
> reasonable to change int to be 64 bits.

Why have you postponed this change?

> As part of that effort we plan to set up a separate dashboard for repositories showing
> the build and test status against different Go versions.

That sounds great! It's probably my favorite :) Have you considered tagging packages
on the dashboard with "approved" if they are reviewed by golang-dev (e.g. graphics,
leveldb-go, etc) and perhaps "recommended" for packages which are maintained
somewhere else, but are checked/used by gophers regularly (e.g mgo and maybe gorilla?).

-christoph

tiny_dust

unread,
Oct 6, 2011, 10:52:13 AM10/6/11
to golang-nuts
i think compiler should check error automaticly when user ignore it
by "_"

example:
f,_:=os.Open("xxx")
=>
f,err01:=os.Open("xxx");check(err01) //func check(err os.Error)
{if err!=nil{panic(err)}}


it is bad idiom to ignore error by "_" without this feature.
this feature will improve robust of error handling.

in many situations(not all), error handling is a crosscutting
concerns,such as deployment problem,programming bugs.
normal logic need not handle these things everywhere. (os.Error is
like the CheckedException of Java)

On 10月6日, 下午10时14分, Florian Weimer <f...@deneb.enyo.de> wrote:
> * Russ Cox:
>
> > Seehttp://blog.golang.org/2011/10/preview-of-go-version-1.html.

Sebastien Binet

unread,
Oct 6, 2011, 12:15:06 PM10/6/11
to golang-nuts


On Oct 6, 5:22 pm, Paulo Pinto <paulo.jpi...@gmail.com> wrote:
> Not to raise a big discussion about it, but I miss generics on the Go
> 1 list.
+1

>
> Having them added afterwards might create issues, assuming that they
> will "eventually"
> be in Go.
+1

-s

chris dollin

unread,
Oct 6, 2011, 12:40:03 PM10/6/11
to Paulo Pinto, golang-nuts
On 6 October 2011 16:22, Paulo Pinto <paulo....@gmail.com> wrote:
> Not to raise a big discussion about it, but I miss generics on the Go
> 1 list.

I can't see that for a Go 1 "early next year" that there's enough time
to devise, implement, and soak-test generics for Go.

Much as I would like to have them myself ...

Chris

--
Chris "allusive" Dollin

Douwe Gelling

unread,
Oct 6, 2011, 12:37:02 PM10/6/11
to golang-nuts
Looks good, although:

"container/vector - not in Go 1
Scheduled for deletion."

Maybe I'm the only one using this package, but why is it removed? I
really
like being able to use a list that automatically grows. Or will there
be some
replacement?

Riton

unread,
Oct 6, 2011, 12:40:58 PM10/6/11
to golan...@googlegroups.com
Will string be implemented as []rune then ?
We could finally use :

s:= "世界"
len(s) // 2
s[1] // 世
range s



Go1 looks really nice !

Jesse McNelis

unread,
Oct 6, 2011, 12:45:53 PM10/6/11
to Douwe Gelling, golang-nuts

Been stuck under a rock for a while? anyway, the append() built-in
offers all the functionality of container/vector for any type of slice.

http://golang.org/doc/go_spec.html#Appending_and_copying_slices
http://code.google.com/p/go-wiki/wiki/SliceTricks

Andrew Gerrand

unread,
Oct 6, 2011, 12:48:11 PM10/6/11
to golan...@googlegroups.com
The built-in append and copy functions make container/vector largely redundant. See:


Andrew

yy

unread,
Oct 6, 2011, 12:49:24 PM10/6/11
to tiny_dust, golang-nuts
2011/10/6 tiny_dust <ustc....@gmail.com>:

> i think compiler should check error automaticly when user ignore it
> by "_"

Errors are just values. The compiler doesn't know that what you are
ignoring is an error.

Douwe Gelling

unread,
Oct 6, 2011, 12:52:54 PM10/6/11
to golang-nuts
On Oct 6, 5:48 pm, Andrew Gerrand <a...@golang.org> wrote:
>
> The built-in append and copy functions make container/vector largely
> redundant. See:
>
> http://code.google.com/p/go-wiki/wiki/SliceTricks
>
> Andrew

Whoop yeah, sorry. Disregard that then :)

chris dollin

unread,
Oct 6, 2011, 12:52:50 PM10/6/11
to golan...@googlegroups.com
On 6 October 2011 17:40, Riton <henri....@gmail.com> wrote:
> Will string be implemented as []rune then ?

I doubt it. That would make most strings a lot fatter than they need be.
You can cast to and from []int already if you need to -- that will just become
[]rune.

> We could finally use :
> s:= "世界"
> len(s) // 2
> s[1] // 世

(s[0], not s[1])

> range

range works on strings already.


--
Chris "allusive" Dollin

Andrew Gerrand

unread,
Oct 6, 2011, 12:56:32 PM10/6/11
to golan...@googlegroups.com
On Thursday, October 6, 2011 6:41:58 AM UTC-7, André Moraes wrote:
The new "Go" tool will have more features than goinstall + make
Or will only replace those?

If it will only replace why not keep goinstall as the tool name?

The "go" command has already been designed. You can see its usage/help text here:


As you can see, it does more than just installation, so "goinstall" isn't really an apt name anymore.

Andrew

Ugorji Nwoke

unread,
Oct 6, 2011, 12:57:39 PM10/6/11
to golan...@googlegroups.com
There's utf8.String type for that. Also, range already allows you loop over the runes of a string. I really like as string is a sequence of bytes, but there's available support for going across code points if you want to.

Riton

unread,
Oct 6, 2011, 1:04:10 PM10/6/11
to golan...@googlegroups.com
Don't you find it inconsistent that range that is supposed to iterate over the elements of the string implemented as a []byte returns you runes instead of bytes ?

Andrew Gerrand

unread,
Oct 6, 2011, 1:06:59 PM10/6/11
to golan...@googlegroups.com


On Thursday, October 6, 2011 6:44:18 AM UTC-7, Brian Ketelsen wrote:

Is the plan to incrementally change the current tree to meet these goals?  How many releases (weekly/monthly or otherwise) do you envision between now and Go 1?  The most invasive changes from my perspective[1] are the package rearrangements and the move to error.Value from os.Error.  I think it would be beneficial to make these structural changes as soon as possible.  The other changes are more subtle.

We intend to introduce these changes over a series of weeklies. The major structural changes will be made in weekly snapshots of their own. Gofix will update user code automatically in most cases.

The next release will be the Go 1 release candidate.

Andrew

  

Ugorji Nwoke

unread,
Oct 6, 2011, 1:18:26 PM10/6/11
to golan...@googlegroups.com
I think, if you want to iterate over a slice of bytes, convert the string to a slice of bytes. ie I expect the following to do different things:
s := "abc"
for idx, val := range s { ... } // iterate over the runes of a string s (special case for a string, just like there's different special-case semantics for a map)
for idx, val := range []byte(s) { ... } // iterate over a byte slice (as a typical slice iteration does)

In practice, it's pretty intuitive and novel.

Riton

unread,
Oct 6, 2011, 1:28:23 PM10/6/11
to golan...@googlegroups.com
range is defined as a way to iterate over the elements, therefore it seems weird that accessing the element of string and iterating over the string produce differents types (byte and rune respectively)

chris dollin

unread,
Oct 6, 2011, 1:32:41 PM10/6/11
to golan...@googlegroups.com

Strings aren't implemented as []byte.

Even if they were, implementing something as []byte doesn't demand that
all accesses be to bytes.

The inconsistency is that s[x] gets you raw bytes but range gets you codepoints.
It's a compromise that keeps strings slim and [] access fast. Most of
the time there's
no problem, and there are no problem-free constructs ...

chris dollin

unread,
Oct 6, 2011, 1:35:01 PM10/6/11
to Eleanor McHugh, golang-nuts
On 6 October 2011 16:11, Eleanor McHugh <ele...@games-with-brains.com> wrote:
> On 6 Oct 2011, at 14:08, Russ Cox wrote:
>> See http://blog.golang.org/2011/10/preview-of-go-version-1.html.
>> Please post comments in this thread.  Thanks.
>
> My main disappointment is that Go 1 won't include a succinct literal form for user-defined function types as the current need to type cast anonymous functions is ugly, ugly, ugly, ugly, ugly.

When does one type-cast anonynous functions?

Or do you mean that an anonymous function comes with a heavy-weight
func ... syntax? It's not clear to me that you could leave it out and preserve
Go's type-safety.

Andrew Gerrand

unread,
Oct 6, 2011, 1:48:02 PM10/6/11
to golan...@googlegroups.com
On Thursday, October 6, 2011 6:43:48 AM UTC-7, André Moraes wrote:
Another thing I forgot to put in the last post:

The exp package will still live in the tip and will be removed only on
the "Go N" versions?

Yes. The exp/ directory will still be in tip, but deleted from the release branch.

Andrew

Andrew Gerrand

unread,
Oct 6, 2011, 1:52:38 PM10/6/11
to golan...@googlegroups.com, r...@golang.org


On Thursday, October 6, 2011 7:02:08 AM UTC-7, Vincent wrote: 
 It will remove equality on function and map values except for comparison with nil.

However this particular change seems a bit drastic... Isn't it possible to keep the possibility to compare function and map values for equality while disallowing their usage as a part of map keys ? Could you elaborate on the potential problems with function equality ?
 
Function equality is rarely used and expensive to implement.  It causes problems in dynamic libraries (based on
experience with C) and it also prevents us from avoiding allocations when creating trivial closures.

Map equality is currently defined as map pointer equality, which isn't very useful (we couldn't find any code that uses it). By removing equality on maps we can redefine map equality to something more useful at a later stage.

Andrew

unread,
Oct 6, 2011, 1:52:31 PM10/6/11
to golang-nuts
Consider the following explanation:

It is currently possible to easily iterate over the individual bytes
of "[]byte" or "string" using a for loop:

for i:=0; i<len(s); i++ {
fn(s[i])
}

On the other hand, should range over a Go string be byte-orien