As you can read on my about me page, I have pretty much always been into learning new languages. This is more true for programming languages than spoken ones, but I do think I’m fairly good at this english one. So recently (shocking since it hasn’t existed that long) I came across Google’s Go language and I have been reading about the features of the language and the design choices the inventors have made.
Now I have to say that I have thought about designing my own programming language for quite a while now (almost a decade) and while I haven’t even started trying to implement it I have spent quite a bit of time writing down features it needs to have, features that are nice to have, etc. Now there are some obvious features that every recent language seems to have, like Object Orientation, Threads, C-style syntax, etc. I was quite surprised that Go went a different way on a few things that seem obvious at first.
Go doesn’t quite have Classes, that is to say that it doesn’t have Inheritance. That seems like a glaringly obvious mistake on their part, but since they had some very smart people think about it for a long time, I’m more inclined to trust them on it than myself. The interesting thing here is Interfaces (no grammatically this makes no sense, but I’m leaving it). If an Object has all the same interfaces as another Object what purpose would there be in the Objects not being interchangable. If it could be used as a different Object without anything failing, why wouldn’t it be allowed to.
C-Style syntax is another thing that’s seemingly obvious, but everyone differs from it a little bit (and they all kinda have to since C doesn’t have classes). Go doesn’t really go that far off the beaten path here, but some things are noteworthy. Variable declarations are the first and most obvious thing. I don’t think turning everything around is a good idea really, but I can live with it. In C# you have someclass somename = new someclass(arguments); which I will be the first to admit is a bit redundant. Still I would have probably gone with: new someclass(arguments) somename instead of the Go equivalent somename:= someclass(arguments).
Semicolons are gone as well. You still can throw them in there to end a statement if you want to have more than one statement in one line of code, but for the most part you probably won’t be using them. I have always thought that that was the way it was supposed to be, but I did favor the consistency of the semicolon over just ending a statement at the end of a line like VB. So here I can have both.
Last, for this post anyway, we have Threads. With every living being having a multicore processor this seems obvious. We do need concurrency. There just isn’t a way around concurrency anymore. The obvious choice seems to be using threads. It’s what everyone else does and it’s fairly simple to implement. You can just let the Operating System’s scheduler figure out when to give another thread the ability to do something. After thinking about this for a long time and writing a few multithreaded programs I have always favored erlang style concurrency. You need a way to pass a message to a different thread and using global (omg !) or shared variables doesn’t seem like a very safe way to do it. Everything else (locking, mutex, etc.) just seems like a workaround for the initial mistake.
So would I make the same choices (after reading a lot about Go) ? Mostly I would have to go with yes. In loops you don’t need the brackets if you have to have the curly braces, same with if statements, semicolons also seem redundant at the end of a line, so I would stick with all that. Concurrency is also an easy one, I like the way Go does it. Classes is where I would go the old fashioned way, but I might well change my mind on it, because Duck typing seems much easier for the programmer. You don’t need to figure out long class diagrams before you write the first line of code.
In short the inventors of the Go language are obviously much smarter than I am, so I’m not really surprised that they changed my mind about a lot of features of a programming language.