Google's GoLang
Jon Harrop
What are the features of this languages in the context of FP?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Paul Rubin
> What are the features of this languages in the context of FP?
As far as I can tell, it's not relevant to FP in any significant way.
It's sort of like Oberon-2 with C syntax, i.e. an imperative language
with garbage collection and some concurrency features.
Jon Harrop
Oh. I read somewhere that it has first-class lexical closures. I guess that
was tripe... :-(
Andrew Reilly
> Paul Rubin wrote:
>> Jon Harrop <j...@ffconsultancy.com> writes:
>>> What are the features of this languages in the context of FP?
>>
>> As far as I can tell, it's not relevant to FP in any significant way.
>> It's sort of like Oberon-2 with C syntax, i.e. an imperative language
>> with garbage collection and some concurrency features.
>
> Oh. I read somewhere that it has first-class lexical closures. I guess
> that was tripe... :-(
No, it seems to have those (although I don't know how complete they are),
the language just seems to have a lot of classically Modula/Oberon/
Smalltalk-ish mutable object mechanism going on too.
I haven't seen any mention of tail-calls in any of the documentation.
Not that that precludes them getting that right, I suppose.
But on the other hand, the CSP threading model does work best if you
don't mutate the messages, and they say that. So who knows.
I think it's a bit early to go drawing conclusions.
--
Andrew
Jon Harrop
> On Sat, 14 Nov 2009 01:30:13 +0000, Jon Harrop wrote:
>> Oh. I read somewhere that it has first-class lexical closures. I guess
>> that was tripe... :-(
>
> No, it seems to have those (although I don't know how complete they are),
Right. I've found some mention of them by Go's authors but I have little
confidence...
> the language just seems to have a lot of classically Modula/Oberon/
> Smalltalk-ish mutable object mechanism going on too.
Yes.
> I haven't seen any mention of tail-calls in any of the documentation.
> Not that that precludes them getting that right, I suppose.
The language does not mandate TCO, the implementation does not always
perform TCO and the implementors do not value TCO.
Sebastian Sylvan has been desperately trying to convince them of several
basic aspects of language design but his efforts seem to be in vain.
> I think it's a bit early to go drawing conclusions.
Sure. I'm still trying to classify Go amongst other existing languages.
My impression is that its designers rightly hated C++ but threw the baby out
with the bath water by not giving Go references (non-null pointers),
exceptions or parametric polymorphism.
Also, they keep talking about "systems programming" languages but their
examples do not fall into that category IMO, e.g. web servers. In essence,
Google's Go is a DSL bred specifically to build giant distributed web apps
like Google search and it looks as though Go will not be competitive for
other applications. So Go's main competitor is probably Erlang and its main
selling point over Erlang is compute performance.
Andrew Reilly
> Also, they keep talking about "systems programming" languages but their
> examples do not fall into that category IMO, e.g. web servers.
While I'm sure it'll get a lot of mileage for that, I wouldn't write it
off as a useful real, embedded systems language. There's quite a bit of
Lingo in it, and Rob Pike et al managed to build a whole operating
system, its network stacks and device drivers with it. (Inferno, AT&T/
Lucent's follow-on to Plan-9.) Before that, Modula-3 and Oberon have
both been used to write operating systems, and they're in the same
ballpark.
Lots of embedded folk have fits about garbage collection, but it should
be OK, with care. Just a different sort of care than they're used to.
It's not as though memory allocation is recommended inside interrupt
handlers in C or C++ based OSes, either.
Not that I expect Go to be used to build any new operating systems any
time soon. The number of computing devices that don't have the grunt to
run a full Unix (usually Linux) stack is rapidly diminishing (which is
quite a scary thought in its own right, IMO.)
Cheers,
--
Andrew
Paul Rubin
> Not that I expect Go to be used to build any new operating systems any
> time soon. The number of computing devices that don't have the grunt to
> run a full Unix (usually Linux) stack is rapidly diminishing (which is
> quite a scary thought in its own right, IMO.)
Au contrare, the number is increasing rapidly. What do you think the
most common OS in the world is right now? I'd guess Javacard, which
runs on the SIM card of every GSM phone. It ships something like two
billion units a year. Those cards have a few kb of memory tops, and
can't possibly run *nix.
Andrew Reilly
That may well be true today, but in a year or so the couple of hundred
Kib or so required to run a Unix will be smaller than the bond-out pads
to the half-dozen connectors to a sim card. The latest 32-bit ARM cores
are smaller than 8051s. Don't forget that every one of those GSM sim
cards is just providing a bit of authentication info for an air-interface
processor more powerful than a Cray-1, and that is a pale shadow of the
processor that's running the GUI and video decode...
To be sure, bits are bits, and joules are joules, and there will probably
always be a case for the smallest budget possible, but over time the
number of applications where that is the determining factor is
diminishing. Just as the Forest curve describes the number of
applications for which deskops aren't "fast enough", there must be a
similar curve describing the bottom end of the spectrum.
Not that I necessarily recommend Unix for those sorts of applications.
Just an order-of-magnitude observation...
Cheers,
--
Andrew
Jon Harrop
> To be sure, bits are bits, and joules are joules, and there will probably
> always be a case for the smallest budget possible, but over time the
> number of applications where that is the determining factor is
> diminishing. Just as the Forest curve describes the number of
> applications for which deskops aren't "fast enough", there must be a
> similar curve describing the bottom end of the spectrum.
This is an interesting question. I'm not so sure. The Forest curve for
desktops relies upon their (roughly) fixed physical size. Desktops have not
become an order of magnitude smaller since they were invented. Indeed, my
two desktops today are bigger than the desktop I had as a teenager.
However, the world's smallest computers are always shrinking. Desktops
turned into massive laptops which turned into handhelds the the Psion and
then phones like my Nokia. When compute power permits, presumably phones
will lose their keyboards to voice recognition and shrink to the size of a
mic, speaker and battery. But I'm sure we'll find plenty of applications
for smaller compute devices still. Wireless sensor networks and smart dust
will require computers so small that they cannot (at least initially) run a
whole Linux stack.
Then you've got the promising new electronics that are bigger and slower
than the previous generation: polymer electronics with plastic logic.
Mobilities are so low in most polymers that you'll struggle to get even the
most primitive CPUs working with them at all, so your animated interactive
advertising on a packet of cornflakes won't be able to run a whole Linux
stack either. At least not initially. ;-)