On learning Go [the programming language]

In solidarity, I reproduce the comment that I had written just before reading yours:

Every time I see a link like this out of the corner of my eye I hope it's a link for Go, the board game. And every time, I am disappointed.

I guess this is how it must feel to be a fan of pythons. Or rubies. Or Java. (No, not that Java, the other one.)

It really does make it hard to like the language. All I can ever remember about Go is that it's about clicking the Back button over and over in annoyance.

Probably not. Sorry about that. I've updated the post title to reflect its contents.

I just started trying to learn how to play Go. It was quite disappointing to get to the second sentence of this article and realize it was about the language and not the game.

They have had their chance to rename it to issue9 (http://code.google.com/p/go/issues/detail?id=9). Unfortunately they didn't. They probably never googled for "go" when they chose the name.

We could simply name the board game Weiqi, or Baduk.

"Ever" is a difficult time frame to bet against.

There are good reasons it won't happen anytime soon.

First, there are 2 kinds of Android programming: * majority of programs are written to Dalvik VM using either official Java SDK or with clever cross-compilers (I believe C# can be used with mono-based compiler) * for performance sensitive programs (i.e. games) code can be compiled to native ARM assembly. There's official NDK from Google based on gcc. However, those programs have very limited access to the system, pretty much enough to write games but you can't access majority of the OS libraries, since those are written in Java and compiled to Dalivk VM.

Go already has an ARM compiler so it wouldn't be hard to make it generate native ARM code compatible with Android, like NDK's gcc does.

Go, however, has a feature (concurrency based on goroutines/channels) that is fundamental to the language and just doesn't mesh well with traditional runtimes, which are provide good support for threads. Making goroutines/channels work on Java/.NET runtimes is either impossible or would have terrible performance.

Again, it's not inconceivable to e.g. modify Dalvik VM to also support goroutines but that's not easy and no-one is even talking about that being a possibility. Go is still a very young implementation, it'll take a year or two before the basics are worked out and then esoteric use cases like supporting Android will invade implementor's minds.

It's possible. Go can produce ARM binaries, and the Android NDK permits one to write Android apps in C. It's conceivable that one could either wrap the NDK with something like [cgo](http://golang.org/cmd/cgo/), or write their own NDK-like thing to communicate with the rest of the Android system. It's a big job, though.

Why not learn both? Pick a small but non-trivial application, and write it in both languages.

I am pretty familiar with and a fan of both languages. I started with Haskell, and found it to be really exciting. Go is very different, but after I got over my initial incredulity at it for not being Haskell or at least an ML variant, I learned to like it quite a bit. I think changed my thinking about programming at least as much as Haskell, perhaps more.

I wanted to end this post by trying to answer your question, but I don't think I can. It's like asking, "Should I teach myself the piano or the guitar?". The real learning comes from what you make, not what you make it with.

It's really hard to say without knowing what your goal is.

If you know languages like C/Java/Python/Ruby, Haskell is much different, so you'll get exposed to radically different ways of thinking about programming.

Go is much closer to those traditional languages although it does add an uncommon (yet practical) way to do concurrent programming (goroutines/channels) that is worth learning about.

I know you don't care about real world applicability, but if it mattered, Go would be a better choice. It's explicitly designed as a practical language and in my opinion is a viable (if not superior in some ways) alternative to mainstream choices like Python or Ruby or Java for writing the most popular kinds of programs today: web applications.