
Go and Brand X: A language comparison - inklesspen
http://www.cowlark.com/2009-11-15-go/
======
pvg
It's an oddly syntax-focused comparison given that we already often refer to
that entire class of languages as 'Algol-style' or 'Algol-derived' and the
block-structure and lexical scope ideas are in wide use even in languages far
afield, syntactically. I think the notion that they 'overlap more than they
differ' is quite inaccurate - they do, if you cherry pick features, gloss over
others (par is not the same as goroutines, interfaces are nothing like
'polymorphic operators', you can't turn all of go's keywords into, say,
Turkish). If you weigh the differences, conservatively and pragmatically, the
languages are tremendously different.

The other points raised:

'effective' vs 'good' - seems like a narrower case of the plentiful and in-
depth literature available about 'worse is better' (and the converse).

'can't spot any language feature that was invented after about 1985' - at this
point the Lisp crowd should probably be reaching for their pitchforks and
lighting their torches. Perhaps formalized systems for hygienic macros came a
bit later?

~~~
stcredzero
_effective vs. good_

I see 'effective vs. good' as an opportunity to _satisfice_.

<http://en.wikipedia.org/wiki/The_Paradox_of_Choice>

Let's take the notion of _satisficing_ and apply old 80-20 rule. About 80% of
your life is not going to matter that much in 5 years. Your choice of
toothpaste, the car you drive, which couch you buy -- these can be complex
decisions, but they aren't going to have as big an influence on your life as
the town you live in, the jobs you take, or your closest friends. It's a
minority of decisions you make which will matter the most, so spend your
maximum effort optimizing those. For the rest, let's just find something that
will do the job.

I think the Go team decided that compilation time, efficient execution,
conciseness, and concurrency were the areas that mattered the most for a
systems programming language. Most of the programming world understands
"Algol-derived" syntax, so why not stick with that? In fact, given that the
majority understands that sort of syntax, this should also be considered an
optimization -- one which is aimed at achieving as large a user base as
possible.

(I wonder if one can consider Python to be an _80-20 satisficed_ language?)

~~~
pvg
If you haven't got around to it yet, google 'worse is better'.

~~~
stcredzero
I've also responded to 'worse is better" numerous times on HN. I don't think
people are aware that what they want is _satisficing_ in most of their design
so that they can spend more effort on the the most important 20%.

------
jdale27
Excellent article. It pleases me that an important language that turned out
not to be very widely used is nevertheless remembered by some -- if not by the
creators of Go, who were apparently doomed to reinvent Algol 68 badly.

I'm also reminded of C.A.R. Hoare's famous quip about Algol _60_ : "Here is a
language so far ahead of its time, that it was not only an improvement on its
predecessors, but also on nearly all its successors." (Sourced at
<http://en.wikiquote.org/wiki/C._A._R._Hoare> .)

~~~
tspiteri
Do you really think the creators of Go do not know Algol 68? They know it much
better than does the article author, who admits he's "not an experienced
programmer in either Algol-68 _or_ Go".

------
sethg
The author admits that one feature present in Go and missing from Algol-68 is
proper closures. I would consider this an extremely significant deficit in
Algol-68, not just one item to bury in a laundry-list comparison.

~~~
tspiteri
I don't think the article is so good. I got the impression that the main
article centers around the part:

 _Take a deep breath. This may shock you._

 _Brand X is Algol-68._

That sort of sounds cool, so why not write an article to show that Algol-68 is
more consistent than Go? Then the author just tries to compare features not
honestly, but with the intention of making Algol-68 look better than Go, so
that he builds up to his cool _Brand X is Algol-68_. His criticism of Go is
mosly unfair, for example, how can he say that Go syntax can look ambiguous? I
don't think I've seen a more explicit and unambiguous language than Go.

------
VBprogrammer
In my own personal opinion, the fact that Google have brought to the forefront
the need for a new systems language is way more important than the exact
feature set they have chosen to include. Even things like garbage collection
and array bounds checking make life better.

One thing I find interesting is that I've seen several people claim that Go is
all but useless until they implement generics. Java has only had generics for
the last 5 years, C# had them after that, and the languages Go is intended to
compete with still don't have them (well C++ has templates and I guess C has
void *)!

~~~
bediger
Personally, I couldn't believe that they put generics in Java, after the
weirdness with C++ templates, and all the problems they buy you.

Java very definitely jumped the shark when they added generics.

------
j_baker
I hate to break it to the author, but programming language design in general
hasn't evolved much since ALGOL. It's not just Go. Sure, we have object-
oriented programming, but that's really not anything earth-shattering from a
language design standpoint.

------
kqr2
See also:

<http://news.ycombinator.com/item?id=941350>

------
dgriffin
I find it hard to make any "system" language that will be better than C or
maybe C++. Go or Algol are just going to be C with some features tacked on. If
someone is going to overtake C it will need to be a whole new approach. I
think that is what the author is trying to get at.

~~~
inklesspen
You are aware that Algol predates C, yes? This would make it hard for Algol to
"just [be] C with some features tacked on", according to any reasonable
interpretation of those words.

~~~
wcarss
It does seem more like C is Algol with some features cut out.

------
waterlesscloud
Wow, the Algol-68 spec really is impenetrable.

------
jorgem
Hard to invent anything new.

~~~
mahmud
Finish the sentence.

Hard to invent anything new if you need to keep backward "knowledge"
compatibility.

Industrial PL design has always been about doing what programmers already
know, but _gradually_ "better". Not challenging them and introducing them to
new concepts. As far back as the first Fortran; language designers were told
to defer to the programmer's expertise, so much so that the #1 requirement for
Fortran was to be an algebriac syntax over assembly language. Fortran didn't
dare to do anything different than assembly (that job was left to Lisp.)
That's why you see dangerous low-level constructs left in every major HLL:
this is to allow the previous generation of programmers the freedom to
circumvent the abstraction to get work done. It's a subtle admission of
distrust of high-level concepts, because management, and studies in
"pragmatics" tell us that programmers need to fall back on sheer muscle and
primitive operators to deliver quality software.

PL designers and compiler hackers can wax poetic over their achievements in
advancing the art, but the market prefers to keep its investment in time,
money and expertise in current technologies. So what you often see is a lousy
compromise between the Ideal and the Material. Inline assembly, longjmp,
pointer arithmetic, unboxed immediate values, compiler directives and promises
to allow the programmer to tell the compiler how to do it's job, etc.

The people behind Go are industrial PL designers; everything they have ever
done was for immediate, pragmatic reasons. They cloned Multics to make it
cheaper and simpler, doing away with much advanced time-sharing OS research
and taking the bare minimum; what they produced was a multitasking OS for
minicomputers that wasn't that much more sophisticated than the microcomputer
OSes of that day: it was CP/M with a login screen. You can see that theme of
"simple, familiar, fast" running through every piece of software tool Bell
Labs has ever touched after that. They might appropriated a few technologies
from academia, Tcl, SML/NJ, etc. but those were done by researchers brought on
board from the outside. When Bell Labs got too ambitious they produced C++,
not a change in tone, but a crescendo of everything they have been doing.
Worse is Better.

~~~
jrockway
The problem was not that they invented this stuff, but that people took it
seriously. Let's break the cycle with Go.

