bst VS ixy-languages

If you like this article then you might also be interested in: https://github.com/c-blake/bst interesting

It's ANSI C with a bespoke macro generics system not Go, does not cover as many balancing rules, and is not written up as nicely. It does do something only weakly represented in your Go impls, AFAICT - "binary symmetry" - the reflection about left-right intrinsic to most ideas in this area. (Mehlhorn has a book that does this, but that is the only other source I know.) It also has API considerations like seek-edit separation and how to handle in-tree duplicate key FIFO/LIFO/etc (as opposed to values which are also collections).

Also, Re: B-trees among several comments - edit heavy B-trees with large nodes (driven by IO bandwidth-delay products) need some "mini-scalable" structure for their nodes since shifting (on average) half the entries can cost. That mini-scale could be another B-tree or it could be a binary search tree, perhaps adjusted to have 2-byte sized pointers into the little arena that is a node if 64Knode is enough. I once heard Sybase (now Microsoft SQL Server?) used skip lists. Anyway, this may be a remaining use case for binary trees even in the presence of a B-tree.

While I agree the common pattern is to use void*/dynamic dispatch, this is not necessary. E.g., https://github.com/glouw/ctl/ or https://github.com/c-blake/bst show a couple ways to have generic code statically specialized in regular old C.

Not really, here it is winning hands down over Swift's ARC implementation.

https://github.com/ixy-languages/ixy-languages

You laugh, but ... https://github.com/ixy-languages/ixy-languages

GC'd languages are designed to leverage GCs, meaning they usually allocate a lot. Some of the more recent ones (C#, Go) have ways around it or to limit it, but in your average GC'd language you have to really bend yourself out of shape to limit allocations (IIRC the Ixy effort / study / thing never managed to make the Java hotpath allocation-free).

It's kind of funny when you see things like this project: https://github.com/ixy-languages/ixy-languages

like not-even-in-the-same-ballpark faster. In this realworld example (userspace network drivers in managed languages) JS manages about 20-30% of native code performance, python iirc is below 1%

- Support for generic-aware value types (struct vs. class) and low-level features like stackalloc: very valuable for high-performance scenarios and native FFI. See for instance https://github.com/ixy-languages/ixy-languages. In comparison, Java doesn't even have unsigned integers. Yes, Project Valhalla is coming someday.

As well, debatable to some folks, but: properties (get/set); operator overloading; LINQ > Java streams; extension methods; default parameters; collection initializers; tuples; nullable reference types; a dozen smaller features

Very bottom of this file https://github.com/ixy-languages/ixy-languages/blob/master/Java-garbage-collectors.md