Hacker News Reader

Comment by earenndil | Hacker News Reader

Honestly, if it's not intended for general use, I don't think it's worth it to complicate the build process, and complicate the process of setting up a dev environment by installing a whole new compiler toolchain just for a couple of small functions.

View on HN

While I agree with your point of view regarding production code, it is this continuous ongoing effort of such language designers that eventually (with a bit of luck as well) turn a programming language from "yet another one" to something relevant.

> Thus, even were Futhark to become the indisputably best language in its area - which is certainly the goal! - the user base would still be small, and so would the development resources.

Exactly. If I'm selecting a language for any critical components, it's going to be one with a strong community, not something obscure that might be a little less verbose or a little more performant.

What if it's a lot more performant? It's of course always a risk to incorporate another language, but sometimes performance is a critical feature, yet you have no time or inclination to write (say) low-level GPU code by hand. Futhark is more of an alternative to CUDA or OpenCL than to high-level languages.

Also, there is the important property that Futhark programs tend to be fairly small, and are semantically close to ordinary functional programming. Thus, even in a worst case situation where the Futhark compiler is abandoned, it is a reasonable task to simply rewrite all the code in another high-level language.

> sometimes performance is a critical feature, yet you have no time or inclination to write (say) low-level GPU code by hand

I also have no time or inclination to integrate an entirely new tool into my build chain, complicate and lengthen the build process, and increase the cognitive load required to begin working on the project.

Sure, that's a fine judgment for most applications. That's exactly why high-performance languages (of any kind) necessarily must remain somewhat niche.

Although I will point out that the point of this post is exactly to try to minimise the build system complication and cognitive load as much as possible, so Futhark will be useful to just slightly more projects.

That's probably why they focussed on making the compiler as simple and straightforward to use as possible, so it does not significantly increase the complexity of your build process.

You would still need to wrap it in some form for it to be useable from most other build systems except make. For build systems such as bazel this is quite some work for little immediate benefit.

That's totally fine.

Futhark is an offer for people that need high performance code, but could spend their time on better things than writing CUDA/OpenCL code by hand.

Clearly that's not everyone. Maybe you don't need high performance code. Maybe you need to squeeze every last bit of performance out of your GPUs, so you actually need to spend time writing your own CUDA/OpenCL code.

So while it might not be worth it for you, it might be worth it for people trying to solve other kinds of problems :)

Reply on news.ycombinator.com