DeVault: Announcing the Hare programming language
DeVault: Announcing the Hare programming language
Posted May 2, 2022 10:38 UTC (Mon) by ddevault (subscriber, #99589)In reply to: DeVault: Announcing the Hare programming language by roc
Parent article: 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.
Posted May 2, 2022 11:36 UTC (Mon)
by ddevault (subscriber, #99589)
[Link] (4 responses)
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.
Posted May 2, 2022 13:56 UTC (Mon)
by ncm (guest, #165)
[Link] (2 responses)
It is 2022, not 1972. Bring something new and valuable to the table. Don't waste our time on 1970s retreads.
Posted May 2, 2022 13:58 UTC (Mon)
by ddevault (subscriber, #99589)
[Link] (1 responses)
Posted May 2, 2022 14:02 UTC (Mon)
by corbet (editor, #1)
[Link]
Posted May 2, 2022 23:48 UTC (Mon)
by roc (subscriber, #30627)
[Link]
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?
Posted May 2, 2022 16:40 UTC (Mon)
by wtarreau (subscriber, #51152)
[Link]
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.
Posted May 2, 2022 13:14 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (10 responses)
Posted May 2, 2022 13:20 UTC (Mon)
by ddevault (subscriber, #99589)
[Link] (9 responses)
Posted May 2, 2022 18:17 UTC (Mon)
by linuxrocks123 (subscriber, #34648)
[Link] (5 responses)
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.
Posted May 2, 2022 18:19 UTC (Mon)
by ddevault (subscriber, #99589)
[Link] (4 responses)
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 :)
Posted May 2, 2022 18:53 UTC (Mon)
by linuxrocks123 (subscriber, #34648)
[Link] (3 responses)
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 :)
Posted May 2, 2022 18:55 UTC (Mon)
by ddevault (subscriber, #99589)
[Link]
Posted May 4, 2022 1:12 UTC (Wed)
by akkartik (guest, #158307)
[Link] (1 responses)
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.
Posted May 4, 2022 13:22 UTC (Wed)
by HelloWorld (guest, #56129)
[Link]
Posted May 2, 2022 19:54 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (1 responses)
I wish you well with your efforts regarding a simpler borrow checker.
Posted May 2, 2022 19:57 UTC (Mon)
by ddevault (subscriber, #99589)
[Link]
Posted May 2, 2022 23:57 UTC (Mon)
by roc (subscriber, #30627)
[Link]
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.)
DeVault: Announcing the Hare programming language
DeVault: Announcing the Hare programming language
DeVault: Announcing the Hare programming language
DeVault: Announcing the Hare programming language
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.
*Sigh*
DeVault: Announcing the Hare programming language
DeVault: Announcing the Hare programming language
DeVault: Announcing the Hare programming language
DeVault: Announcing the Hare programming language
DeVault: Announcing the Hare programming language
DeVault: Announcing the Hare programming language
DeVault: Announcing the Hare programming language
DeVault: Announcing the Hare programming language
Use-after-free checking at low runtime cost
Use-after-free checking at low runtime cost
DeVault: Announcing the Hare programming language
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.
DeVault: Announcing the Hare programming language
DeVault: Announcing the Hare programming language