Go 1.3 Beta 1 Released

[Andrew Gerrand]

Hi Go nuts,

We have just released go1.3beta1, a beta version of Go 1.3.
It is cut from the default branch at revision f8b50ad4cac4.

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 this page:

    https://code.google.com/p/go/wiki/Downloads

Note this is different to the usual location.

To find out what has changed, read the release notes for Go 1.3:

    http://tip.golang.org/doc/go1.3

Documentation for Go 1.3 is available at:

    http://tip.golang.org/

Our goal is to release the official version of Go 1.3 on June 1, 2014.

Andrew

[Karan Misra]

Cool.

On Wednesday, April 23, 2014 4:56:53 AM UTC+5:30, ada wil wrote:

Type system needs an overhaul. Until then golang is just another toy language.

[Dan Kortschak]

Yeah, toys are fun.

On Tue, 2014-04-22 at 18:24 -0700, Karan Misra wrote:
> Cool.

[bsr]

:-))

[Ahmed Waheed]

shiny.

[bit...@gmail.com]

Thank you for all your guys' hard work.

[Mike Kinney]

Thanks.

Is there supposed to be a Solaris package available in binary downloads? (https://code.google.com/p/go/wiki/Downloads)

[Ian Lance Taylor]

On Tue, Apr 22, 2014 at 8:49 PM, Mike Kinney <mike....@gmail.com> wrote:
>
> Is there supposed to be a Solaris package available in binary downloads?
> (https://code.google.com/p/go/wiki/Downloads)

No. Solaris not a first class port, at least not yet. You will have
to build it yourself.

Ian

[Vincenzo Prignano]

So excited to test this out with some projects I am running

On Wednesday, April 23, 2014 12:34:45 AM UTC+2, Andrew Gerrand wrote:

[Lucio]

Feel free, the source is there...

Lucio.

[Alex Zorin]

Woohoo, `go tool cover` works for cgo projects now.

Great job

[jfcg...@gmail.com]

Thanks to all the people for this beautiful release (beta). Lots of improvements were made apparently.

One thing I see missing is a tls.LoadX509KeyPair-like function for encrypted key pair files.

1st mentioned here:

https://groups.google.com/forum/#!topic/golang-nuts/ht_gQ2ET0c0

Issue here:

https://code.google.com/p/go/issues/detail?id=6722

was planned for 1.3 i guess.

A starting point (and why there should be a function for encrypted key pairs: due to its length and amount of changes needed to the current functions) here:

http://play.golang.org/p/8OYTuZtZIQ

As we would all agree, key pairs should be kept encrypted on the hard disk, and a simple function accepting file names and a password to load the key pair would be very convenient.

Any plan on adding it? 1.3 or 1.4?

Thanks,

Serhat

[Brian Hatfield]

I didn't see it in the release notes, but a thing I saw talked about for 1.3 was potentially reigning in the compiled binary sizes a little bit. Is that a quiet feature in this release?

--
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/d/optout.

[Jérôme Champion]

Thanks for the hard work!

Is there any example of how to use and how to not use the sync.Pool type?

[Ignacio Grande]

Go itself is using sync.Pool in some libraries, for example: http://tip.golang.org/src/pkg/io/ioutil/ioutil.go?h=Pool#L140 . It looks pretty straightforward to use. There are more uses (look for Pool in the search box).

I suppose that reused data structures will not be cleared, maybe it should be mentioned in the documentation. 

[Andrew Gerrand]

On 23 April 2014 20:25, <jfcg...@gmail.com> wrote:

Thanks to all the people for this beautiful release (beta). Lots of improvements were made apparently.

One thing I see missing is a tls.LoadX509KeyPair-like function for encrypted key pair files.

1st mentioned here:

https://groups.google.com/forum/#!topic/golang-nuts/ht_gQ2ET0c0

Issue here:

https://code.google.com/p/go/issues/detail?id=6722

was planned for 1.3 i guess.

A starting point (and why there should be a function for encrypted key pairs: due to its length and amount of changes needed to the current functions) here:

http://play.golang.org/p/8OYTuZtZIQ

As we would all agree, key pairs should be kept encrypted on the hard disk, and a simple function accepting file names and a password to load the key pair would be very convenient.

Any plan on adding it? 1.3 or 1.4?

It was planned for 1.3 but didn't get done. Hopefully we can get it into 1.4.

Andrew

[Frank Schröder]

Here is a summary of all of our go code 1.2.1 vs. tip from today.

$ ~/go/bin/go version; make clean; du -hs ~/gopath/bin; time make GO=~/go/bin/go clean installall; du -hs ~/gopath/bin
go version go1.2.1 darwin/amd64
131M    /Users/frschroeder/gopath/bin

real    0m10.896s
user    0m19.253s
sys    0m4.590s

258M    /Users/frschroeder/gopath/bin

go1.2.1: 127MB

$ ~/gotip/bin/go version; make clean; du -hs ~/gopath/bin; time make GO=~/gotip/bin/go clean installall; du -hs ~/gopath/bin
go version devel +f613443bb13a Tue Apr 22 21:12:15 2014 -0700 darwin/amd64
131M    /Users/frschroeder/gopath/bin

real    0m7.540s
user    0m18.092s
sys    0m3.824s
232M    /Users/frschroeder/gopath/bin

tip: 101M (~20% less) which is what I see on average per binary plus faster compile times.

Frank

[Dan Kortschak]

That doesn't look like it should work - the error checks out with the source and the source agrees with the oracle docs on the web. Have you checked that it works with go1.2 again? (my guess is that you had stale packages that your upgrade brought up to date and thus broke the build of this package).

On 24/04/2014, at 12:12 AM, "triv...@gmail.com" <triv...@gmail.com> wrote:

> here's one possible CGO issue for you guy, when building github.com/mattn/oci8 which previously works under go 1.2

[Romain Griffiths]

Thank you for your work. I am having pleasure to code with go.

Do you know if the bug with gbd where next sometime continue is fixed ?

Romain

[Ian Lance Taylor]

On Apr 23, 2014 2:52 PM, "Romain Griffiths" <romain.g...@gmail.com> wrote:
>
>
> Thank you for your work. I am having pleasure to code with go.
>
> Do you know if the bug with gbd where next sometime continue is fixed ?

There are said to be various problems with gdb, but I believe that particular one is fixed.

Ian

[ajstarks]

I'm seeing 16-22% binary size reduction on MacOS X and linux/arm.

[rec...@gmail.com]

Cool, improvements on http package and performance are just amazing! Great work!

在 2014年4月23日星期三UTC+8上午6时34分45秒，Andrew Gerrand写道：

[shka...@gmail.com]

Guys, thank you for all your hard work!

[Rob Napier]

I see that there was some work done in 1.3 around net/http/transfer.go to add more support around sending Trailers, but I don't see anything about it in the release notes, and the code still says:

   228		// TODO(petar): Place trailer writer code here.

(Though immediately after that it actually does seem to send Trailer, which it didn't in 1.2.) The docs don't seem to have additional information. Does net/http support sending Trailers in 1.3? I am working on a custom protocol over HTTP, and it would be convenient to send status information at the end in the form of a trailer.

(Also, 1.3 knocks over 15% off my binary sizes. Nice work.)

Thanks,

-Rob

[minux]

On Apr 25, 2014 9:30 PM, "Rob Napier" <robn...@gmail.com> wrote:
>
> I see that there was some work done in 1.3 around net/http/transfer.go to add more support around sending Trailers, but I don't see anything about it in the release notes, and the code still says:
>    228 // TODO(petar): Place trailer writer code here.
> (Though immediately after that it actually does seem to send Trailer, which it didn't in 1.2.) The docs don't seem to have additional information. Does net/http support sending Trailers in 1.3? I am working on a custom protocol over HTTP, and it would be convenient to send status information at the end in the form of a trailer.

the status for trailer support is best summarized in a recent CL: https://codereview.appspot.com/86660043

[Rob Napier]

Thanks a lot. For anyone else interested, the most salient note is from net/http/client_test.go, which nicely summarizes the current and planned situation:

+ // TODO: golang.org/issue/7759: there's no way yet for

+ // the server to set trailers without hijacking, so do

+ // that for now, just to test the client. Later, in

+ // Go 1.4, it should be be implicit that any mutations

+ // to w.Header() after the initial write are the

+ // trailers to be sent, if and only if they were

+ // previously declared with w.Header().Set("Trailer",

+ // ..keys..)

This (anticipated) 1.4 behavior sounds ideal. Thanks.

-Rob

--
Rob Napier -- Software and Security Consulting
Cocoaphony blog -- http://robnapier.net/blog

iOS Programming Pushing the Limits -- http://robnapier.net/book

[Roger Pack]

On Tuesday, April 22, 2014 4:34:45 PM UTC-6, Andrew Gerrand wrote:

Hi Go nuts,

We have just released go1.3beta1, a beta version of Go 1.3.
It is cut from the default branch at revision f8b50ad4cac4.

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

I'm not sure if this is worthy of a tracker, but using the "writing web applications" tutorial code:

http://golang.org/doc/articles/wiki/final.go

And running this:

$ ab -n2500 http://localhost:8080/edit/test

with 1.3 (go1.3beta1.darwin-amd64-osx10.6)

I get ~955 requests per second.

With 1.2.2

I get ~982 requests per second.

Should be reproducible on your side (seems to reproduce reliably here).  FWIW.

Compilation for the same (on this particular box) went down from 2.3s with 1.2.2

to 1.4s with 1.3.1 awesome!

-roger-

[Brad Fitzpatrick]

On Wed, May 7, 2014 at 12:04 PM, Roger Pack <rogerp...@gmail.com> wrote:

On Tuesday, April 22, 2014 4:34:45 PM UTC-6, Andrew Gerrand wrote:

Hi Go nuts,

We have just released go1.3beta1, a beta version of Go 1.3.
It is cut from the default branch at revision f8b50ad4cac4.

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

I'm not sure if this is worthy of a tracker, but using the "writing web applications" tutorial code:

http://golang.org/doc/articles/wiki/final.go

And running this:

$ ab -n2500 http://localhost:8080/edit/test

If you're using "ab", everything following is questionable to the point of useless.

I've been bit by ab's stupidity too many times to count. Please don't draw any conclusions from it.

[James Bardin]

On Wednesday, May 7, 2014 3:19:30 PM UTC-4, bradfitz wrote:

If you're using "ab", everything following is questionable to the point of useless.

yes, please don't use ab anymore. With fast calls over loopback, you're mostly benchmarking ab itself. If you want an easy http bench tool with some stat output wrk is very good.

FWIW wrk with 2 threads on my laptop can do about >20k req/s on that go program in both go1.2.1 and tip on darwin.

[Karan Misra]

Absolutely. I have been bitten by “ab” before, and I steer clear of it.

And while we are on the topic of benchmarking, why not give boom a try. Written my Gopher rakyll, it is quite up for the task. https://github.com/rakyll/boom

I recently gave it a decent workout when working on an article comparing some of the web frameworks: https://github.com/kidoman/fibrous#summary

For this micro bench, Go 1.3 beta1 managed to pull 31k+ req/s on a single core (GOMAXPROCS=1) on my laptop. In comparison, node.js was giving around 8k req/s

I still need to get the code (and the results) peer reviewed (as I might be doing something stupid somewhere.) I invited codegangsta (martini author) to have a look at the martini numbers as well (before the story pops.)

Regards,

Karan

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/Sc5BEMaZmE0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Roger Pack]

OK I'm not trying to say anything is bad necessarily, just showing my reported benchmarks (I assume they wanted some benchmark reports "from the field" for the beta...)

here's my (best of 10 style) results

wrk git master, run like this $ ./wrk  -t12 -c40 -d5s http://localhost:8080/edit/test

1.2.2:

10434.32 req/s

1.3:

10077.09 req/s

siege, run like this $ siege -b -t2S  http://localhost:8080/edit/test

1.2.2:

4049.19 req/s

1.3:

3919.08 req/s

So overall, ab reports a speed difference of +2.8%, wrk reports a speed difference of +3.5% and siege reports a speed difference of 3.3%.

This is on OS X 10.6 with an old core2 duo.

On Linux they seem to be at about equal speed (1.2% slower in some tests, in some tests equal).  Anybody notice any speed differences with this or anything else?

Thanks!

-roger-

[Frank Schröder]

What is the status of pprof support?

I'm getting output like this on tip builds including Go 1.3 beta 1 even after cleaning everything out. This is on OSX. Is this my setup?

Fetching /pprof/heap profile from localhost:3333 to
  /var/folders/c6/w93tf40s62n1m251kwd55ld03900l6/T/g_PQTzhZcV
Wrote profile to /var/folders/c6/w93tf40s62n1m251kwd55ld03900l6/T/g_PQTzhZcV
Adjusting heap profiles for 1-in-524288 sampling rate
addr2line: syminit: Undefined error: 0
Welcome to pprof!  For help, type 'help'.
(pprof) top
Total: 4522.8 MB
  4522.8 100.0% 100.0%   4522.8 100.0% 0000000000423f35
     0.0   0.0% 100.0%      0.5   0.0% 000000000040e585
     0.0   0.0% 100.0%      0.5   0.0% 0000000000410ef7
     0.0   0.0% 100.0%      0.5   0.0% 00000000004115c4
     0.0   0.0% 100.0%      0.5   0.0% 0000000000412104
     0.0   0.0% 100.0%   4522.3 100.0% 00000000004138cf
     0.0   0.0% 100.0%      0.5   0.0% 00000000004143fd

On Wednesday, April 23, 2014 12:34:45 AM UTC+2, Andrew Gerrand wrote:

Hi Go nuts,

We have just released go1.3beta1, a beta version of Go 1.3.
It is cut from the default branch at revision f8b50ad4cac4.

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

[Michael Jones]

http://research.swtch.com/macpprof

--

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.