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

111–120 of 272 posts

Re: Criticizing Hare language approach for generic data structures

#111

Post by samhw »

jolux wrote: post #106
socialdemocrat wrote: post #100

Why do people spend so much energy shooting down a language nobody uses? If you don’t like it you don’t have to use it. I would hate to be the creator of Hare and get so much crap for simply daring to exist. He is making a language he likes and wants to use. There are probably some people who like it and find it useful. Good for them! A lot of us have dreams of building our own language. He is following his passions…

We don’t need more memory-unsafe languages with no generics and no functional programming. We just don’t. If it were a toy project for learning and pedagogical purposes that’s one thing but for code that’s supposed to be used in production it’s useless.

> for code that’s supposed to be used in production it’s useless

Then ... don't use it. Others can use it and see what they learn from it, or even whether they find it productive to build stuff with. Even Brainfuck and Malbolge have devoted users who enjoy the challenges they pose, so I can promise you there's room enough in the world for this language. Let's just have some camomile tea and calm down a little.

Re: Criticizing Hare language approach for generic data structures

#112

Post by HL33tibCe7 »

socialdemocrat wrote: post #100

Why do people spend so much energy shooting down a language nobody uses? If you don’t like it you don’t have to use it. I would hate to be the creator of Hare and get so much crap for simply daring to exist. He is making a language he likes and wants to use. There are probably some people who like it and find it useful. Good for them! A lot of us have dreams of building our own language. He is following his passions…

If the author of Hare didn't want feedback on his language, or didn't want other people to use his language, he shouldn't have advertised it in blog posts and on sites like https://harelang.org/, which is clearly an advertisement for the language. As it happens, he has.

You might think "nobody will use the language", but if nobody pushes back and says why people shouldn't use the language, perhaps people will start to. It's really important that people do write feedback pieces like this, because it helps other people be informed about their choices.

Re: Criticizing Hare language approach for generic data structures

#113

Post by 0des »

capableweb wrote: post #96
0des wrote: post #69

Earlier quoted context omitted.

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

For someone to start using a new language in the Kernel, some of the existing "guard" has to approve it, meaning they've investigated if it's fit or not. Or can anyone willy-nilly contribute to the Kernel without anyone approving changes going into the main branch?

The existing guard doesnt have to prove anything, theyre on the way out. C is a tough language and not a lot of people have the patience for it, and even less people are being forced to learn it like the rest of us in school. As this segment of the community ages out, we arent going to see more code written in C, so we have the new group with Rust, recreating all of the same issues in effigy of C, but with better string handling. It's not like it is terrible code, but as Nikola Tesla used to say "it is what it is, and it aint what it aint".

You see how parties completely unrelated to the fight got Linus ousted? That was not based on technical merit, it was due to the changing tide regarding outcomes when people are offended/mistreated. Rust has significant overlap with the community that gave way to this, don't think it is 100% open arms and welcomes, because that is not the case.

Every day we stray further from God.

Re: Criticizing Hare language approach for generic data structures

#114

Post by carapace »

flohofwoe wrote: post #42

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…

I knew a guy who only used PHP (and a little JS) and he literally did not know the difference between hash maps, linked lists, and arrays. The SOB is a millionaire now.

Re: Criticizing Hare language approach for generic data structures

#115

Post by allanparthore »

nynx wrote: post #78
mh7 wrote: post #68

Earlier quoted context omitted.

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.

Configuring pins and peripherals with code is a chore, I use graphical tools for that.

But C has no problems abstracting away peripherals, just hide the register bits in a private TU and expose i2c_init(), i2c_write(), etc.

Re: Criticizing Hare language approach for generic data structures

#116

Post by 0des »

ddevault wrote: post #73
0des wrote: post #70

Earlier quoted context omitted.

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.

Im choosing to imagine that you typed this with one hand behind your back with some fingers crossed Drew.

Re: Criticizing Hare language approach for generic data structures

#117

Post by jolux »

amelius wrote: post #108
jolux wrote: post #106

Earlier quoted context omitted.

We don’t need more memory-unsafe languages with no generics and no functional programming. We just don’t. If it were a toy project for learning and pedagogical purposes that’s one thing but for code that’s supposed to be used in production it’s useless.

Not sure what you mean. Rust has no functional programming either ...

Functional programming patterns are very common in Rust code. It doesn’t have automatic currying or higher-kinded types but it has generic associated types, anonymous functions, closures, and a rich set of collections with functional processing methods in the standard library.

Re: Criticizing Hare language approach for generic data structures

#118

Post by ansible »

lawl wrote: post #76
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.

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

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

That would have interested me more a few years ago, but I'm deeply invested in Rust these days.

Is that all you'd change about Go? One of the reasons I moved was the error handling and lack of generics. Go has fixed the latter, but I can't stand not having Result and Option these days. The '?' is awesome too.

Re: Criticizing Hare language approach for generic data structures

#119

Post by veltas »

ahmedalsudani wrote: post #105
veltas wrote: post #57

Earlier quoted context omitted.

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

Easy to write, sure. But every time a developer has to look at it for the first time, they'll need to learn this hashmap's interface. Do I need to manage memory? Does it manage memory? How do I iterate? How do I add a new key space without thrashing the original implementation and making it twice as complicated? That's the biggest thing a standard interface gives you. Even if it's less performant and not well-designe…

I agree with all your points except "are actually well-designed and performant". I mean they perform well enough but when I write simple hashmaps that perform better than libstdc++ (yes with the same hash) anecdotally I don't have a lot of confidence.

Re: Criticizing Hare language approach for generic data structures

#120

Post by nynx »

allanparthore wrote: post #115
nynx wrote: post #78

Earlier quoted context omitted.

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.

Configuring pins and peripherals with code is a chore, I use graphical tools for that. But C has no problems abstracting away peripherals, just hide the register bits in a private TU and expose i2c_init(), i2c_write(), etc.

It’s a chore because the alternative in C is to do things perfectly without the machine doubling checking your work. That assumption does not hold with tools other than C.
Post reply on HN