
The Chapel Parallel Programming Language - wuschel
https://chapel-lang.org/
======
eismcc
I’ve worked with Chapel a lot. It’s an insanely powerful language that will
challenge your ideas (at least for me) about many language constructs in the
spirit of HPC. I went to it around 2014 for doing distributed arm projects and
implemented several projects. Here’s a simple search engine. My github had a
number of chapel projects.

Once you get the hang of Chapel you will find it changes how you think about
parallel computing. For more advanced concepts the learning curve is steep and
not something you can get in a hello world example, but totally worth the
effort.

[https://github.com/briangu/chearch](https://github.com/briangu/chearch)

~~~
zentiggr
For us non-HPC developers, does it make any sense to dig deeper? I get the
feeling there could be some interesting thread/core usage maximisation ideas,
or some such, but I've not delved before so I have no frame of reference.

~~~
pjmlp
Depends where your main interests in computing are are, if you are into
programming languages, it is always worth having a look.

------
fizixer
Chapel was one of the three language chosen by DARPA in early 2010s (late
2000s?) to be the potential future of HPC (the other two being Fortress and
X10).

I think the idea was to fund these languages, allow the developers to throw
them at the supercomputers, have a multi-year shoot out, and pick the one that
wins out.

I'm not sure what happened to the findings/results (feel free to chime in).

What I do know is that I've been in the HPC application side for almost 15
years and not one of the big projects I'm involved with use any of these, or
any other "new" HPC languages.

The go-to languages/frameworks are the same: C/C++/Fortran, combined with
OpenMP/MPI (MPI includes networking, but use of separate networking frameworks
is also an option), and Cuda for GPUs (maybe very occasional OpenCL), with
python being the massive success as the glue between all the system-level
languages/frameworks. And now with the advent of tensor computing, the
paradigm appears to be shifting once more (maybe not a shift, but one more
item in the laundray list of heterogenous hardware).

Go read the overview, new features, whatever on the linked Chapel website: not
a single mention of GPU. That's cz Chapel/Fortress/X10 were
conceived/developed around the time GPGPU was just taking off. Nobody saw
GPGPU coming and it has taken the HPC world by storm. And yet, after more than
a decade, the "new HPC language" website has zero mention of GPUs. What a
shame.

I'm not saying the new HPC languages are overrated. But I do believe the
promise of an HPC language hasn't panned out, and yet at the same time new
computer-architecture/hardware paradigms keep emerging which the "new" HPC
languages {were never designed for, never foresaw}.

~~~
auggierose
Same opinion here. Parallel first language, and no GPU support??

~~~
pjmlp
Many HPC worloads are MPI first, and then something else later.

Still there is ongoing GPU support work, see sibling comment.

~~~
mppf
Right, GPU support is very important to us and we expect to make something
satisfying. We just havn't been able to prioritize it yet.

------
dang
Related from 2016:
[https://news.ycombinator.com/item?id=11747709](https://news.ycombinator.com/item?id=11747709)

2014:
[https://news.ycombinator.com/item?id=7951706](https://news.ycombinator.com/item?id=7951706)

A bit from 2013:
[https://news.ycombinator.com/item?id=5047197](https://news.ycombinator.com/item?id=5047197)

A bit from 2016:
[https://news.ycombinator.com/item?id=11257792](https://news.ycombinator.com/item?id=11257792)

Various mentions over the years:
[https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...](https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=cray%20chapel&sort=byDate&type=comment)

------
bovine3dom
Chapel has great syntax and ergonomics as others have mentioned. What it
doesn't currently have is great performance, e.g. [1]. That said, it appears
to be heading in the right direction [2]. I last checked about 5 years ago and
the story was much worse.

[1]:
[https://drops.dagstuhl.de/opus/volltexte/2019/10879/pdf/OASI...](https://drops.dagstuhl.de/opus/volltexte/2019/10879/pdf/OASIcs-
SLATE-2019-12.pdf)

[2]: [https://chapel-lang.org/perf/chapcs/](https://chapel-
lang.org/perf/chapcs/)

~~~
roknovosel
Wow, never thought I'd see my paper[1] on HN :)

Even though getting the right performance was tricky, I was more frustrated
with the lack of tooling, sometimes cryptic compiler messages and long
compilation times for even mid-sized programs. Most of the issues were
mitigated by the great community around Chapel. They are usually very
responsive and helpful in their Gitter channel.

In regards to actual parallel programming, Chapel was a breeze. Documentation
is solid and most of the parallel concepts were easy to use.

------
fulafel
These HPC programming languages (there are others too) would be good
candidates for GPU programming, hopefully GPU world will at some point emerge
from the C++ dark ages despite all the hinderances (proprietary fragmented SW
stacks).

~~~
eismcc
There was GPU support in a branch a long time ago. I think they missed the
boat on that and it would have been a great way to get distributed GPU systems
even 5yrs ago

~~~
mppf
GPU support is still really important. We don't see major issues with
providing native Chapel -> GPU code generation and hope to work on it soon.

------
blondin
really love the syntax of this language and how they are repurposing existing
programming language primitives for parallelism.

but i also just spent quite some time looking for a substantial example of
usage and had to give up. the only thing close to that are the unit tests. and
the language has been in development since late 2011.

that's somehow dispiriting.

that, in a nutshell, is the unfortunate situation with some of these
interesting modern programming languages.

~~~
cultus
I never understand why people go to all this work of developing and even
marketing major libraries or languages if you aren't going to at least give
some doc examples. Jeez, just copy and paste some unit tests and put some
prose explanation in. It doesn't take long.

~~~
zentiggr
You missed the "HPC" acronym.

If you're not in the market to run supercomuting projects, you'll likely never
use this language.

If you are, there's a very high chance you know about it already.

Sharp divide between those sides.

~~~
ken
And yet, in the presentation slides linked to from their homepage, they brag
that it aims to be "programmable as Python, fast as Fortran, scalable as MPI,
SHMEM, or UPC, portable as C, flexible as C++, fun as [your favorite
programming language]". It's not even supercomputer-specific: they say it runs
on "a Mac laptop".

If even half of those are true, why _wouldn 't_ I want to use it for every
program I write?

(Easy answer: it looks like most of those are still simply "aims", and not
actually that close to being true.)

~~~
bradcray
I think it's plausible you would want to use Chapel for every program you
write. I definitely want to use it for every program I write, but I'm also
biased.

The main disincentive to doing so today is that Chapel is not nearly as
broadly adopted or well-supported as the languages you probably do use in
practice today. The Chapel team is trying to get it to that point, but it's a
modest-sized team taking on large challenges (both technical and social, as
this thread indicates). To date, we haven't made a significant effort to draw
in a massive/mainstream audience because we know we're not ready for it yet,
either in terms of the language's maturity or our ability to support a large
group of users. But we hope and intend to get there.

That said, I think we're already achieving the aims in the slide you quote—far
more than your easy answer suggests—though there's obviously room for
differences of opinion (e.g., what does it really mean to be "as programmable
as Python?"). If you're interested in pointers to supporting details, let me
know.

~~~
zentiggr
I forget that many of the people and projects that get mentioned here are here
as well. Thanks for a deeper viewpoint!

I'll definitely put Chapel on my curious list.

------
eyegor
Why do so few of these small programming language projects have a "why x?"
section? How do they expect to gain marketshare if they aren't frontloading
their value? This is a fairly old project and yet they've never taken the time
to put a sales pitch on their website. In the past 12 years they've added 15
links to their press page [0]. This is a fairly mature project and I have no
idea why I should investigate it. I guess it's fine if they never want users,
but as someone who's worked in the startup world this sort of thing really
gets under my skin.

[0] [https://chapel-lang.org/press.html](https://chapel-lang.org/press.html)

~~~
zentiggr
> Why do so few of these small programming language projects have a "why x?"
> section?

They do... you missed the Cray name in the logo, and the 'runs on HPC
systems".

> How do they expect to gain marketshare if they aren't frontloading their
> value?

I'm guessing their marketshare is already well defined, there aren't a ton of
supercomputing clusters in the world.

> This is a fairly old project and yet they've never taken the time to put a
> sales pitch on their website.

See above. They only have to sell to a small fraction of people compared to
your startup 'eatt the world' mentality.

> In the past 12 years they've added 15 links to their press page [0].

And?

> This is a fairly mature project and I have no idea why I should investigate
> it.

Never needed to run code on big iron, gotcha.

> I guess it's fine if they never want users, but as someone who's worked in
> the startup world this sort of thing really gets under my skin.

As this is not a language for startups, I don't think they care if you're
annoyed. They are likely dealing more with multi-million dollar single project
runs that could take months to complete.

At least look up the meaning of things like HPC before you just shove the
concept through your narrow filter of expectations.

I don't expect to ever run high performance code like this, and I'm curious to
see what the design could tell me just in passing.

~~~
eyegor
I send jobs to HPC systems on a daily basis at work. This website fails
miserably to capture me as a potential customer. The cray name has plenty of
baggage, but that doesn't give this language value. I do not currently work in
the startup space, but having done it, I get annoyed when people put so little
effort into selling their projects. I'm sure that a lot of time was spent
building this (it's been around for over a decade), but they've put
essentially nothing into marketing it.

I run high performance multi node code at work, typically 1-2k cores
continuously. I have several contracts with HPE. Am I not part of the target
audience for this language?

~~~
zentiggr
None of that detail came across in the post i replied to. Yes, given that
extra information, i would rescind about 95 percent of my snark.

