Go 1.1 is released

http://blog.golang.org/2013/05/go-11-is-released.html

by enneff • 13 years ago

484 290 13 years ago

blog.golang.org

todd3834• 13 years ago

"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! :-)

atarighat• 13 years ago

Go is awesome!

xxchan• 13 years ago

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.

burntsushi11• 13 years ago

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

[1] http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

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

pjmlp7• 13 years ago

Congratulations to everyone involved for their work.

shurcooL3• 13 years ago

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

minamea3• 13 years ago

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

cjh_• 13 years ago

http://golang.org/doc/faq#generics

voidlogic13• 13 years ago

>>Any plans to add templates/a form of generic programming?

The Go team is open to generics as soon as there is a proposal they feel fits right without performance penalties. Read: http://golang.org/doc/faq#generics

>>Does the community care about that?

Yes, but most people in the Go community are OK waiting for the "right" solution.

>>How have people been working around that?

Generics are nice and convenient, but you can write anything/everything without generics. Just look at everything written in C. And C doesn't have interfaces like Go.

coldtea11• 13 years ago

>The Go team is open to generics as soon as there is a proposal they feel fits right without performance penalties.

Because using interface{} for the same tasks fits so much better and has so much better performance right?

Tons of languages have implemented Generics -- it's not rocket science since at least 2 decades.

If the Go team is not interesting in working on the thing, then I doubt they would be really evaluating any "proposal".

jff2• 13 years ago

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.

enneff9• 13 years ago

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

That's not true. We just don't have a way of doing them that works well in the language. http://golang.org/doc/faq#generics

voidlogic13• 13 years ago

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

Not so http://golang.org/doc/faq#generics; "This remains an open issue." In the discussions I have read, if an implementation of generics is proposed that doesn't sacrifice performance and it truly generic, they are open to it.

What I have seen said is that implementing generics was not on the table for 1.1 or maybe even 1.x

minamea3• 13 years ago

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

_ak4• 13 years ago

Russ Cox wrote down in 2009 what's the dilemma about generics: http://research.swtch.com/generic I think this is a very valuable article to understand why the Go team hesitates to implement generics in some suboptimal form.

coldtea11• 13 years ago

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

No, they have repeatedly made ho-hum excuses about how they can't think of any proper way of implementing them, and that they will do them if they find a "clean way".

>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!"

Well, isn't this dismissal of them a kind of "confirmation bias"?

Sure, they people who don't care about generics can churn out tons of code without them. Like people have been churning out tons of code in C or pre-generics Java anyway. And, sure, they might not even miss them.

Plus, some of the core Go members have been using languages without generic for decades and even created some. So, being used to working like that, it makes sense for them not to miss them.

That doesn't mean the people who DO want them are wrong in wanting them in -- or that because guys writing C for several decades doesn't find a need for generics in Go, means that there really isn't one.

stonemetal2• 13 years ago

I haven't looked at go beyond doing the tutorial, so what follows isn't a learned opinion. The interface system in Go covers most of what you would do with generics, if you use interfaces your code is generic. The only friction over a generics implementation is the way you wire up types to interfaces.

minamea3• 13 years ago

Someone correct me if I'm wrong, but I think that's true only if you use methods and not operators, because Go doesn't support operator overloading.

jgrahamc5• 13 years ago

No generics. Less speed than C. Lame.

jgrahamc5• 13 years ago

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

fixxer• 13 years ago

"Damn the torpedos and downvotes, I'm gonna make this joke work!"

You, sir, are a risk taker. Kudos.

voidlogic13• 13 years ago

Yeah, who needs type and memory safety, a large standard library, OO via interfaces, structural typing, garbage collection, functions as first class citizens, closures, blisteringly fast build times or easy concurrency.....

enneff9• 13 years ago

It's a reference to CmdrTaco's impressively off-base assessment of the first iPod: http://slashdot.org/story/01/10/23/1816257/apple-releases-ip...

