|
|
Log in / Subscribe / Register

DeVault: Announcing the Hare programming language

DeVault: Announcing the Hare programming language

Posted May 2, 2022 10:35 UTC (Mon) by roc (subscriber, #30627)
In reply to: DeVault: Announcing the Hare programming language by ddevault
Parent article: DeVault: Announcing the Hare programming language

The problem is that any code exposed to potentially malicious input is a security attack surface. And even if you don't care about your device being compromised, it's still a hazard for others; e.g. any compromised network-attached device can be part of a botnet for DDoS or a relay for ransomware attacks.

to post comments

DeVault: Announcing the Hare programming language

Posted May 2, 2022 10:38 UTC (Mon) by ddevault (subscriber, #99589) [Link] (18 responses)

Aye, this is why Hare *does* offer some security features. We just don't offer all of the same features as Rust does, and that's fine. It's a different set of trade-offs.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 11:33 UTC (Mon) by khim (subscriber, #9252) [Link] (6 responses)

The majority of problems in real-world C/C++ programs come from issues with memory management. Unless you can explain what you have done to avoid this issue other security features are not all that interesting.

It's like making a car and then deciding that adding wheels to it would be too hard. Such car would still be useful for some things, but it wouldn't be useful for most people.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 11:36 UTC (Mon) by ddevault (subscriber, #99589) [Link] (4 responses)

I have already explained Hare's security features many times, some of which relate directly to memory management, such as nullable pointer types or bounds-checked slices. Memory issues are much more rare in Hare programs than in C programs.

Part of Hare's goal is to question the orthodoxy pushed by Rust and its proponents and to look for a different solution. No, it's not Rust. No, it's not going to be Rust. That does not rule it out as an interesting language.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 13:56 UTC (Mon) by ncm (guest, #165) [Link] (2 responses)

It does, when you demonstrate you have utterly failed to comprehend Rust's, let alone C++'s, value proposition.

It is 2022, not 1972. Bring something new and valuable to the table. Don't waste our time on 1970s retreads.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 13:58 UTC (Mon) by ddevault (subscriber, #99589) [Link] (1 responses)

Rest assured that I fully understand the value Rust supposes it offers, and C++ also. You have not invented the God language, and you are not His servant. If you aren't interested then Hare, then fine, more power to you, but bugger off while we build the language we want - not the language you want.

*Sigh*

Posted May 2, 2022 14:02 UTC (Mon) by corbet (editor, #1) [Link]

Someday we'll be able to post an item on programming languages without things degrading this way. Evidently not today. Let's all please back off a bit now.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 23:48 UTC (Mon) by roc (subscriber, #30627) [Link]

> Memory issues are much more rare in Hare programs than in C programs.

Do you have evidence this is true in practice? I guess you've fuzzed Hare programs and equivalent C programs and measured the bug rates?

DeVault: Announcing the Hare programming language

Posted May 2, 2022 16:40 UTC (Mon) by wtarreau (subscriber, #51152) [Link]

> The majority of problems in real-world C/C++ programs come from issues with memory management

I disagree with that claim. At least it's not what I'm suffering the most from. They're among the longest ones to debug though. Most problems I'm seeing actually result from undefined behaviors (especially recently when compilers started to abuse them to win the compilers war), and problems with integer type promotion that's a real mess in C, and that started to turn something bening into real bugs with the arrival of size_t everywhere and 64-bit machines while dealing with plenty of APIs written for ints. These ones are often considered to be memory management issues because they result in buffer overflows and so on but they actually are not at all.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 13:14 UTC (Mon) by HelloWorld (guest, #56129) [Link] (10 responses)

So what trade-off is that? What does it buy you not to prevent resource leaks and use-after-free bugs statically? Really the only answer I can think of is that it makes the language easier to learn. So you save perhaps a couple of weeks of fighting with the borrow checker in order to later spend months debugging leaks and use-after-free issues – assuming you even find them before they cause a production outage and cost you millions of dollars. That doesn't seem like a good trade-off to me.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 13:20 UTC (Mon) by ddevault (subscriber, #99589) [Link] (9 responses)

The trade-offs come in the form of the complexity of the language and its implementation, which in Rust's case is utterly out of control. I'm not convinced that borrow checking cannot be done more simply - we intend to research this for Hare - but it's not the holy grail of programming which creates a moral lower class among other language, as the Rust adherents in this thread seem to believe.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 18:17 UTC (Mon) by linuxrocks123 (subscriber, #34648) [Link] (5 responses)

How about this: keep track of all the pointers in the runtime, and, when a memory region is freed, replace all the pointers that refer to it with NULL. Then, if anyone tries to do a use after free, they'll get an immediate crash. This wouldn't be a feature you'd want to have turned on for production code, but it could help a lot during development and testing, and it would avoid burdening the programmer with additional borrow-checking rules. I hope, also, that you'll allow bounds checking and similar features to be turned off after debugging and testing are done: I'd rather not pay the cost of those debugging aids in production.

The reception you've gotten from others in this comment section is very unfortunate, although, given the people involved, I'm also not terribly surprised they're acting this way. A good philosophy for handling negativity from ignorant, opinionated blowhards is to just ignore them and keep doing what you love. I'm sure you'll make something great with Hare.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 18:19 UTC (Mon) by ddevault (subscriber, #99589) [Link] (4 responses)

>How about this: keep track of all the pointers in the runtime

This is a non-starter, it's too expensive. Interesting idea, though. We are planning on writing an optional debug allocator which will address many memory-related bugs, such as use-after-free, in a similar manner to valgrind.

> The reception you've gotten from others in this comment section is very unfortunate, although, given the people involved, I'm also not terribly surprised they're acting this way. A good philosophy for handling negativity from ignorant, opinionated blowhards is to just ignore them and keep doing what you love. I'm sure you'll make something great with Hare.

Thanks :)

DeVault: Announcing the Hare programming language

Posted May 2, 2022 18:53 UTC (Mon) by linuxrocks123 (subscriber, #34648) [Link] (3 responses)

> This is a non-starter, it's too expensive.

What if you used a pool allocator to separate the pointers from the non-pointers? That would add a level of indirection to structs that had pointers, since they'd have to be converted to pointers to pointers, and also to pointers on the stack, since ditto. But then you'd have a nice contiguous array of all your pointers that you'd just have to scan upon calls to free, and you might be able to use SIMD for that.

If you've thought of that and it's too expensive, I'll stop now, but I just thought I'd mention it in case you hadn't thought of it :)

DeVault: Announcing the Hare programming language

Posted May 2, 2022 18:55 UTC (Mon) by ddevault (subscriber, #99589) [Link]

I don't have time to give this idea the thought it deserves right now, but thanks for sharing. Added it to my notes for improvements to allocator insights.

Use-after-free checking at low runtime cost

Posted May 4, 2022 1:12 UTC (Wed) by akkartik (guest, #158307) [Link] (1 responses)

Since you seem interested in this space, I'll throw out one idea I particularly like and have used in a project [1]: manage heap allocations using a fat pointer that includes an allocation id. The pointer contains the allocation id and so does the payload. Every dereference of the fat pointer compares the allocation id in the pointer and payload. Freeing an allocation resets its allocation id. Future allocations that reuse the allocation will never generate the same allocation id. A use-after-free dereference then leads to an immediate abort, which is easier to debug and more secure.

The overhead of this scheme is too great for most C/Rust programmers, but I think it's much lower than tracking all pointers or indirections in structs containing pointers.

[1] https://github.com/akkartik/mu

Use-after-free checking at low runtime cost

Posted May 4, 2022 13:22 UTC (Wed) by HelloWorld (guest, #56129) [Link]

The best that a run-time check for this sort of thing can do is turn one bug into a different kind of bug, at a considerable performance cost. While that can be useful for legacy programming languages like C (primarily as a debugging tool), it's simply the wrong approach for new languages. Modern programming language design should be focused on statically preventing bugs, and messing around with run-time checks is simply a waste of time.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 19:54 UTC (Mon) by HelloWorld (guest, #56129) [Link] (1 responses)

> I'm not convinced that borrow checking cannot be done more simply - we intend to research this for Hare
I don't think something this fundamental can be retrofitted. It specifically says on the Hare website that you intend to place a strong emphasis on backward compatibility, which means that once programs with lifetime issues (leaks/use-after-free) are out there, the compiler needs to be able to compile them, and thus the same bugs can occur in new code as well.

I wish you well with your efforts regarding a simpler borrow checker.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 19:57 UTC (Mon) by ddevault (subscriber, #99589) [Link]

To be clear, we're only committed to backwards compatibility following 1.0. Borrow checker research will be done prior to 1.0.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 23:57 UTC (Mon) by roc (subscriber, #30627) [Link]

Optimizing for a simpler language and implementation makes sense when your audience is mostly the people working on the language and implementation. It makes less sense when your audience is mainly people developing in the language, and even less sense when you also consider users of software developed in the language.

Language simplicity is good for developers, of course, but absence of memory corruption and data races provides another kind of simplicity. (And I think Rust is relatively free of the kind of "accidental" complexity that C and C++ are full of.)


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds