I always enjoy these write-ups on porting or developing on OpenBSD. They tend to frequently involve doing something, or doing something slightly incorrectly, and once tweaks are made the end result is usually more security or better quality code, and allowing the OpenBSD system to do what it was designed to do.
"Hare is a systems programming language designed to be simple, stable, and robust. Hare uses a static type system, manual memory management, and a minimal runtime. It is well-suited to writing operating systems, system tools, compilers, networking software, and other low-level, high performance tasks. " [0]
For me, the most amazing feature of hare is its commitment to long-term stability [0]. Backwards compatibility is universally acknowledged to be a good thing, but hare proposes a much more revolutionary idea: forward compatibility.
"A Hare program written on the day that 1.0 releases will still compile in 50 years on contemporary Hare compilers. In fact, a Hare compiler written on the same release date will compile new Hare programs 50 years from now. That’s something which hasn’t really been done before, and I’m looking forward to seeing it usher in a renewed commitment to stability and long-term reliability in the software ecosystem."
> A Hare program written on the day that 1.0 releases will still compile in 50 years on contemporary Hare compilers. In fact, a Hare compiler written on the same release date will compile new Hare programs 50 years from now. That’s something which hasn’t really been done before [snip]
Because fifty years ago, 16-bit systems and 36-bit systems were still commercially interesting. Code meant to be performant on systems with 36-bit words and 18-bit pointers, where it's possible to operate on arbitrary bitfields within a word using native opcodes, would probably not fare well on systems from a later era, where a machine word is a power-of-two multiple of eight, a pointer is a machine word, and a byte is eight bits practically by definition.
It's taken decades to nail down the fundamental shape of the basic machine-level data types. We weren't there yet in the early 1970s.
I get what you're saying, but I don't think you've identified the problem correctly: with the proper programming abstractions, it shouldn't matter what the word size or byte size of the machine is. The problem with code from that era is that compilers were as anemic as the processors that they ran on, so there was not a lot of room (and experience, as you say) to conceive programming languages that were fully decoupled from the software architecture (someone will come in now and shout LISP).
We still have that same problem today when it comes to vector code (and graphics/LLM/tensor processing): the abstractions we use are tightly coupled to the hardware capabilities, which means lots of redesign surrounding the compiler and code structures every time a new hardware iteration comes out. I fully expect that in another 10-20 years, our current approach to vector programming will look as primitive as how we look at system code from 50 years ago.
So while Hare may still be able to compile single-issue imperative code 50 years from now, I don't think it's too far left-field to posit that the sequential/imperative paradigm we use now might end up being replaced with different processing/signaling paradigms on both the language design and the processor design front, leaving Hare as nothing but a quaint footnote like B.
Fulfilment of such a commitment is impressive. But the commitment itself is of very little value. Marriage comes with commitment vows, many of them end in divorce and a large number of those divorces are because one or both partners broke the commitments.
So far Hare 1.0 doesn't exist, so the clock hasn't even started. Neither the hypothetical Hare program, nor the hypothetical Hare compiler exist. It's true that it hasn't been done before by any language but it also just hasn't been done at all.
It's funny, because OpenBSD is the system that's the most happy to force a change on a program (usually for very good reasons, like disallowing W|X memory). I'd love to see Hare try it though.
Yeah, but if the language is fighting libc etc. this hard I have severe doubts that it'll actually be stable or robust, and it has already given up on simplicity.
Mmm. Suitability claims seem premature. Is this brown liquid I have "well suited" as a condiment, toilet cleaner, beverage and engine coolant? Maybe, but I think I should try at least some of these uses in anger before I make such bold claims for it. Reckon I'll check it's a good beverage first.
Hare is from the same era as various "C++ Successor Languages" announced in 2022. It has a few years yet before we might sensibly write it off as never going anywhere, but it also hasn't done very much with its time so far. Its "draft specification" document still has a 2022 copyright for example.
Its authors acknowledged and fixed a bug that I found in their "example" of why they don't need generics, but of course that kind of misses the point - using generics wouldn't incur this global risk, fix it once and fix it everywhere, hand roll it each time, bugs every single time.
11 comments
[ 2.8 ms ] story [ 29.2 ms ] thread"Hare is a systems programming language designed to be simple, stable, and robust. Hare uses a static type system, manual memory management, and a minimal runtime. It is well-suited to writing operating systems, system tools, compilers, networking software, and other low-level, high performance tasks. " [0]
[0] https://harelang.org/
"A Hare program written on the day that 1.0 releases will still compile in 50 years on contemporary Hare compilers. In fact, a Hare compiler written on the same release date will compile new Hare programs 50 years from now. That’s something which hasn’t really been done before, and I’m looking forward to seeing it usher in a renewed commitment to stability and long-term reliability in the software ecosystem."
[0] https://harelang.org/blog/2022-11-27-hare-is-boring/
Because fifty years ago, 16-bit systems and 36-bit systems were still commercially interesting. Code meant to be performant on systems with 36-bit words and 18-bit pointers, where it's possible to operate on arbitrary bitfields within a word using native opcodes, would probably not fare well on systems from a later era, where a machine word is a power-of-two multiple of eight, a pointer is a machine word, and a byte is eight bits practically by definition.
It's taken decades to nail down the fundamental shape of the basic machine-level data types. We weren't there yet in the early 1970s.
We still have that same problem today when it comes to vector code (and graphics/LLM/tensor processing): the abstractions we use are tightly coupled to the hardware capabilities, which means lots of redesign surrounding the compiler and code structures every time a new hardware iteration comes out. I fully expect that in another 10-20 years, our current approach to vector programming will look as primitive as how we look at system code from 50 years ago.
So while Hare may still be able to compile single-issue imperative code 50 years from now, I don't think it's too far left-field to posit that the sequential/imperative paradigm we use now might end up being replaced with different processing/signaling paradigms on both the language design and the processor design front, leaving Hare as nothing but a quaint footnote like B.
Hare wants forwards compatibility, for which the equivalent statement for Go would be "Go 1.21.4 code will compile with the Go 1.0 compiler".
So far Hare 1.0 doesn't exist, so the clock hasn't even started. Neither the hypothetical Hare program, nor the hypothetical Hare compiler exist. It's true that it hasn't been done before by any language but it also just hasn't been done at all.
Hare is from the same era as various "C++ Successor Languages" announced in 2022. It has a few years yet before we might sensibly write it off as never going anywhere, but it also hasn't done very much with its time so far. Its "draft specification" document still has a 2022 copyright for example.
Its authors acknowledged and fixed a bug that I found in their "example" of why they don't need generics, but of course that kind of misses the point - using generics wouldn't incur this global risk, fix it once and fix it everywhere, hand roll it each time, bugs every single time.