Porting Hare to OpenBSD
harelang.org
harelang.org
"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]
"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."
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.