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

61–70 of 272 posts

Re: Criticizing Hare language approach for generic data structures

#61

Post by ayende »

ddevault wrote: post #49
eptcyka wrote: post #32

Earlier quoted context omitted.

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

Something like this:

    struct cmp
    {
       hash: *fn(_:*void) u64,
       eq  : *fn(_:*void, _:*void) bool,
       free: *fn(_:*void) void 
    }
With maybe some default options should be enough for at least the basics. Note that the indirection overhead would be significant, but without generics or something similar, you don't really have a choice.

Re: Criticizing Hare language approach for generic data structures

#63

Post by eatonphil »

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?

Re: Criticizing Hare language approach for generic data structures

#64

Post by ATsch »

thrower123 wrote: post #50

We seem to be very worked up over a virtually unknown new C-replacement language that's more likely than not to fizzle and become yet another 0.1% also-ran.

I feel like people are less getting worked up over Hare itself, and more what it represents. It is very much a reactionary language, defined less by any grand new ideas or visions and more by rejection of things that many people see as valuable progress over the last few decades. It doesn't help that it is being pushed by an already highly notable and controversial figure. The language just happens to be a convenient vehicle for arguing about these engineering (and personal) values.

Re: Criticizing Hare language approach for generic data structures

#65

Post by ddevault »

ayende wrote: post #61
ddevault wrote: post #49

Earlier quoted context omitted.

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.

Something like this: struct cmp { hash: *fn(_:*void) u64, eq : *fn(_:*void, _:*void) bool, free: *fn(_:*void) void } With maybe some default options should be enough for at least the basics. Note that the indirection overhead would be significant, but without generics or something similar, you don't really have a choice.

The problem here is *void, which is not great. You lose type safety with this approach, and the allocation problems are still present. Rolling your own can be both more type safe and better suited to your problem area, and it's not particularly difficult.

Re: Criticizing Hare language approach for generic data structures

#66

Post by ddevault »

ayende wrote: post #34
ddevault wrote: post #14

Earlier quoted context omitted.

Most application's bottlenecks are not their linked lists, and optimizing for anything other than your bottleneck is not the wisest use of your time. Performance is a budget, and I feel comfortable spending some of that budget on simplicity.

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 exist in a few niche situations -- I only ever wrote a Hare program with linked lists once.

Re: Criticizing Hare language approach for generic data structures

#67

Post by skitter »

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

The problem is less that it doesn't provide an implementation, but more that it doesn't allow anyone else to provide an implementation either (aside via code generation).

Re: Criticizing Hare language approach for generic data structures

#68

Post by mh7 »

nynx wrote: post #40
hypeatei wrote: post #30

Earlier quoted context omitted.

Agreed, I don't know how writing anything in C today would be considered a productive use of time besides low level / embedded work.

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.

Re: Criticizing Hare language approach for generic data structures

#69

Post by 0des »

capableweb wrote: post #51
0des wrote: post #47

Earlier quoted context omitted.

Quoted post unavailable.

I have no fists in this fight, but wanted some clarification. Are you saying the reason Rust is now being integrated into the Kernel instead of Golang is because of the success of evangelists, not because of the merit of the language itself? I'm not involved in Kernel development myself, but if I was, I'd see your statement as a big hit in the face that we don't know what we're doing, if they (Kernel developers) are…

Its not existing kernel devs that suddenly switched to rust. It is the incoming cohort.

Re: Criticizing Hare language approach for generic data structures

#70

Post by 0des »

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

Earlier quoted context omitted.

Quoted post unavailable.

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.
Post reply on HN