The Hare programming language

submited by

Style Pass

2022-06-21 13:30:03

Hare offers many important advances over its main inspiration, C, when it comes to safety features. These features prevent the programmer from making mistakes, ideally without preventing them from doing what they want to do. Some of these features reduce the risk of classic security problems, such as buffer overflows, but they are generally designed with the broader hope of reducing the risk of your program having bugs of any kind. After all, any bug can become a security vulnerability under the right conditions.

Hare does not offer the same safety features as other programming languages. It does not run in a sandboxed virtual machine like JavaScript or C#, and it does not have a borrow checker like Rust. Safety features are one trade-off weighed against many, and each programming language comes away with a different set. Naturally, no programming language can totally prevent the introduction of bugs, including security vulnerabilities. Regardless, features which can reduce that risk are often useful, should the trade-offs be desirable.

For instance, say we wanted to prevent use-after-free bugs. One approach would be to use a garbage collector. These aren’t too complicated, so goal #2 isn’t in trouble, but goals #1 and #3 aren’t looking great. Garbage collection magically stops your code (sometimes at predictable points, but it’s generally not very explicit), which is not very transparent and is definitely off the table for use-cases like kernels, video games, real-time applications, and so on. The behavior of a Hare program should be easy to predict, and a garbage collector interferes with that goal. Thus, despite the fact that a garbage collector would improve safety and ease-of-use, it’s not a good fit for Hare.