
Go 1.3 beta 1 released - curiouslearn
http://tip.golang.org/doc/go1.3
======
patrickxb
I'm excited about sync.Pool:

[http://tip.golang.org/pkg/sync/#Pool](http://tip.golang.org/pkg/sync/#Pool)

There are a lot of cases where people write their own version of this (myself
included, but also the connections in database/sql for example). It will be
great to have an implementation in the standard library. This technique has
been very, very useful in StatHat's production code as we have grown.

~~~
mediocregopher
Reading the documentation, it seems that sync.Pool will automatically shrink
the pool size when it's not being used? If so, unless in the future it
provides some way to specify a cleanup function for those values, using it for
connections and the like would result in hanging connections (I think, not
100% sure).

~~~
kisielk
It only removes values that have been put back in to the pool. The assumption
is that anything you've put back in to the pool has already been cleaned up to
a state where it's ready to be used again when it's taken out.

~~~
Someone
That's exactly the complaint. You don't use a connection pool to get rid of
allocs and frees, but to get rid of lengthy calls that initialise the
connection. Because of that, you don't want to close your connection before
returning it to the pool. So, the pool will have to close those connections
whenever it disposes of an object in the pool.

I don't know enough go to interpret what 'might be deallocated' means in this
part of
[http://tip.golang.org/pkg/sync/#Pool](http://tip.golang.org/pkg/sync/#Pool):

 _" Any item stored in the Pool may be removed automatically at any time
without notification. If the Pool holds the only reference when this happens,
the item might be deallocated."_

Is there some interface{} similar to C++ destructors, or is that a reference
to the fact that the garbage collector need not deallocate unreachable
objects?

~~~
mediocregopher
There's not a destructor method like there is in C++. I'm not sure why they
defined Pool to only interact with interface{}, it seems like it would have
been much easier to define an interface which looks like:

    
    
      type PoolObject interface {
          Destroy()
      }
    

And have it interact with that. The NewPool func would look like:

    
    
      func NewPool(func() PoolObject) Pool
    

EDIT: Changed my code a bit

------
thescrewdriver
I really wish they'd add string interpolation to Go. After being able to use
s"My name is $name and surname is $surname" in Scala and "My name is #{name}
and surname is #{surname}" in Ruby I find working with printf a giant step
backwards.

~~~
DrJokepu
I wish they didn't! Magic features like this belong to magic languages like
Ruby. Go is not meant to be a magic language.

~~~
ahuth
There isn't much difference between this:

    
    
        "My name is #{name} and surname is #{surname}"
    

and this:

    
    
        "My name is " + name + " and surname is " + surname
    

or this:

    
    
        fmt.Println("My name is %s and surname is %s", name, surname)
    

Except the first one is much more readable.

String interpolation seems like a small thing, but I find myself wanting to
use it all the time. It's definitely not a "magic" feature. Javascript really
needs it as well.

~~~
lazyjones
> _Except the first one is much more readable._

I disagree, especially in the presence of syntax highlighting editors.

String interpolation would be a redundant alternative to existing mechanisms
(the above plus text/template for longer strings) and just make parsing more
complex. I don't think it would fit in well with Go's philosophy of providing
pleasant, minimalistic syntax.

~~~
thescrewdriver
I find that there are some disturbing similarities between the Java community
and the Go community when it comes to features and culture. There seems to be
an unwritten assumption that the language is perfect in its current form and
any additional features are a source of evil (up until the day when they are
added, in which case they are suddenly evidence of the language's
superiority).

~~~
lazyjones
> _the language is perfect in its current form_

It works really well in its current form, that is probably the general
consensous.

> _additional features are a source of evil_

Some of us have walked down that path before (e.g. Perl, Scala) and think we
have seen the light (or at least the darkness).

> _up until the day when they are added, in which case they are suddenly
> evidence of the language 's superiority_

That sounded very much like flamebait. Could you name an example of a feature
added to Go that was previously considered evil and then as evidence of Go's
superiority?

~~~
SiVal
Thescrewdriver is absolutely correct about Java. Many years ago, I
participated in several Java user groups here in Silicon Valley. We frequently
had members of the Java team from Sun as guest speakers. It always went
roughly the same: we professional Java devs would ask them for a few language
features that most of us wanted, and they would explain to us that they knew
better than we did what a programming language should have and suggest that we
should get over it.

Then a representative from Microsoft started attending a couple of the biggest
Java SIGs, and he would ask us how we would change Java if we could. We were
happy to answer. A few of the suggestions were broadly desired by the groups.

He took lots of notes, and a year or so later C# was announced. It included
several of those features. My impression is that most of us considered it a
better Java, as a language design. (The Achilles Heel of its relationship to
Microsoft was a huge, but separate, issue from the design of the language
itself.)

The Java Team suddenly had a whole new attitude about their fossilized
masterpiece, and features we had been told for years were bad ideas were
touted as evidence of Java's ongoing spirit of innovation with each new
version of Java.

------
unoti
The support for Native Client sounds interesting, but the distinction that
it's not portable native client makes me wonder what you might use this for.
What would one use the native client support for?

Could I use it to allow developers to make plugins for a product in Go and C++
in a secure way, instead of using say Lua?

~~~
rouille
On a related note, do you know if anyone is using Go with Lua plugins (or any
other plugin system for that matter) in production. If so, does it work well?

~~~
Matrixik
Heka? [https://github.com/mozilla-services/heka](https://github.com/mozilla-
services/heka)

[http://hekad.readthedocs.org/en/latest/sandbox/index.html#sa...](http://hekad.readthedocs.org/en/latest/sandbox/index.html#sandbox)

------
binarycrusader
I'm not asking for generics, but I really want an equivalent to Python's set
data type for strings and numbers at the leas built-in. I'm aware of golang
set on GitHub and the gen project as well, but I'm shocked that Go doesn't
have an equivalent to the set data type yet.

I'm open to suggestions.

~~~
xal
I tend to use map[string]interface{} when I need a set. It works okay.

~~~
farslan
struct{} is better because it doesn't do an allocating. See:
[https://github.com/fatih/set/blob/master/set_ts.go#L18](https://github.com/fatih/set/blob/master/set_ts.go#L18)

------
ancarda
For those wondering, os/fsnotify was pushed back to 1.4

~~~
whyrusleeping
Do you know where their current implementation of this is? I want to mess
around with it and dont care if i have to change code later.

~~~
nathany
The code is identical on GitHub and Google Code right now. The difference is
that we may make breaking changes under go.exp while leaving the
howeyc/fsnotify API as is.

We're still figuring out what os/fsnotify will look like.

------
politician
I'm very happy about the improvements to net/http.

~~~
pkulak
Looks like they fixed the connection leak and you can now set real timeouts?
Maybe I can finally stop using this hack:

[https://github.com/pkulak/simpletransport](https://github.com/pkulak/simpletransport)

It sure would be nice to reuse connections without memory blowing up!

------
pdq
Here's the Go 1.3 Release Notes:

[http://tip.golang.org/doc/go1.3](http://tip.golang.org/doc/go1.3)

------
marcosvm
It's cool to get those news a couple of days before Gophercon. I'd guess I'm
listening to some announcements there.

------
neals
How are we on IDE's? Last time I tried go (over a year ago) I couldn't really
find a nice IDE.

~~~
leaveyou
I use [https://code.google.com/p/liteide/](https://code.google.com/p/liteide/)
on ubuntu and it works well for my needs (and it gets better with each
version). It has all the basic features of an editor and the code completion
is quite good in the last versions. It's very easy to use (no complicate setup
needed) and I never felt the need to try GoSublime or other alternatives.

~~~
jksmith
+1 Gets the job done.

------
higherpurpose
If Go is coming to Native Client, then perhaps it will come to Android, too?

~~~
4ad
An ARM target has been exiting for years, it works just fine on Android.
Unfortunately (?) this doesn't allow creating GUI apps or using the Android
APIs. Camlistore[1] is written in Go and uses a Go backend on Android, it just
has a Java shim for the GUI.

[1] [https://camlistore.org/](https://camlistore.org/)

------
jshen
Random question, why would someone use gccgo over the standard go compiler?

~~~
cespare
One reason is that gccgo supports many architectures that gc does not (SPARC,
MIPS, PowerPC, Alpha). It also was the only way to get Go on Solaris until the
more recent port of gc to that platform.

gccgo is also supposed to produce better code for certain computationally
heavy workloads.

~~~
4ad
> gccgo is also supposed to produce better code for certain computationally
> heavy workloads.

Unfortunately, this is very seldom true. Gccgo could potentially generate
faster floating point code, but its lack of escape analysis grinds it to a
halt.

------
giovannibajo1
Cross compilation of programs using cgo? I thought that was landing in 1.3 as
well

~~~
4ad
It works fine, provided you have a gcc cross-toolchain.

------
dkural
How does performance compare to C++ for this release?

~~~
vanderZwan
I haven't seen a direct comparison yet, but here's a bunch of benchmarks Rob
Pike did comparing Go releases to Go releases:

[https://groups.google.com/forum/#!topic/golang-
dev/2YRmu_AWz...](https://groups.google.com/forum/#!topic/golang-
dev/2YRmu_AWz68)

If you have one version where you have a good grasp of how it compares to C++,
that should provide an answer, right?

~~~
dkural
thank you!

------
evidencepi
"but that the next GCC release, 4.10, will likely have the Go 1.4 version of
gccgo." LOL

------
obilgic
generics please?

    
    
        contains no language changes

~~~
rockybox
It took Java 5 versions over 8 years to get generics. It's not going to happen
in a minor release.

~~~
coldtea
Yes, but Java was left behind and ate C#'s dust (and now Scala's) because of
lack of progress like that.

Not the best example to justify adding generics late.

