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

91–100 of 323 posts

Re: The Hare programming language

#91

Post by anonymoushn »

the_duke wrote: post #82
vladharbuz wrote: post #66

Earlier quoted context omitted.

While Drew is the designer of Hare, a lot of us worked on Hare, and we tried really hard to create something useful and valuable. I think it would be a shame if you disregard it because of something that Drew said at whatever point in time. If you have the time, please try Hare and let us know what you think! Aside from that, the question of memory safety is more complex than you make it out to be, and Drew, myself a…

I am sympathetic, but I agree with others that any new systems language in 2022 must have memory and thread safety with minimal escape hatches as its utmost priority and a core component of the language design. Otherwise, what's the point? Yet another language that is a bit more convenient than the alternatives but doesn't do much to help with all the vulnerabilities and bugs in our software? We already have quite a…

Making the Rust ownership model central to the core language and standard library has meant that after 11 years of Rust, your program still can't have two objects of the same type owned by different allocators. As a result, I am interested in other approaches to these problems.

Re: The Hare programming language

#92

Post by yakubin »

nyanpasu64 wrote: post #81
yakubin wrote: post #76

Earlier quoted context omitted.

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

C++ lets you easily delete a T* or T const*, Rust has https://doc.rust-lang.org/std/primitive.pointer.html#2-consu... I guess? > UnsafeCell also owns T, so transforming &mut T into UnsafeCell also doesn't make sense. I wanted to transform a &mut T into &UnsafeCell (note the &) and copy the reference, to allow shared mutation scoped within the lifetime of the source &mut T. How can this be accomplished?

> C++ lets you easily delete a T* or T const*, Rust has https://doc.rust-lang.org/std/primitive.pointer.html#2-consu... I guess?

Box deletes the owned object when it goes out of scope without being moved (like unique_ptr in C++). So if anything, you want to go the other way: https://doc.rust-lang.org/std/boxed/struct.Box.html#method.f...

However, you can delete a *T by using https://doc.rust-lang.org/std/alloc/trait.Allocator.html#tym...> with the Global allocator (since this is the one you're most likely using).

> I wanted to transform a &mut T into &UnsafeCell (note the &) and copy the reference, to allow shared mutation scoped within the lifetime of the source &mut T. How can this be accomplished?

If you want to have two instances of one &mut T, you don't go through &UnsafeCell. Instead you may cast &mut T into *mut T and then use this: https://doc.rust-lang.org/std/primitive.pointer.html#method....>. This however will cast into any lifetime, so if you want to bind the two lifetimes together, then you need to have the lifetime of the original &mut T explicitly specified, and then you assign the result of the method I linked to a variable with explicitly specified type where you specify the lifetime annotation. Alternatively, you may write a separate function which accepts both references as arguments and binds the two lifetimes together the usual way.

I admit it's a bit unergonomic. The best way currently would be to have the data stored as UnsafeCell in the first place and then call get_mut() on it to get all the references. However, if this reference comes from outside, you're left with the little mess I outlined above.

Re: The Hare programming language

#93

Post by anonymoushn »

ddevault wrote: post #32
triyambakam wrote: post #31

Earlier quoted context omitted.

Could you share any of your thoughts on comparing Hare to Zig? Zig seems to have the most similar goals to Hare but I think Zig is already quite complicated.

Hare is much simpler than Zig. The Hare compiler is 1/10th the size of the Zig compiler. The standard libraries, which I reckon are pretty comparable in terms of features, are again separated by an order of magnitude in size. Zig is also (presently) based on LLVM, which heaps on another huge pile of complexity, whereas Hare is based on qbe: 13,000 lines of C89. Bootstrapping Hare is also significantly easier and much…

> The standard libraries, which I reckon are pretty comparable in terms of features, are again separated by an order of magnitude in size.

I would be extremely surprised if this were the case, especially given that the Zig standard library is full of generics.

Re: The Hare programming language

#94

Post by lifthrasiir »

Tagged union type seems a defining feature of Hare to me. It is not exactly "tagged" in the sense that it internally has tags but users don't explicitly see them [1]. This kind of types are normally headaches for language designers (cf. polymorphic variants in OCaml), but the Hare type system is simple enough that it doesn't pose a significant problem. In turn it gives an intuitive model of conversion; you don't have to convert from, say, one type of error to another type of error. Zig error type is also similar in this aspect, but it is not as general as Hare's tagged union type.

[1] I really want to refer this as to "untagged" union type, but of course this will cause a confusion with C-style unsafe unions.

Re: The Hare programming language

#96

Post by the_duke »

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

The problem here is that focusing on a language can lead to lots of small API design decisions that make it very cumbersome to support other systems later without significant breaking changes.

I can appreciate the ideological and practical purity of that decision, but even Linux aficionados need to deploy code to other operating systems to make a living.

Re: The Hare programming language

#97

Post by Shadonototra »

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…

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

We have sanitizers if you are a bad programmer, use that if you don't trust yourself

Re: The Hare programming language

#100

Post by the_duke »

ddevault wrote: post #35
staticassertion wrote: post #30

Earlier quoted context omitted.

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

I am not a security maximalist: I will not pursue it at the expense of everything else. There is a trend among security professionals , as it were, to place anything on the chopping block in the name of security. I find this is often counter-productive, since the #1 way to improve security is to reduce complexity, which many approaches (e.g. Rust) fail at. Security is one factor which Hare balances with the rest, and…

> #1 way to improve security is to reduce complexity

If managing memory lifetime is an inherently complex problem (which it is), the complexity has to live somewhere.

That somewhere is either in the facilities the language provides, or in user code and manual validation.

Post reply on HN