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

71–80 of 272 posts

Re: Criticizing Hare language approach for generic data structures

#71

Post by tialaramex »

Yesterday, while reading about Hare, I discovered the problem this blog post alludes to (Hare's own module code just assumes if the hash for two modules was identical, they're the same module) and I reported it to Hare's developer list.

https://lists.sr.ht/~sircmpwn/hare-dev/%3C20220503143516.19e...

I was sort of expecting Drew to... fix it? I mean, what you'd hope for is an updated blog post with a mea culpa in it, but I'm not setting my expectations so high. Fixing the bug seems like a pretty basic place to start though.

Re: Criticizing Hare language approach for generic data structures

#72

Post by formerly_proven »

eatonphil wrote: post #63
rieTohgh6 wrote: post #6

TreeMap as a fallback for bucket and/or some king of random salt for hashes had to be introduced due to security issues (DoS) - I doubt anybody would remember about such stuff when making own hashmap implementation.

Any links to learn more?

The average performance of hashtables generally depends on collisions being rare, but if the hashed index is trivially derivable from the key, then an attacker can supply data where everything hashes to the same index, regressing performance to the point that it's a DoS attack.

This is why cryptographically secure short-output hash functions like SipHash were developed.

Re: Criticizing Hare language approach for generic data structures

#73

Post by ddevault »

0des wrote: post #70
antonvs wrote: post #59

Earlier quoted context omitted.

My understanding is that Go has several features that make it unsuitable as a Linux kernel language, e.g. automatic garbage collection, its concurrency model, and possibly the nature of its runtime dependency (which is related to the previous two items.)

Garbage collection is not mandatory, and the concurrency model is often hailed as one of Gos best features.

I like Go and I use it often. I also work on kernels. Go is not suitable for writing kernels.

Re: Criticizing Hare language approach for generic data structures

#74

Post by ddevault »

tialaramex wrote: post #71

Yesterday, while reading about Hare, I discovered the problem this blog post alludes to (Hare's own module code just assumes if the hash for two modules was identical, they're the same module) and I reported it to Hare's developer list. https://lists.sr.ht/~sircmpwn/hare-dev/%3C20220503143516.19e... I was sort of expecting Drew to... fix it? I mean, what you'd hope for is an updated blog post with a mea culpa in it,…

Thanks for the email - yours is one of 46 emails in my Hare queue, which is why it has not been addressed yet. I agree with your comments and have filed a ticket to address them, however, and I will answer your email in time. Thanks for your patience!

Re: Criticizing Hare language approach for generic data structures

#75

Post by mumblemumble »

capableweb wrote: post #54
MrBuddyCasino wrote: post #28

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.

Correct me if I'm wrong, but Hare doesn't say "we need no package manager" but instead "we don't need a new package manager, use the one your OS provides", at least from how I understand it.

That strikes me as another C-ism that didn't deserve to be carried forward into a 21st century language.

There's a reason we call it "dependency hell" and not "happy fun fussing with dependency version conflicts among projects that are completely unrelated except that you happen to be using the same computer to work on them time."

Re: Criticizing Hare language approach for generic data structures

#76

Post by lawl »

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.

> 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't give you enough control, the problem is that it's garbage collected. And you'd need to work around the GC. It's doable and people have done it though. Good idea? Maybe not.

Still waiting for someone to make "go but with ownership and borrow checker"

Re: Criticizing Hare language approach for generic data structures

#77

Post by ddevault »

eatonphil wrote: post #63
rieTohgh6 wrote: post #6

TreeMap as a fallback for bucket and/or some king of random salt for hashes had to be introduced due to security issues (DoS) - I doubt anybody would remember about such stuff when making own hashmap implementation.

Any links to learn more?

https://en.wikipedia.org/wiki/Collision_attack#Hash_flooding

Note that this is only a problem when an attacker can influence your hash table usage, and can be mitigated with hashing functions like siphash. This is not necessary for the majority of hash tables in the wild.

Re: Criticizing Hare language approach for generic data structures

#78

Post by nynx »

mh7 wrote: post #68
nynx wrote: post #40

Earlier quoted context omitted.

Even in the embedded world, it’s becoming less justifiable to use C when your platform supports rust.

rust doesn't offer much value for embedded (mcu, bare metal, tiny stuff) imo. No allocation = no leaks, no use after free, no dangling pointers. No multi core = no atomics or concurrency to worry about. Ring buffers solve 99% of my interrupt data sharing = no need to worry about synchronization. Bounds/safety checks? Need to run and test release builds most of the time because of space/memory constraints.

Rust absolutely benefits embedded software. A big reason is that the type system allows libraries to let you enforce invariants at compile time.

For example, your i2c controller only supports two specific pins and they have to be in a specific mode? That can be a compile error if you make a mistake.

Re: Criticizing Hare language approach for generic data structures

#79

Post by BaculumMeumEst »

ddevault wrote: post #66
ayende wrote: 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…

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?

Re: Criticizing Hare language approach for generic data structures

#80

Post by tialaramex »

0des wrote: post #70
antonvs wrote: post #59

Earlier quoted context omitted.

My understanding is that Go has several features that make it unsuitable as a Linux kernel language, e.g. automatic garbage collection, its concurrency model, and possibly the nature of its runtime dependency (which is related to the previous two items.)

Garbage collection is not mandatory, and the concurrency model is often hailed as one of Gos best features.

A best feature it may well be, but it requires infrastructure and the OS kernel provides that infrastructure it doesn't depend on it.

Rust for Linux relies on the fact that Rust is deliberately structured in layers so that the bottom layer doesn't need that infrastructure, this was needed to make embedded Rust practical, but it's also important for Linux. Actually, Linux needs even more than Rust had initially, but that's driven further improvements to Rust itself.

You could add a layer to do all this lifting (that's what e.g. a Java OS does) but that's not going to fly in Linux, which is one reason why Go for Linux isn't a thing whereas Rust for Linux is.

Post reply on HN