Re: [9fans] Re: advantages of limbo

[David Tolpin <dvd@davidashen.net>]

> > The only claim I have found is that reference counting + coloring
> > is better than mark'n'sweep. Given that Java's GC is not mark'n'sweep
> > for a long time already, and the performance problems related to
> > memory management are insignificant since the release of HotSpot,
> > are there any other advantages of limbo over Java?
> > 
> No, at that level of detail I'm really neither competent nor really
> likely to be persuaded that computer languages can be meaningfully
> compared.  When you start going that deep into the architecture, you
> may as well resort to assembler.  At least, I would, largely because I
> enjoy assmebler programming unless the host architecture is positively
> foul.

Unfortunately. limbo the language contains a fix for the  reference-counting
garbage collector. It uses keyword cyclic because garbage collector
needs it. 

> > Besides, are there measured comparisons of Java and Limbo in the
> > area of memory usage and GC performance? My experience with implementing
> > GC in virtual machines is that reference-counting+graph coloring can
> > easily result in slower execution than mark'n'sweep.
> > 
> Again, too detailed to be interesting, in my opinion.  Programming
> languages are notations to express algorithms: the efficiency must lie
> in the algorithms, not the translators (also, in my opinion).

But the efficiency issue of GC technique was the only advantage 
of limbo over Java mentioned in the article. If it cannot be
used, then what are other advantages?

Are there code examples in limbo and Java which can convince someone
that limbo is more convenient?

David