Two most interesting news for me are:<p>> The garbage collector is also more precise, which costs a small amount of CPU time but can reduce the size of the heap significantly, especially on 32-bit architectures.<p>Previously, 32-bit version was almost unusable is some cases when garbage collector kept the allocations for which
he falsely believed to be used even if they were not. I'd like to know if this means that the problem is finally solved.<p>> Previous Go implementations made int and uint 32 bits on all systems. Both the gc and gccgo implementations now make int and uint 64 bits on 64-bit platforms such as AMD64/x86-64.<p>This is a C-like can of worms, forcing you to test on more platforms just to be sure that you have portable code. I believed there's no reason to do such things with primitive data types in the new languages of 21st century (compare with <a href="http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html" rel="nofollow">http://docs.oracle.com/javase/tutorial/java/nutsandbolts/dat...</a>). I'd like to see any discussion about such in my opinion quite strange decision.
Worth also knowing that the Go team has made significant improvements in crypto speed:<p><a href="https://code.google.com/p/go/source/detail?r=eb2c99e6ec17db272ef3a20fa416f3fe86ba9f29" rel="nofollow">https://code.google.com/p/go/source/detail?r=eb2c99e6ec17db2...</a><p><a href="https://code.google.com/p/go/source/detail?r=e7304334527349c395f150e109296dfc0f81d271" rel="nofollow">https://code.google.com/p/go/source/detail?r=e7304334527349c...</a><p><a href="https://code.google.com/p/go/source/detail?r=e5620fd3ba5fb1d5fb083dbba864ca66d84fa859" rel="nofollow">https://code.google.com/p/go/source/detail?r=e5620fd3ba5fb1d...</a><p>Fast approaching OpenSSL speeds.<p>Also, the integration of the network poller into the main scheduler is likely to make a big difference to Go programs that make heavy use of the network.
It's not released yet, this is just a preliminary document. There are still open issues for Go 1.1: <a href="http://swtch.com/~rsc/go11.html" rel="nofollow">http://swtch.com/~rsc/go11.html</a>
And I guess there will be a RC first.
For those of us who are wondering if 1.1 is stable enough to upgrade: Google is already using Go 1.1 in production.<p>And the company is betting big time on Go, more than 50% of their codebase will be (re)written in Go in a couple of years.<p>Source: core dev on the golang team.
I grew up with Pascal and its derivatives, so I have a strong sense of the aesthetic of programming languages. I can't take Go seriously, or bring myself to use it, because it appears to have no aesthetic sense at all. It's ugly! Strings of keywords and punctuation, no rhythm to it, just a lot of mess. Like a cross between C and Prolog, perhaps, with a smattering of Python but only the ugly bits. I really don't like it.<p>Now, if you want to see a recent language with a bit of style to it -- and bear in mind I know nothing of how it is to use in practice, so I'm basing my opinions entirely on the look of it -- I think Rust is one of the best of the pack. So much smoother.<p>TL;DR (for any Redditors who may have stumbled in on their way to the Ron Paul fansite): languages have a flavour, and Go's flavour is "mess".
I'm interested in tracking Go as a replacement for Erlang. Some things that should probably happen:<p>* GC works on 32 bit systems.<p>* Scheduler improvements so that things are a bit more robust ( <a href="http://code.google.com/p/go/issues/detail?id=543" rel="nofollow">http://code.google.com/p/go/issues/detail?id=543</a> )<p>* A fairly solid library implementing supervision trees or something like it.<p>* Probably some other things, but those strike me as the big ones. The important thing is for the system to be able to run for months at a time.<p>I think they'll get there eventually. Maybe not 100%, but 'good enough' sooner or later.
Whenever I look through golangs specs, I always get stuck on the same question.<p>Why are the methods we define restricted to the types we define? I'm SURE there is a good reason.<p>Others have said that it's because if you did allow that kind of thing to happen, you might get naming collisions in packages. I don't buy this argument, you could get naming collisions anyway from packages, Go resolves those issues by aliasing. Go also allows for polymorphic behavior by packaging the actual type of the method caller with its actual value, so resolving which method to use isn't any more complicated.<p>I don't get it, I'm sure there's a good reason! I just hope it's a good enough reason to throw out the kind of freedom that would allow you.
> In Go 1.1, an integer division by constant zero is not a legal program, so it is a compile-time error<p>How often do be people accidentally divide by a constant 0? I personally use that to simulate runtime errors all the time in python. It's shorter than writing "raise Exception()".
We have integer madness here and no one is commenting on it. Why making this int change and why now? I don't like Java, but well-defined integer types sizes is a good thing. Most of the world uses intXX_t typedefs in C and C++ too.
Can you please delete this article until go1.1 is officially released. Just in case the go developers make any last minute changes. Otherwise this article may lead to confusion for those who choose to skip out on reading it on golang.org when go1.1 is released because they read it here.
"We trust that many of our users' programs will also see improvements just by updating their Go installation and recompiling."<p>Does anyone know if it is possible to determine what version of Go a given binary was compiled with? Perhaps extracting some metadata from an ELF section?
I'd more than welcome any instructions and pointers on how to install Golang 1.1 on my computer which has 1.03 installed already. Either to replace my current version or maybe to install it aside 1.03 for testing. Thanks a lot.