Go 1.3 beta 1 released

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

by curiouslearn • 12 years ago

199 128 12 years ago

tip.golang.org

ancarda• 12 years ago

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

landr0id2• 12 years ago

That's unfortunate. I looked around this post details why it was pushed: https://groups.google.com/forum/#!msg/golang-dev/bShm2sqbrTY...

nathany2• 12 years ago

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.

whyrusleeping3• 12 years ago

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.

landr0id2• 12 years ago

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

_Soulou• 12 years ago

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

nathany2• 12 years ago

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.

obilgic• 12 years ago

generics please?

    contains no language changes

tptacek• 12 years ago

My guess is you'll probably know a year in advance if that's actually going to happen.

rockybox• 12 years ago

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

pjmlp3• 12 years ago

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

coldtea3• 12 years ago

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.

LanceH2• 12 years ago

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

burke• 12 years ago

I think it's safe to say that'll be 2.0, 3.0, or never -- not a point release.

bsg753• 12 years ago

If you need generics, Go is not the language you need.

voidlogic• 12 years ago

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.

pdq• 12 years ago

Here's the Go 1.3 Release Notes:

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

patrickxb• 12 years ago

I'm excited about 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.

mediocregopher2• 12 years ago

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• 12 years ago

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.

frou_dh2• 12 years ago

I'm looking forward to it too. I think it'll be a good way to have one-per-type free-lists inside my toy language implementation. At the moment, garbage is created like crazy in there for all the short-lived immutable values.

unoti• 12 years ago

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?

krasin• 12 years ago

http://play.golang.org runs user programs inside Native Client. See more on the blog post: http://blog.golang.org/playground

rouille• 12 years ago

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• 12 years ago

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

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

jshen• 12 years ago

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

cespare3• 12 years ago

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.

4ad4• 12 years ago

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.

whyrusleeping3• 12 years ago

with gccgo you get to take advantage of a lot of gcc's optimizations (-O3) and it can generate faster code because of it.

4ad4• 12 years ago

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

binarycrusader5• 12 years ago

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• 12 years ago

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

cespare3• 12 years ago

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

farslan• 12 years ago

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

cespare3• 12 years ago

    s := make(map[string]struct{})
    s["foo"] = struct{}{}
    if _, ok := s["foo"]; ok {
      // exists
    }

There are varying amounts of fluff you can put on top of this, but that's the basic approach. Wrap it up in a type with methods if you're using it a lot in a program.

Perhaps you also want built-in union, intersection, difference, etc. I personally find I need a set with simple membership testing about 10x as often as I need more advanced set operations, so from my perspective it's fine to leave those to third-party libraries.

binarycrusader5• 12 years ago

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.

ImJasonH2• 12 years ago

https://gist.github.com/ImJasonH/7791518

binarycrusader5• 12 years ago

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.

politician• 12 years ago

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

pkulak• 12 years ago

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

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

dkural2• 12 years ago

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

vanderZwan• 12 years ago

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

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

dkural2• 12 years ago

thank you!

higherpurpose• 12 years ago

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

ithkuil• 12 years ago

Native client support for ARM is not yet there.

4ad4• 12 years ago

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/

evidencepi• 12 years ago

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

neals• 12 years ago

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

leaveyou• 12 years ago

I use 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• 12 years ago

+1 Gets the job done.

bananas• 12 years ago

I haven't found one I like yet. However after a few years of hand holding by visual studio I'm less inclined to deal with one as they are complicated and require a lot more maintenance than a basic text editor. So vim it is for me and that's good enough as it highlights and indents well. The compiler takes so little time and the language is so normalised that I'm not sure there is a great advantage in an IDE either.

_ak• 12 years ago

Most people I know use vim or SublimeText to write their Go code.

I personally prefer vim, and use the vim support delivered with Go plus gocode for code completion, that's really all I need for development. Unlike with Java, I never felt the need for an IDE with Go.

kellros• 12 years ago

Intellij IDEA with http://go-ide.com/ works for me. Some useful features:

1. Quickly run/restart your application 2. Run specific unit test (all in package, all in file or specific one) 3. Parameter and func signatures are more detailed via CTRL+P (parameter info) than what you would get with GoSublime and GoCode.

There's only one thing so far I found a bit quirky:

Say you got a function with the signature func() (err error) and pass it as a parameter to another function that has the signature func F(f func() error), it will complain that the signatures don't match, but it will still compile.

JoelHobson• 12 years ago

I've been using Light Table with the LightTable-Go plugin (I'm one of the contributors). Support is still fairly basic, but for my needs it works pretty well. If you want to try it, grab the plugin from github and not the ide's plugin manager - that one hasn't been updated in some time.

de_dave• 12 years ago

I've been more than happy with VIm and the vim-golang extension.

rjammala• 12 years ago

I use emacs and gocode. The following url's explain how to setup emacs for go:

http://dominik.honnef.co/posts/2013/03/writing_go_in_emacs/

http://dominik.honnef.co/posts/2013/08/writing_go_in_emacs__...

bsg753• 12 years ago

https://github.com/Komodo/komodo-go

Not so much an IDE, dependent on your definition. More of a set of editor extensions, but useful so far.

Of course IDE availability should be low on the list of selection criteria for any language...

marcosvm• 12 years ago

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

thescrewdriver8• 12 years ago

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.

DrJokepu3• 12 years ago

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

thescrewdriver8• 12 years ago

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.

ahuth3• 12 years ago

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.

coldtea3• 12 years ago

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.

ImJasonH2• 12 years ago

http://play.golang.org/p/DdwCOZwiCk

jerf2• 12 years ago

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.

NateDad6• 12 years ago

I'm actually hugely not a fan of magically rendering code variables in strings. It's super error prone, and way too magical.

If you really want named variables in format strings you can make a template like "My name is {{.Name}} and surname is {{.Surname}}", and render the template with either a map of strings to strings, or a struct with the right named values.

why-el• 12 years ago

Ah, I think there should be a formula that spills out how many minutes will pass before language discussion descends to syntax assassination.

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

I mean, in the thread that announces a new version of a language whose designers made it abundantly clear that it is intended to solve Google's problems, the top comment is about how to interpolate strings? I think they made a very good move by ignoring most syntax requests (There are a lot) and move on. Even better is their decision to harmonize formatting and build the formatter right into the language.

Syntax is extremely overrated, and evidence for it has been provided years ago. [1]

[1] http://c2.com/cgi/wiki?ProgrammingLanguagesAnInterpreterBase...

Edit: typos.

thescrewdriver8• 12 years ago

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.

dilap2• 12 years ago

Pretty much impossible to add at this point w/o breaking back-compat, though, right?

thescrewdriver8• 12 years ago

fmt.RichPrint("....")

giovannibajo1• 12 years ago

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

4ad4• 12 years ago

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

Go 1.3 beta 1 released

Related Stories