[microtonal]

After that, time will pave way to The Go paradox[2].

I am not sure.

Most people who know the important low-level languages well, are not likely to be a fan of Go. Seasoned C++ hackers will miss templates dearly (no, interfaces are not a replacement for templates, they are a replacement for abstract base classes) and C/C++ programmers dislike the lack of control over memory management. If you are using C or C++ in 2012, you probably have good reasons and Go mostly sacrifices the advantages of C and C++.

Someone who is familiar enough with Haskell, ML, or Scala, will dislike the fact that Go practically ignored (or rejected?) two or three decades of research an programming languages. From the perspective of PL research, Go is a weak language.

In other words, the low-level and strong typing crowds are not that much interested in Go. If there is a new imperative language that does interest them, it is probably Rust.

The question is, who does switch to Go? One would guess that these are mostly Python and Ruby programmers who have never written much C, C++, or Haskell, and are looking for something faster and compiled. Yes, this is a generalization, and there are plenty of exceptions. Not exactly the 'Python paradox', 'better than the rest', programmers.

Following the Google+ community, discussions on HN, and to an extend the Go mailing lists, confirms those suspicions. There are lot of grandiose claims supporting Go (one of my personal pet peeves are people claiming that 'Go interfaces are like Haskell typeclasses'). But if you look at the language spec, there is not much interesting. Goroutines are nice, but they are just green threads. Channels have been done elsewhere.

Go is just a very boring language (which isn't necessarily bad), pretty much like Java, without the good package management (no versioning), good IDEs, broad library support, or a performant garbage collector.

Boring languages attract more mediocre programmers than great programmers.

Edit: if you downvote, please, at least leave a comment ;).

[icey]

Hi, mediocre programmer here!

I would add a bullet point to the list of reasons I like go: "Boring to people who bring up Haskell in every programming conversation" ;)

Seriously though, there are huge classes of problems in which the "interesting" part of the problem isn't the software that gets written but the business needs it solves. I am a fan of functional programming (I started the Clojure subreddit, and do a lot of "for fun" programming in it), but I've never run across a problem at my business where I felt like I needed to crack open Okasaki's book, or thought "this would be easier with an applicative functor".

Something I've enjoyed about learning Go is the open & accepting nature of the community; I don't think I've ever heard someone called "mediocre" because of other languages they use.

I am happy to feel like I don't have to be an incredible programmer to read the source code of the language I use, or the libraries I pull into my projects. I just want to get shit done so I can work on the problems that I find interesting, and for lots of us, that's just not going to be yet another implementation of datalog.

[aninteger]

I can't downvote but I'm using C/C++ in 2013 instead of Go simply because Go is not portable enough. There is currently no PowerPC port and that is still a requirement for me.

[jff]

gccgo might solve your problem, if you actually want the problem to be solved.

[3pt14159]

Easier concurrancy and better string management. Current c/c++ people already learned the common methods. Also, less ambiguous lines of code.

[burntsushi]

> no, interfaces are not a replacement for templates, they are a replacement for abstract base classes

Interfaces aren't a replacement for templates, but they aren't a replacement for abstract base classes either. Interfaces in Go provide polymorphism through structural sub-typing. My limited knowledge of abstract base classes says that these are very much not the same.

> Someone who is familiar enough with Haskell, ML, or Scala, will dislike the fact that Go practically ignored (or rejected?) two or three decades of research an programming languages. From the perspective of PL research, Go is a weak language.

I am a Haskell programmer, but that crowd is impossible to please unless you've provided every PL feature out of research in the last few decades. I've seen virtually no appreciation for simplicity of language design as an entire unit.

> If there is a new imperative language that does interest them, it is probably Rust.

Yes. I can't wait for Rust to get a bit more love in the documentation department. Pattern matching? Algebraic data types? Thread local storage? Type classes? Yes please! Where do I sign up?

> The question is, who does switch to Go? One would guess that these are mostly Python and Ruby programmers who have never written much C, C++, or Haskell, and are looking for something faster and compiled. Yes, this is a generalization, and there are plenty of exceptions. Not exactly the 'Python paradox', 'better than the rest', programmers.

In my experience, most Go programmers are in fact coming from Python and Ruby.

The premise of the "Go" or "Python" paradox is that skilled programmers tend to be the first ones to adopt new languages. Then the less-skilled programmers follow when there is sufficient buzz. I think that if one accepts that premise, it is applicable for Go.

> one of my personal pet peeves are people claiming that 'Go interfaces are like Haskell typeclasses'

