
Go 1.1 RC1 is out - bockris
https://groups.google.com/forum/#!msg/golang-nuts/9hEw6max1hU/SZIRA3YPyGsJ
======
taliesinb
I'm glad that escape analysis now allows for more natural if/then control
flow.

But I'm still unhappy that using named return values _still_ requires you to
put a superfluous "return;" at the end of such a function.

The whole reason I use named return values is to cut down on the boilerplate
code that carries the return value around -- so why not cut out the final
boilerplate 'return'? It doesn't solve any problem or add any information!

Otherwise, there are some nice improvements here. Other than the things
mentioned so far, I'm glad to see reflection filling out -- the day a Go REPL
will be possible is approaching.

~~~
burntsushi
> Other than the things mentioned so far, I'm glad to see reflection filling
> out -- the day a Go REPL will be possible is approaching.

Very close indeed! Struct, array and function types still can't be constructed
at run time, but as of Go 1.1, function _values_ can be as well as slice, map
and channel types. I exploit some of this in my `ty` package. [1,2]

[1] - <http://godoc.org/github.com/BurntSushi/ty>

[2] - <http://blog.burntsushi.net/type-parametric-functions-golang>

~~~
taliesinb
This is pretty cool!

I tried to convince rsc at some point about the enormous value of REPLs for
rapid development.. imagine connecting to an embedded REPL on a server to do
live debugging. I don't think I quite convinced him to drop everything and do
it himself, though.

Do you have plans to experiment with a transpiler to smooth away all the
remaining type noise?

Maybe a first step would be to explore how one could add pluggable 'dialect
translators' to the go tool so that anyone could write simple extensions for
the language while preserving the existing toolchain.

~~~
burntsushi
> Do you have plans to experiment with a transpiler to smooth away all the
> remaining type noise?

I don't have any particular plans; the `ty` package was a night of hacking
plus several days of polishing/writing. :-)

One of the major bummers about moving into the reflection world is
_performance_. My blog article talks about it a little bit, but it's also
worth looking more closely at the things I didn't talk about in the
benchmarks. (For instance, it seems that function calls in the reflection
world pay a very steep price.)

Re transpiler: do you mean a {Language}-to-Go source translation? If so, it
seems like you'd want to avoid `reflect` completely in that case. But maybe I
am misunderstanding.

> I tried to convince rsc at some point about the enormous value of REPLs for
> rapid development ... I don't think I quite convinced him to drop everything
> and do it himself, though.

A REPL would be very nice, but a REPL using `reflect` would definitely be a
lot of work. You'd need to make extensive use of the sub-packages in `go` to
convert the `Read` portion of the `REPL` into appropriate reflection types.
You could do it now, but you wouldn't be able to define new functions, structs
or interfaces. And `reflect` cannot spawn goroutines either, which is a
bummer.

------
dtwwtd
The race detector sounds interesting:

<http://tip.golang.org/doc/go1.1#race>

~~~
Cowen
I'll paraphrase something Andrew Gerrand said about this at a golang meetup
last night:

Because race conditions are so hard to detect, the race detector is obviously
prone to false negatives. Just because the tester doesn't find any race
conditions doesn't necessarily mean that there _aren't_ any. But the race
detector never finds false positives. If it finds a race condition, that
condition is very real.

You could just run your app with the race detector on all the time, but there
is a performance cost to using the race detector.

One way to get around this in cloud/clustered environments is to deploy your
app on a few machines with the race detector on and the rest with the race
detector off. That way you're running your app with a production load and
you're more likely to find race conditions, but you'll mitigate the
performance costs associated with the race detector.

~~~
dtwwtd
It makes sense to me that it can't possibly detect all race conditions but I
had never really thought about the ability to detect _any_ race conditions
programmatically.

Running the detector on just a few nodes sounds like a great way to offset the
performance penalty a bit. The docs on the race detector say that "memory
usage may increase by 5-10x and execution time by 2-20x" which could be quite
significant.

I also wonder about the effectiveness of randomly fuzzing your app with the
race detector on as a form of testing.

~~~
chubot
I'll take a bet that detecting ALL race conditions is equivalent to the
halting problem.

Certainly for an entire program it is... not sure if you limit it to the just
the code paths executed.

~~~
pcwalton
It will always be inexact. All dynamic analyses of this type are, because they
only observe what the program does as it executes and do not enforce any
restrictions.

If you want a more guaranteed form of race freedom, you need to constrain what
programs can do, either with dynamic restrictions on mutable state sharing
(like Erlang or the parallel extensions to JavaScript do) or with a type
system strong enough to reason about sharing of data (like Haskell or Rust).

