DeVault: Announcing the Hare programming language

Sort is interesting because it says it is (or at least, that it might be, and since this isn't 1.0 let us assume it is) an allocating sort, but it doesn't say whether it's stable. I presume it's a stable sort.

I feel like the kind of people who might actually care about the micro-managing needed to be effective in a language like Hare probably want at least the option of an in-place (ie not allocating) sort, even if it's unstable. After all, if you're actually sorting, say, integers, you certainly don't care about stability but you might care about the allocation cost.

Hashtables are hard, and there is a lot of opportunity to either malfunction or mistakenly destroy your performance, which is a reason that Rust - which (contrary what is sometimes suggested) actually mercilessly weeded out less useful or necessary data structures for the standard library in 1.0 - still has HashMap and HashSet long after special use structures like LruCache were put out to pasture. You're going to implement HashMap<Key,Value> and once you've done that why not HashSet = HashMap<Key,()> and do the extra lifting for the set-like methods ?

The "modcache" built in the Hare example is an old-school bucketed hash, but with a fixed number of dynamically growing buckets. I assume that in practice Hare would work fine with just a simple vector here anyway, but if not "modcache" is leaving a lot of performance on the floor. In the process of doing that, it also seems to have a nasty bug. If we have two modules with identical hashes (not difficult to arrange for the hashes provided with Hare, there is no SipHash) then it seems to me that ...

if (bucket[i].hash == hash) {return bucket[i].task; }

... never checks this is actually the same module, only that it has the same hash.