Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

“It’s not a bad benchmark, it’s just showcasing a contrived scenario with different sets of rules for different kinds of languages”.

Most people aren't building applications whose business requirements preclude preallocating memory except for languages which lack garbage collectors.



So those are scare quotes not actually quotation?

If we don't experience a performance problem, we don't need a workaround.


No, that’s not an actual quotation. I was having a laugh at the silly logic which attempts to justify the benchmark. And preallocating isn’t a workaround, it’s idiomatic in Go.


That is not a contradiction: it can be both idiomatic in Go and a workaround to avoid garbage collection.


And that’s a valid point for the set of applications whose purpose is generating garbage. But overwhelmingly this isn’t interesting and people mistake this benchmark for a useful indicator of programming language performance in the general case.


And the set of applications that will inevitably generate garbage, which might be left to automatic garbage collection.

Errare humanum est.

"Energy Efficiency across Programming Languages" not "programming language performance in the general case".


It’s not a very compelling defense of a benchmark to argue that it measures something different for some languages than others—in this case for Go the benchmark measures poorly/carelessly written code while for other languages it measures meticulously optimized code.

I maintain a contrived benchmark is not a useful benchmark.


In this case for Go, the same as other languages that provide automatic garbage collection.

In this case for Go, the same as other languages that provide a library pool implementation.

Apparently the study authors found a use.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: