DeVault: Announcing the Hare programming language [LWN.net]

DeVault: Announcing the Hare programming language

Posted May 2, 2022 18:22 UTC (Mon) by wtarreau (subscriber, #51152)
In reply to: DeVault: Announcing the Hare programming language by ddevault
Parent article: DeVault: Announcing the Hare programming language

The point to keep in mind is that the vast majority of code written in modern languages is copy-pasted from stackoverflow or even probably github copilot because these languages are so painful and stubborn that when you don't know how to express something that sounds simple and the compiler refuses, you have to attack it another side and at some point you run out of ideas. And *that* is exactly the problem: users getting used to blindly copy-pasting code before thinking rarely read the doc. In certain programs it's so obvious that the function doesn't even do what its name suggests, or it fails to produce correct outputs for some special values. If your crypto lib relies only on the doc, there will be failures in field, in either direction (too strict or too lose). Instead, pass an argument so that the user explicitly expresses their intent, e.g. opportunistic or mandatory. This way if they fail after copy-pasting, well, there's hardly anything more that can be done to save them from seeking a totally different job that doesn't involve a keyboard (nor a mouse).

to post comments

DeVault: Announcing the Hare programming language

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

Accommodating negligent programmers are a use-case we have deliberately decided to eschew. A Rust programmer could equally come up with severely flawed code copy-pasting from StackOverflow, compilers cannot completely solve human stupidity.

Even so, we do not rely entirely on the docs. Again, crypto::keystore is just a small part of a larger secure system, and with defense in depth its failure is unlikely to be an issue. Using crypto::keystore on a system without secure kernel key management does not actually introduce a security bug - it just gives an opportunity for exploitation if you find *another* bug which allows you to read arbitrary memory from the process (the likelihood of which is prevented, again, defense in depth, by things like bounds-checked slices). Our other cryptographic APIs are also designed to make errors as unlikely as possible, such as via mandatory error handling and automatic zeroing of caller-provided private data.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 10:26 UTC (Tue) by peter-b (guest, #66996) [Link] (2 responses)

> Accommodating negligent programmers are a use-case we have deliberately decided to eschew.

Aww, shucks. As a programmer who sometimes writes less than perfect code, it sounds like Hare is not for me.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 10:27 UTC (Tue) by ddevault (subscriber, #99589) [Link]

There's a difference between negligence and simply writing poor code. I don't think this is worth writing Hare off over.

DeVault: Announcing the Hare programming language

Posted May 4, 2022 4:01 UTC (Wed) by timrichardson (subscriber, #72836) [Link]

That is so out of context it's not funny.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 19:48 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

> The point to keep in mind is that the vast majority of code written in modern languages is copy-pasted from stackoverflow or even probably github copilot

Interesting take. Any evidence for "vast majority of code"?

> because these languages are so painful and stubborn that when you don't know how to express something that sounds simple and the compiler refuses, you have to attack it another side and at some point you run out of ideas.

Ah, yes, because I enjoy having to figure out what data is tracked by which mutex manually (and somehow communicating this to everyone else that works in the vicinity) instead of the compiler saying "uh, hey, did you forget to consider threads here?". Yes, much better when I have to pick up someone else's debugging state to figure out what went wrong. Repeat for uninitialized data, memory management miscommunications, single-threaded code being improperly used from multiple threads[1], etc. </s>

If you're working in tricky areas, expect tricky code. I'd rather someone convince the compiler that they got it right instead of expecting anyone else coming along and fixing warnings or whatever tripping over those 3 lines that took an hour to get right because threads are hard and the comment was ignored by `clang-tidy -fix` and a rubber stamp review.

[1] I agree with you: docs are not enough, you need something more. Rust's `Sync` trait seems to do well enough.