My first thought – who needs another language? Are new languages the new rage?
If I were to design a new language (I am not qualified, trust me), what would it address . . .
- It would be garbage collected (no brainer)
- It would run in a VM (actually, many different VMs )
- It would also be statically typed (I think many would disagree these days)
- Threading would be a focus (with message passing as a language feature). Certainly include some aspects of functional programming languages
- It would have first class functions to throw around
- Some sort of cool, built-in data types – if only to set it apart from other languages.
- Nearly all functionality in libraries, and try to get others to actually write the libraries
Sounds a bit like Google Go - “Expressive, concurrent, garbage collected” they say. Fast, safe, concurrent, fun, open source they continue. Fun and fast? I don’t think “compile time” is an issue and nearly everything these days, interpreted or not, runs “nearly as quickly as C or C++ code”. So that’s nothing new. All programming is fun. (Well, nearly all).
My language would not have a googly-goofy name, like “Go” with all the “Go nuts”, “Go for it”, etc., phrases being thrown around. I do like the co-routines moniker, err, I mean Go-routines, however. At least they did not call it “goo” or “goog”. In fact, without the goroutines I probably would not have given this thing a second look.
So what is new with this language?
A Systems Programming Language
I think that title is a clue as to what this all might be about – I would love to see C/C++ disappear, but I would like to see that done through evolution of those languages. Something like removing all the “bad goo” from C/C++, but leaving the good stuff alone. Maybe that is impossible – we can only pile on, not take away. A colleague of mine once said that C/C++ would always be around because someone has to write the thread scheduler and the device drivers for the OS – I disagree, eventually we will jettison what is bad about C and keep what’s not. Is that GO? I don’t know.
Why does it have pointers? Who in their right mind would add that as a language feature? It has no pointer arithmetic – so maybe this is OK, then? Slices – they seem to allow you to address arbitrary blobs of bytes (defined via a pointer, maybe) or portions of arrays, as the documentation states, in a semi-safe manner without the pointer arithmetic. Sounds reasonable for a systems programming language. I wonder, then, why are strings immutable?
Things I like
- Maps, slices, and channels
- Go-Routines
- No implicit numeric conversions
- Lots of implicit “compatible conversions” (my terminology)
- No side-effects or alternatives syntaxes for things
- No operator overloading
Things Not-so-hot
- No exception handling
- No generics
- Pointers
- No method overloading
No type inheritance? I’ll have to think about that one for a while. Sounds very interesting, though, since a significant amount of refactoring I seem to do involves unwinding complex type hierarchies into composition models. There is also implicitly-inherited (my terminology) types – i.e., when one type just happens to implement a set of methods that matches another type or interface. They are then magically, implicitly compatible. That is cool. Very cool.
I plan to spend some time over the next few months looking at Google Go. There are lots of very smart people over in google-land, so I am sure there is a lot to consider and learn from the ideas around Go. Too bad I’ll have to fire up linux or actually boot the Macbook into OSX instead of Windows 7 to play with it. Stupid decision on google’s part, if you ask me.