Less than four months after its unveiling at an early, experimental stage, Google Go looks promising to developers who say it offers significant improvements over other programming languages.
Less than four months after its unveiling at an early, experimental stage, Google Go looks promising to developers who say it offers significant improvements over other programming languages.
[quote]The programming language aims to combine the speed of Python with the robustness of C++[/quote]
This guy, Juan Carlos Perez, does not know what he is talking about. He is not even able to duplicate correctly what he reads somewhere else.
The speed of Python is not the speed of working with Python.
There is nothing in this article. Move along, please.
I actually found that [mis]quote amusing.
Speed of Python and the robustness of C++?
Is that anything like the type-safety of assembler combined with the raw performance of QBasic?
Well yes, speed of python is a bit of a joke, but C++ isn’t exactly un-robust. It has many robustness features not found in Python, e.g. compile-time linking, const-correctness and static typing. I’d take those over ‘safe’ segfaults any day.
One may consider withholding judgment on the validity/usefulness of the go language until at least one hard-core application appears that is written in it. The number as of a few months ago was apparently zero.
Edited 2010-03-01 14:42 UTC
The problem is that while the language does have some really interesting features, there are too many holes and unknowns at the moment to really embark into writing anything serious with it.
The go developers prefer to approach things slowly and consider every feature they add in the language, even features that we are used to from other languages.
It’s not a bad thing but it means is that go will mature slowly, especially since things like C++ interoperability are kind of a pain in the ass at the moment (mainly because of the conceptual mismatch between C++ and Go. For instance, go doesn’t allow to overload functions, which alone is a major problem to interface any moderately complex C++ api with Go), which means that there’s not much in the way of bindings to useful frameworks like Qt.
I also felt that the go community have a bit of a “let’s rewrite everything in go!” mentality where they’d rather develop “pure” go libraries from scratch than binding to filthy C++ ones.
Also, they are rather uncompromising in their approach, they put compilation time above everything. If they can’t implement a feature in a way that avoid contextual parsing or add any form of ambiguity (like what function overload to match with parameters), they don’t put it in and have a slightly annoying tendency to rationalize it as the missing feature being unnecessary.
Basically Go has some nice features but in my opinion they’re not so awesome that I’d be willing to work without exceptions, templates, RAII and most of the other goodies of C++.
Edited 2010-03-01 15:30 UTC
I always wondered: Does Go support code inheritance? Function implementations seem to be bound to a concrete type (not interface). Well they need to be in order to access things that are not in the interface (like “private” fields). But what to do when I’d like to make a new type that inherits from the former but overwrites some (not all) methods? I don’t care about subtyping, because Gos interfaces make it implicit (structural equivalence instead of name equivalence like in most other languages – actually I think its higher order subtyping (matching), very much like concepts in C++0x). But how does one inherit CODE? Inheritance is not subtyping or vice versa. You need both in order to be productive (though not necessarily by using the same language feature – it could be done separately). I really hope the Go developers know that. Every serious language developer should have done a lecture in programming languages, type systems and preferably also object oriented-, functional- and logical-languages. Just to see what mistakes all the existing languages already made and why some of the odd points of a lot of languages are actually NO mistakes but well thought of design decisions (type erasure in Javas Generics, no OO in Haskell etc.).
Edited 2010-03-01 14:47 UTC
Go programmers explicitly consider implementation inheritance a bad idea.
I tend to agree with them. It’s hardly necessary, you should use composition instead. Todays OOP overuses it quite a bit.
Unless you have something larger than a hobby project. Imagine that you have a large class library project, with well-paying customers. Now, suppose that in interface has proven to be incomplete. Adding a method to your interface will burden all those customers depending on it (and whose code bases are out of your control). Do such a thing to often, and they will really dislike your product.
If you used an abstract class instead, you could just have added the methods, and provide a default implementation.
Both composition and inheritance have their place in object-oriented programming. Use both wisely.
With respect to Go: they consider more things to be useless or too unimportant to implement initially. Generics or templates anyone? I had a quick look at Go, and currently it is mostly useless for serious projects without having a lot of code duplication and ugliness. Even D, which has not stabilized yet, is far more useful.
Edited 2010-03-01 15:30 UTC
Yeah, the best things about Go are the go routines, the interfaces and type inference for locals. With GDC and/or C++0x Closures, C++0x Concepts (which sadly did not make it into C++0x but will be included in a update) and the auto keyword there are equivalent things in C++. Given the fact there is a much larger existing codebase in C++ I think Go will have a hard time to compete. Still it is great to have more diversity and a fresh view on things.
There are loads of things that make it compelling
– compile 120k loc in under 8 seconds on a laptop
– mixins for polymorphism/code reuse
– actor model for concurrency
– nice type inference system
I haven’t dug too deep into go, but it seems like they are trying to incorporate productivity features from higher level languages and bringing them into a systems language. Even if it doesn’t work, it is a very interesting project, and I would love to see more stuff like this in the future.
What about mixins?
There is a hidden coupling with inheritance that makes it inappropriate for most things, unless you are using a language that doesn’t really give you any other choice. Composition + modular class extension is the way to go.
IMO implicit mixins in go are downright scary, but that is a side issue…
There are implicit mixins in Go? Please do explain! What are “implicit” mixins?
Edited 2010-03-01 17:26 UTC
A go “interface” is essentially a mixin, you can define methods on it and they will get attached to the object. The difference between a go interface and a mixin is that mixins are explicitly included in a class or an object, a go interface auto detects types that are compatible, and will include itself implicitly.
Edited 2010-03-01 17:37 UTC
Out of curiosity – how does Java deal with this?
I don’t see this as a real problem with statically typed languages. An ide could add a default implementation by mere press of a button. Empty default implementation is handy (done many of those myself), but I can’t bring myself to care about the issue.
If I understand this right then composition is similar to/the same as mixins. Well that was what I meant with _code_ inheritance. A language level way to do things like mixins, where you do not have to write manual delegate methods (brrr) but just say: may thing (type, interface, object, whatever) “inherits” all features from that other thing/concept/mixin/whatever. I do not speak of a type hierarchy there. I just want a way to define a concept that provides some features (real code, not just an interface) and possibly also has a required interface (structural equivalence!). Then I define a type an say this type gets all features defined by the concept. This removes code duplication. Ruby (and most dynamic languages, e.g. also Python) support such things. You don’t need a dynamic language for this, its just very easy to implement this feature in a dynamic language. There are people who wrote a paper+demo implementation for mixins in Java (all statically typed and type safe).
I’m not gonna start using a language that requires me to manually write delegate methods. I guess not much people will do that. Google should add mixins to Go and it would be fine.
Yes:
http://golang.org/doc/effective_go.html#embedding
You can cherry-pick methods from multiple types, Go will resolve name conflicts for you. It’s a bit like multiple inheritance done right.
Ok I took another look at the documentation of Go. It seems that it does support inheritance and calls it embedding. It’s almost but not quite a mixin. The required interface part is missing. In a mixin I would also define things the “embedding” type has to provide and can be used in methods of the mixin (or “embedded” type) itself.
<blockquote>We understand that a significant fraction of computers in the world run Windows and it would be great if those computers could run Go programs. However, the Go team is small and we don’t have the resources to do a Windows port at the moment. We would be more than willing to answer questions and offer advice to anyone willing to develop a Windows version. </blockquote>
Interesting way to phrase that…an overwhelming majority becomes a “significant fraction”.
I haven’t tried to build it on cygwin, but I would think that would be at least worth a try.
Computers is an overloaded word (he didn’t say personnal computers): there are quite a few computers in phones, appliances, etc.
Those computers don’t run Windows..
For a programming language to be termed “good”, it should reduce the boilerplate code he needs to write. It needs to have some form of code-reuse. I know of three methods:
1. Inheritance
2. Delegation
3. Templates*
Delegation is where you send the arguments of one function to another function, then return the output. Something like “return func(args);”.
Inheritance is simply defined as satisfying the “is-a” relationship i.e., subtyping. This means that half the code people write, such as “class CarOwner extends Car, Person” is flawed cuz CarOwner is not a Car. This also means that “interface inheritance” is closer to the actual method of using inheritance, instead people use inheritance to attain composition.
C++ featured manual inheritance, but delegation was automated. A whole lotta languages made the same mistake. It was done right only by few languages such as Eiffel, which made the language more powerful through proper inheritance mechanisms such as deleting and renaming methods. C++0x has some of these features though they don’t work as well as in Eiffel.
Go features neither of the above mentioned mechanisms which is why I don’t consider it a “good” language. What I like about the language is the stress put on the tools for the language, but the language is still too crappy. It uses something akin to a “dynamic VTable” implementation which gives it speeds equal to the “virtual” keyword in C++. But that is wrought with problems in C++…
I’m not quite sure how safe it will be in Go.
I don’t like how interfaces can’t inherit other interfaces.
It doesn’t allow you to swap the classes as in JVM.
It’s not faster than LuaJIT which is an interpreter for on a *much* simpler language.
As you may tell I’m not interested in the language yet.. It really depends on how much effort Google wishes to put into spreading the language. Until then it’s not a language I would favour.. Groovy, Scala, D and even Zimbu are a lot more interesting to me.
—
* – BTW; I said code-reuse, not polymorphism. Templates allow for some arcane magic.. This might even start a flame war so I left it be..