Live data from Hacker News

The Hare programming language

harelang.org

41–50 of 323 posts

Re: The Hare programming language

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

Hare doesn't care much about mathematical purity, and the features it does have were chosen on the basis of what is useful in systems programming.

There are sum types (tagged unions), but product types (tuples) were a late addition and we still don't have support for tuple unpacking or pattern matching on them.

Tuple unpacking is something that's been put off for very long but looks like it is going to finally happen soon. Pattern matching on types other than tagged unions hasn't been completely ruled out yet, but is also not guaranteed to happen.

Re: The Hare programming language

#43

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 think developers should feel a lot more responsibility in this area. I think most programmers would agree with that sentiment. Getting everyone to agree on what is "responsible" and what isn't however... Hare is a manifestation of the belief that in order to develop responsibly, one has to keep their software, and their code, simple. An example of what I mean by this: An important feature of Rust is the use of co…

It sounds like Hare has a philosophy around safety here and it's just not documented - at least not where I could find it, scrolling around a bit.

I did find this page, though: https://harelang.org/blog/2021-02-09-hare-advances-on-c/

Which I found very interesting.

Re: The Hare programming language

#44

Earlier quoted context omitted.

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

I think I understand your view better now. Are you aware of any current memory management strategies (implemented as part of a language or otherwise) that perform well in situations with high performance requirements? For example, as someone who works on video games and real-time audio, most options seem non-starters to me aside from Rust, even if I decided to make sacrifices for the sake of security, and I at least…

Not staticassertion, but I'm a hobbyist in real-time audio. I like Rust as a vocabulary for describing/teaching safe programming (&/&mut/Send/Sync). I find that multithreaded programs written in Rust are usually correct while multithreaded programs written in C++ are usually wrong, because Rust encodes the rules of shared-memory threading in its type system (&T: Sync objects are thread-shared, but are either immutable or atomic or requires locking to acquire a &mut T). I also appreciate guiding users towards exclusive references (&mut) to make it easier to reason about code. However I find it makes it too difficult to mutate through shared references or write unsafe code (passing Stacked Borrows while lending out &mut is more like solving puzzles than writing imperative code, and writing code that never touches & and &mut is a quagmire of addr_of_mut!() and unsafe blocks on every pointer dereference), and the Rust community appears uninterested in making unsafe programming more ergonomic.

Personally I'm a fan of C++'s unique_ptr/& as an unsafe escape hatch from Rust's single ownership or runtime refcounting overhead. It's at least as safe as Rust's unsafe pointers, and far more pleasant to use. Qt's QObject ownership system is reasonably ergonomic and QPointer is fun (though dangerous since it can turn into null unexpectedly), but Qt uses it pervasively (rather than only when safe memory management fails), relies on prose documentation to describe which pointers transfer ownership or not (resulting in memory management bugs), and QObject child destruction and nulling-out QPointers relies on runtime overhead. I haven't tried ECS or generational indexes yet, but those are popular in games, and Vale has its own ideas in this field (https://verdagon.dev/blog/generational-references).

On an aesthetic/principled level, I'd rather punt alias analysis to the programmer (pointer/restrict or &/&mut) rather than compiler complexity/magic (TBAA and provenance checking). Glancing at https://harelang.org/specification/, it seems Hare lacks an equivalent of restrict/&mut, and I wonder if that prevents the compiler from ever adding support for removing redundant loads/stores through pointers.

Re: The Hare programming language

#45

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…

> C++ definitely isn't it, and while Rust does bring significant advances in this field, it's a very large and complicated language.

It really isn't. Not compared to C++, at least. Or to managed language runtimes, which are just as "large and complicated", only beneath the hood.

Re: The Hare programming language

#46
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 functiona…

The biggest missing feature here would be a way to not only select by type and for example allow something like

   type foo = (A int | B int)
Which from my cursory reading does not seem to be possible?

Re: The Hare programming language

#47

Earlier quoted context omitted.

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…

> C++ definitely isn't it, and while Rust does bring significant advances in this field, it's a very large and complicated language. It really isn't. Not compared to C++, at least. Or to managed language runtimes, which are just as "large and complicated", only beneath the hood.

It's certainly much more complicated than Go, and not just on the surface

Re: The Hare programming language

#49

Earlier quoted context omitted.

I think I understand your view better now. Are you aware of any current memory management strategies (implemented as part of a language or otherwise) that perform well in situations with high performance requirements? For example, as someone who works on video games and real-time audio, most options seem non-starters to me aside from Rust, even if I decided to make sacrifices for the sake of security, and I at least…

Not staticassertion, but I'm a hobbyist in real-time audio. I like Rust as a vocabulary for describing/teaching safe programming (&/&mut/Send/Sync). I find that multithreaded programs written in Rust are usually correct while multithreaded programs written in C++ are usually wrong, because Rust encodes the rules of shared-memory threading in its type system (&T: Sync objects are thread-shared, but are either immutabl…

> However I find it makes it too difficult to mutate through shared references

It's not that difficult, you just need to use UnsafeCell or one of its safe derivatives (each of which has some potential runtime overhead) to keep the semantics tractable.

Re: The Hare programming language

#50
post #46

Earlier quoted context omitted.

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

The biggest missing feature here would be a way to not only select by type and for example allow something like type foo = (A int | B int) Which from my cursory reading does not seem to be possible?

I'm not sure what you mean by "select by type". I can say that you can define new types:

   type a = int;
   type b = int;
   type c = (a | b);
Which seems to be what you're angling for here? I also suspect that you're approaching this from a Rust- or Zig-like background where enums and tagged unions are closely related; this is not so in Hare.
Post reply on HN