Live data from Hacker News

Criticizing Hare language approach for generic data structures

ayende.com

81–90 of 272 posts

Re: Criticizing Hare language approach for generic data structures

#81
post #76

Earlier quoted context omitted.

Rust still considers itself a “systems programming language” . They are moving Rust into the Linux kernel and android drivers. It doesn’t get any more “systems programming” then that. But you are correct about go, it doesn’t give the programmer enough control to be used at that level.

> But you are correct about go, it doesn’t give the programmer enough control to be used at that level. What I like about go is that I can go full unsafe.Pointer if i want to, and do whatever I want. The other thing I really like, is that they did such a good job discouraging it that i frequently hear people complain about go having pointers but not even letting you have fun with them. The problem isn't that go doesn…

I think that being garbage collected is exactly the control problem in question.

I'm no a systems programmer unless you count hobby microcontroller projects, but my understanding is that, when a systems programmer is talking about control, they tend to be talking first and foremost about keeping tight limits on memory usage. Pointers and suchlike just happen to be key tools that help you do that.

Re: Criticizing Hare language approach for generic data structures

#82
post #34

Earlier quoted context omitted.

Linked list has a O(N) search time, which is atrocious. A really common optimization is to replace a linear scan on a list with a hash table. In most languages, that is a trivial step to do, which means that it gets done. There isn't any overhead. With hare, you just blew your complexity budget on this thing.

It's not atrocious unless you need the performance. A linked list with a hundred items which is scanned every 90 seconds or something does not really demand attention for optimization, but it will be simpler, easier to write, easier to understand, and easier to debug, and those are wins are not to be sniffed at. And for the record, Hare does have built-in growable slices, so linked lists are pretty rare in Hare. They…

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.

Re: Criticizing Hare language approach for generic data structures

#83

I don't get this guy. He's just raging. I agree a hashmap is not simple and Hare's post is a bit naive, but I don't get what's his problem with the language not providing a default implementation. It's part of the language's design. It's targeting people that most likely won't need a hash table. It's not aiming to be a high-level batteries-included language like Java.

I think that even the mere fact that there are a billion implementations of a hashmap kind of implies that a hash table _is_ a simple data structure, that you may complicate in a bazillion ways in order to cater for some specific usecase / requeriment. But at it's core, a simple data structure.

Why assume that? The specific points in the post appear to be common to all implementations: implementing hashing for example.

Re: Criticizing Hare language approach for generic data structures

#84

Earlier quoted context omitted.

It's not atrocious unless you need the performance. A linked list with a hundred items which is scanned every 90 seconds or something does not really demand attention for optimization, but it will be simpler, easier to write, easier to understand, and easier to debug, and those are wins are not to be sniffed at. And for the record, Hare does have built-in growable slices, so linked lists are pretty rare in Hare. They…

Do you remember what the reason that you went with a linked list in that case? I’ve been learning hare and was curious about where to use them. Also, did you use a nullable pointers to represent the next node element in the linked list? Or a tagged union of ( ptr | void)? Or something else?

Yep. I used it in a kernel to create a linked list of statically allocated data structures in a context where dynamic allocation was off the table. You can see the code here:

https://git.sr.ht/~yerinalexey/carrot/tree/master/item/conso...

Went with nullable pointer types, which is also a rarely used feature in Hare.

Re: Criticizing Hare language approach for generic data structures

#85

Earlier quoted context omitted.

There's a mature open source library for them packaged for Arch and other distros. Using that would be less work than trying to implement it from scratch.

Are you suggesting there aren't mature implementations of hash maps in C you can easily vendor?

What does “vendor” mean in this context? Is it just a synonym for “distribute”?

Re: Criticizing Hare language approach for generic data structures

#86
post #76

Earlier quoted context omitted.

Rust still considers itself a “systems programming language” . They are moving Rust into the Linux kernel and android drivers. It doesn’t get any more “systems programming” then that. But you are correct about go, it doesn’t give the programmer enough control to be used at that level.

> But you are correct about go, it doesn’t give the programmer enough control to be used at that level. What I like about go is that I can go full unsafe.Pointer if i want to, and do whatever I want. The other thing I really like, is that they did such a good job discouraging it that i frequently hear people complain about go having pointers but not even letting you have fun with them. The problem isn't that go doesn…

[deleted]

Re: Criticizing Hare language approach for generic data structures

#87

Earlier quoted context omitted.

BYOD combined with "we don't need a package manager" sounds like a particularly bad combination. I understand Rust's "small stdlib but great package ecosystem", but whats the appeal of "anemic stdlib plus no package ecosystem"? Maybe I would come up with something like this if I only ever worked on Linux software using C, but outside those niches these choices seem weird.

I question the assertion that Hare's standard library is "anemic"; it includes a pretty decent set of batteries for many use-cases: https://docs.harelang.org Many Hare programs will not need to have dependencies at all. We encourage a more conservative approach to dependencies than is common in many modern languages such as Cargo, PyPI, npm, Go, etc. Even dependency-heavy Hare projects will not have hundreds of depen…

That does look like a decent collection of functionality, but a HashMap as mentioned in the submission seems like a pretty glaring omission. I can't remember the last time I wrote a program that didn't use a Map. Even dynamic languages that tend to be quite light on types almost universally include a map type.

I can definitely see the problems with the Node "explosion of modules" approach, but if we're looking at fixing issues with C then IMO "everyone implementing their own data structures and not always with the care and attention they deserve" is right up there with things like lack of proper arrays/strings and poor null handling.

It seems like it ought to be possible to find a middle ground where dependencies are easy to find, install, update and integrate with a standardised build system, but where there is a cultural norm of being conscious of dependency size and not using micro-dependencies

Re: Criticizing Hare language approach for generic data structures

#88
post #31

Thanks for writing this up, though I feel that it may be a bit premature since at this point hardly anyone has any real experience writing Hare code. Regardless, I understand that this is a contentious design decision of Hare, so I would be happy to explain in it in more detail. We have discussed adding first-class maps to the language many times. We recognize the value in this feature and have tried to come up with…

I think that there is a problem here with regards to what you are trying to do. You are conflating the _implementation_ of a hash table with the _existence_ of a hash table. You list a few problems: Computing the hash for arbitrary structure & check equality of the hash is something that you can do by adding a func in the creation of the map. That will likely add overhead (since you can't inline it, and most of them…

>You were able to "get away" with implementing a pretty bare bone thing, but you called it out as something that should be viable in general.

I can see how you had this impression from the language of the blog post, but what I meant to express is that the approach generalizes, even if this specific code does not.

>The web is full of those (response and request headers, query string parameters), data formats (JSON is basically a hashtable plus some fancy pieces) , caches (that are just hash tables), etc.

The web generally falls well outside of the target use-cases for Hare.

Re: Criticizing Hare language approach for generic data structures

#90

Earlier quoted context omitted.

Do you remember what the reason that you went with a linked list in that case? I’ve been learning hare and was curious about where to use them. Also, did you use a nullable pointers to represent the next node element in the linked list? Or a tagged union of ( ptr | void)? Or something else?

Yep. I used it in a kernel to create a linked list of statically allocated data structures in a context where dynamic allocation was off the table. You can see the code here: https://git.sr.ht/~yerinalexey/carrot/tree/master/item/conso... Went with nullable pointer types, which is also a rarely used feature in Hare.

Cool, thanks for the link and info
Post reply on HN