Python & Go

[John Nagle]

sturlamolden wrote:
> On 12 Nov, 01:53, kj <no.em... at please.post> wrote:
>> I'm just learning about Google's latest: the GO (Go?) language.

     It's interesting.  The semantics are closer to Java than any other
mainstream language.  While Java usually is run with a "virtual machine",
Go is more like Java hard-compiled (which you can do with GCC.)

     It's far less dynamic than Python, which is good for performance.
(That's not an inherent problem with Python. It's a problem with the
CPython implementation.  See Shed Skin.)

     The declaration syntax is borrowed from the Pascal/Modula/Ada
family of languages, and it's an improvement over the C/C++ approach.
I suspect that Go is LALR(1), which means it can be parsed with a
simple context-independent parser.  C and C++ are very difficult to
parse, and modules can't be parsed independently.  (Because of the
C/C++ type syntax, you have to look up type names to find out how
to parse declarations. So the include files have to be present
to parse declarations.  This is why there aren't many tools that
manipulate C and C++ source code.)

     Having concurrency in the language is a win.  Syntax for queues
is a minor win. But the language doesn't directly address the issue of "who
locks what".  There are shared variables, and mutexes, but the language doesn't
let you talk about which variables are shared.  When the language doesn't
know that, you either have to restrict optimization (as in Python) or have
painful mechanisms like "mutable" as in C++.

     Leaving out exceptions was a mistake.  Exceptions are well understood now,
and they're far better than the usual "ignore errors" approach one sees in lamer
C programs.

     The interface mechanism is simple enough.  In a static language, you can
convert "duck typing" to inheritance at link time, when you have the chance
to see what can match what.  So the implementation doesn't actually have to
search for a match at run time.

					John Nagle