
Go 1.1 is released - enneff
http://blog.golang.org/2013/05/go-11-is-released.html
======
orangethirty
I'm rewriting Nuuton with Go. Before, I was using a combination of Python
(with Django), and Lisp (for the back end processing). After playing around
with Go for a couple of hours, I decided to do a little test. Went ahead and
wrote a simple API that mimicked how Nuuton worked. It turned out to be so
simple and fun to build that I decided to trash all of the old code base and
rewrite it in Go. The performance is great (it runs circles around the
Python/Django code (expected)), but what I like is the syntax, and how easy it
is to work with it. In my mind, its the right mix of C and Python. Its just an
awesome language to work with.

~~~
alatkins
Awesome idea, because as we all know the choice of implementation language is
absolutely crucial to the success of a startup.

~~~
gcr
How much fun the founders have _is_ directly related to the chance of the
startup's success, and a person's ability to learn is directly related to
their personal success.

Sarcasm doesn't belong on HN.

~~~
orangethirty
Well, I was having fun with Python and Lisp. But it was a bit painful between
all of the different parts. Plus on the front end, I was writing mostly
Django. Which has its own set of conventions. I like to keep things simple.
And that made me move to Go. Its simple.

~~~
gcr
Exactly. You switched to Go because it rewarded you. Here you made an
improvement that you liked, and you grew happier. Now, when you sit down to
write, you'll be more likely to think "Wow, here I get to learn another piece
of the Go ecosystem," which will probably drive you to continue working on
your startup.

~~~
TylerE
I think a _huge_ part of go's success is the go command. For those of us
coming from scripting language having the whole "configure/make/install"
problem solved (and solved _well_ ) by the core language greatly lowers the
barrier to entry.

~~~
orangethirty
Go acts like a scripting language, but runs like a compiled one. That's why I
love it. The right mix of C and Python.

~~~
gcr
That trait is shared by lots of languages though. Racket and some other lisps
do exactly that. So does PyPy.

~~~
TylerE
The difference is it's a true compilation. Most lisps will save like a data
image that still needs to launch the runtime.

------
genwin
In February I deployed a website written in Go. It's been running 24/7 since
then, pulling from thousands of data sources every ten minutes, no problems,
no memory leaks. The thing is so fast on my cheap server (4 ms turnaround)
that the only thing I would've done differently is to use a cheaper server.

~~~
sergiotapia
Does Go have a defacto web framework?

~~~
elithrar
> Does Go have a defacto web framework?

There's a few, but I think it's still too early to really call out a "defacto"
framework.

Revel, as mentioned, is a popular "full stack" framework, but it can be pretty
heavy. web.go[1] gets a lot of use (it sits at a Flask/Sinatra level), and
beego[5] looks good but it's also totally acceptable to plug a few libraries
together without much work on top.

For example, I'm using:

\- mux, sessions, schema & context from Gorilla[2]

\- go.auth for social sign-in [3]

\- the RethinkDB driver [4]

... and that's about it. Write your routes with mux, set up your handlers with
auth/sessions/schema, and generate your models & queries with whatever DB you
want. The standard html/template library is good enough (and there's a
Mustache library if you need it), and the standard http library covers
everything in between.

TL;DR: If you enjoy writing Flask/Sinatra apps, you'll enjoy writing Go web
apps. If you're coming from a full-stack framework (like me), there is
definitely a learning curve, but I feel that Go's documentation and std. lib
flatten that out a little.

[1]: <https://github.com/hoisie/web>

[2]: <http://www.gorillatoolkit.org/>

[3]: <https://github.com/bradrydzewski/go.auth>

[4]: <https://github.com/christopherhesse/rethinkgo>

[5]: <https://github.com/astaxie/beego>

~~~
russellbeattie
When you said Revel is "heavy" - did you mean slow, uses lots of
memory/CPU/other or just has lots of custom bits to learn/use?

~~~
elithrar
> When you said Revel is "heavy" [...]

