THTheWiggles·Jul 10, 2025
Those are two different projects. This is the Futhark lang page https://github.com/diku-dk/futhark and it's mainly Haskell.
In Futhark – Automatic C imports in Nimdiku-dk
futhark
Haskell2017–2025
diku-dk / futhark
futhark
:boom::computer::boom: A data-parallel functional programming language
6Distinct people
7Mentions
0Explicit recommenders
2.8KGitHub stars
What to know before exploring
What it is
:boom::computer::boom: A data-parallel functional programming language
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year7 dated mentions
Observed mentions: 2017-09-26 21:10:13 UTC to 2025-07-10 07:05:32 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
7 sourcesThere is no on-going work to support Metal apart from the work done by Miles. There's an old issue about it: https://github.com/diku-dk/futhark/issues/853#issuecomment-5...
In GPU Programming: When, Why and How?We actually have a long-standing issue regarding WebGPU[0]. Long story short, we want to support it, and Athas did some exploratory work a couple of years ago and decided that WebGPU wasn't mature enough yet. We already have a WebAssembly backend, so as soon as it is possible to access WebGPU from WebAssembly it should be relatively straightforward.
[0]: https://github.com/diku-dk/futhark/issues/1403
In GPU Programming: When, Why and How?This is both a comprehensive guide, and an excellent reference! I use it often when writing SML for side projects.
For those interested in parallel, functional programming, I recommend taking a look at Futhark, which leverages data parallelism to make very fast parallel programs. It is based on SML, and has similar syntax, but can automatically build programs that (among other targets) run on the GPU using CUDA or OpenCL. It is also worth checking out MPL, which extends the (already awesome) whole-program optimizing compiler MLton to add support for nested, fork-join parallelism.
https://github.com/diku-dk/futhark
https://github.com/MPLLang/mpl
In Programming in Standard ML (2011) [pdf]no native Windows support:
https://github.com/diku-dk/futhark/issues/1761
In Array short-circuitingI cannot overstate the importance of using a programming language targeting GPUs directly like Futhark (https://github.com/diku-dk/futhark). In this case, it is a functional, declarative language where you can focus on the why, not the how. Just like CPUs are incredibly complex, higher level abstractions are very important.
If you were a pro GPU programmer and had 10 years, Futhark would be maybe 10x slower. But just like we do not program in assembly when making critically fast software, most non-simple things are easier written in this.
In Generic GPU KernelsWe already have both a radix sort[0] and a bitonic merge sort[1]. They perform alright - nothing world-shaking, but fine. I was more interested in whether string sorting has some particularly clever algorithms.
[0]: https://github.com/diku-dk/futhark/blob/master/futlib/radix_...
[1]: https://github.com/diku-dk/futhark/blob/master/futlib/merge_...
In Calling Futhark from C and Haskell