|Go 1.3 Beta 1 Released||Andrew Gerrand||4/22/14 3:34 PM|
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:
You can download binary and source distributions from this page:
Note this is different to the usual location.
To find out what has changed, read the release notes for Go 1.3:
Documentation for Go 1.3 is available at:
Our goal is to release the official version of Go 1.3 on June 1, 2014.
|unk...@googlegroups.com||4/22/14 4:26 PM||<This message has been deleted.>|
|Re: Go 1.3 Beta 1 Released||Karan Misra||4/22/14 6:24 PM|
On Wednesday, April 23, 2014 4:56:53 AM UTC+5:30, ada wil wrote:
|Re: [go-nuts] Re: Go 1.3 Beta 1 Released||kortschak||4/22/14 6:26 PM|
Yeah, toys are fun.
On Tue, 2014-04-22 at 18:24 -0700, Karan Misra wrote:
|Re: [go-nuts] Re: Go 1.3 Beta 1 Released||bsr||4/22/14 7:15 PM|
|Re: Go 1.3 Beta 1 Released||Ahmed (OneOfOne) W.||4/22/14 7:31 PM|
|Re: Go 1.3 Beta 1 Released||Aaron Lefkowitz||4/22/14 8:26 PM|
Thank you for all your guys' hard work.
|Re: Go 1.3 Beta 1 Released||Mike Kinney||4/22/14 8:49 PM|
|Re: [go-nuts] Re: Go 1.3 Beta 1 Released||Ian Lance Taylor||4/22/14 9:00 PM|
|Re: Go 1.3 Beta 1 Released||Vince Prignano||4/22/14 9:38 PM|
So excited to test this out with some projects I am running
|Re: Go 1.3 Beta 1 Released||Lucio||4/22/14 10:05 PM|
Feel free, the source is there...
|Re: Go 1.3 Beta 1 Released||Alex Zorin||4/23/14 1:43 AM|
Woohoo, `go tool cover` works for cgo projects now.
|Re: Go 1.3 Beta 1 Released||Serhat Şevki Dinçer||4/23/14 3:25 AM|
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:
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:
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?
|Re: [go-nuts] Go 1.3 Beta 1 Released||Brian Hatfield||4/23/14 4:29 AM|
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?
|Re: Go 1.3 Beta 1 Released||Jérôme Champion||4/23/14 4:49 AM|
|unk...@googlegroups.com||4/23/14 7:07 AM||<This message has been deleted.>|
|Re: Go 1.3 Beta 1 Released||Ignacio Grande||4/23/14 7:39 AM|
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.
|Re: [go-nuts] Re: Go 1.3 Beta 1 Released||Andrew Gerrand||4/23/14 9:14 AM|
It was planned for 1.3 but didn't get done. Hopefully we can get it into 1.4.
|Re: [go-nuts] Go 1.3 Beta 1 Released||Frank Schröder||4/23/14 1:56 PM|
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
$ ~/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
tip: 101M (~20% less) which is what I see on average per binary plus faster compile times.
|Re: [go-nuts] Re: Go 1.3 Beta 1 Released||kortschak||4/23/14 2:16 PM|
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
|Go 1.3 Beta 1 Released||Romain Griffiths||4/23/14 2:51 PM|
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 ?
|Re: [go-nuts] Go 1.3 Beta 1 Released||Ian Lance Taylor||4/23/14 4:09 PM|
There are said to be various problems with gdb, but I believe that particular one is fixed.
|Re: [go-nuts] Go 1.3 Beta 1 Released||ajstarks||4/23/14 9:22 PM|
I'm seeing 16-22% binary size reduction on MacOS X and linux/arm.
|Re: Go 1.3 Beta 1 Released||Shuaiying Shane Hou||4/23/14 10:34 PM|
Cool, improvements on http package and performance are just amazing! Great work!
在 2014年4月23日星期三UTC+8上午6时34分45秒，Andrew Gerrand写道：
|Re: Go 1.3 Beta 1 Released||Sergey Shkarupin||4/24/14 7:38 AM|
Guys, thank you for all your hard work!
|Re: Go 1.3 Beta 1 Released||Rob Napier||4/25/14 6:30 PM|
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.)
On Tuesday, April 22, 2014 6:34:45 PM UTC-4, Andrew Gerrand wrote:
|Re: [go-nuts] Re: Go 1.3 Beta 1 Released||minux||4/25/14 6:36 PM|
the status for trailer support is best summarized in a recent CL: https://codereview.appspot.com/86660043
|Re: [go-nuts] Re: Go 1.3 Beta 1 Released||Rob Napier||4/25/14 6:44 PM|
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:
This (anticipated) 1.4 behavior sounds ideal. Thanks.
|Re: Go 1.3 Beta 1 Released||Roger Pack||5/7/14 12:04 PM|
I'm not sure if this is worthy of a tracker, but using the "writing web applications" tutorial code:
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.
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!
|Re: [go-nuts] Re: Go 1.3 Beta 1 Released||bradfitz||5/7/14 12:19 PM|
On Wed, May 7, 2014 at 12:04 PM, Roger Pack <rogerp...@gmail.com> wrote:
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.
|Re: [go-nuts] Re: Go 1.3 Beta 1 Released||James Bardin||5/7/14 12:38 PM|
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.
|Re: Re: [go-nuts] Go 1.3 Beta 1 Released||Karan Misra||5/7/14 10:28 PM|
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.)
|Fwd: [go-nuts] Re: Go 1.3 Beta 1 Released||Roger Pack||5/12/14 10:56 AM|
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
siege, run like this $ siege -b -t2S http://localhost:8080/edit/test
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?
|Re: Go 1.3 Beta 1 Released||Frank Schröder||5/17/14 1:26 PM|
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
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'.
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
|Re: [go-nuts] Re: Go 1.3 Beta 1 Released||Michael Jones||5/17/14 2:57 PM|