Go is on a trajectory to become the next enterprise programming language
hackernoon.com
hackernoon.com
>Many languages are stronger in individual areas, but no other language scores so consistently well when looking at all of them combined, especially in regards to large-scale software engineering.
I use a number of wildly different languages, including Common Lisp, APL, and most recently Ada; each of these languages is lacking things the other has, but it also vastly more suited to other tasks than the rest. I've never used Go. Unlike these three languages I've mentioned, which have perfectly good reasons for lacking whatever it is they lack, Go very often has poor reasons or perhaps even no reasons, although I don't skulk around the mailing lists or whatnot.
>Go focuses on alleviating these large-scale engineering pains, sometimes at the cost of making engineering in the small a bit more cumbersome, for example by requiring a few extra lines of code here and there.
While reading this article, I've been left to wonder ''Why not Ada?'' and the answer seems to be that Google simply doesn't care about Ada. This is exactly the manner of thing Ada was created for.
>Many people are surprised that Go doesn’t contain concepts they love in other languages. Go is indeed a very small and simple language that contains only a minimal selection of orthogonal and proven concepts. This encourages developers to write the simplest possible code with the least amount of cognitive overhead so that many other people can understand and work with it.
A more cynical view is that Go is designed to use programmers as unintelligent implementing machines, which is why it's so opinionated. Its opinions have little or nothing to do with good programs and apparently everything to do with preventing the damage any single fool they want to use can cause or, worse, prevent a new hire who isn't a fool from writing a good program that makes them more valuable than their peers and harder to fire. There's no macros in Go, only the same thing, everywhere, no matter how poorly suited it is to the problem. If everyone writes Go the same, it's easy to fire and interchange employees without friction.
>Good code is obvious, avoids cleverness, obscure language features, twisted control flow, and indirections.
I'd like an example of such ''good code''. Simple code for complex problems is often ''clever'' and may even take some time to understand. This seems to contradict with earlier parts of the article.
>An example is error handling. It would be easier to just let exceptions interrupt code at various points and bubble up the call chain. Go requires to handle or return each error manually. This makes it explicit exactly where code can be interrupted and how errors are handled or wrapped. Overall, this makes error handling more cumbersome to write but easier to understand.
I think Ada does it rather well. The entire point of exceptions is handling exceptional circumstances and it's much more pleasant to have such handling in one place rather than everywhere it can happen. Not only that, but return values can be ignored by accident, which is a major issue.
Now, clearly, avoiding exceptional circumstances wherever possible seems to be the best option, but when that's not feasible, exceptions seem a rather good solution to this issue.
>Go is so small and simple that the entire language and its underlying concepts can be studied in just a couple of days. In our experience, after no more than a week of training (compared to months in other languages) Go beginners can make sense of code written by Go experts and contribute to it.
I'd think Forth is simple. Go doesn't seem to be. There's nothing wrong with new programmers being able to understand expert code, but this does betray that underlying feeling that Go is an attempt to de-skill programming.
A simple language isn't equivalent to a language that is good for writing programs in. Ofttimes, a lack of edge cases in the world of the language doesn't correspond to a lack of edge cases in real use. Take a look at Ada for a counterexample; the rules may not have a nice technical explanation, but the corresponding real world explanation is very simple, because it's usually to prevent some manner of error.
>The different programmers feel more at home in each other’s code bases.
A major aspect of ''programming in the large'' is not needing to see other people's code, but just the interfaces to it that are exposed.
>Go was written in the age of multi-core CPUs and has easy, high-level CSP-style concurrency built into the language.
Multiple threads of execution is, again, something Ada has been doing rather well for decades, with its tasks and protected objects and whatnot.
>Taken as a whole, they position Go as an excellent choice for large development projects looking for a modern programming language beyond Java.
Sans the standard library (Does Go actually have a real standard?), every advantage of Go listed seems to reasonably apply to Ada, whereas Ada also lacks many of the disadvantages. Ada can run in a GCed environment, but is also suited to real-time computing, as two examples.
For a good example of my criticisms, take a look at this:
https://tech.slashdot.org/story/17/01/03/1924218
It's my understanding Go lacked a proper mechanism for determining time and many people critiqued this, but it wasn't considered an issue until someone important was hit by it. This is a good example of the problems caused by a language that is not only uncustomizable by the users, but is designed by people who don't care and won't care. Unless you're someone, Google doesn't care about what you think and the language certainly doesn't, considering it is designed at every point to take away programmer choice.
As is usual, here's the Rob Pike quote:
''They're not capable of understanding a brilliant language, but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.''
The only ''philosophy'' these things espouse is that the computer isn't a tool for leveraging the mind.