It provides nearly everything, likely including things you don't even need.
It's likely that a lot of the parts included won't be needed by a "typical"
web application, and if you want to do things another way you'll need to spend
some time switching those components out. To be fair though, having
"everything" can be a big plus, especially when you don't know what you might
need (or have the time to glue things together).

I don't know how tightly coupled the components are in Revel, but if it's like
Django, some things are easy to add/remove (middleware), and others are much
harder to work around (ORM, views, etc.).

------
jgrahamc
No generics. Less speed than C. Lame.

~~~
jgrahamc
Seriously, congratulations to the Go team.

And for those who missed my attempt at humor:
[http://slashdot.org/story/01/10/23/1816257/apple-releases-
ip...](http://slashdot.org/story/01/10/23/1816257/apple-releases-ipod)

~~~
fixxer
"Damn the torpedos and downvotes, I'm gonna make this joke _work_!"

You, sir, are a risk taker. Kudos.

------
todd3834
"It is likely that your Go code will run noticeably faster when built with Go
1.1" I have been extremely impressed with Go's performance and now it is even
faster! :-)

~~~
xxchan
Really? I always found it somewhat lacking in this. It has the potential to be
so so much faster. Glad to see they're finally working on it.

~~~
burntsushi
In terms of speed, Go 1.1 is nearly on par with Java. [1]*

[1] -
[http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...](http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=java&data=u64q)

* - To the extent that you may find micro-benchmarks a useful measuring stick.

