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

71–80 of 323 posts

Re: The Hare programming language

#71

Post by zozbot234 »

nyanpasu64 wrote: post #63
zozbot234 wrote: post #49

Earlier quoted context omitted.

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

One of the strange things about Rust is the &UnsafeCell /*mut T dichotomy. &UnsafeCell is easier to work with, and you can soundly acquire &mut T as long as they never overlap, but you can't turn a Box > into a &UnsafeCell and back to a Box > to delete it, because provenance or something. *mut T is harder to work with, this is UB according to miri since you didn't specify `&mut x as *mut i32 as *const i32`: let mut x…

These are different things. UnsafeCell is for shared mutable data. *mut T is for data that you assert will never be mutated while it's being shared with some other reference, but you can't rely on the compiler to prove this fact for you.

Re: The Hare programming language

#72

Post by zelphirkalt »

turminal wrote: post #47
zozbot234 wrote: post #45

Earlier quoted context omitted.

> 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

Well, that's because Go, as per design, is quite limited. Its type system is lacking things Rust has. The languages have (had?) different goals. You can see one past example in generics. How long it took to finally drag the Go developers to implement them, coming to recognize their usefulness, instead of sticking to the rather limiting "No we want the language to be very simple so that everyone can understand and use it." attitude. Rust has been designed with that safety aspect as one of its primary goals and that will incur some cost in being less simple.

Re: The Hare programming language

#73

Post by staticassertion »

throwawaymaths wrote: post #59
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…

Maybe be less zealous and aware of your assumptions? Your assumption is that memory safety has to be baked in the language. It could be baked into proof assistants that are part of (optional or add-on) tooling, like what sel4 does. A simpler language makes this more possible, and the things that a proof assistants can do go far beyond what rust is able to provide, without sacrificing compilation speed or other forms…

My assumptions are based on study and experience. My "Zealotry" is just a desire to reduce harm to users in an area that I personally believe we should strive not to regress on.

I'm not interested in discussing Rust. Frankly, I'm sure there will be plenty of other people already doing so.

What's clear from this thread is that Hare does attempt to move the needle, relative to C, with regards to safety. My opinion is that that's not enough for the use cases they're targeting, but I suppose it's really up to whoever's writing the software to decide that.

Re: The Hare programming language

#74

Post by nyanpasu64 »

joeberon wrote: post #36
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 agree. It is quite clear that it is impossible to write large code bases safely with manual memory management. Even very small programs often have massive problems. I think many programmers are simply in denial about this.

I see Rust as a counterexample, serving as a formalization of provably safe patterns of manual memory management. I do wish it made it easier to write human-checked code the compiler cannot verify; unsafe code is so painful with unnecessary pitfalls, that many people write either wrong-but-ergonomic unsafe code (https://github.com/mcoblenz/Bronze/, https://github.com/emu-rs/snes-apu) or add runtime overhead (Rc and RefCell).

Re: The Hare programming language

#75

Post by ed_elliott_asc »

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

Who are your target audience?

Re: The Hare programming language

#76

Post by yakubin »

nyanpasu64 wrote: post #63
zozbot234 wrote: post #49

Earlier quoted context omitted.

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

One of the strange things about Rust is the &UnsafeCell /*mut T dichotomy. &UnsafeCell is easier to work with, and you can soundly acquire &mut T as long as they never overlap, but you can't turn a Box > into a &UnsafeCell and back to a Box > to delete it, because provenance or something. *mut T is harder to work with, this is UB according to miri since you didn't specify `&mut x as *mut i32 as *const i32`: let mut x…

You cannot turn a &T into a Box, because &T borrows T, while Box owns T, and moreover it holds it in a separate allocation, so even &mut T cannot be transformed into Box --- it already lives in some allocated space and whatever there is a reference to, cannot be moved to a new allocation. For moving T you need T, not a reference to T. The case with UnsafeCell substituted in place of T is just a special case.

UnsafeCell also owns T, so transforming &mut T into UnsafeCell also doesn't make sense. The unsafe equivalent of references is pointers.

Re: The Hare programming language

#77

Post by CyberRabbi »

pizza234 wrote: post #64
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…

Quoted post unavailable.

How is that statement an indictment against him? That’s his opinion. Does it make you a bad person to eschew Rust?

Re: The Hare programming language

#78

Post by staticassertion »

pizza234 wrote: post #64
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…

Quoted post unavailable.

I don't think it's fair to boil the language down to one person, or a person's views down to one statement.

Re: The Hare programming language

#79

Post by kwhitefoot »

ddevault wrote: post #6
Isinlor wrote: post #3

I don't see any explanation of why this language exists. Does it do something better than any other language?

It's difficult to compare Hare to every other language project at once, but the rationale is ultimately the same: we think we can fill different niches than the others. If I were to speak generally about Hare compared to other efforts, I would focus on its simplicity and stability goals. It's the only new language in this space that's arguably simpler than C, in my opinion, and the goal is to provide a small, stable…

The example that hashes itself looks rather similar to Nim with the principal differences being that Hare is a little more verbose because it looks like you /have/ to fully qualify references to imported symbols and that Hare uses braces while Nim uses Python style indentation to delimit blocks.

Re: The Hare programming language

#80

Post by nyanpasu64 »

erk__ wrote: post #62
ddevault wrote: post #50

Earlier quoted context omitted.

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.

I do know those languages, but this is more the ADT way from ML. The example you linked did not really make it clear from my point of view because one of the points is that it will collapse if there are multiples of a specific type. But your way seems to make it possible.

Tagged unions of free-floating types (polymorphic variants, C++ std::variant) and enum holding cases namespaced within themselves (Rust/Haskell) are two alternative designs. I personally prefer having both in a language. But if only one is available in a language, I prefer free-floating types, since it's more flexible and allows using the same type in multiple tagged unions, and you can somewhat emulate enums using tagged unions and namespaces (like I've done in C++ at https://gitlab.com/exotracker/exotracker-cpp/-/blob/eb8458b2...). If you take that approach, to prevent collapsing in the generic case when two type parameters are the same, you'd have to define newtypes for each type stored in a union.
Post reply on HN