Hacker News Reader

Comment by smanek | Hacker News Reader

It's different, because I'm saying that much system level work has to optimize by not using a garbage collector. I've literally implemented off-heap malloc()/free() in Java because GC is so untenable.

I argue that makes a language with has a GC that you can't avoid (as far as I know, it's impossible to allocate an 'object' off-heap in Go) a fairly poor choice for much system level work.

Which means, if Go is to find a niche, it's got to be at a 'higher-level.' And that requires competing more directly against Java or Python - a much higher bar than trying to be better than C.

View on HN

I don't think you're getting his point. I can still replace GC with malloc() and we end up with the same criticisms of C that you have of Go and Java.

> I'm saying that much system level work has to optimize by not using malloc(). I've literally implemented off-heap malloc()/free() in C because malloc() is so untenable.

Anyone who has had to write fast C programs that make a lot of small objects eventually ends up here. You end up incorporating some sort of pool based allocator, which I'm sure you can come up with in Go just as you can in C (or Java, or whatever).

Outside of professionals and core contributors who write performance critical C, most folks haven't done a whole lot of work with a profiler with C programs. One doesn't get performance for free. It's paid for in some way, shape or form. The only thing that's up for grabs is how and when you pay for it. The costliest form of payment is developer hours, which you try not to pay if you can avoid it, though you sometimes can't avoid it.

You could make the same kind of criticisms, but not with the same strength. there are real quantitative differences between the speed of explicit malloc/free and even a really nice garbage collector. (Unless you have a very special allocation pattern, like a whole lot of short-lived allocations and a generational garbage collector that uses stop-and-copy for the nursery generation. That's like the best possible case for GC.)

1 - a whole lot of OO and functional Lisp programs use your "very special" pattern of short lived allocations.

2 - You can rig the game so generational GC beats malloc/free.

3 - It's not a criticism, it's a general principle. One always pays for performance. If your performance requirements are low enough, you can even take out a loan on them, so to speak, by using a more expressive language.

Reply on news.ycombinator.com