Go 1.3 beta 1 released (opens in new tab)

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.

> I understand your pain, but this is nowhere near a real issue for systems that Go is designed to help build.

I spend most of my day designing and coding the sorts of systems which Go was designed to help build. I'll agree that this isn't a major issue, but it is affecting whether or not I actually enjoy using Go.

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.

Go is designed to be a very practical and productive language. It's not quite clear how you're defining "magic" ...

String interpolation is both practical and useful.

There's nothing "magical" about it.

The intention of the programmer and the result is actually even more explicit than passing the values as arguments to some printf function.

One thing Go won't do, is pull the variables out of the local scope into the string interpolation automatically. As I think easy string interpolation is an antipattern, and I'm comfortable having to feed values into the string formatter, I'm not upset, but you're not going to convince people with that.

As we slowly, oh so slowly, but surely move into languages where buffer overflows are not possible to write (or at least require scary excursions into some sort of "unsafe" package), easy string interpolations that allow the programmer to believe they don't have to think about the correct encoding of the value become the next most pressing security threat. Pretty much every "injection" is due to over-simplified string interpolation.

Unfortunately, if your string interpolation syntax is as easy is "This is an interpolated $string"... it's also wrong. Dead wrong, very wrong, run away screaming wrong wrong wrong! String interpolation is actually a very hard problem, and this must irreducibly manifest itself in the API. ImJasonH's example, while it isn't "string interpolation" in the Ruby/Perl/etc. sense, does involve using a template system with sensible escaping mechanisms... it's HTML-specific, though, but for HTML it's incredibly powerful and easy to use correctly. In fact Go's HTML templating is the most powerful and easy-to-use correct HTML templating system I've ever seen that isn't in Haskell. Presumably there are others out there, but I've seen a lot of the competition and most of them will sit by, twiddling their thumbs and whistling idly, while you put 100 injections of every kind into your HTML page.

My guess is Go will never grow this style of string interpolation, pretty much because it is so very, very frequently wrong. The way Go is already doing it is as easy as it can feasibly be, without encouraging wrongness.

fmt.RichPrint("....")

Heka? https://github.com/mozilla-services/heka

http://hekad.readthedocs.org/en/latest/sandbox/index.html#sa...

Yes, I was actually looking for the union intersection, etc. functionality. I use that extensively in the project I work on. And it's core enough that I want it in the language, not as a third-party add on because of the performance implications and because of things the language can enforce natively. The Python set data type really is great for a certain class of problems. In particular, graph analysis and traversal.

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

Why interface{}? You're storing a value (and using space for it) that you don't need.

Thanks, that does seems like a rather elegant, simple implementation. I still want to see it in the core language or primary implementation, but seeing the different ways people implement sets in Go is helpful because I'm certain there are pitfalls in doing so.

Yah, we didn't want to rush it and end up stuck with a subpar package in the standard library.

If you are at GopherCon, I'll be giving a lightning talk on Saturday 11:40am on things I've learned by contributing to fsnotify and other open source projects. Happy to chat more about fsnotify afterwards.

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.

Check this out (make sure you read the README) https://github.com/howeyc/fsnotify

You can find it here : code.google.com/p/go.exp/fsnotify

+1 Gets the job done.

> 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.

There is extremely little code in the world that is faster with gccgo. Yes, gccgo can do better with floating point, but the lack of escape analysis slows it down tremendously in every real world situation out there.

http://dave.cheney.net/2013/11/19/benchmarking-go-1-2rc5-vs-...

thank you!

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.

Stop using Java and C++ for comparing generics in Go. There are lots of languages that had generics on day one.

And during all that time they were telling us we didn't need them.

In reality of people just don't know how to program without generics. Go provides interfaces which can be used to write generic code. Think of everything that has been written in C without generics or Java pre 1.4.

I'm all of the day generics is finely added (and yes I missed it a lot when I was new to Go a couple years ago), but it is much less of a issue then some people make it out to be.