First Thoughts on Hare2022-07-30
I've been poking around with Hare to kick the tires and see how the language is shaping up while it is still in heavy development. Here I note a few things I have found surprisingly pleasant.
Easy to Pick Up
I have something of a problem with programming languages. I can't not look into each and every one. Never mind the fact that TCL went out of fashion decades ago or that people think J looks like line noise; if you write a programming language I will at least read the documentation to get a feel for it. Unfortunately with Hare being so early in development there is a dearth of documentation outside of the tutorial.
For larger projects and more complex languages this may have been a sufficiently high barrier to make me put off looking any further. In the case of Hare though I found the language simple enough with logical choices (like making the language expression-oriented!) that I found reading the standard library etc. enough to give me a feel for things.
Welcoming to Contributors
I will admit, I am willing to give Hare a chance so early in development because it is one of Drew DeVault's projects and I've enjoyed contributing fixes to his projects in the past. It turns out Hare is no different. When I saw the release announcement I browsed through the bug tracker and saw a few things I figured I could fix. In a few hours I had picked up a ticket I was interested in, learned enough of the language to make a fix, added tests and sent a patch. Then I made another.
How many projects - open-source, proprietary or other can boast such an easy on-ramp?
What Works Well?
- leverage other tools (QBE, Valgrind, etc.)
While I have seen QBE mentioned before, probably in the context of cproc, I haven't given it much thought. Hare has changed that for me because of how small everything is. The Hare compiler is a front-end concerned with an intentionally small language leveraging a tiny back-end to generate efficient code. It works really, really well. If you have ever tried to go spelunking through LLVM or GCC you probably know what a nightmare any single trace ends up like. Hare and QBE are the exact opposite. It isn't that they aren't clever, they end up clever where it seems to matter. It is as though the 80/20 principle was distilled in a secret lab somewhere.
It may be that Hare gets this next one for free but it is a big one for me, personally. I don't need to find or learn many new tools to develop within it. My first patch to the standard library was to fix an issue with uninitialized memory flagged by Valgrind. I've used Valgrind before, I can work out how to fix whatever it is telling me. I have not used it as much but GDB seems to work with approximately as much effort. Having experienced the opposite with languages like Go, Hare is a breath of fresh air.
- integrated tests
This is probably a matter of taste but the way Hare integrates tests within the source file reminds me of Racket's integrated test submodules. I think the style is becoming more prevalent (I'm pretty sure I've seen it in the wild with Zig). It makes my own preferred development style really ergonomic, looking for call-sites and examples when making changes is just using your editor's search function (or
- principle of least astonishment
I read about the twenty year anniversary of Valgrind this week and have been thinking about how I might use it more. An opportunity presented itself today when I tentatively started re-writing some C code in Hare. I had a small program that ran but was hideously slow, rather than overthink things I thought I might see if Valgrind could make any sense of a compiled Hare program. It turns out it can without any work, I just invoked
valgrind --tool=callgrind my-programand it just worked. I spent maybe two minutes looking at just the number of calls per-function and realized my problem — Hare's regular expressions are POSIX extended regular expressions and thus don't have the option for non-greedy matches so something like
<h1>(.*)</h1>will give a pretty sweet example of Shlemiel the painter's algorithm. The fix is to either add something like
<h1>(.[^/]*)</h1>or the correct thing and give up on using regular expressions). I was able to confirm my intuition partly because the regular expression library is very straight-forward.
Thoughts So Far
I like it! While I don't have too many projects that need a systems programming language I see the appeal in this one. It feels very much like something which you can understand the entirety of. Reading about using io_uring within Hare was a nice read not because it demonstrates any great feat of the language but because it gets out of the way. My sense of Hare so far is that you can learn it and then get to work (probably with a copy of The Linux Programming Interface handy). For me personally that vision appeals greatly after spending so much of my life chasing down package conflicts and bugs in third-party libraries.