So I read the FAQ on the “Go” site here.  Despite my better judgment I do like some of the conventions and minimalism they’ve adopted, such as having postfix, but not prefix notation for incrementing.  And there were a few statements that *really* hit home for me, like this one:

Another point is that a large part of the difficulty of concurrent and multi-threaded programming is memory management; as objects get passed among threads it becomes cumbersome to guarantee they become freed safely. Automatic garbage collection makes concurrent code far easier to write. Of course, implementing garbage collection in a concurrent environment is itself a challenge, but meeting it once rather than in every program helps everyone.

Finally, concurrency aside, garbage collection makes interfaces simpler because they don’t need to specify how memory is managed across them.

They’ve articulated a key principle of their approach - that they are solving something that is a hard problem, not because it is hard, but because it is hard and useful to the end users (other programmers).  They are faced with a choice of solving that problem once in the language (implementing good, efficient garbage collection), or implementing it myriad times in the programs written with this language (a la C and C++).  Hard problems that have a lot of re-use and benefit are worth solving.

If we look at a good BPMS, it serves some of the same function – handling parallelism, memory management, and other key software architecture concerns for the business process author – in order to allow the author to focus more clearly on solving the business problem. BPMS offerings largely have a lot of room to improve on all these fronts – but they’re still the best thing we have for a “language” that fits the “problem” (despite rules vendors’ claims to the contrary).

I’m often faced with a problem that lends itself to being solved once, well – or many times, poorly.  And often the software engineers of our world tell me “yes, but that’s hard, and not on the road map.”  A great example of this is date calculations that transparently do things like comparing, navigating timezones, calculating differences, navigating business days (and calendars), etc.  A better example is robust versioning for complex assets like business process models which include all the implementation details.

Other “features” that caught my eye in Go:

• No generic types.  No exceptions.  They admit they don’t have a good solution yet, so they don’t slap a band-aid on it.  Try not to write code that breaks.
• No type inheritance.  A type is more like an “interface” – where any object that implements the methods the type requires are, by definition, “of that type”.  This reminds me a bit of protocols in objective-C, but without the necessity of pre-defining the relationships (technically, you can define and compile-and-link later in objective-C but that’s another story).
• No overloading.  Never in the history of software engineering has a more useless and anti-performant feature been introduced at a language level.  Nice to see another language that forgoes operator overloading.

Of course, this minimalism will be tested with time – especially if the audience of Go users expands – or if the language is handed over to a standards body full of people who really have it as an interest to keep tweaking the language (a la Java and C++) – over time making it increasingly complicated.

In the meantime, I’m just happy to be pleasantly surprised that this supposed prank has some decent substance.  Did Google really need to design a new language to handle concurrency and other large-scale problems well?  I can’t say for sure, but at least once going down that road they’ve made some promising early design decisions: focusing on the key, differentiated problems their solving, and postponing or not solving areas that are not directly related.

No related posts.