------
mratzloff
If we're talking about wishlist items, I'd like a tool, any tool, for
detecting memory leaks. I understand they can't use Valgrind itself[1], but as
it stands, detecting where leaks exist can be very difficult.

[1] <http://code.google.com/p/go/issues/detail?id=782>

~~~
voidlogic
Outside of using cgo or working on the Go runtime (written in C), how are you
leaking memory in a garbage collected language? Your code either has a
reference to something, or it doesn't. If your code has a reference to
something, how is a tool going to know you don't mean too have that reference?

Outside of the "dangling reference" issue above "leaking" in a GCd language is
non-trivial. Here is a related Java discussion:
[http://stackoverflow.com/questions/6470651/creating-a-
memory...](http://stackoverflow.com/questions/6470651/creating-a-memory-leak-
with-java) . Also note Go doesn't have ClassLoader or class static fields.

~~~
supersillyus
You can leak memory by leaking goroutines. If a goroutine is waiting on a
channel that nobody else has access to, it lives forever, as does the memory
it references.

So, you can pretty easily leak memory without messing with unsafe things.

~~~
voidlogic
That is a pretty serious bug, that is not at all as easy to miss as something
like a memory leak is in C/C++.

It is also pretty easy to detect by this (or something better), which might be
handy in a big program: <http://play.golang.org/p/XmKfgQ4TmS>

~~~
supersillyus
I somewhat disagree. Even if you don't use channels as iterators/generators
(which many folks do), it's not hard to end up with a goroutine blocked on a
channel that'll never be closed/written to, and this situation (like memory
leaks) can result from changes elsewhere in the program or branches not
normally taken. A goroutine count doesn't seem like it'd be useful for
diagnosing this in a non-trivial program. The runtime could probably detect if
there are goroutines blocked on channels that no other goroutine has access
to, and that'd be quite helpful for debugging, but as of now it doesn't. Even
if it did, it couldn't catch all goroutine leaks.

~~~
voidlogic
>>A goroutine count doesn't seem like it'd be useful for diagnosing this in a
non-trivial program.

Sure it is, if you are leaking goroutines you will see an every increasing
count, even when your app is idle if the count doesn't return to the proper
baseline then you know you have a problem.

If you start a goroutine should should have a plan for terminating it. If you
don't have a natural way like the life cycle of handling a request then you
need to use channels (defer/close are your friends), waitgroups, condition
vars etc. I work on some fairly large Go applications and this hasn't been a
pain point.

------
schoper
They finally fix:

    
    
      func hello() int {
          if true {
              return 0
          } else {
              return 1
          }
      }
    
      >go run func.go
      ./func.go:3: function ends without a return statement

~~~
chatmasta
I've been taught by some pretty experienced engineers that in terms of
readability, multiple return statements are a bad idea. Instead, you should
conditionally set a return variable, and return it once at the end of the
function. But I'm not sold.... what is HN's thought on this matter?

~~~
mseepgood
> I've been taught by some pretty experienced engineers that in terms of
> readability, multiple return statements are a bad idea

They were wrong and probably not as experienced as they/you thought. Guard
clauses make code simpler and more understandable.

~~~
adamnemecek
Guard clauses and single return statements are not mutually exclusive.

~~~
masklinn
The whole idea of guard clauses in algol-derived languages (not functional
ones) is to bail out immediately with an early return...

