Forcing allocations for every node isn't justified by a desire to demonstrate dynamically sized binary trees. A naive dynamically-sized tree would just keep a list of node buffers and allocate a new node buffer every time the previous one fills up (perhaps with subsequent buffers doubling in size). The benchmark is, by all appearances, contrived to be slower.

https://news.ycombinator.com/item?id=28274485

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).

It will intentionally use more memory for the sake of throughput, hence why this post has all .NET program flag for it, as it's a _speed_ benchmark primarily.

Tons of very "interesting" attributes like this:

    // prevent inlining into main to decrease JIT time to generate main
    [SkipLocalsInit][MethodImpl(NoInlining)]

    [SkipLocalsInit][StructLayout(LayoutKind.Explicit, Pack = 32)]

    [SkipLocalsInit][MethodImpl(AggressiveOptimization | NoInlining)]

    [FieldOffset(32)]

Not to mention that the entire file is using explicit vectorization, which I consider to be a very high degree of optimization -- tons of software never bothers to implement explicit vectorization, and does just fine.

If all of this is "nothing out of the ordinary", then "ordinary" C# has changed a lot since I last spent much time with it.

[0]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

At the time I was hired, it was to modernize an Access application used internally, to try to sell it as a product.

.Net was still in beta at the time (this was early in 2001). I figured I might as well go with the flow and try it out.

It was a crazy ride, and I've since left the company ... but we went through every version from beta through 4.8 before I left.

I'm now using .Net 5 in Azure to power my new company's REST APIs.

Avoid vscode for C# development, unlike TS/JS (which is top of the line), the support for C# even in core is toy level.

I've always thought the whole ecosystem looked really productive, and the code I've had to review occasionally looked well structured and readable. But when I was starting out MSDN cost a fortune and I've never really considered trying to learn it.

https://0x85.org/csharp-emacs.html

Seems pretty simple. Though the binary size is definitely not on par with go.

p44 "Oberon — The Overlooked Jewel" Michael Franz, in "The School of Niklaus Wirth".

https://www.google.com/books/edition/The_School_of_Niklaus_W...

I very much want my computer to work as hard as it can to make my code more performant for free. What I would like to see more is a separate debug and release build mode, where the former can go as fast as it can without optimizations, while the latter can be as slow as it wants and result in the most optimal binary it can produce. Zig does that for example.

At the very least, I couldn't realistically re-run some of the example benchmarks from the source embedded in the HTML, because they did not include vendoring/version information for external packages they depend on. That made me doubt the provenance of https://salsa.debian.org/benchmarksgame-team/benchmarksgame.