So a few times I’ve been tempted to “try out” Google’s language named “Go” (which actually is harder to search for on the Internet than the letter “C” because the word “go” is commonly used in expressive English whereas the letter “C” is rarely used in conversation).
However, just like Java, I keep hitting brick walls that prevent any practical use of the language in business.
In general Go appears has been engineered to satisfy a particular clique of developers with rose-coloured glasses on. While it could have been a significant boost to multi-processor application development it has adopted a rigidity around the semantics that will likely alienate a great majority who might have otherwise considered it.
Stubbornness isn’t new in a product that an author wishes to be used in a particular way. The author of FileZilla stubbornly resisted adding FTP proxy support to his product arguing that routers’ NAT should be correctly configured instead; but relented in version 3.0.4 RC1 / 3.0.3 / 2.2.32 after overwhelming demand for the feature. Unfortunately Perl, which used to be a very flexible language, recently started rejecting a commonly used qw operator idiom with no means of turning off the warning/error generated by its use – breaking generations of code out there in production today – a most unprofessional result of stubbornness.
Go Will Not Compile If A Variable or Import Is Unused
According to the language FAQ:
Some have asked for a compiler option to turn those checks off or at least reduce them to warnings. Such an option has not been added, though, because compiler options should not affect the semantics of the language and because the Go compiler does not report warnings, only errors that prevent compilation.
There are two reasons for having no warnings. First, if it’s worth complaining about, it’s worth fixing in the code. (And if it’s not worth fixing, it’s not worth mentioning.) Second, having the compiler generate warnings encourages the implementation to warn about weak cases that can make compilation noisy, masking real errors that should be fixed.
Whilst I absolutely agree that production code should not generate any warnings there are advantages to their presence.
- sometimes languages change but old code needs to be run in a new environment – Perl, for example, recently changed the semantics of the qw operator that has broken a lot of old code; the inflexibility of the language to suppress or merely generate warnings for code that was legitimate is a rigidity that prevents pragmatic use in a workplace over time
- the development cycle necessarily has broken code because it isn’t finished yet – during a bug fixing cycle one may comment out blocks of code to try and isolate a problem – but being unable to leave unused variables around severely impacts on the ability of this tried-and-tested technique of problem isolation to be implemented
- a warning is something that is serious enough to know about – but, in the right circumstances – can be ignored; ever crossed the road when the lights were red but you looked both ways and no cars were coming? Consider yourself to be ignoring a warning. It happens every day in real lives. It happens in business, too. Nobody should be encouraged for recklessly ignoring warnings – but they are useful informational tools to those who make informed judgements off the back of them
It clearly makes no sense to prevent a program from compilation with a superfluous variable or import. No sense whatsoever. It makes sense to warn, just as C and C++ will, but no professional language would stop a developer from developing in this circumstance.
Exports Must Have a Leading Upper-Case Letter
In one of the more ridiculous restrictions of the language come the requirement to differentiate between methods and variables local to a module from those that are exported by mere capitalisation of the identifier.
To prove how ridiculous this is we have a FAQ questioning how a language without case (such as Japanese) can possibly export methods! In fact the sheer arrogance on display is beyond all reasonable sense with this quote from the FAQ: “The case-for-visibility rule is unlikely to change however; it’s one of our favorite features of Go”. Just enormously stupid. Forcing an atypical grammar to suit a personal itch.
Such inflexibility doesn’t leave any room for the developer to find their own style of naming conventions. And it requires that one innately knows the rules for naming conventions.
To the developer this makes experimentation/design nearly impossible as it means a search-and-replace across a file (to change the name of the variable right throughout the code) if one decides to change the export status of a method or variable rather than a simple public/private type keyword or an explicit export declaration.