[throwaway894345]

So what about C, Rust, and C++? They’re all allowed to use bespoke pools and custom allocators. The fastest Rust implementation imports an allocator crate. No doubt you can lawyer the rules to make sure Go still appears slow, but in reality this benchmark doesn’t tell you anything about the language’s general performance because while Go’s allocator is slower, idiomatic Go allocates much less frequently than other languages, but this benchmark prohibits idiomatic optimizations. Moreover, there isn’t a benchmark that shows gc latency, which is the flip side of the allocator coin. So if you really want to die on the hill of “worthless but well-lawyered benchmark rules” be my guest.

[igouy]

What-about-ism.

https://golang.org/doc/faq#garbage_collection

> They’re all allowed to use bespoke pools and custom allocators.

No. They are allowed a library memory pool.

As-it-says: 'Please don't implement your own custom "arena" or "memory pool" or "free list" - they will not be accepted.'

> … while Go’s allocator is slower…

So that tiny tiny program shows it's slower because it's slower.

[throwaway894345]

> What-about-ism.

Not sure what you're referring to here.

> No. They are allowed a library memory pool.

Yes, this is a contrived rule. In reality, a Go developer would write the extra ~dozen lines (all of the heavy lifting done by the builtin slice implementation) and call it a day.

> So that tiny tiny program shows it's slower because it's slower.

Tautology. It's slower because the contrived rules preclude idiomatic optimizations.

My point is that these contrived benchmarks don't indicate anything about the relative performance of these languages, but you keep responding with some variation of "but Go is slower in these benchmarks!" which everyone already agrees with. So unless you're going to actually address the point, I don't see the point in continuing on. It feels like you're hell-bent on using this thread for your personal programming language holy war, which is disinteresting to me (see again my first post) and against the site rules.

[igouy]

> … a Go developer would write the extra ~dozen lines…

And a C# developer could write a program that would avoid GC, and a Java developer…, and…

It feels like you're hell-bent on using this thread for your personal programming language holy war…

[throwaway894345]

> And a C# developer could write a program that would avoid GC, and a Java developer…, and…

Are those idiomatic? If so, then they should be permitted to apply those optimizations. Again, the whole point of benchmarks is to indicate real-world use.

> It feels like you're hell-bent on using this thread for your personal programming language holy war…

I've reiterated my substantial point over and over again ("contrived rules don't indicate real world use, which is the definitional purpose of benchmarks") and you still haven't addressed it. But in any case, perhaps if both of us think the other is waging a holy war, it's an indicator that the thread has run its course.