Futhark 0.20.1 released, with reflections on stability
A language is a medium of communication, and it serves its purpose best when it doesn’t change too often. This is the case both when the recipient is a human and when it is a machine. I’ve always been attracted to the idea of very stable programming languages where tools and implementations continue to improve behind the scene, but programs keep working as they always have. There’s something delightful about being able to effortlessly compile a C or SML program from the 90s.
Of course, most of the languages I actually use do not work that way. In practice, a stable language is a stale language, and our reliance on third party libraries (and their associated hosting platforms) also makes source code bitrot rapid. This is not necessarily a big problem - it’s more likely that my appreciation of stability is more of a nostalgic affectation. In related news, we made a new Futhark (full changelog here). I already wrote about two of the additions made since the last major version:
A few other highlights:
A memory usage optimisation that lowers general memory footprint (by Philip Munksgaard, and we’ll write lots more about this in the future).
Significantly faster segmented scans in the CUDA backend, due to Morten Tychsen Clausen.
The
tracefunction (and its intended replacement, the#[trace]attribute) now also works in compiled code.A huge number of bug fixes.
Based on our idiosyncratic interpretation of semantic versioning, the version number implies that we changed the language somehow. So what changed? Mostly small fiddly things:
Changes to infix operators, mostly that you cannot define your own function called
!anymore.A change to a parameter type in a C API function that nobody has ever used.
Futhark is a research language, and it has never really been stable,
nor expected to be. But I always hoped we would eventually reach a
point where the surface language solidified, and most improvements
would subsequently happen internally. I think we are close to
something like that. Most of the design
flaws have been fixed. The
last time we broke most Futhark programs was in 0.18.1, about a year
ago, where we changed the type of all sizes from i32 to i64.
Before then, the last major change was in 0.15.1 (March 2020), which
added size-dependent
types -
and broke many programs. Before that, we frequently changed many
things radically. I particularly recall when we moved from f(x,y)
notation for function calls to f x y, since I had to semi-manually
update just about every program we had.
I do get the feeling that Futhark has stabilised now. No major known issues remain that will have to be addressed with compatibility-breaking changes in the future. As Futhark is a research language, I still find it very likely that we will add major few features, particularly to the type system, but actually removing or breaking things should be rare. We’ll see.