That is annoying, but completely understandable. They are deceptively similar on the surface. But I don't think this kind of confusion is unique to Go. You'll see it everywhere.

You know what else people confuse? That Go interfaces are just like abstract base classes! :P

> But if you look at the language spec, there is not much interesting.

That's kind of the point. If you don't accept the overall simplicity of the design Go as a feature, then I can't blame you if you dismiss Go. If all you want to judge a language by is whether it includes cool and exciting new features, then Go will never be a good choice for you a priori.

> Go is just a very boring language (which isn't necessarily bad), pretty much like Java, without the good package management (no versioning)

I am utterly baffled. Go's approach to packaging is literally the best tool of its class that I've ever used. The Go tool militates toward convention rather than providing a dizzying array of features. This makes it strictly less powerful than other packaging tools, but god dammit, it makes it dead simple to install packages.

You want to try my window manager, which is roughly 30,000 LOC (including my X libraries)? If you have Go installed: `go get github.com/BurntSushi/wingo`. That's it. You're done. I just ran it on my system, and it downloaded, compiled and installed my window manager---along with all of its dependencies---in less than 30 seconds.

You might say---other build tools can do this! But do you know how many lines of configuration I had to write for any of this to work? None. I didn't specify dependencies. No strange command line flags. Nothing. The common case Just Works.

> Goroutines are nice, but they are just green threads. Channels have been done elsewhere.

This is a vast understatement. Just green threads? And please, tell me, what other mainstream language supports green threads? I know Haskell and Erlang do. Rust will (yay). Anything else? No? (I know Java doesn't, but I can't remember if this is a limitation of the JVM or if Scala or Clojure have green threads). Go does. That's a pretty big deal. Go makes a solid concurrent style of programming in a C-like language virtually free. Sure, everything is still mutable, but there are powerful idioms that---in my experience---militate against race conditions. It's not as good as Haskell/Erlang/Rust in the compile time safety department, but I'll be damned if it isn't loads easier than my other choices: C, C++, Java, Python, Ruby, Lua, blah blah.

> Boring languages attract more mediocre programmers than great programmers.

And close minded folk think they have all the answers. It's possible for people to enjoy using more than one tool. I'm a hacker, and I love good tools. Go is a great tool. So is Haskell. I hope that Rust will be.

[microtonal]

You know what else people confuse? That Go interfaces are just like abstract base classes! :P

I think you are confused by abstract base classes in Java. In C++, which has multiple inheritance, a class can inherit from multiple classes. An abstract without implemented methods behave like an interface, it specifies what deriving classes should implement. The largest difference is in implementation: in C++ a base class pointer is just that and methods will be looked up via the vtable, in Go the interface-typed 'pointer' is actually a type pointer - instance pointer tuple (which is ugly, because it clouds nils). And in Go you do not have to specify the interfaces being implemented explicitly. Some see that as an advantage, others as a disadvantage (since a struct + functions can accidentally implement an interface, while not implementing the intended semantics).

I am utterly baffled. Go's approach to packaging is literally the best tool of its class that I've ever used.

No version management. Fun for hobby projects, a nightmare for large mission critical programs.

This is a vast understatement. Just green threads? And please, tell me, what other mainstream language supports green threads? I know Haskell and Erlang do.

Many languages have green thread implementations (Ruby 1.8, Python, etc.). But there is a varying amount of multiplexing to native threads and some implementations are hampered by global interpreter locks, etc. In fact, even old Java versions implemented green threads, but they were replaced by native threads.

[burntsushi]

> And in Go you do not have to specify the interfaces being implemented explicitly.

This is precisely what I meant by "... [interfaces] aren't a replacement for abstract base classes either. Interfaces in Go provide polymorphism through structural sub-typing."

Whether it's a good thing or not, it drastically changes the way they are used.

> No version management. Fun for hobby projects, a nightmare for large mission critical programs.

I use the `go` tool for more than hobby projects.

You are re-stating what I already acknowledged. What point are you trying to convey? I said the `go` tool was strictly less powerful, but that it was awesome for the common case. If you don't think that's worth anything, then I'm not sure what else to tell you.

> Many languages have green thread implementations (Ruby 1.8, Python, etc.). But there is a varying amount of multiplexing to native threads and some implementations are hampered by global interpreter locks, etc. In fact, even old Java versions implemented green threads, but they were replaced by native threads.

So........... Go wins here.

Do you really want to have a conversation? Or do you just want to mirror everything I said right back at me?