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

51–60 of 272 posts

Re: Criticizing Hare language approach for generic data structures

#51

Post by capableweb »

0des wrote: post #47
celeritascelery wrote: post #46

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.

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 being sold to use Rust because of marketing, not because of the value of the language.

Re: Criticizing Hare language approach for generic data structures

#52

Post by turminal »

nynx wrote: post #17

It’s unfortunate that people are trying to revive a better version of the past, when the world has moved on and the past ultimately really wasn’t that great. C is a terrible language for building things in the modern world. Not including the progress over the last 4 decades in your new language is a mistake.

Sorry, but I can't agree with the take that Hare doesn't include the progress over the last 4 decades. Sure, it doesn't include every new development, but that's impossible anyway unless you're fine with being a kitchen sink language.

Re: Criticizing Hare language approach for generic data structures

#53

Post by orthoxerox »

MrBuddyCasino wrote: post #28
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…

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.

> but whats the appeal of "anemic stdlib plus no package ecosystem"?

You can declare your language feature complete sooner

Re: Criticizing Hare language approach for generic data structures

#54

Post by capableweb »

MrBuddyCasino wrote: post #28
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…

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.

Re: Criticizing Hare language approach for generic data structures

#55

Post by gradschool »

edflsafoiewq wrote: post #37
gradschool wrote: post #35

Earlier quoted context omitted.

Was there a good reason not to use Judy arrays?

Why would writing a Judy array three times have been better? Aren't they infamously difficult to implement?

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.

Re: Criticizing Hare language approach for generic data structures

#56

Post by nynx »

turminal wrote: post #52
nynx wrote: post #17

It’s unfortunate that people are trying to revive a better version of the past, when the world has moved on and the past ultimately really wasn’t that great. C is a terrible language for building things in the modern world. Not including the progress over the last 4 decades in your new language is a mistake.

Sorry, but I can't agree with the take that Hare doesn't include the progress over the last 4 decades. Sure, it doesn't include every new development, but that's impossible anyway unless you're fine with being a kitchen sink language.

It is great that Hare has tagged unions and non-nullable types, but polymorphism has been a huge part of language advancement.

Re: Criticizing Hare language approach for generic data structures

#57

Post by veltas »

grnmamba wrote: post #10

The primary reason I prefer working in C++ over C is that, for all of C++'s faults, it ships with a solid collection of containers and algorithms in the standard library. unordered_map may suck compared to other implementations, but it's a vast improvement over linked lists or home-grown hashmaps. Anyone can write a hash map, in the same way that anyone can write an HTTP server over a weekend. Doesn't mean it will be…

> it's a vast improvement over linked lists or home-grown hashmaps.

One of the easiest things to do is write home-grown hashmaps that perform better than std::unordered_map. I suppose you have to worry more about technical debt / bugs, but yes home-grown hashmaps are feasible and I don't think std::unorderd_map is a "vast improvement".

Re: Criticizing Hare language approach for generic data structures

#58

Post by ddevault »

MrBuddyCasino wrote: post #28
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…

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 dependencies, but maybe dozens at most. Think more C, not Node.

https://harelang.org/distributions/

Re: Criticizing Hare language approach for generic data structures

#59

Post by antonvs »

0des wrote: post #47
celeritascelery wrote: post #46

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.

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

Re: Criticizing Hare language approach for generic data structures

#60

Post by eatonphil »

gradschool wrote: post #55
edflsafoiewq wrote: post #37

Earlier quoted context omitted.

Why would writing a Judy array three times have been better? Aren't they infamously difficult to implement?

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