pjmlp7• 13 years ago

I do complain a lot about Go's design in HN, but today is a reason to celebrate, not to bash the authors.

jlgreco6• 13 years ago

His comment is a reference to the infamous CmdrTaco comment on the newly-released iPod. "No wireless. Less space than a nomad. Lame."

I assume he is jokingly suggesting that the detractors are wrong.

samplonius• 13 years ago

Chet and Erik's download Go 1.1:

Chet: "Get out the drool cup!" Erik: "In use, my friend! Drooool!" Chet: "Then break out the scraper, because someone's gonna have to scrape my jaw off the floor!" Erik: "That's also in use, to scrape my spooge off the monitor! Spoooge!" Chet: "Ouch! Fetch me my eye medicine, because I have an eyeache from watching a whole mixed bag of eye candy!" Erik: "All of the eye medicine's already in my eye! I'm done with the scraper, though."

timothya• 13 years ago

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)

melling• 13 years ago

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)?

enneff9• 13 years ago

The Juju guys at Canonical said at GoSF that their >100k LoC project compiles in 6 seconds.

azinman210• 13 years ago

Much better than SBT compiling my Scala project (20k? LoC) in 75 seconds (!) on my latest MBP. And that was not from scratch, but having changed about 10 lines of code.

tptacek3• 13 years ago

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.

StavrosK3• 13 years ago

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

Okay, Go is fast, but it's not that fast. My 1000 LoC program takes ~1 second to compile. While it's certainly fast enough for me, it's not imperceptible.

recuter• 13 years ago

Which is the entire raison d'être for the Go project and thus it can be dubbed a success. Any other advantages over C are just gravy. :)

A nicer, more accessible (python/ruby/etc folks seem to like it a lot), faster compiling reasonable alternative to C is a worthy goal - I really don't get why some people get into flamewars over it.

georgemcbay3• 13 years ago

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

__david__2• 13 years ago

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

I did some ocaml work a few years ago and had a similar revelation. Its compiler is just as fast—my short little programs were more or less instantaneously compiled. Fast compiling is really, really nice, even though it seems like a silly thing to tout.

vidarh9• 13 years ago

C compilers are largely slow because they are written with the expectations of a lot of optimization and large projects rather than with much concern for compile times.

C compilers that are written to be fast rather than flexible can be extremely fast. E.g. see Fabrice Bellards "TCCBOOT", that he demonstrated compiling the Linux kernel at boot-time in 15 seconds on a 2.4GHz Pentium 4: http://bellard.org/tcc/tccboot_readme.html

TCC can also be treated much like an interpreter like your go example.

justin663• 13 years ago

If your memory goes back this far: it's Turbo Pascal fast. :)

snaky4• 13 years ago

Turbo Pascal was so fast mostly because of not compiler but linker and .tpu files format.

edit: s/tpl/tpu/

btw, the tp linker - http://turbopascal.org/linking-modules-and-creating-exe-file

pacala• 13 years ago

Haha, you've just sold me. I'm switching to Go for my next project :)

icelancer• 13 years ago

I've been reading this thread trying to find a reason to switch to Go. Then I read this comment and it brought back some very good memories (TP was my first language after command-line BASIC on the Apple IIe and TRS-80). Sigh. Looks like I have a new weekend project!

jgrahamc5• 13 years ago

The main Go program I work on is CloudFlare's Railgun which is 18,000 lines of code. It builds in 4s.

   % make clean
   % time make make-listener make-sender make-diag make-ssl...
   3.42s user
   1.05s system
   105% cpu
   4.240 total
   % find src/ -name '*.go' | xargs wc -l | tail -1
   17870 total

And that's building everything sequentially. If I switch to using -j4 I get a 2s build from clean.

   % make clean
   % time make -j4 make-listener make-sender make-diag make-ssl...
   5.75s user
   1.99s system
   382% cpu
   2.020 total

