Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Criticizing Hare language approach for generic data structures

ayende.com

Post reply on HN
Print view View original

41–50 of 272 posts

Re: Criticizing Hare language approach for generic data structures

#41

Post by one-more-minute »

formerly_proven wrote: post #2

"Bring your own datastructures" is likely one of the C carry-overs for Hare. If you think about many "classic" C applications, a lot of them basically only exist around/for one or a few data structures (e.g. most servers, many utilities etc.). In that context BYODS is somewhat defensible: If you don't care to implement the data structure, why does your application exist in the first place? But that's not "modern" app…

Rust and Go seemed to initially want to target C programmers [1], but ended up capturing users from higher level languages – even Python and such – who wanted better performance and more control, because they had so many affordances.

Hare clearly isn't like that: it's _actually_ aimed at (FOSS) C programmers, almost stubbornly so, and isn't going to appeal to many others. But for those people I can see C-with-tagged-unions being an improvement, and there's value in finding the minimal diff that makes a language better.

[1] Remember when Go called itself a "systems programming language"? Neither community seems to use this phrase any more, though.

Re: Criticizing Hare language approach for generic data structures

#42

Post by flohofwoe »

This reads like a rant of a person caught too much in their own bubble, a bubble in which hash maps seem to be of extreme importance. I've coded a lot of C in the past few years, and I can count the number of times when I would have actually needed a proper high performance hash map with all bells and whistles on one hand. A piece of code where hash map lookups are so frequent that it becomes a performance bottleneck is either badly designed, or a special case which needs a very careful implementation.

Builtin hash maps are convenient for "dictionary languages" like Python or Javascript, but beyond that they are highly specialized and tailored to specific data sets and hardware properties.

Re: Criticizing Hare language approach for generic data structures

#43

Post by sedeki »

ayende wrote: post #15
sedeki wrote: post #11

Earlier quoted context omitted.

How is it possible that the design of a language do not allow for external code/libraries?

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).

Right, I take my question back

Re: Criticizing Hare language approach for generic data structures

#44

Post by remus »

_trackno5 wrote: post #27

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.

Maybe it's just the problems I work on and the code I write, but I use hash maps all over the place. Having to write my own sounds like a total pain in the ass, it'll almost certainly not be as performant and/or have some subtle bugs to figure out.

I guess Im not the target audience for the language, but the lack of basic data structures like this adds a lot of friction for me.

Re: Criticizing Hare language approach for generic data structures

#45

Post by alxlaz »

masklinn wrote: post #19
alxlaz wrote: post #16

Earlier quoted context omitted.

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.

Re: Criticizing Hare language approach for generic data structures

#46

Post by celeritascelery »

one-more-minute wrote: post #41
formerly_proven wrote: post #2

"Bring your own datastructures" is likely one of the C carry-overs for Hare. If you think about many "classic" C applications, a lot of them basically only exist around/for one or a few data structures (e.g. most servers, many utilities etc.). In that context BYODS is somewhat defensible: If you don't care to implement the data structure, why does your application exist in the first place? But that's not "modern" app…

Rust and Go seemed to initially want to target C programmers [1], but ended up capturing users from higher level languages – even Python and such – who wanted better performance and more control, because they had so many affordances. Hare clearly isn't like that: it's _actually_ aimed at (FOSS) C programmers, almost stubbornly so, and isn't going to appeal to many others. But for those people I can see C-with-tagged-…

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.

Re: Criticizing Hare language approach for generic data structures

#47

Post by 0des »

celeritascelery wrote: post #46
one-more-minute wrote: post #41

Earlier quoted context omitted.

Rust and Go seemed to initially want to target C programmers [1], but ended up capturing users from higher level languages – even Python and such – who wanted better performance and more control, because they had so many affordances. Hare clearly isn't like that: it's _actually_ aimed at (FOSS) C programmers, almost stubbornly so, and isn't going to appeal to many others. But for those people I can see C-with-tagged-…

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.

No post body was provided.

Re: Criticizing Hare language approach for generic data structures

#48

Post by ddevault »

rootlocus wrote: post #39
ddevault wrote: post #13

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…

> We recognize the value in this feature and have tried to come up with a good way of doing it that fits within the design constraints of the language, but it has several design issues. > Recall that Hare is designed to be similar to C in terms of scope and goals. This sounds like the language inherits all the limitations of C and isn't able to provide sufficient expressivity to solve problems that you yourself consi…

It does inherit some of the limitations of C, but in exchange, it also inherits much of the power. The trade-offs are similar to C, which is desirable in many cases. But, you may be working under different constraints, in which case you may be better off with another language - which is totally fine!

Re: Criticizing Hare language approach for generic data structures

#49

Post by ddevault »

eptcyka wrote: post #32
ddevault wrote: post #13

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…

> There are three key problems: finding a good way of hashing arbitrary data structures (or arbitrarily limiting the kinds of keys the map can store), finding a good way of determining equality of arbitrary data structures, and dealing with memory allocation semantics. It's not unheard of or unreasonable to have collections that have take an allocator as an argument. And a comparator and a hash function as arguments.…

Aye, we would have probably gone with a design similar to what you suggest... if we had generics, but we do not. Generics simply don't fit with the core values of the language. I still believe that there is room for languages without them.
Post reply on HN