Streaming Combinators and Extracting Flat Parallelism
futhark-lang.org
Streaming Combinators and Extracting Flat Parallelism
1–10 of 19 posts
Re: Streaming Combinators and Extracting Flat Parallelism
#2Re: Streaming Combinators and Extracting Flat Parallelism
#3Has anyone here tried Futhark? Is it ready to use or mostly PL research?
Re: Streaming Combinators and Extracting Flat Parallelism
#4Has anyone here tried Futhark? Is it ready to use or mostly PL research?
These types of things are mostly PL research. Staring at their repo, Futhark is better than most in terms of "readyness", but it's still probably not something you'd want to start programming all your GPU code in :) It lacks a lot of developer friendliness.
Re: Streaming Combinators and Extracting Flat Parallelism
#5Earlier quoted context omitted.
These types of things are mostly PL research. Staring at their repo, Futhark is better than most in terms of "readyness", but it's still probably not something you'd want to start programming all your GPU code in :) It lacks a lot of developer friendliness.
What would be a good starting point for adding more friendliness?
I am nearly positive that the tooling that came with Go is a pretty big reason for its success.
Re: Streaming Combinators and Extracting Flat Parallelism
#6Has anyone here tried Futhark? Is it ready to use or mostly PL research?
Now to the question whether APL is ready for production use... ;)
[1] http://futhark-lang.org/blog/2016-06-20-futhark-as-an-apl-co...
Re: Streaming Combinators and Extracting Flat Parallelism
#7Has anyone here tried Futhark? Is it ready to use or mostly PL research?
Apparently you can write APL and have it transpiled to Futhark[1]. Now to the question whether APL is ready for production use... ;) [1] http://futhark-lang.org/blog/2016-06-20-futhark-as-an-apl-co...
Re: Streaming Combinators and Extracting Flat Parallelism
#8Re: Streaming Combinators and Extracting Flat Parallelism
#9Earlier quoted context omitted.
These types of things are mostly PL research. Staring at their repo, Futhark is better than most in terms of "readyness", but it's still probably not something you'd want to start programming all your GPU code in :) It lacks a lot of developer friendliness.
What would be a good starting point for adding more friendliness?
It also misses a bunch of syntactic sugar that make programming inconsistent from what one would expect in a bunch of cases (they acknowledge this up front).
Past that, in part, getting people to adopt new languages is about either providing them an ecosystem that is amazing to start and trying to convince them to jump ... OR meeting them where they are now (IE building integration into existing editors, tooling, etc).
Usually people try to get people to jump. You'll note that this rarely works and is a very long and slow burn when it does. This is true even when the new ecosystem is huge. The successful jump cases are usually somewhere in the middle, where they are leveraging existing ecosystems but providing something better enough.
Futhark is neither providing a better ecosystem to jump to, or meeting people where they are.