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

81–90 of 323 posts

Re: The Hare programming language

#81

Post by nyanpasu64 »

yakubin wrote: post #76
nyanpasu64 wrote: post #63

Earlier quoted context omitted.

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

Re: The Hare programming language

#82

Post by the_duke »

vladharbuz wrote: post #66
pizza234 wrote: post #64

Earlier quoted context omitted.

Quoted post unavailable.

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 few languages like that: Zig, Nim and D to name a few. (for both Nim and D GC is optional)

Rust is by no means the ultima ratio. It's complex and places a lot of immediate burden on the developer. I'm sure there are better solutions out there that don't sacrifice the safety guarantess. Particularly because Rust not only has the borrow checker but also a general focus on very type-system heavy designs.

But it has proven to be a significant step up from the likes of C and C++, and the additional burden pays off immensely in maintainability and correctness. I can count the memory/thread unsafety issues I encountered in 5 years of Rust on one hand, and in each case the culprit was a C library. (either because of a bad wrapper, or inherent incorrectness in the library)

Memory and thread safety can't be retrofitted into a language without producing a mess, as can be seen by the discussions and efforts in D, C++ and to some extent Swift.

They need to be central to the core language and standard library.

Re: The Hare programming language

#83

Post by nyanpasu64 »

zozbot234 wrote: post #71
nyanpasu64 wrote: post #63

Earlier quoted context omitted.

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.

If I have a &mut T, what pointer type do I convert it into (and create multiple copies of), to allow shared mutation scoped within the lifetime of the source &mut T?

Re: The Hare programming language

#84

Post by jpe90 »

Since the language is officially announced now, here's an interesting analysis on the language: https://tilde.team/~kiedtl/blog/hare/

Personally I'm very interesting in playing with it. Generics, functional programming constructs, and a lot of the syntactic sugar you find in modern languages have their uses but I think there's a lot of merit to the idea that you might not want them in a systems language. I think cleaning up some of C's rough edges and providing batteries while keeping things extremely simple and clear is very compelling. I'm also appreciative that it doesn't seem overly opinionated where it doesn't need to be.

It's kind of a bummer that there's no MacOS support so I'll have to SSH into my linux box to play with it. I hope the language takes off and support for other platforms materializes. Congratulations to everyone who worked on this.

Re: The Hare programming language

#85

Post by the_duke »

Koiwai wrote: post #57
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…

While any modern operating system is the living counter point, so far it's manageable.

Every (popular) modern operating system sits on decades old foundations written in C that can't just be replaced, so that's not a particularly strong argument.

It's noteworthy that Google is financing the effort to bring Rust to the Linux kernel, that Microsoft is also investing in the language and that there are newer, production usage focused operating systems written in Rust. (eg Hubris [1])

[1] https://github.com/oxidecomputer/hubris

Re: The Hare programming language

#86

Post by zozbot234 »

nyanpasu64 wrote: post #83
zozbot234 wrote: post #71

Earlier quoted context omitted.

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.

If I have a &mut T, what pointer type do I convert it into (and create multiple copies of), to allow shared mutation scoped within the lifetime of the source &mut T?

You can have multiple *mut T aliasing to the same data, but if you mutate through them you're on your own wrt. Rust's safety rules.

Re: The Hare programming language

#87

Post by turminal »

jpe90 wrote: post #84

Since the language is officially announced now, here's an interesting analysis on the language: https://tilde.team/~kiedtl/blog/hare/ Personally I'm very interesting in playing with it. Generics, functional programming constructs, and a lot of the syntactic sugar you find in modern languages have their uses but I think there's a lot of merit to the idea that you might not want them in a systems language. I think clea…

> Since the language is officially announced now, here's an interesting analysis on the language: https://tilde.team/~kiedtl/blog/hare/

Just a reminder (since I can't see a date in the blog post) that this was written almost a year ago. Lots of things have changed in the language since then.

Re: The Hare programming language

#88

Post by sanxiyn »

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…

> Otherwise, what's the point?

Hare seems to solve spatial memory safety and null safety, which I think is a big deal.

Re: The Hare programming language

#89

Post by lifthrasiir »

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…

> There is a trend among security professionals, as it were, to place anything on the chopping block in the name of security.

I really have to disagree on this, in spite of not being a security professional, because the history has proven that even a single byte of unexpected write---either via buffer overflow or dangling pointer---can be disastrous. Honestly I'm not very interested in other aspects of memory safety, it would be even okay that such unexpected write reliably crashes the process or equivalent. But that single aspect of memory safety is very much crucial and disavowing it is not a good response.

> [...] the #1 way to improve security is to reduce complexity, [...]

I should also note that many seemingly simple approaches are complex in other ways. Reducing apparent complexity may or may not reduce latent complexity.

Re: The Hare programming language

#90

Post by zozbot234 »

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…

> Rust is by no means the ultima ratio. It's complex and places a lot of immediate burden on the developer. I'm sure there are better solutions out there that don't sacrifice the safety guarantess.

There are undoubtedly better solutions than Rust, but they tend to allow for more developer-managed complexity rather than less! For example, one might imagine a cleaned-up variety of the GhostCell pattern, to decouple ownership- and borrow-checking from the handling of references. The principled extreme would be a language that just implements full-blown separation logic for you and lets you build up the most common patterns (including "ownership" itself) starting from that remarkably "simple" base.

Post reply on HN