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

The Hare programming language

harelang.org

Post reply on HN
Print view View original

21–30 of 323 posts

Re: The Hare programming language

#21

Post by vladharbuz »

staticassertion wrote: post #19

lol my other post got flagged, so let me reiterate perhaps in a less inflammatory way. It is disappointing to see that "trust the programmer" is a design goal. Programmers can not be trusted with manual memory management. We have decades of proof, billions and billions of dollars of bug fixes and mitigation investments, real world damages, etc. Building a language like this and saying you hope it will be the foundati…

I can sort of understand where you're coming from — manual memory management can be difficult, and doing it improperly can cause bugs. However, in my experience, we're very far from having a magical solution for memory management. C++ definitely isn't it, and while Rust does bring significant advances in this field, it's a very large and complicated language. Unfortunately, the memory management strategy of every other language I've tried introduces performance penalties that make it unsuitable for e.g. video games. Trust me, I really wish this weren't the case! :(

Until we have some kind of significantly better solution that solves all memory management problems, I would rather work in a simple language that lets me carefully do everything myself, and if that language is also an improvement over C, I'm happy. However, that's just me, and I can fully appreciate that others are free to choose the tools that are good for them!

Re: The Hare programming language

#22

Post by staticassertion »

ddevault wrote: post #20
staticassertion wrote: post #19

lol my other post got flagged, so let me reiterate perhaps in a less inflammatory way. It is disappointing to see that "trust the programmer" is a design goal. Programmers can not be trusted with manual memory management. We have decades of proof, billions and billions of dollars of bug fixes and mitigation investments, real world damages, etc. Building a language like this and saying you hope it will be the foundati…

There are plans to research an optional borrow checker for Hare. Hare also does offer many "safety" advantages over C: checked slice and array access, exhaustive switch and match, nullable pointer types, less undefined behavior, no strict pointer aliasing, fewer aggressive optimizations, and so on. Hare code is much less likely to have these errors when compared to C code. I would ultimately just come out and say tha…

I think a section on safety might be worthwhile. For example, Zig pretty clearly states that it wants to focus on spatial memory safety, which it sounds like Hare is going for as well.

That's certainly an improvement and worth noting, although it obviously leaves temporal safety on the table.

> but the argument that we're morally in the wrong to prefer another approach is not really appreciated.

Well, sorry to hear it's not appreciated, but... I think developers should feel a lot more responsibility in this area. So many people have been harmed by these issues.

Re: The Hare programming language

#23

Post by closeneough »

staticassertion wrote: post #19

lol my other post got flagged, so let me reiterate perhaps in a less inflammatory way. It is disappointing to see that "trust the programmer" is a design goal. Programmers can not be trusted with manual memory management. We have decades of proof, billions and billions of dollars of bug fixes and mitigation investments, real world damages, etc. Building a language like this and saying you hope it will be the foundati…

Imho as everywhere in this field there are tradeoffs to choose for improving this problem: Complexity (rust, formal proofs), runtime overhead (GC), etc.

Hare tries to be simple, so that it's easier to reason about the code and hence maybe find/avoid such bugs more easily.

Re: The Hare programming language

#24

Post by aledue »

Are hare's tagged unions and pattern matching comparable to ADTs found in functional languages? I really miss them in C and would like a "better C" that offers them. Rust does, but of course it's a much bigger language.

Re: The Hare programming language

#25

Post by ddevault »

staticassertion wrote: post #22
ddevault wrote: post #20

Earlier quoted context omitted.

There are plans to research an optional borrow checker for Hare. Hare also does offer many "safety" advantages over C: checked slice and array access, exhaustive switch and match, nullable pointer types, less undefined behavior, no strict pointer aliasing, fewer aggressive optimizations, and so on. Hare code is much less likely to have these errors when compared to C code. I would ultimately just come out and say tha…

I think a section on safety might be worthwhile. For example, Zig pretty clearly states that it wants to focus on spatial memory safety, which it sounds like Hare is going for as well. That's certainly an improvement and worth noting, although it obviously leaves temporal safety on the table. > but the argument that we're morally in the wrong to prefer another approach is not really appreciated. Well, sorry to hear i…

I don't really want to engage with the RESF. We have the level of safety that we feel is appropriate. Believe me, we do feel responsible for quality, working code: but we take responsibility for it personally, as programmers, and culturally, as a community, and let the language help us: not mandate us.

Give us some time to see how Hare actually performs in the wild before making your judgements, okay?

Re: The Hare programming language

#27

Post by staticassertion »

vladharbuz wrote: post #21
staticassertion wrote: post #19

lol my other post got flagged, so let me reiterate perhaps in a less inflammatory way. It is disappointing to see that "trust the programmer" is a design goal. Programmers can not be trusted with manual memory management. We have decades of proof, billions and billions of dollars of bug fixes and mitigation investments, real world damages, etc. Building a language like this and saying you hope it will be the foundati…

I can sort of understand where you're coming from — manual memory management can be difficult, and doing it improperly can cause bugs. However, in my experience, we're very far from having a magical solution for memory management. C++ definitely isn't it, and while Rust does bring significant advances in this field, it's a very large and complicated language. Unfortunately, the memory management strategy of every oth…

I hear you, but I think the problem is that you're framing this as "I, the developer, don't want to accept these costs". And that's fine when the software doesn't leave your system.

The problem is that you're them pushing other costs onto your users ie: exploitable software. So from the developer perspective, great, it works for you, but the cost is there.

I'm sympathetic to not wanting to use the other languages available, I'm not saying that any other language is doing things the "right" way, there's room for a lot of improvement. But I personally think that setting out to build new systems software in a memory unsafe language is setting users up for very serious harm.

Re: The Hare programming language

#28

Post by ddevault »

xeeeeeeeeeeenu wrote: post #26

Not supporting Windows and macOS will likely hurt the adoption of the language. Anyway, is it possible to target bare-metal with Hare? Is it possible to use it without the standard library?

> Not supporting Windows and macOS will likely hurt the adoption of the language.

Not among our target audience it won't.

> Anyway, is it possible to target bare-metal with Hare? Is it possible to use it without the standard library?

Yes. Here are two kernels written in Hare that don't use the stdlib:

https://git.sr.ht/~sircmpwn/helios

https://git.sr.ht/~yerinalexey/carrot

Re: The Hare programming language

#29

Post by ddevault »

aledue wrote: post #24

Are hare's tagged unions and pattern matching comparable to ADTs found in functional languages? I really miss them in C and would like a "better C" that offers them. Rust does, but of course it's a much bigger language.

They are a subset, I suppose. I'm not an expert at functional programming so I couldn't say. The tutorial which introduces tagged unions is here:

https://harelang.org/tutorials/introduction/#tagged-unions-i...

They are also covered in section 6.5.18 of the Hare specification:

https://harelang.org/specification.pdf

Would be curious to hear your thoughts on how they compare given your (presumed) background in functional programming.

Re: The Hare programming language

#30

Post by staticassertion »

ddevault wrote: post #25
staticassertion wrote: post #22

Earlier quoted context omitted.

I think a section on safety might be worthwhile. For example, Zig pretty clearly states that it wants to focus on spatial memory safety, which it sounds like Hare is going for as well. That's certainly an improvement and worth noting, although it obviously leaves temporal safety on the table. > but the argument that we're morally in the wrong to prefer another approach is not really appreciated. Well, sorry to hear i…

I don't really want to engage with the RESF. We have the level of safety that we feel is appropriate. Believe me, we do feel responsible for quality, working code: but we take responsibility for it personally, as programmers, and culturally, as a community, and let the language help us: not mandate us. Give us some time to see how Hare actually performs in the wild before making your judgements, okay?

I'm a security professional, and I'm speaking as a security professional, not as an evangelist for any language's approach.

> Give us some time to see how Hare actually performs in the wild before making your judgements, okay?

I'm certainly very curious to see how the approach plays out, but only intellectually so. As a security professional I already strongly suspect that improvements in spatial safety won't be sufficient to change the types of threats a user faces. I could justify this point, but I'd rather hand wave from an authority position since I suspect there's no desire for that.

But we obviously disagree and I'm not expecting to change your mind. I just wanted to comment publicly that I hope we developers will form a culture where we think about the safety of users first and foremost and, as a community, prioritize that over our own preferences with regards to our programming experience.

Post reply on HN