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