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

DeVault: Announcing the Hare programming language

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

One thing that makes Hare stand out from other new languages: excluding any kind of generics from the language, and also not providing a built-in generic hashtable type --- instead telling developers to reimplement hashtables wherever they need one: https://harelang.org/blog/2021-03-26-high-level-data-stru...
Though at least they don't expect you to reimplement sorting as well:
https://docs.harelang.org/sort
though the API is very old-school C.

Personally I kinda doubt that this extreme focus on the simplicity of the language (at the expense of security, and making basic stuff like hashtables more work to use, and taking a performance hit for not using a modern compiler backend) is going to appeal to many people who just want to *use* a programming language. We'll see I guess.

to post comments

The illusion of apparent simplicity

Posted May 2, 2022 10:50 UTC (Mon) by atnot (guest, #124910) [Link] (18 responses)

I feel like there's an unfortunate thing that C-derived languages and projects often do where they confuse the simplicity of something with the simplicity of it's implementation. As the waterbed theory points out, a lot of the time, making something simple creates a lot of complexity elsewhere. Simplicity, to the programmer, is about being able to build good mental models, but the real world is rarely simple to begin with and making things smooth often takes significant effort to fill in the cracks.

Confusing the simplicity of the program with the simplicity of it's implementation lets you instead frame your refusal to address complex problems as a virtue and push all of the burden on your users instead.

The illusion of apparent simplicity

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

Simplicity of the implementation is part of your total complexity cost, plain and simple. You cannot offload simplicity onto a vendor. All of the code in your system is your responsibility, and less code == fewer bugs.

The illusion of apparent simplicity

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

Less code in the language system means more code elsewhere. Complexity is irreducible, but addressing it in a place subject to concentrated attention mitigates risk.

Hare, like Zig and C, offers nothing to help concentrate attention on solutions that programs may rely on. C++ and Rust both do, by supporting encapsulating complexity in powerful libraries that amortize focused attention -- debugging, optimization, comprehensive testing -- across all uses. C++ offers more native language power for the programmer to express intentions clearly and concisely, while Rust builds in compiler support for protecting against errors common in languages like C and Hare. Both further provide well-tested standard libraries that already encapsulate a huge amount of the unavoidable complexity programs must have to deliver essential service.

The illusion of apparent simplicity

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

> Less code in the language system means more code elsewhere. Complexity is irreducible, but addressing it in a place subject to concentrated attention mitigates risk.

This is grossly false. Programming is an art form in exceptionally wasteful complexity. It is *not* irreducible, rather we are living in an era of gross negligence on the part of engineers who don't bother to reduce it. Yes, a C++ or Rust x86_ArrayVectorMap<Optional<int>> will outperform []int. But it will have 10x the surface area for bugs - including security bugs - and in 99 cases out of 100 the extra performance and supposed ease of use (leaving aside ease of debugging, which suffers immensely) *just isn't needed*.

The illusion of apparent simplicity

Posted May 2, 2022 14:00 UTC (Mon) by ncm (guest, #165) [Link] (7 responses)

People who fail to understand failures past are doomed to repeat them. Hare repeats them, and sets up users to repeat them, indefinitely.

The illusion of apparent simplicity

Posted May 2, 2022 14:02 UTC (Mon) by ddevault (subscriber, #99589) [Link] (6 responses)

>People who fail to understand failures past are doomed to repeat them.

Precisely my thoughts on Rust.

The illusion of apparent simplicity

Posted May 2, 2022 15:07 UTC (Mon) by ncm (guest, #165) [Link] (5 responses)

Hare addresses none of the problems solved by Rust. It addresses none of the problems solved by C++. It is not evidently meant for Go, Java, or Swift coders. C coders will not want it, because it is not C.

So, its natural competition is Zig. Which of what Zig attempts does Hare not? Does Hare bring anything to the table that Zig does not?

Your indictment of x86_ArrayVectorMap<Optional<int>> might bite if in fact you could identify so much as a single bug, never mind security hole, caused by reliance on it in preference to a less featureful feature.

There is nothing wrong with putting forward a new thing to address old problems. Go and Java addressed old problems by presenting a weaker language explicitly meant for weaker programmers. C++ and Rust address them by presenting a powerful language meant for serious professionals. There is, manifestly, room for all of them.

In a language promoted in a top-level LWN article, I just want to see some indication that its author has enough understanding of old problems and current solutions not to un-solve what is already solved elsewhere, and maybe try to solve others not solved elsewhere. Thus far I am not seeing that.

The illusion of apparent simplicity

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

Your sensibilities to not define LWN's scope, at least not so far as I'm aware. A "development quote", which are footnotes in the weekly editions, is also far from a "top-level LWN article".

If Hare does not appeal to you, then do not use it. You have a different set of values than Hare, so I cannot pose its benefits in a way that you will understand, since you view many of them as demerits. Hare does not aim to make any other language obsolete, keep using whatever you like and Hare will be enjoyed by those to whom it appeals.

The illusion of apparent simplicity

Posted May 4, 2022 10:18 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (3 responses)

You haven't answered his question, though.

Who is Hare designed to appeal to, and what does Hare bring to the table for them that Zig does not?

The illusion of apparent simplicity

Posted May 4, 2022 10:22 UTC (Wed) by ddevault (subscriber, #99589) [Link] (2 responses)

Hare is much simpler than Zig, and can do similar tasks. It's has 1/10th the lines of code and both the language and standard library have a more narrowly defined, fixed scope which will not grow in complexity with time. Hare is a more conservative project than Zig and aims to provide a more robust and reliable basis for software built on it for the long-term. A Hare program written on the day of the 1.0 release will still compile and run correctly in 50 years. A Hare *compiler* written on the day of the 1.0 release will still compile new code written 50 years from now.

There are many differences between them, but the core philosophical differences boil down to this.

The illusion of apparent simplicity

Posted May 4, 2022 11:36 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (1 responses)

> Hare is much simpler than Zig, and can do similar tasks

No, it cannot. For example it cannot do async/await.

> A Hare *compiler* written on the day of the 1.0 release will still compile new code written 50 years from now.

Thanks for proving that you aren't learning from past mistakes, I guess.

The illusion of apparent simplicity

Posted May 6, 2022 7:23 UTC (Fri) by ddevault (subscriber, #99589) [Link]

I was not referring to a similar set of language features, but a similar set of supported use-cases.

The illusion of apparent simplicity

Posted May 2, 2022 16:36 UTC (Mon) by kleptog (subscriber, #1183) [Link] (1 responses)

I think the point was slightly different: when solving a problem that problem comes with a certain amount of complexity and that complexity is irreducible if you still want to solve them problem.

If you're writing an HTML parser, a YAML parser, a TLS library, an X.509 parser, the program will contain a certain amount of complexity which cannot be removed while still actually solving the problem. So the question is really: does a programming language allow you to express this complexity without requiring lots of additional overhead complexity.

Writing a YAML parser in Assembler is clearly insane, for example. Processing text files with Awk works really well because that's what it was designed for.

In this day and age, *no-one* should be out there writing their own X.509 parser or TLS library unless you really have a brand new use case that is core to your program. Just import a library and get on with your life. Now, a leftpad library is obviously overboard, but importing libraries to handle complexity that you don't want to deal with yourself is a good thing and shouldn't be discouraged.

The illusion of apparent simplicity

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

> If you're writing an HTML parser, a YAML parser, a TLS library, an X.509 parser, the program will contain a certain amount of complexity which cannot be removed while still actually solving the problem. So the question is really: does a programming language allow you to express this complexity without requiring lots of additional overhead complexity.

I actually agree with this take. And we do intend to implement all of these things, actually, except perhaps YAML, which is a den of snakes (so is X.509, but one we unfortunately cannot avoid). However, I don't think these use-cases call for much re-usable logic beyond what Hare already offers, unless someone seeks to implement a parse-them-all abstraction, which I would consider highly misguided. The level of complexity of such implementations in Hare will, I think, map relatively closely onto the minimum required level of complexity. We aim to provide exactly the right number of primitives to support robust implementations, and no more.

Hare does provide several features to help with this sort of thing, by the way. For example, quoting the author of Monocypher on Hare's use of slices for cryptography:

> I like that (apparently) slices are used for the API. Having written a cryptographic library in C, I saw how we are reading from and writing to buffers all the time, and having to specify their length explicitly means my functions have many more arguments than I would have liked.

Other primitives in the stdlib also encourage good/robust design, such as bufio, and things like mandatory error handling ensure you never accidentally forget to verify that some authenc data was actually authenticated.

The illusion of apparent simplicity

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

False.

Code that is relied on by more programs gets more attention to its reliability, safety, and performance, as the wider use allows amortizing that attention across all uses. This applies to commonly used libraries, moreso to language-standard libraries, and even more to compilers themselves.

A language like Hare, Zig, or C that is inadequate to express powerful libraries necessarily dissipates attention across all the re-implementations of semantics that could have been coded once, in one place, and got right once. Modern languages deliver their value by enabling that expression. A new language that fails to deliver what we have already learned to do in this direction is, at best, an attractive nuisance.

C has a ready excuse: its roots are in the 1960s. We should have higher expectations for a language coming more than five decades later. Hare utterly fails to deliver on any such expectations. It has no legitimate claim on our attention.

The illusion of apparent simplicity

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

Then don't give it your attention. I'm not convinced that we would substantially benefit from it in any case.

Let's calm this down a bit please

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

Discussion of Hare language features, strengths, and weaknesses is clearly appropriate here. But please let's try not to get into language-advocacy flamewars, that really doesn't help.

Thank you.

The illusion of apparent simplicity

Posted May 3, 2022 0:48 UTC (Tue) by roc (subscriber, #30627) [Link]

Code that is used and tested by thousands of people is much less of a problem than code that is used and tested by only a few people. Just adding up all the code complexity over the entire system and trying to minimize that objective function is not the right way to go. If it was, you wouldn't use Linux.

> less code == fewer bugs.

Requiring everyone to reimplement hash tables at every use will not be "less code" or "fewer bugs".

The illusion of apparent simplicity

Posted May 3, 2022 20:22 UTC (Tue) by ssokolow (guest, #94568) [Link]

I'm reminded of this Bryan Cantrill quote:

When developing for embedded systems — and especially for the flotilla of microcontrollers that surround a host CPU on the kinds of servers we’re building at Oxide — memory use is critical. Historically, C has been the best fit for these applications just because it so lean: by providing essentially nothing other than the portable assembler that is the language itself, it avoids the implicit assumptions (and girth) of a complicated runtime. But the nothing that C provides reflects history more than minimalism; it is not an elegant nothing, but rather an ill-considered nothing that leaves those who build embedded systems building effectively everything themselves — and in a language that does little to help them write correct software.
-- http://dtrace.org/blogs/bmc/2020/10/11/rust-after-the-honeymoon/

DeVault: Announcing the Hare programming language

Posted May 3, 2022 13:24 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

Sort is interesting because it says it is (or at least, that it might be, and since this isn't 1.0 let us assume it is) an allocating sort, but it doesn't say whether it's stable. I presume it's a stable sort.

I feel like the kind of people who might actually care about the micro-managing needed to be effective in a language like Hare probably want at least the option of an in-place (ie not allocating) sort, even if it's unstable. After all, if you're actually sorting, say, integers, you certainly don't care about stability but you might care about the allocation cost.

Hashtables are hard, and there is a lot of opportunity to either malfunction or mistakenly destroy your performance, which is a reason that Rust - which (contrary what is sometimes suggested) actually mercilessly weeded out less useful or necessary data structures for the standard library in 1.0 - still has HashMap and HashSet long after special use structures like LruCache were put out to pasture. You're going to implement HashMap<Key,Value> and once you've done that why not HashSet = HashMap<Key,()> and do the extra lifting for the set-like methods ?

The "modcache" built in the Hare example is an old-school bucketed hash, but with a fixed number of dynamically growing buckets. I assume that in practice Hare would work fine with just a simple vector here anyway, but if not "modcache" is leaving a lot of performance on the floor. In the process of doing that, it also seems to have a nasty bug. If we have two modules with identical hashes (not difficult to arrange for the hashes provided with Hare, there is no SipHash) then it seems to me that ...

if (bucket[i].hash == hash) {return bucket[i].task; }

... never checks this is actually the same module, only that it has the same hash.