[http://martinfowler.com/refactoring/catalog/replaceNestedCon...](http://martinfowler.com/refactoring/catalog/replaceNestedConditionalWithGuardClauses.html)

~~~
adamnemecek
I understand that but you can have a macro wrapping a goto statement to a
predefined label which will do that for you (and potentially set some errors).
It's debatable whether this really gives you anything but I kind of like this
style since you can replace the whole if statement with a single line
something like check_memory(pointer);. The goto's become particularly useful
if you want to have some cleanup done at the end of the function even if
something during the function fails.

~~~
masklinn
Now your assuming the language has goto. Which definitely is not the case
these days.

~~~
adamnemecek
Well the discussion is about go and go does have gotos.
<http://golang.org/ref/spec#Goto_statements>

------
CoffeeDregs
OT: I had not seen that there was a GCC compiler frontend for Go. Does anyone
have any experience with that? Do you lose lots of Go specific tooling?

~~~
chimeracoder
> Do you lose lots of Go specific tooling?

No, gccgo has been developed as a first-class compiler; the intent has always
been to separate Go-the-language from Go-the-implementation, to prevent a
single implementation from becoming the _de facto_ standard over the language
specification - a problem which we've seen happen in many other languages.

You can essentially use gccgo as a drop-in replacement for gc; it's only an
extra command-line flag you add to the compilation to specify the compiler.

gccgo is actually likelier to be _faster_ than gc for most computationally
bound code, since it piggybacks off of the optimizations that gcc has
incorporated over the last couple of decades. However, gc may be preferred if
you're relying heavily on goroutines (ie, in the hundreds/thousands), since gc
is better optimized for that.

------
kristianp
Interesting comment in that thread:

"It's worth mentioning the function representation change, since it means
closures no longer require runtime code generation (which among other things
allows the heap to be marked non-executable on supported systems)."

Anyone know what that means?

~~~
dylanvee
Marking the heap's region of memory as non-executable improves security.
<http://en.wikipedia.org/wiki/Executable_space_protection>

~~~
kristianp
Sorry, I wasn't clearer, but I have heard of NX. The part I was wondering
about was how the function representation changed.

------
ngoldbaum
Right now it's hard to do numerical analysis on large problems using Go. To
fix that, I'd be really excited to see bindings for MPI or something like it.
In particular, go doesn't have a concept of an Allreduce or an AllToAll
communication. I know that one can do that by calling the C MPI bindings from
go, but it would be cool if there were a natural way to do it using go's
parallelism and concurrency patterns.

It would also be nice to have a first-class array object - from what I
understand, current support for multidimensional arrays is very C-like in that
you're really dealing with pointer arrays.

~~~
taliesinb
Why not write your own, better, MPI with Go? That's exactly the kind of thing
it is designed for.

I agree about the numerics. I'm tempted to write an very bare-bones
implementation of Mathematica's kernel in Go, but I'll probably wait until
people have done more numerics work in Go.

------
bbrunner
I haven't made the jump to using any of the 1.1 betas or this RC but the
reported 30-40% performance bumps look nice. I'm really still waiting for an
easy way to get gccgo working on os x though.

And I'm glad that they're bumping up the heap size to system-dependent values
on 64bit systems. The fixed heap size of 16 GB was a really unfortunate
constraint (even if it could be changed with a little hacking around).

~~~
4ad
Gccgo doesn't work on OS X (or any other non-ELF) platform, and it's useless
on anything but Linux anyway as segmented stacks are supported only with the
gold linker, which is not ported to non-Linux platforms.

------
ameen
__Go noob here __

Can actual products (Web apps in my case) be built with Go?

~~~
blinkingled
Sure. Go doesn't yet have any mature web frameworks like django for python but
quite a bit of what is needed to build web apps is already part of Golang.
(Packages net/http, html/template etc.)

If I remember correctly Google switched their download service to using Go and
there was a post here not long ago claiming they went from a lot of servers to
merely 2 by switching to Golang.

See <http://golang.org/doc/articles/wiki/> for an example.

~~~
ameen
Is Go really that efficient? I heard similar claims from somewhere else, and
this has been a motivation for me to learn and then build something in Go.

And what might be the reason for that? Speed? Parallel processing?

~~~
blinkingled
While I don't have any first hand experience with Go's performance - it is not
that hard to believe it will be fast enough - it is a compiled language, so no
interpreter / JIT overhead like Ruby / NodeJS. Plus they try to be closer to C
where it makes sense (it has pointers but no pointer math for e.g.).

The synthetic language benchmarks also put it very close to gcc -O2 C
performance. About the only things that need to be improved further (so I've
heard) in Go are the GC, coroutine/thread scheduler and crypto performance.
They are already better in 1.1 release but Crypto is still not close to
OpenSSL performance.

~~~
diakritikal
Crypto performance improvements, briefly benched and blogged by jgc:
[http://blog.jgc.org/2013/04/update-on-go-11-crypto-
performan...](http://blog.jgc.org/2013/04/update-on-go-11-crypto-
performance.html)

------
knodi
What about the 8 remaining issues <http://swtch.com/~rsc/go11.html> will they
be part of the Go 1.1 final?

~~~
JulienSchmidt
gccgo issues: maybe, since gccgo is not included in the Go package

other issues: probably not, since these are new issues that are being worked
on

------
timothya
I guess this website is going to have to change soon:
<http://isgo1point1outyet.com/>

~~~
dubcanada
Why is that a website? I just can't believe someone bought that. And why
didn't he buy

1outyet.com and make a subdomain, so it could be

isgo1.1outyet.com ?

~~~
mseepgood
> Why is that a website? I just can't believe someone bought that.

It was a demo in a talk by @enneff at Railsberry 2013:
<https://github.com/nf/go11>

The site should update automatically once the repository is tagged.

~~~
joshrotenberg
Slides here:

<http://talks.godoc.org/github.com/nf/go11/talk.slide#1>

------
pstuart
Solaris support would be nice...

~~~
rsc
I believe gccgo already works on Solaris.
<http://golang.org/doc/install/gccgo>

