Re: [dev] [OT]: Go programming language

From: frederic <>
Date: Sun, 15 Nov 2009 14:24:41 +0100

> On Sun, Nov 15, 2009 at 12:43:46PM +0100, Szabolcs Nagy wrote:
>> On 11/15/09, frederic <> wrote:
>> and sacrifices some efficiency to have a few higher level language
>> features (gc, interface, string, map, package, init, defer, closure..)
>> as a bonus it has multi tasking support (go, chan, select), good
>> library support and stricter semantics
> Be careful what you say. None of those features necessarilly sacrifice
> efficiency. In fact, garbage collection can be a huge performace boon
> when implemented properly, in that garbage can be lazily freed in hunks
> and with minimal locking.

Compared to your grand-daddy's GC? Obviously yes. But no GC language has
yet prevailed against C in benchmarks.

> Interfaces and packages are free, as far as performance is concerned,
> though implementations may vary.

It seems to me that there's virtual tables behind interfaces, which means
one level of indirection.
It may be cheap compared to the provided facility, but it's not free.

> C strings are slow when you need to get their length.

It's not a win-all situation. Immutable strings may be more expensive in
some use cases.
Furthermore, they either have to convert back to zero-terminated strings
when passing them to libs, or use the trick of appending ("quand mÍme") a
zero byte, which is redundant wrt to the array lenght.

> Closures needn't be any more expensive than any other kind of function
> reference,

One has to pass at least an extra parameter, which is a pointer to the
captured values. It is always more expensive than passing a pointer to a

All this is more than just nit-picking. Pike claims a 10-20% loss compared
to C, which would still be quite good. However, the first benchmarks tell
another story at the moment:
Received on Sun Nov 15 2009 - 13:24:41 UTC

This archive was generated by hypermail 2.2.0 : Sun Nov 15 2009 - 13:36:02 UTC