Posted on February 2, 2026 by Troels Henriksen

Futhark 0.25.35 has just been released (or perhaps escaped). I used to make a post like this for most releases, but it has actually been over two years and 30 releases since the previous announcement. Is this because Futhark has stopped changing? In a way it is: we also have not had a change to the middle version number (25) in two and a half years, which implies that the language has been stable for that long. This means that programs written two and a half years ago should still work, and in practice the changes made in 0.25.1 did not make many (if any) programs invalid - they merely extended what you can do. Skimming through the changelog, it seems that 0.22.1 was the most recent version to make a truly user-visible change (by removing some prelude functions that nobody used). In 0.21.1, we made def a reserved word, which certainly broke some reasonable code. In 0.20.1 we fiddled with some edge cases of unary operators (and made some related changes to the prelude), which I think is perhaps the last gasp of Futhark’s once instability. It really has been a fairly stable language for quite a while now.

That does not mean nothing changes, of course. Since Futhark in its current form is a pretty good (if still imperfect) language for data parallel programming, we do a lot of investigation into parallel algorithms where Futhark is merely a tool. William Henrich Due, a PhD student here at DIKU, has recently done work on data parallel algorithms for hash maps and union-find structures (draft paper on the former), a lot of which ends up in the containers package for Futhark.

Futhark itself also improves, of course. Version 0.25.35 has seen substantial improvements in its tooling, mainly due to code contributions from VegOwOtenks. In particular, futhark profile now produces far more useful information, such as heat maps of the program source code, that shows where the run-time is spent. This has already proven useful during human trials in our course on data-parallel programming, where some students used it to analyse the code they wrote as part of their final projects. The work is built on top of the improvements to tracking source locations made last year, although there are still cases where it does not work so well. VegOwOtenks has also added additional features to Futhark’s language server (exposing the formatter), and judging by the open pull requests, will make several more. The language server was written by a student in the first place, and is perhaps the most prominent component of Futhark that is primarily written by non-core hackers (although I certainly use it every day through Eglot).

Another nice improvement is by Amirreza Hashemi, a student at DTU, who improved the implementation of scan for the multicore backend through an approach described in this paper, which is largely written by the contributors to Accelerate. This was quite thorough work, that explored some of the edge cases about what should be done when the operator or input preprocessing is complicated. I think some work remains to be done here, but scans are in most cases quite a bit faster now, which is always good.