An incremental build (no op) of the entire tree is one second:

   % time make -j4 make-listener make-sender make-diag make-ssl...
   1.56s user
   0.73s system
   209% cpu
   1.090 total

Yes, we wrap the go build tools with make. Not because they are lacking anything for Go but because we do other stuff (like build documentation and release packages).

(I should have not counted the tests in the above analysis. There are 7,290 lines of tests and 10,580 lines of code).

stock_toaster• 13 years ago

  > Yes, we wrap the go build tools with make.

Do you wrap `go build` or do you wrap the 6g/6l tools directly?

agentS3• 13 years ago

I assume you're calling the go command a few times in parallel, hence the improvement with -j4. I wonder if it would be faster to aggregate all the packages you need to build in a variable, and call the go command with all of them.

i.e. instead of issuing "go build foo/mylib" and "go build bar/myotherlib" in parallel, just issuing "go build foo/mylib bar/myotherlib".

I say this because I remember there being logic inside the go command to parallelize builds already, see the "-p" flag in "go help build". In particular, the go command will be able to avoid statting all the files, comparing mod times twice, recomputing the DAG, etc. Although, considering how fast it runs anyway, this speedup might be negligible...

buro9• 13 years ago

We have similar times being reported on a codebase of 17,482 lines of code.

    : time go build -a

    real	0m3.980s
    user	0m5.012s
    sys	0m1.140s

But that is unrealistic, in dev we skip the -a flag:

    : time go build

    real	0m1.854s
    user	0m1.760s
    sys	0m0.332s

vidarh9• 13 years ago

Given the way people are praising Go for compilation speed here I'm surprised at your numbers, which does not seem to support the claim it's all that fast, unless your build machine is antiquated...

