[igouy]

> absolutely idiomatic and trivial optimization

Which is not accepted for the C# programs either.

sync.Pool is accepted —

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

> the Go version is expressly contrived to be slower

The requirements were contrived in April 2008.

afaict Go initial release was March 2012.

[throwaway894345]

> Which is not accepted for the C# programs either.

Because C# doesn't benefit from this kind of optimization. Its GC is generational, which means that it has very fast allocations at the expense of high latency. In most applications, lower latency is more important than slower allocations (not least of all because these batch-allocating optimizations are nearly trivial), but these benchmarks don't reflect that at all.

> The requirements were contrived in April 2008. afaict Go initial release was March 2012.

Contrived = "the rules artificially prohibit idiomatic optimizations". It doesn't require that the maintainers have a prejudice against Go (although as you point out, the maintainers have had a decade to revisit their rules).

[igouy]

> Because C# doesn't benefit…

C# does provide a memory pool implementation.

[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…