
Go is on a trajectory to become the next enterprise programming language - kevingoslar
https://hackernoon.com/go-is-on-a-trajectory-to-become-the-next-enterprise-programming-language-3b75d70544e
======
taylodl
What do you mean by 'enterprise'? If you mean an organization in the Fortune
500 whose primary products do not include IT products and services then I
seriously doubt it. Java has been #1 on the TIOBE index for the past 15 years.
That's a HUGE amount of inertia in tooling, existing application portfolios,
know-how, etc. such that Java will probably be the #1 enterprise language for
at least the next 10 years. After that it's anyone's guess but odds are it
won't be Go.

------
verisimilitudes
I'm inclined to believe Go would be left to languish as Plan 9 and other
projects from Bell Labs are, were it not for the support of Google. Go is
certainly designed as other _enterprise programming languages_ are, though,
which is to write they're designed to weaken programmer agency.

>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](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.

