Hacker News Reader

Comment by cromwellian | Hacker News Reader

Delegation can have a performance cost that inheritance doesn't have however, at least, depending on the compiler. Go's current compiler seems engineered for correctness, not performance, at least last time I checked, the JVM was beating it on several benchmarks.

View on HN

Go seems to be headed towards pretty fast and predictable performance rather than the fastest possible performance at the expense of predictability. (For example, the work to replace segmented stacks with contiguous stacks improves performance in some cases but also makes function call performance more predictable.)

A JVM can have fast or slow performance depending on JVM flags, warmup time, and the phase of the moon.

Not really bashing Go, but I was was disappointed that for what is purportedly a 'systems programming language', performance was far behind C/C++/D/Mars/etc. I expect a little more from a statically ahead-of-time compiled language.

For 80% of apps, that's just fine, but would you write a mobile web browser in Go, or say, Call of Duty? Seems you'd be leaving 50% performance on the table in some scenarios.

I tend to give 'systems programming language' special status. They're how you achieve maximum system performance if not writing in assembly. You write kernels, device drivers, virtual machines, and games in them. If they are imposing severe performance or memory overhead, then they are application programming languages, not systems programming languages.

I think the messaging around Go has changed a bit since it was originally introduced. If you look at the front page of golang.org, it doesn't talk about Go as a systems programming language. I do remember the way it was pitched initially, but I agree with what you're saying and think that even the Go people themselves wouldn't lump Go in with C for things like kernels or leading edge games.

Depending on the language, delegation can be faster. For instance in C++, virtual function dispatch is slower than calling a non-virtual member. It is easier for the compiler to optimize member function calls vs virtual functions which cannot be inlined.

If the compiler does global optimizations, it can infer when virtual functions aren't really virtual. For example, if a virtual function is never overridden, or never overridden by any live type (after dead code removal), then it can be implicitly converted to a non-virtual function.

Since C++ doesn't have interfaces, only pure virtual functions, you'll pay the cost of the virtual dispatch, even if you use delegation, won't you? (The context of my comment is the use of interfaces, with implementations using delegation instead to do implementation inheritance)

e.g.

interface I

class Concrete implements I

  delegate to Shared

class Concrete2 implements I

  delegate to Shared

Yes, if you don't use any interfaces at all, and just a concrete class, then it's a different situation.

Reply on news.ycombinator.com