Criticizing Hare language approach for generic data structures

Re:Criticizing Hare language approach for generic data struc... by ben-schaaf on Wednesday May 04, 2022 @08:42AM (#31259626)

For sure there's plenty of circumstances where you don't need more performance, but you can't seriously argue re-implementing another linked list is simpler, easier to write, easier to understand or easier to debug than `std::vector`/`Vec`. Multiple allocations and setting up pointers is certainly more complex than allocation/copy. It's most definitely easier to write because you're not writing it, someone else already has. It's easier to read because there's a whole lot less of it. And a single contiguous allocation is way easier to debug.

[ Parent | on HN ]

Re:Criticizing Hare language approach for generic data struc... by tialaramex on Wednesday May 04, 2022 @09:40AM (#31260218)

My impression, although it was difficult to be sure, is that Hare's "slices" (or maybe arrays?) are actually vectors, in at least some cases.

It seems you can grow them by appending, so they aren't like Rust's slice which is non-owning or a typical array which can't grow.

I suspect a Linked List is actually almost never the right shape for a data structure in Hare, because you should just use these vectors to do that.

The two actual rationales for Linked List in the 21st century (other than "I was writing C and I don't know what I'm doing") are: 1. Concurrency, Lock Free and sometimes even Wait Free algorithms are practical for Linked List and the other costs pale into comparison on highly contended data structures and 2. I'm doing some serious acrobatics with huge lists, I constantly perform split/ merge operations and so those being cheap is crucial. Hare doesn't have concurrency, and nobody should attempt such acrobatics in a language this dangerous.

[ Parent | on HN ]