My home server is an AMD FX-4100 (quad core, 3GHz; this is one of the early Bulldozer CPU's and definitively not a speed daemon - I picked up the CPU and motherboard for <$150 a year or two ago).

I just tested a 6k C program that compiled in 1s flat with gcc 4.7.2, or .44 seconds with -j4, and a 13k lines one that completed in 2 seconds, or .88 with -j4.

Gcc isn't exactly renowned for being a fast c compiler.

A "no op" build of the 13k project takes .004 seconds, though, perhaps that's the reason - if your make setup is horrendously complicated perhaps it's slowing your numbers down a lot. And it's certainly possible to make C compilation incredibly slow if you do lots of nasty pre-processor hacks.

But then again whether 6k, 13k or 18k lines, both your project and mine are tiny.

ehmuidifici• 13 years ago

Congratulations, keep up the good work!

oakaz8• 13 years ago

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.

melvinmt• 13 years ago

go get/install <package-url>?

http://golang.org/cmd/go/#hdr-Download_and_install_packages_...

oakaz8• 13 years ago

It's the equivalent of npm install <package-url> command, not the NPM.

mvzink2• 13 years ago

    $ go get github.com/person/project

It will even figure out dependencies by checking every import (and you can do 'import "github.com/person/project"' too), and builds the source by default.

And yes, "go get" comes with the standard gotools.

oakaz8• 13 years ago

As I said in my previous comment, it's just the equivalent of `npm install person/project` not NPM.

Edit: WTF? why this comment is down-voted now?

exch• 13 years ago

To get a good overview of third party libraries 'out there', you can browse the index at http://godoc.org/-/index

These are by no means all the 3rd party stuff out there, but it's a good starting point.

Incidentally, this website is intended to automatically generate and serve the documentation for all those projects in a centralized place. You don't even have to submit your projects. Just type the import path in the search box, and the site fetches the code by itself.

Edit: And here's anther community-built site to do continuous integration testing for your projects. It too, has an index of registered projects: http://goci.me/

oakaz8• 13 years ago

No offense but that page is horrible. I liked the project pages though.

I think Go needs to focus on improving its community and its aesthetic culture.

mmgutz2• 13 years ago

`go get` but it's not anywhere as featured as npm. Forget about versions or using yours or anybody else's fork of a project without editing code or using symlinks. "github.com/your_fork/somelib" is not a replacement for "github.com/foo/somelib". For those that don't use node, using a fork or a specific commit in node is a simple version change in package.json.

oakaz8• 13 years ago

who is talking about forks or versions here?

try this in your command-line: npm install name/project

encoderer5• 13 years ago

I see what you're saying in your replies down-thread from this, but honestly the fact that there's not a directory of packages has never been an issue for me. I google when I go looking for a package, then "go get" it.

oakaz8• 13 years ago

Is this the most productive way of coding?

burntsushi11• 13 years ago

> 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

oakaz8• 13 years ago

> That's not messy; that's idiomatic Go

Haha.

Everybody understands Go has a tool that deals with dependencies for you. And any other language can have it.

And this is why I avoid monopolistic platforms even though they are fast. If the owner of your platform has no taste of aesthetics, you'll write fast and ugly looking code. which is not fun for me.

As PG says in his book, a good solution should also look good and simple.

Go is very imperative, ugly looking, and not simple.

> http://godoc.org/-/index

This link is actually a self-answer by you.

evincarofautumn• 13 years ago

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

drivebyacct24• 13 years ago

What on Earth are you talking about? Go's dependency system tied to SCM is awesome.

teraflop2• 13 years ago

It has a crucial limitation compared to "real" dependency managers like Ivy, Maven, NPM, Leiningen, pip, et al.: you can't declare a dependency on a particular version of a module, only on the trunk. So you have to either maintain local mirrors of every single module, or just give up on reproducible builds and accept that upstream might introduce a bug or a breaking change at any time.

The Go developers are aware of this limitation, and their typical recommendation on the mailing list is that you should never need to use anything other than the latest version of any third-party library, e.g.: https://groups.google.com/d/topic/golang-nuts/3gEseiCwdf0/di...

cobrabyte• 13 years ago

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!

enneff9• 13 years ago

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

genwin4• 13 years ago

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.

sergiotapia3• 13 years ago

Does Go have a defacto web framework?

voidlogic13• 13 years ago

Many of the people in the Go community are anti-framework and pro-library. (inversion of control; a library is provided code called by your code, versus a Framework provided code that calls your code).

That being said, right now the dominate Go web library is "net/http" from the Go standard library, supplemented by Gorilla (as needed): http://www.gorillatoolkit.org/

If what you are looking for is really a Go web framework however, there are a few in development including Revel: http://robfig.github.io/revel/

lelandbatey• 13 years ago

I would love to know about this as well. Basically a basic rundown of how Go works in relation to running various web facing stuff (a simple API for example).

speg• 13 years ago

I've seen Gorilla (http://www.gorillatoolkit.org/) used quite a bit. The standard library is also good enough for small and quick things.

elithrar4• 13 years ago

> 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

nteon• 13 years ago

I've written a small production web project and several medium-sized personal projects in Go, and have not yet found a need for a web framework outside of net/http. I've used several libraries that work as nested/stacked handlers under net/http; Go's structure embedding is a natural fit for that.

swah3• 13 years ago

Do you have a database?

genwin4• 13 years ago

Yes, SQLite. Users are served solely from memory.

orangethirty9• 13 years ago

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.

jervisfm• 13 years ago

What is your Nuuton project about ?

orangethirty9• 13 years ago

A search engine. From what I know, its the only engine using Go (aside from Google.) Blekko uses Perl, DDG uses python (I think), Bing uses unicorn blood, and all the smallr ones use Jva and/or C++.

alatkins• 13 years ago

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

gcr3• 13 years ago

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.

orangethirty9• 13 years ago

I thought about COBOL, but then I realized I did not work at a bank.

aaronbrethorst• 13 years ago

If the stories are to be believed, the only reason we're having this conversation on this particular message board is because they actually do at times.

http://www.paulgraham.com/avg.html

pbreit• 13 years ago

It's definitely important. Not only can the language contribute to better development (however you want to define "better"), Go, in particular is attractive to engineers you might really want to hire.

electrichead• 13 years ago

I must say I like the name. What differentiates your search engine from the others?

orangethirty9• 13 years ago

I am building it for us. Rather than to hype it up and cash in. It is truly a search engine aimed at hackers. In terms of features, you will learn as it goes through the BETA. Keep posted at the blog nuuton.com/blog.

swah3• 13 years ago

I tried to use it but felt it was so slow to write your ideas that programming got boring (no advanced loops/generators, no list comprehensions, lambda functions aren't used very much IIRC). I'd probably stick with Python unless performance matters.

But OTOH it really "just works" out of the box.

nine_k2• 13 years ago

It's a bit strange to complain about lack of use for "lambda functions" in a language where there's a keyword that generally accepts a function reference, most often a function literal? (This keyword coincidentally is the language name lower-cased.)

WRT generators: have you tried using channels? "The tour of Go" seems to instill you with the idea that you should not iterate over lists and use channels instead.

I also miss list comprehensions and, for that matter, type-parametrized functions.

OTOH, static duck typing is brilliant: best of both worlds.

MetaCosm2• 13 years ago

It is "boring" -- absolutely. It is almost insanely so at times (even when solving complex problems). The number of times you get to feel insanely clever is very low.

But, that output / work product is -- and a huge part of Go's value is around the EDGES of a system (build, standard formatting, deploys, etc)

reeses• 13 years ago

If you're missing lambdas based on Python's neutered implementation, you're not really missing anything with go.

sergiotapia3• 13 years ago

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/

voidlogic13• 13 years ago

>>How much do I need to know about pointers to use and learn Go?

Do you understand how they work in C? Maybe try reading a little about that. For Go, I'd recommend starting here: http://tour.golang.org/#1 (Don't miss the next arrow in the lower right-)

After running through that you should have an idea of what you don't know- which makes asking questions people can provide useful answers to much easier. :)

>>Is Go garbage collected in the C#/Ruby sense?

I'm not sure what your sense of C#/Ruby GC is, but I'd go with yes.

city41• 13 years ago

Pointers are not difficult. Take what you know about references as a starting point and go from there. In many cases, references and pointers behave very similar. When you get into the more interesting things that are possible with pointers, just remember they are merely a value that holds a memory address. If you keep that in mind, the complexity is muted a lot. Just dig into Go and see what you find.

genwin4• 13 years ago

I concur with this approach. My former languages do not have pointers either. It is refreshing to have them as an option, and they are not difficult to get used to.

coldtea11• 13 years ago

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

sergiotapia3• 13 years ago

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

a_bonobo• 13 years ago

I was under the impression that slices, maps and channels are reference types - i.e., if you pass them to a function using (foo) you'll pass "only" the reference like in Python, but that might be old information. Is that still valid?

kibibu3• 13 years ago

You need a little more than that, unfortunately.

A quick example: the standard library `flag` package lets you parse command line arguments, and returns either pointers or values. You need to know which is which. It's easy, for example, to do this:

    var filename = flag.String("file", "default.txt", "file to open")
    fmt.Println("Using file ", filename)

The above code looks ok at first glance, but prints the address of filename rather than its value. It can be fixed by using `flag.StringVal` instead of `flag.String`, or dereferencing `filename` using `* filename` in the Println.

So I would say you need to know way less about pointers than C but you still need to know the difference.

http://golang.org/pkg/flag/

cma• 13 years ago

If you make a change to an integer that was in a variable and passed in by parameter, does Javascript really make the change to the caller's variable?

optimusclimb• 13 years ago

If it's been 8 years, it's about time :) ...

