vs. Limbo

729 views
Skip to first unread message

Bug Q.

unread,
Dec 16, 2009, 12:13:08 PM12/16/09
to golang-nuts
Hello clever friends!

This "new language" seems to be built on quite a long legacy. ;) I
think I could easily teach myself Go and definitely admire its
approach, but since I've had my eyes set on Limbo/Inferno for a good
while as the platform for a big project, I'd much rather put aside the
rest of my worries as simply as possible. Could I ask someone
qualified enough to shortly compare their design choices and overall
"feel" (idiomology, expressiveness etc.)?

Many thanks,
Bug ('^.^')`

Bug Q.

unread,
Dec 17, 2009, 4:10:56 PM12/17/09
to golang-nuts
OK, I'm assuming that no one wanted to answer me; that's fine.
Maybe it's obvious, or maybe I was a bit presumptuous or vague.

If you'd bear with me, though, I'd like to pry a little deeper!
I'm not terribly experienced in the nature of compilers,
so I'll just start off by describing what I can already see:

Obviously, Go is newer and faster, whereas Limbo is portable-r.
Limbo already has a debugger, but Go is being ogled by many.
The way coroutines are scheduled appears to be quite similar.
Go has a more C-like syntax, but Limbo's is easier to read (imo),
and they have very few differences in semantic structure.

In fact, I wonder how much could be done toward a translator...
so to rephrase my question: precisely what would impede me
from systematically translating code between these languages?
(Theoretically, since I know the environment & libraries differ.)

I'd appreciate anyone clarifying any of my observations, too.
Otherwise, I guess I'll just keep digging...

Thanks again,
Bug

Rob 'Commander' Pike

unread,
Dec 17, 2009, 4:57:13 PM12/17/09
to Bug Q., golang-nuts
Limbo was intended as a sort of scripting language for connecting
components inside a set-top box. It matured enough to be usable for
general programming under restricted situations. Go has a broader
ambit.

I haven't used Limbo for over a decade, but the last time I did, it
was still single-threaded. Concurrent, yes, but the interpreter (yes,
it is interpreted, although it has an unsophisticated what-we-now-call-
JIT) needed to run on a single what-we-now-call-core. That may have
changed, but I doubt it; the implementation must become significantly
more sophisticated to run correctly on multi-core computers.

Go is a true compiled language, with run-time support for higher-level
stuff such as concurrency. But it is also, from day one, designed for
multi-core machines.

-rob

Russ Cox

unread,
Dec 17, 2009, 7:50:16 PM12/17/09
to Bug Q., golang-nuts
> Go has a more C-like syntax, but Limbo's is easier to read (imo),
> and they have very few differences in semantic structure.

Having written a modest amount of code in each,
I can say that they are much more alike syntactically
than they are semantically. They're very different languages.
They share select and channels but almost everything else
is different in important ways.

The comment that they "very few differences in semantic structure"
is simply not true.

> In fact, I wonder how much could be done toward a translator...
> so to rephrase my question: precisely what would impede me
> from systematically translating code between these languages?

The languages are much more different than you think.
It would be quite a bit of effort. The Inferno VM is tuned
for running Limbo, not other languages, just as the Java VM
is tuned for running Java, not other languages. Running Go
on either would require new VM instructions to do well.

Russ

Reply all
Reply to author
Forward
0 new messages