Hey, Google go b-tree implementation author here. A few important things:<p>- this implementation was done by me while I worked at Google and needed a good ordered tree. It is not and never was supported by Google, just open sourced by the company and written on company time.<p>- it now supports generics! Actually, iirc it did almost at the time that this article came out. In go 1.18 and higher, the original API uses a specialization of the generic underneath.
Discussed at the time:<p><i>Making Faster B-Trees with Go Generics</i> - <a href="https://news.ycombinator.com/item?id=31182645">https://news.ycombinator.com/item?id=31182645</a> - April 2022 (44 comments)
This may be confusing to those familiar with Google's libraries. The baseline is the Go BTree, which I personally never heard of until just now, not the C++ absl::btree_set. The benchmarks aren't directly comparable, but the C++ version also comes with good microbenchmark coverage.<p><a href="https://github.com/google/btree">https://github.com/google/btree</a><p><a href="https://github.com/abseil/abseil-cpp/blob/master/absl/container/btree_set.h">https://github.com/abseil/abseil-cpp/blob/master/absl/contai...</a>
This feels like such a non-news. They've pretty much created a language which is deliberately dumbed down to be 20 years behind other languages, then they are proud that they could speed it up with a feature that was fairly well-known almost 20 years ago.<p>Also the obsession with not providing tools for the programmer to use the stack, and rely on compiler internals to not heap-allocate everything.
The headline is dismal. Now writers can’t even be bothered to write what the improvement is? 40% of ______? “…Just trust us, 40% of something is ‘shaved’ …it’s good we promise.”
Another way of seeing it is that "40% of the code became imaginary", in the sense that you have to figure out what the macro is expanding to.<p>I'm not against generics. I was just wondering myself in a boring afternoon :)