Do yourself a favor, and learn the basics of pointers (might as well just read up on C), then move on to Go.

Before you go down the route of buying a paper book, try the interactive tutorial on the golang web site. It's pretty good. There's also a lot of good, and free, reading material on that site to help you learn.

Also, regarding pointers: They're really not that bad, but I understand a lot of people can have trouble with them.

Just realize that in languages like Ruby, and Python, you're never directly working with the computer's memory (as in RAM) - that is abstracted from you.

However, in a language like C, you are. (As an aside, you still aren't directly dealing with it, the operating system abstracts it from your program via the virtual memory system, but you can ignore that for now, and look it up some time when you see fit.) So the first thing you need to make sure is that you understand the difference between stack storage, and heap storage.

Once you understand the heap, and that it is essentially a large block of memory with sequential addresses, you can begin to understand pointers. They are just variables that contain the address of some other variable stored in memory. Languages that support pointers usually give you some syntactic sugar to make working with the "pointed to" object through the pointer easy.

Of course it can all get more complicated, but in summary, give them a shot...you'll gain a much better understanding of many things once you learn them a bit.

shurcooL3• 13 years ago

I started with this. http://tour.golang.org/

Then I went through those. https://news.ycombinator.com/item?id=5365401

jesstaa• 13 years ago

You already know everything you need to know about pointers. In Ruby almost everything is a pointer. What you need to learn about is 'values'.

e12e2• 13 years ago

As others have pointed out - you probably know enough about pointers to get started from the (rather excellent) documentation.

As for learning pointers -- I've never been able to get entirely comfortable with pointers in C -- the syntax just feels unnatural to me. I much prefer either assembler (intel syntax) -- or Pascal, eg:

http://www.tutorialspoint.com/pascal/pascal_pointers.htm

Go syntax is closer to C, though. So knowing C, Go might be easier (than not knowing C) -- but it isn't a prerequisite.

mamcx• 13 years ago

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

elithrar4• 13 years ago

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

4ad2• 13 years ago

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.

yepguy• 13 years ago

No, the ARM architecture is only supported on Linux right now (although unofficially it's mostly working on some other platforms too).

I remember reading that Go was ported to darwin/arm, but it can never be supported since there is no way to legally run their test suite for it.

myko• 13 years ago

iOS is too locked down to properly build Go code for. It's possible to write useful Go code on Android though, Brad Fitzpatrick posted about doing so recently:

https://plus.google.com/115863474911002159675/posts/DWmyygSr...

501• 13 years ago

This ticket might interest you: http://code.google.com/p/go/issues/detail?id=837

Maybe one day it'll come. If on that day iOS has gained a public XPC API I'll be quite the happy camper.

klobucar• 13 years ago

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

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

kibwen2• 13 years ago

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.

enneff9• 13 years ago

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

kibwen2• 13 years ago

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?

owyn• 13 years ago

I asked this exact question once when bradfitz was giving a talk about Go at AirBnB. The answer was that the team is led by minimalists who are interested in keeping it lean and avoiding bloat and especially in avoiding it becoming C++. In fact, you can see his answer about Go 2.0 roadmap plans (where the answer is basically "too soon to think about that yet") followed by my question (at 54:50) of this talk:

http://www.youtube.com/watch?feature=player_detailpage&v...

I guess the question then is "do you trust those guys?" So far the answer seems to be yes.

mcot2• 13 years ago

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.

azinman210• 13 years ago

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.

landr0id• 13 years ago

`<-c` is the main routine waiting for the other goroutine to finish (`c <- true`). It's being blocked until there's something for it to receive.

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

The `range` clause returns two values: index, and value at that index. It's really pretty easy to read and get used to once you actually read some documents.

elithrar4• 13 years ago

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

I feel that braces on blocks are more important to readability/clarity—because blocks should be identifiable—compared to parentheses for if statements. I don't think the if gets lost in there, but if you do then that's fine.

> We also see that "make" is lowercase yet a method, but os.Create and ParallelWrite has caps for a method.

That's because "make" is a built-in function for building slices and maps.

Packages with exportable functions (i.e. os.Create, http.HandleFunc, etc, etc) use capitalisation to denote "public" functions[1]. Functions within the os or http packages (for example) that should not be used directly by someone using the library retain a lowerCase approach. This reduces the risk and confusion surrounding which functions you should be working with when using a library.

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

Each key:value pair in m (a map, or "dictionary") is being assigned—hence the :=, which declares & assigns k & v in one line—for the entire range ('length', really).

Obviously you don't agree with some of the syntax in Go. That's fine. But some of your criticisms appear to stem from a misunderstanding or lack of knowledge about some language-agnostic concepts (channels, range, exportable functions) that I don't think Go obscures.

[1] http://golang.org/doc/effective_go.html#commentary

azinman210• 13 years ago

I agree with you on blocks/scoping. If dropping the parens I think Python does it right with its tab-based blocks.

Was uninformed about caps. That was a minor point for me, however, and in hindsight I should have at least investigated that before saying something.

Ok I see the consistency in :=, but in that sense I'd personally like to see something closer to Scala where the tuple is explicit by doing something like:

  for (k, v) := range m {

Which doesn't look all that much better, mostly because of the := (I've never liked in any lang) and the spacing between range, m, and {.

  for (k, v) := range(m) {

Could be yet another way to help make it more clear what is modifying what.

When you're tired and have been starting at code all day long having more visual gestalt in the language helps... syntax highlighting serves much of this but it's better IMHO if the language highlights itself.

__david__2• 13 years ago

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

It does look weird at first—I thought the same thing. But after writing some code with it, the design has a nice simplicity. When decoding C types, you have to sort of go back and forth "int * x[]" (an array of pointers to int) but in go it's always one direction: "int * []x". The type is always grouped together and that ends up being much easier for humans to parse.

Ditto for putting the return type after the function args. Seems backward if you're used to C/Java/etc but it makes things nicely composable, plus now every function starts with "func", and not a random return type.

I'm fine with the losing the parens around the ifs. Other languages do that and less syntax can look less messy. I do, however, HATE the required curlies. And the fact that stupid go-fmt always wants to format them out differently than I do:

    if short_check { short_code() } // My preferred formatting for short error tests
    if short_check { // go-fmt always wants to do this.
        short_code()
    }                // Blech.

For that reason alone I refuse to use go-fmt on my code :-). But I'm stubborn that way...

losvedir• 13 years ago

> For that reason alone I refuse to use go-fmt on my code

Nooooo! :-p

I used to prefer short one-liners like that (well, still do in ruby), but in Go I'm starting to kind of enjoy the blindingly obvious, verbose way of doing it. It makes me feel like Mr. Rogers[1][2]. Sure it's plodding, but it's exceedingly clear and easy to understand.

[1] http://www.youtube.com/watch?v=yXEuEUQIP3Q [2] http://www.youtube.com/watch?v=Upm9LnuCBUM

bad_user4• 13 years ago

Of course, you could have:

   def parallelWrite(data: Array[Byte])

No pointers to worry about, generics, etc ...

azinman210• 13 years ago

Why not int x? :) No confusion there! Except what that actually is underlying it all. I'm actually shocked that Go even has pointers given coding C++ at Google was all about passing by reference, although at least they put a lot of sane constraints on them (no pointing to arbitrary memory addresses, no pointer arithmetic, etc).

Google code style guidelines are anti-one liner, so that's not surprising to me that Go's formatter tries to enforce that.

I also employ one-liners but judiciously. It can be easy to miss the condition or side effect, particularly with returns. I waffle on whether it should or shouldn't be allowed. But there's something to code compactness on large projects...

enneff9• 13 years ago

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

jbarham2• 13 years ago

Also, "recent PhD from the MIT Media Lab". Maybe http://scratch.mit.edu/ is more his thing? ;)

tikhonj• 13 years ago

That sort of comment is a horrible scourge on all the Haskell articles. It's somewhat surprising to see it with Go just because of how C-like Go's syntax is.

azinman210• 13 years ago

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.

vidarh9• 13 years ago

Personally, whether or not I superficially find a language unreadable has a remarkable correlation with how likely I find I am to like a language once I learn more about it. Go does not do well on that measure for me either.

In Go's case, I tried to give it the benefit of the doubt, and went through a couple of tutorials, but while there were some nice parts of it that just reinforced my initial impression.

monjaro• 13 years ago

What a pointless complaint. Literally none of those things are real issues. Use the language for a day and it'll all be second nature.

azinman210• 13 years ago

Do aesthetics not matter?

kibibu3• 13 years ago

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

Every other language except:

- Actionscript, TypeScript, Haxe

    var x:int = 10;

- ML, OCaml, Haskell and derivatives

    val x : int = 10;

- Pascal and derivatives

    Var x : Integer;

- Ada and derivatives

    x : integer := 10;

- Old-school MASM Assembly syntax

    DSEG            segment
    x               word

- SQL

    CREATE TABLE tbl { x INT }

- Basic

    Dim x as Integer

- XML DTDs even

    <!ELEMENT x (#PCDATA)>

azinman210• 13 years ago

"put them in front of the type"

I meant the [], not just generally the type.

go: data []byte most (all?) other languages that use [] in arrays: data byte[]

inopinatus• 13 years ago

I read those examples and had no trouble inferring their meaning. I have no Go experience whatsoever and have not even read the introduction or tutorial. Yet, building entirely on what I know from speaking several C-like and non-C-like languages, here's what it looks like to me:

clearly c is some kind of "chan"nel-based synchronisation object for which <- is both the read & write operator (presumably blocking); the "go func" declaration is building a closure that is immediately invoked which, given this appears to be a parallelism demo, probably happens in a separate thread (green or OS unstated). m appears to be a map of string to string, so the assignment to k,v is almost certainly a tuple returned from iterator "range m" because that's just how things go in documentation-level examples.

I know nobody likes a smart-ass but it's a good example and even if some of the above is wrong, I got a taste of Go from it that I rather like. So thanks.

jbeshir• 13 years ago

All correct.

stcredzero• 13 years ago

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

enneff9• 13 years ago

A friend did a couple of of the Ludlum Dare comps in Go. Here's the most recent one: https://github.com/kurrik/ld26

iand• 13 years ago

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.

lclarkmichalek• 13 years ago

I'm doing a little game in it at the moment. Had to write my own allegro bindings (https://github.com/bluepeppers/allegro), but it's fun enough. One thing I really enjoy is mixing event handling with the goroutines. For example, I wanted to start scrolling the map on the user's click, and then stop when they release the button. So on click, I fired up a goroutine just to watch for the button release and handle the scrolling. So much easier than having some variable somewhere called "isButtonXDown" and then checking it in the main loop. Of course, you have to be carefully with concurrency, but it's a lot of fun.

rcoh• 13 years ago

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!

venuzr• 13 years ago

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

jussij2• 13 years ago

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

http://geekmonkey.org/articles/20-comparison-of-ides-for-goo...

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.

f2f• 13 years ago

the %v and %T flags to the printing package. surprisingly powerful :)

kamaal2• 13 years ago

Go doesn't have exception handling.

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

Devilboy• 13 years ago

It has explicit error handling (via multiple return values) which the authors argue is superior (even if more verbose) because they know from experience that programmers tend to make mistakes forgetting to check for errors in their code. If the error code comes back as a return value the programmer has to consciously decide what to do with it immediately, leading to better code on average.

osi• 13 years ago

as long as you aren't calling what you consider to be a 'return void' function (like writing data to a socket). then it is easy to forget to check the return value.

icebraining3• 13 years ago

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

kamaal2• 13 years ago

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.

bjacokes• 13 years ago

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.

iLikeCookies• 13 years ago

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.

Go 1.1 is released

Related Stories