Go 1.1 Release Candidate 1 released

11,041 views
Skip to first unread message

Andrew Gerrand

unread,
May 1, 2013, 10:59:11 AM5/1/13
to golang-nuts
Hi Go nuts,

We have just released go1.1rc1, a release candidate for Go 1.1. It is cut from the default branch at revision bea6199b09ea.

This release candidate should be stable and production-ready, but please exercise caution when deploying it to critical systems.

Please help us by testing your Go programs with the new tool chain and libraries, and report any problems using the issue tracker:
    http://golang.org/issue/new

You can download binary and source distributions from the usual place:
    https://code.google.com/p/go/downloads/list?q=go1.1rc1

To find out what has changed, read the release notes for Go 1.1:
    http://tip.golang.org/doc/go1.1.html

Documentation for Go 1.1 is available at http://tip.golang.org/

Thanks to everyone who has contributed to the release so far. We're almost there!

Andrew

Kevin Gillette

unread,
May 1, 2013, 12:34:36 PM5/1/13
to golan...@googlegroups.com
Unless it's not being included in rc1, I feel it's worth mentioning the function representation change, since it means closures no longer require runtime code generation (which among other things allows the heap to be marked non-executable on supported systems).

Rob Pike

unread,
May 1, 2013, 12:40:13 PM5/1/13
to Kevin Gillette, golan...@googlegroups.com
It's part of Go 1.1.

-rob

minux

unread,
May 1, 2013, 2:40:53 PM5/1/13
to andyamst...@gmail.com, golan...@googlegroups.com

On Thu, May 2, 2013 at 1:04 AM, <andyamst...@gmail.com> wrote:
This is great thank you.  I am looking at using Go as part of our Android app - I know that Dave Cheney has released tarballs for ARM but I can't find any instructions on how to get setup for Go development on ARM.  If yo know of any blog posts with an example it would be appreciated.
basically the same with other platforms.

just follow tip.golang.org/doc/install and replace the download URL with that of Dave's tarballs'.

Keith Rarick

unread,
May 1, 2013, 4:35:00 PM5/1/13
to Andrew Gerrand, golang-nuts
Hooray!

I've updated the Heroku Go buildpack's go1.1 branch
to pull go1.1rc1 by default. If you're already using this
branch, you don't have to do anything; your next push
will use go1.1rc1.

If you're familiar with buildpacks and want to use this,
you can set your buildpack URL to:
https://github.com/kr/heroku-buildpack-go.git#go1.1

For more information, see the Go buildpack's readme at:
https://github.com/kr/heroku-buildpack-go

As a reminder, soon after Go 1.1 is officially out, I'll update
the buildpack's master branch to use 1.1.
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

andrey mirtchovski

unread,
May 1, 2013, 10:00:28 PM5/1/13
to golang-nuts, Andrew Gerrand
i'm having a strange problem with running statically linked cgo code
compiled on 10.8.{3,4} to 10.7.5. just tried all the examples from
misc/cgo/stdio and they all compile fine on mountain lion but fail
miserably on lion with:

$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.7.5
BuildVersion: 11G63b
$ ./chain; ./fib; ./hello
Illegal instruction: 4
Illegal instruction: 4
Illegal instruction: 4
$

two 64-bit lion boxes i've tried so far and they both fail in the same
way. neither is at my disposal and neither has dev tools on it so i'm
worried i can't do much to help. still, i wonder if others can
reproduce and have an idea how to mitigate this. i wouldn't want to be
forced to distribute two different binaries or to drop to 10.7 for
development. any magic LDFLAGS available?

andrey

andrey mirtchovski

unread,
May 1, 2013, 10:15:23 PM5/1/13
to golang-nuts, Andrew Gerrand
> i'm having a strange problem with running statically linked cgo code
[snip]

just to add, non-cgo programs compiled on mountain lion seem to work fine on lion. godoc happily serves the main page which, i assume, exercises the cgo parts in net?

this on 10.7.5. godoc works, the other three don't:

$ otool -L godoc chain hello fib
godoc:
 /usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current version 0.0.0)
 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 0.0.0, current version 0.0.0)
 /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 0.0.0, current version 0.0.0)
chain:
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
hello:
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
fib:
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

John Barham

unread,
May 1, 2013, 10:48:39 PM5/1/13
to golang-nuts
Very nice! I'm seeing ~30% speedups in some of my compute heavy code
compared to the beta releases.

Would it be worth considering annotating the 1.1 standard library
documentation to indicate what changes were introduced in 1.1 so that
the reader could avoid inadvertently writing code that's backward
incompatible with 1.0? See e.g.
http://docs.python.org/2.7/library/datetime.html#datetime.timedelta.total_seconds
from the Python documentation.

John

Dave Cheney

unread,
May 1, 2013, 11:37:09 PM5/1/13
to John Barham, golang-nuts
That is unexpected, in terms of the compilers, very very little has changed from beta2

John Barham

unread,
May 1, 2013, 11:51:34 PM5/1/13
to Dave Cheney, golang-nuts
My mistake, I've just double-checked no speedup from beta2, so the
original must have been built w/ 1.0.3.

Dave Cheney

unread,
May 2, 2013, 1:07:54 AM5/2/13
to John Barham, golang-nuts
Excellent. That is in line with the general expected speed up from 1.0 to 1.1rc.

Maxim Khitrov