~~~
igouy
*"Toy programs" as-in -- [http://books.google.com/books?id=gQ-fSqbLfFoC&lpg=PP1...](http://books.google.com/books?id=gQ-fSqbLfFoC&lpg=PP1&dq=Computer%20Architecture&pg=PA37#v=onepage&q=toy%20benchmark&f=false)

------
azinman2
As a no-go programmer looking through the data race detector docs
(<http://golang.org/doc/articles/race_detector.html>), it to me shows snippets
of a really ugly language with poor readability. Examples from Google's page:

    
    
      var service map[string]net.Addr
    

When I read this it's easy to skip seeing string, aside from the fact that ]
as a delimiter also looks like net.Addr was accidentally combined with the
previous line.

    
    
      func ParallelWrite(data []byte) chan error {
    	res := make(chan error, 2)
    	f1, err := os.Create("file1")
    	if err != nil {
    		res <- err
    	} else {
    

Here we see no parenthesizes used in if statements, yet we retain {. In
skimming it's easy to miss the if in the first place. Yet everywhere else
they're happy to use parenthesizes. We also see that "make" is lowercase yet a
method, but os.Create and ParallelWrite has caps for a method.

There's also the fact that the array (I'm guessing) of bytes diverges from
every other language to put them in front of the type which looks like crap.
We see the same poor choices of delimiters as with map value types.

Then there's this

    
    
      func main() {
    	c := make(chan bool)
    	m := make(map[string]string)
    	go func() {
    		m["1"] = "a" // First conflicting access.
    		c <- true
    	}()
    	m["2"] = "b" // Second conflicting access.
    	<-c
    	for k, v := range m {
    		fmt.Println(k, v)
    	}
      }
    

<-c looks like its just dangling, and if this is meant to say there's some
kind of stream or assignment then does it just go to /dev/null? Yet "c <\-
true" is also correct? I'd argue for either void <\- c, _ <\- c, or c.read()
if wanted to support something like that.

It's also difficult to tell in the for loop if v is being assigned as "range
m", or if "k, v" are a tuple resulting from "range m"

It's too bad because the goals of the language are quite nice from a CS
perspective.

~~~
enneff
Did you seriously just post "As someone who doesn't know how to read this
language, this language seems really unreadable!" ??

As any Go programmer will tell you, Go is a very readable language. It's one
of the design goals. It is _not_ a design goal to impress people making
superficial judgements.

Also, LOL: <https://news.ycombinator.com/item?id=5327478>

~~~
azinman2
I'm hoping you're lol'ing with me and not at me, because that's a comment on
the parody of HN, which is obviously a parody comment itself.

Yes I did just post that. Should I wait until there's an article on coding
aesthetics first? I'm a seasoned programmer with experience in many languages.
Reading a new language should make me want to use it because it's an
improvement in many ways, particularly around expressivity and clarity. IMHO
Go isn't as good as it could be. I wasn't saying Go as a whole is bad or not
worthwhile.

~~~
enneff
Yes, it's obviously a parody comment, but here you are perpetrating the meme
for real. Don't you see the irony?

Like I said, Go isn't designed to impress superficially. It's a pragmatic
language for getting work done.

~~~
azinman2
I never said Go was bad. I just said it was ugly and gave examples. Those code
samples came from the race condition page detector which I wanted to learn
about, because that's awesome.

If a programming experience was designed to impress superficially, then it
wouldn't live in a pure text editor at all. I'm commenting on aesthetics as it
also relates to usability (readability). I don't get this mindset that things
that functionally work well have to be ugly. It's a very unix/engineering
mentality that just isn't true. You CAN have both.

------
sergiotapia
Programmer for 8 years, in a wide variaty of languages but never touched a
language that had pointers.

How much do I need to know about pointers to use and learn Go? Is Go garbage
collected in the C#/Ruby sense?

I recently switched from full ORM usage to hand tuned SQL queries and loved
watching the speed of my application increase 10-fold. I'm having a bit of a
speed high and Go seems like the perfect language for this.

What book should I buy to learn Go from the ground up?

Edit:This seems like the perfect place to start.

<http://www.golang-book.com/>

~~~
coldtea
> _How much do I need to know about pointers to use and learn Go?_

Very little. Just what pass by value and pass by reference mean in the context
of pointers.

The very basic you need to know is: if a function argument is defined as
(*foo), you are changing the item you pass to the function (like in Javascript
or Java), whereas if it's defined as (foo), you're changing a copy of it and
the original item remains unaffected.

Go has pointers, but no pointer arithmetic (in the base language), and it also
has GC, so most of the problems people have with pointers in C are not there.

~~~
sergiotapia
>The very basic you need to know is: if a function argument is defined as
(*foo), you are changing the item you pass to the function (like in Javascript
or Java), whereas if it's defined as (foo), you're changing a copy of it and
the original item remains unaffected.

=============================

So it's like PHP where I need to pass in `function modify(&$foo) {` to modify
a variable passed by reference.

~~~
chrisguitarguy
> So it's like PHP where I need to pass in `function modify(&$foo) {` to
> modify a variable passed by reference.

If you're thinking in terms of PHP's primitive types, then yes: that's
probably the best equivalent. PHP has the whole objects always being "passed
by reference" [0] thing going on too.

0\. <http://php.net/manual/en/language.oop5.references.php>

------
minamea
Any plans to add templates/a form of generic programming? Does the community
care about that? How have people been working around that?

And congrats!

EDIT: Yes I know what the faq says [1]. I was wondering if someone working on
that can shed light on how the development of a satisfactory proposal has been
going. Also, what's exactly wrong with template instantion like in C++ from
the perspective of Go devs?

[1] <http://golang.org/doc/faq#generics>

~~~
jff
It gets brought up continually on the mailing list.

The Go authors have repeatedly stated that they will not be implementing
generics.

They don't seem to miss them, I don't miss them, and indeed most people who
write much Go don't seem to miss them. The people who continually whine about
generics seem to be the type who say, "Oh boy, I'd sure LOVE to write a bunch
of kickass code in Go, but I just couldn't do ANYTHING without generics! Why
don't you put them in, then I'll try the tutorial"

It's not something we feel the need to work around, we just sit down and write
concise programs that do the job, in fewer lines than C++.

Edit: as others have mentioned, it seems the authors would be willing to put
them in if they find a way to do it without crapping up the language. If they
do, I'll try writing Go code with generics, but they have a bad taste for me
after dealing with code containing GenericType.cpp, GenericType.hpp,
AbstractType.cpp, AbstractType.hpp, AbstractGenericType.cpp, and
AbstractGenericType.hpp all in one place.

~~~
minamea
This is a bad attitude, imo. The Go standard library wouldn't be possible
without generics [1]. It's just that the functionality exposed to the standard
library isn't exposed otherwise.

If it's a feature _needed_ for the standard library, then it's safe to say the
devs will need it to. The devs aren't (shouldn't) be consistently writing
programs that are more trivial than the standard library.

[1] <http://golang.org/doc/effective_go.html#append>

~~~
encoderer
Not sure I agree with this logic.

I could easily write a custom Append func in my own application because I
would know the Slice types I'm trying to operate on. Writing a language
feature is different than writing an application, and it has nothing to do
with how trivial something is.

Honestly, Append() as a concept is about as trivial as it gets..

~~~
gnuvince
> I could easily write a custom Append func in my own application because I
> would know the Slice types I'm trying to operate on.

More precisely, you would write one custom Append function per Slice type.
AppendString, AppendInt, AppendWhatever.

~~~
encoderer
Yeah, that was supposed to be singular: because I would know the Slice type
I'm trying to operate on. Appreciate the clarification. I'll leave the typo
there for context.

------
melling
One of the features of Go is suppose to be compilation speed. Can anyone
compare to C, for example, or discuss compilation speed in large projects
(e.g. >100k loc)?

~~~
tptacek
The Go compiler is so fast you can use it the way you would a scripting
interpreter ("go run whatever.go"); it builds the whole standard library in
seconds. Every program I've written in it (topping out at around 20kloc)
compiles instantaneously --- I can't perceive the amount of time it takes to
compile.

C compilers are fast, but they aren't that fast. Go compiles so fast that it
changes the way you write and organize code; you would never consider
compilation overhead in any decision you made in a Go source tree, where you
might do that in a C codebase. For instance, Go programmers routinely compile
code, run it, and throw away the compiled binary! You wouldn't think it would
be possible for compiler speed to be so much better than C that it would make
a difference, but Go's compiler manages it.

~~~
georgemcbay
"You wouldn't think it would be possible for compiler speed to be so much
better than C that it would make a difference"

I would think that, even before I had used Go. Ignoring the smaller scanning
benefits of Go that come about from the more rigid syntax for braces and such,
the C preprocessor system introduces a complete nightmare when it comes to
requiring multiple passes over the same code, especially for code that is
naive about include guards, pre-compiled headers and other "best practices".

C (and C++ is even worse) has a lot of very large low hanging fruit to cull
when it comes to writing languages with faster compilers. Whatever speed C
compilers have now is due to the geniuses who wrote the compilers and decades
of shoulders to stand on, the language is actively working against them at
nearly every turn when it comes to compilation speed.

That aside, I agree. Go compiles very, very fast. So fast that it never
occurred to me that "go get" did a compilation until it was pointed out to me
that it did.

~~~
haberman
> C (and C++ is even worse) has a lot of very large low hanging fruit to cull
> when it comes to writing languages with faster compilers.

I look forward to seeing the speed boost that C and C++ get if/when modules
are available: <http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf>

~~~
pjmlp
Me too. Not sure if they make it to C++14 though. :(

~~~
pcwalton
They're delayed to C++17. C++14 is an incremental release only.

~~~
pjmlp
Yes. Actually I wonder if they will make it to C++17 even, but I keep looking
forward to it.

------
timothya
This website now reflects it too: <http://isgo1point1outyet.com/>

(For those that don't know, this website was created for a talk about Go given
by Andrew Gerrand. Code: <https://github.com/nf/go11> , slides:
<http://talks.godoc.org/github.com/nf/go11/talk.slide#17>)

------
bjacokes
Our web hosting service at Parse (launched last week) is built entirely in Go.
It happens to live in a sweet spot for the language: we need to query Memcache
and/or Mongo to figure out exactly how to route a request but don't want to
block the thread, which is dead simple in Go. I've personally had a great time
using the language, and I am hoping to write up a blog post on our experience
within the next week.

------
klobucar
Just waiting on the PR to go through for Homebrew to pick-up go 1.1 :)

<https://github.com/mxcl/homebrew/pull/19782>

------
kibwen
Does Go have a roadmap of development work for future releases? One thing that
I've been very curious about is if the Go devs will be able to resist the
tendency of every other language (save perhaps Lua) to linearly increase in
complexity over time.

~~~
enneff
We are most certainly concerned with language complexity. We will only add
features that mesh well with the Go we know and love, not just for the sake of
utility (every feature is at least useful).

~~~
kibwen
That's good to hear, but it still raises the question of what you're spending
your time on. :) I imagine that all the low-hanging GC-related fruit has been
plucked for 1.1, so what are users clamoring for now? Without a maximalist
attitude, do you foresee a point where the language is declared as "done" and
all the full-time devs just pack up and move on?

~~~
howeman
At this point there are something like 600 open issues, so I think that will
be a while.

------
mcot2
Go is awesome! The best feature of 1.1 is very large heaps on Linux x64. I was
bumping into the limits before but the 1.1 rc has been rock solid so far.

------
pjmlp
Congratulations to everyone involved for their work.

~~~
shurcooL
And thank you so much! As of lately, Go is the leading source of my happiness
in my dev life.

------
cobrabyte
Fantastic! Thanks to the Golang team for getting this out the door!

I'm surprised by the speed of the dev team. It seems that just a few days ago
that we saw the latest RC and just a few days before then was the previous RC.
Fast development!

~~~
enneff
We would have preferred to have hit RC a bit earlier and left more time
between candidates, but we had such a lengthy beta period that we felt it was
okay to crank out a few RCs to iron out the last issues and release. I hope
the next release cycle will be shorter, and the candidates will come out
earlier (and be a lot rougher).

------
venuzr
What is the recommended way to go about debugging a Go program? Is there
something better than GDB if I want to look at the call stack, have
breakpoints, look at the state of variables etc.

Using GDB seems akin to working with assembly

~~~
jussij
There're a few Go IDEs that integrate GDB into the IDE.

[http://geekmonkey.org/articles/20-comparison-of-ides-for-
goo...](http://geekmonkey.org/articles/20-comparison-of-ides-for-google-go)

I'm the author of one of them (Zeus) and while the results are not as slick as
the _Visual Studio_ debugger it's a better than straight out GDB.

------
oakaz
What is the NPM equivalent in the Go world?

I wanna give Go a start but can't see any community website that lists Go
libraries like NPM.

EDIT: I'm not asking for "npm install person/project", I'm asking for a
community website and a file like package.json that records information about
a project.

As I observe, Go projects are really messy. I saw some code importing
dependencies like "import github.com/foo/bar".

I think Go should focus on declarative programming and its aesthetics culture.

~~~
burntsushi
> As I observe, Go projects are really messy. I saw some code importing code
> like "import github.com/foo/bar".

That's not messy; that's idiomatic Go. By convention, package imports can be
URLs to version control repositories, which the `go` tool uses to determine
dependencies and install them automatically.

Go has no equivalent `package.json` file. All package information is inferred
from the source code.

The closest thing to a central repository is on the Go wiki. [1] Many people
also use godoc.org [2], which is searchable.

[1] - <https://code.google.com/p/go-wiki/wiki/Projects>

[2] - <http://godoc.org/-/index>

~~~
evincarofautumn
> That’s not messy; that’s idiomatic Go.

The two aren’t mutually exclusive. If that URL goes down, is there a fallback
mechanism?

For what it’s worth, I agree with oakaz’s sentiment that Go is “very
imperative” and “not simple”. It is deliberately designed that way, with lots
of syntax and types for representing (abstractly) the inherent complexities of
its intended domain. Any ugliness, however, is purely subjective.

~~~
burntsushi
> The two aren’t mutually exclusive.

The OP (of this thread) said, 'I saw some code importing dependencies like
"import github.com/foo/bar."' I did not understand this as a criticism of the
design choice of using URLs as imports, but rather, a statement about _some_
Go projects doing something horrendously wrong.

Yes, one can think URLs as imports is both messy and idiomatic, but I do not
feel that was central point of the OP. I suspect we will never get a
clarification, though.

> If that URL goes down, is there a fallback mechanism?

I don't know what you mean. If the package is no longer available at the URL
then it cannot be downloaded from that URL.

> For what it’s worth, I agree with oakaz’s sentiment that Go is “very
> imperative” and “not simple”. It is deliberately designed that way, with
> lots of syntax and types for representing (abstractly) the inherent
> complexities of its intended domain.

Go was not deliberately designed to be "not simple." In fact, it was
deliberately designed _to be simple_. Simplicity's name is invoked again and
again as a justification for including or not including changes to the
language.

------
mamcx
The ARM branch mean is possible to do iOS dev on it?

~~~
elithrar
> The ARM branch mean is possible to do iOS dev on it?

No. You can compile for ARM + a platform (i.e. Linux, BSD) if you want to run
Go code on an ARM device. Think RaspberryPi or Beaglebone running an ARM port
of Ubuntu/Arch.

Writing Go code targeting iOS (or Android) is a whole 'nother ballgame.

~~~
4ad
Android is just Linux, Go works perfectly fine on it. Go issues syscalls
directly and doesn't use libc for that (it uses glibc for name resolution, but
with cgo disabled it doesn't do even that).

Minux did an iOS port, it's not part of the official tree because an iOS port
required a rooted device. Perhaps this might have changed as with two word
funcs, the Go runtime doesn't do runtime code generation.

------
rcoh
I'm especially excited about the race detector. It looks like a practical
implementation of <http://cseweb.ucsd.edu/~savage/papers/Sosp97.pdf>. Always
exciting to see research coming up in practice!

------
iLikeCookies
Hey guys! I was inspired by all these rave responses. And decided to download
and try. When I came to downloads page I saw only about 1000 downloads
(uploaded 38 hours ago). And all my inspiration has disappeared.

It would be interesting to compare number of downloads for Python/Ruby.

------
kamaal
Go doesn't have exception handling.

How practical is it to use such a language for large code bases?

~~~
icebraining
Practical is subjective, but there are a lot of large, successful projects
written in C, so it's definitively feasible.

~~~
kamaal
Of course if you say 'you have to live with it' then you really have to 'live
with it'. After some time, you no longer complain about it.

But this is 2013, there are somethings that expected to come from a language
default. Exceptions are one of them, few such things I can think of are things
like regular expressions, closures etc.

~~~
seabrookmx
Exceptions are extremely controversial in programming language circles. They
reduce encapsulation, and the try/catch syntax as seen in java encourages bad
error handling. Any idiot can put their whole program in a giant try/catch
block.

It's really a hard design problem. I agree that some form of error handling
should be a language default, but I'm not sure if "traditional" exceptions
should be it. As a C++ dev who has worked on projects with and without
exceptions, I can say there is pros and cons to both.

~~~
lucian1900
It's not that hard, basically a solved problem in Common Lisp and more
recently Rust: use conditions. They only unwind (not re-wind), so there's no
worry about exception safety (as in C++) and they allow strictly more power
than exceptions.

------
stcredzero
It seems a shame that more hasn't been done with Go and games. The concurrency
facilities seem particularly fantastic for this.

~~~
iand
There is quite a lot of gamedev activity in Go and quite a few bindings to GL,
SDL and the like. I've written a (bad) game in it and am currently working on
a better one. I know of at least one commercial game being written in it.
There are lots of emulators written in go for some reason too.

I'm finding the multiplayer aspects of my current game to be an excellent fit
for Go, making good use of concurrency and networking.

------
ehmuidifici
Congratulations, keep up the good work!

