And before you tell me that the GC isn't that big a deal: it is. Literally every big project I've worked on in a garbage collected language reserves a bunch of memory off-heap at startup and uses that for allocations on the critical path because the GC kills performance.
You could replace occurrences of GC with malloc, switch the language to C, and it would be just as factual. Basically, what the author is saying is equivalent to, "Real projects have to optimize." Well, yes. This isn't deep. It certainly isn't surprising, and it doesn't strike me as a good reason for not learning a language.
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.
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).
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.
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 replace occurrences of GC with malloc, switch the language to C, and it would be just as factual. Basically, what the author is saying is equivalent to, "Real projects have to optimize." Well, yes. This isn't deep. It certainly isn't surprising, and it doesn't strike me as a good reason for not learning a language.