unread,
May 2, 2013, 9:08:45 AM5/2/13
to John Barham, golang-nuts
On Wed, May 1, 2013 at 10:48 PM, John Barham <jba...@gmail.com> wrote:
> Would it be worth considering annotating the 1.1 standard library
> documentation to indicate what changes were introduced in 1.1 so that
> the reader could avoid inadvertently writing code that's backward
> incompatible with 1.0? See e.g.
> http://docs.python.org/2.7/library/datetime.html#datetime.timedelta.total_seconds
> from the Python documentation.

It's a bit different for Python since users are required to have a
specific minimum version installed to run your application (unless you
package it with py2exe or something similar). These days it's even
worse, with some applications requiring Python 3 and others only
supporting 2.

Go code written for 1.0 still works under 1.1, but there is no real
reason to write new code that's backward compatible. It's only the
developer that needs to keep their Go installation up to date. Users
can download and run binaries without installing anything extra.

Andrew Gerrand

unread,
May 2, 2013, 9:17:29 AM5/2/13
to John Barham, golang-nuts

On 1 May 2013 22:48, John Barham <jba...@gmail.com> wrote:
Would it be worth considering annotating the 1.1 standard library
documentation to indicate what changes were introduced in 1.1 so that
the reader could avoid inadvertently writing code that's backward
incompatible with 1.0?

Everyone should upgrade to 1.1. We made some small provisions (with the "go1.1" build tag) to support code that runs under 1.0 and 1.1, but the majority should just migrate o 1.1 en masse. We work hard to make sure people don't need to think about versions.

Andrew

Hans Stimer

unread,
May 2, 2013, 10:43:45 AM5/2/13
to Andrew Gerrand, golang-nuts
Given your very strong statement: "Everyone should upgrade to 1.1.", I take it Google has switched all production code from 1 to 1.1?

Andrew Gerrand

unread,
May 2, 2013, 10:44:54 AM5/2/13
to Hans Stimer, golang-nuts

On 2 May 2013 10:43, Hans Stimer <hans....@gmail.com> wrote:
Given your very strong statement: "Everyone should upgrade to 1.1.", I take it Google has switched all production code from 1 to 1.1?

Yes, we have. But I meant that everyone should upgrade to 1.1 once it is finally released. The more adventurous (like us, at Google) can switch to 1.1 RC1 today.

Andrew

Paulo Pinto

unread,
May 2, 2013, 11:30:31 AM5/2/13
to golang-nuts
Unless users == Go developers.

As soon as Go usage grows, versioning will become an issue.

On 2 Mai, 15:08, Maxim Khitrov <m...@mxcrypt.com> wrote:
> On Wed, May 1, 2013 at 10:48 PM, John Barham <jbar...@gmail.com> wrote:
> > Would it be worth considering annotating the 1.1 standard library
> > documentation to indicate what changes were introduced in 1.1 so that
> > the reader could avoid inadvertently writing code that's backward
> > incompatible with 1.0?  See e.g.
> >http://docs.python.org/2.7/library/datetime.html#datetime.timedelta.t...

ryan.bressler

unread,
May 2, 2013, 11:37:42 AM5/2/13
to golan...@googlegroups.com
Go1.1 has been working great for me but i'm wondering what other people seeing in terms of performance of go1.1 code vs gccgo?

I have some decision tree code that uses recursion and closures ... it performs quite well under go1.1 but using gcc 4.8.0 it is much slower (about 3x depending on the input data). I'm wondering if gccgo has not seen the changes to how anonymous functions etc work included in go1.1 yet and will get faster with 4.8.1?

Ryan

minux

unread,
May 2, 2013, 12:05:05 PM5/2/13
to ryan.bressler, golan...@googlegroups.com
On Thu, May 2, 2013 at 11:37 PM, ryan.bressler <ryanbr...@gmail.com> wrote:
Go1.1 has been working great for me but i'm wondering what other people seeing in terms of performance of go1.1 code vs gccgo?

I have some decision tree code that uses recursion and closures ... it performs quite well under go1.1 but using gcc 4.8.0 it is much slower (about 3x depending on the input data). I'm wondering if gccgo has not seen the changes to how anonymous functions etc work included in go1.1 yet and will get faster with 4.8.1?
gccgo 4.8.0 doesn't have the recent function closure representation change included in Go 1.1, and
gccgo 4.8.0 uses an old snapshot of Go 1.1 packages.
gccgo 4.8.1 should be the real Go 1.1 release for gccgo.

see also:

Rémy Oudompheng

unread,
May 2, 2013, 4:16:40 PM5/2/13
to ryan.bressler, golang-nuts
On 2013/5/2 ryan.bressler <ryanbr...@gmail.com> wrote:
> Go1.1 has been working great for me but i'm wondering what other people
> seeing in terms of performance of go1.1 code vs gccgo?
>
> I have some decision tree code that uses recursion and closures ... it
> performs quite well under go1.1 but using gcc 4.8.0 it is much slower (about
> 3x depending on the input data). I'm wondering if gccgo has not seen the
> changes to how anonymous functions etc work included in go1.1 yet and will
> get faster with 4.8.1?
>
> Ryan

GCCGO does not perform escape analysis like the gc compiler: on
non-numerical computations, memory allocation and GC is often the
bottleneck and the new function representation allows to put an even
larger amount of data on stack than Go 1.0, hence the difference you
see.

Gccgo can however benefit from the runtime and library improvements of
Go 1.1, for example, the new garbage collector, but creating no
garbage will still be better than collecting it fast.

Regards,
Rémy.
Reply all
Reply to author
Forward
0 new messages