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