7 ms·

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 Ha

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.

ddevault 4y ago
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?
- staticassertion 4y ago
  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.
  - ddevault 4y ago
    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 I refuse to accept a doom-and-gloom the-cancer-which-is-killing-software perspective on this approach.
    - staticassertion 4y ago
      You can paint me as an overdramatic security person all you like, but it's really quite the opposite. I'd just like developers to think more about reducing harm to users. > to place anything on the chopping block in the name of security. Straw man argument. I absolutely am not a "security maximalist", nor am I unwilling to make tradeoffs - any competent security professional makes them all the time. > the #1 way to improve security is to reduce complexity Not really, no. Even if "complexity" were a defined term I don't think you'd be able to support this. Python's pickle makes things really simple - you just dump an object out, and you can load it up again later. Would you call that secure? It's a rhetorical question, to be clear, I'm not interested in debate on this. > I refuse to accept a doom-and-gloom the-cancer-which-is-killing-software perspective on this approach OK. I commented publicly that I believe developers should care more about harm to users. You can do with that what you like. Let's end it here? I don't think we're going to agree on much.
    - lifthrasiir 4y ago
      > 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.
turminal 4y ago
> 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 complex compiler features in order to facilitate development of multithreaded programs and ensure temporal safety. In Hare programmers are encouraged to keep their software single threaded, because despite features like Rust's, concurrent programs turn out much more complex to write and maintain than sequential ones. Keeping software single-threaded also eliminates many ways in which a program could fail due to lack of compiler enforced temporal safety.
- staticassertion 4y ago
  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/ https://harelang.org/blog/2021-02-09-hare-advances-on-c/ Which I found very interesting.
- the_duke 4y ago
  Single threaded development seems a noteworthy goal, and I partially agree that it often leads to much simpler code and works well in systems like Erlang. But it is also a questionable focus in the days of barely increasing single core performance, especially in a systems language. I believe one of the reasons Rust got so popular is that it made concurrency much easier and safer right at a time where the need for it increased significantly. If that is the recommendation, maybe the standard library could focus on easily spawning and coordinating multiple processes instead, with very easy to use process communication.
  - astrange 4y ago
    Unfortunately you can't make things faster by making them concurrent, at least not in the way computers are currently designed. (And they're probably designed near-optimally unless we get memristors.) In my experience it's the opposite; you can make concurrent programs faster by removing it, because it adds overhead and they tend to wait on nothing or have unnecessary thread hops. And it makes them more power efficient too, which is often more important than being "faster". Instead you want to respect the CPU under you and the way its caching and OoO instruction decoding work.
pjmlp 4y ago
I don't see it as an improvement, because they are taking what Modula-2 already offered in 1978 in terms of systems programing safety. I guess not having to type keywords in caps (because who uses IDE/smart editors) and having a C like syntax is the selling point.

ddevault 4y ago

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?

staticassertion 4y ago
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.
- ddevault 4y ago
  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 I refuse to accept a doom-and-gloom the-cancer-which-is-killing-software perspective on this approach.
  - staticassertion 4y ago
    You can paint me as an overdramatic security person all you like, but it's really quite the opposite. I'd just like developers to think more about reducing harm to users. > to place anything on the chopping block in the name of security. Straw man argument. I absolutely am not a "security maximalist", nor am I unwilling to make tradeoffs - any competent security professional makes them all the time. > the #1 way to improve security is to reduce complexity Not really, no. Even if "complexity" were a defined term I don't think you'd be able to support this. Python's pickle makes things really simple - you just dump an object out, and you can load it up again later. Would you call that secure? It's a rhetorical question, to be clear, I'm not interested in debate on this. > I refuse to accept a doom-and-gloom the-cancer-which-is-killing-software perspective on this approach OK. I commented publicly that I believe developers should care more about harm to users. You can do with that what you like. Let's end it here? I don't think we're going to agree on much.
  - lifthrasiir 4y ago
    > 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.

turminal 4y ago

> 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 complex compiler features in order to facilitate development of multithreaded programs and ensure temporal safety. In Hare programmers are encouraged to keep their software single threaded, because despite features like Rust's, concurrent programs turn out much more complex to write and maintain than sequential ones. Keeping software single-threaded also eliminates many ways in which a program could fail due to lack of compiler enforced temporal safety.

staticassertion 4y ago
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/ https://harelang.org/blog/2021-02-09-hare-advances-on-c/ Which I found very interesting.
the_duke 4y ago
Single threaded development seems a noteworthy goal, and I partially agree that it often leads to much simpler code and works well in systems like Erlang. But it is also a questionable focus in the days of barely increasing single core performance, especially in a systems language. I believe one of the reasons Rust got so popular is that it made concurrency much easier and safer right at a time where the need for it increased significantly. If that is the recommendation, maybe the standard library could focus on easily spawning and coordinating multiple processes instead, with very easy to use process communication.
- astrange 4y ago
  Unfortunately you can't make things faster by making them concurrent, at least not in the way computers are currently designed. (And they're probably designed near-optimally unless we get memristors.) In my experience it's the opposite; you can make concurrent programs faster by removing it, because it adds overhead and they tend to wait on nothing or have unnecessary thread hops. And it makes them more power efficient too, which is often more important than being "faster". Instead you want to respect the CPU under you and the way its caching and OoO instruction decoding work.

pjmlp 4y ago

I don't see it as an improvement, because they are taking what Modula-2 already offered in 1978 in terms of systems programing safety. I guess not having to type keywords in caps (because who uses IDE/smart editors) and having a C like syntax is the selling point.