What's the problem? People will just use libraries. Why does it need to be part of the base language? Seems like that made C++ quite a mess in fact, while NPM-like ecosystems have done well.
The problem is that you can't properly implement data structures for a statically typed language in libraries without some kind of generics. You can try with explicit casting to void* or whatever Hare uses, but that comes at the cost of type safety.
The entire post is a reply to [1], which mentions the exact code the OP criticizes. Drew said "Hare doesn’t provide us with a generic hash map, but we were able to build one ourselves in just a few lines of code", but the OP demonstrates that hash map is incorrect.
So... people will just use libraries that have a correct implementation?
Lots of C++ compilers shipped STL implementations with atrocious performance (and outright bugs) for like a decade. It's not like putting something in the standard library guarantees correctness or performance.
> So... people will just use libraries that have a correct implementation?
The entire issue is that the language does not allow for that: like Go (pre 1.18) it does not have userland generics. And unlike Go it doesn't even have a builtin hashmap, only arrays and slices.
C doesn't have userland generics or built-in hashmaps, and there are plenty of hash map implementations in libraries out there (glib, apr to name just a few). Yes, they obviously don't have the type safety that generics enable. But the fact that an implementation of a hash map data structure was buggy doesn't mean that all other implementations will be. And, as those of us who used C++ back in the early '00s very painfully remember, generics support and an authoritative implementation don't guarantee you get good generic data structures, either.
Edit: plus, realistically now, the article's criticism revolves around shortcomings of a particular implementation of a hash table. If Hare had generics, and a hash map implementation in the standard library, and that implementation used the same hashing algorithm and made the same assumptions (e.g. no key collisions), all that criticism would still hold. You can find poor implementations of any data structure in any language.
The issue is _generic_ data structures, not external code.
If I have to re-create a hash table for each scenario, I'll not invest the proper time to do so.
So if I need a hash table to map inodes to strings and another to map strings to IP addresses, I'll need to create that anew each time.
That means either writing a lot of code twice, or relying on manual code generation (which sucks for many reasons).
No support for generics or custom allocators, combined with no desire to implement a package manager. The language author accepts that (1) Hare is just as limited as C and (2) C has no way of implementing a good hash map.
> Recall that Hare is designed to be similar to C in terms of scope and goals. C also provides no general-purpose hash map, and little by way of other data structures (though some attempts exist, none of them good).
So you're stuck using a crappy general-purpose hash map that you have to convince your linux distribution package managers to maintain.
