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.
> 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.
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?
I'm an HPC developer, my workstation is a 122 PetaFLOP machine.
I go to the Rust language website, and I am able to understand in 1 minute what's the language for, and what value it adds with respect to the alternatives.
I look the Chapel website, and I get nothing. So I have to guess, and my guess is that's a framework developed by one research group to publish research about parallel computing, but that almost nobody uses for anything real in practice - except for the one or two simulation tools that they managed to lock-in 10 years ago. It's not clear to me which value these adds w.r.t the alternatives, like pure MPI+OpenMP, HPX, Fortran co-arrays, and the other dozens or hundreds of half dead research projects that were supposed to "revolutionize" HPC over the last 4 decades. The sad part is that I'm probably right.
The 3 most used languages in "classical" HPC are C, C++ and Fortran. Python was barely used, but now the recent trend of building "AI" HPC national centers have put it in 4th place. The three most used parallel programming paradigms used are MPI (which a dozen of implementations available and in active development), OpenMP, and CUDA. The amount of people that use OpenCL in classical HPC is insignificant. There are more widely-used codes using OpenACC than Intel Thread Building blocks. The users of modern frameworks like HPX is almost non-existent, and the users of things like Chapel are a signed zero. I've access to a handful of >10 Petaflop systems, and none of them have Chapel even available through their module system.
This doesn't say anything at all over whether Chapel is actually good or bad. But it is actually the job of those getting public funding payed by taxpayer dollars to advertise why we should keep funding them and not fund something else. The fact that their website doesn't even try to pitch it suggest me that the only purpose of the project is for the group that develops it to explore interesting ideas and publish papers, as I mentioned above. That's definitely something worth doing, and often decades later these ideas percolate into solutions that people actually use. But simulation frameworks that run on the Top 10 supercomputers usually take hundreds of people and multiple decades to write, and aren't something that follow trendy research frameworks.
Programming languages aren't literal businesses who the hell cares about ""frontloading their value"" mein gott. There's no reason to force your startup world ""wisdom"" on programming language websites.
Chapel is targeted at a pretty specific niche in the first place (and is pretty good at what it does). I don't think they're really after the general purpose programming language market and if you're in HPC you've probably already heard of it anyway.
That isn't startup world wisdom, it's just "how to sell x". You don't get users, or maintainers, without a sales pitch.
But I actually do work with HPC on occasion, and I don't work with cray technologies. I'm very much aware of their existence, but they have never convinced me to go out and use their products. I've heard several pitches by HPE folks, and they often push towards slurm or bright systems over the cray ecosystem. Maybe I'm just not the target audience, but I routinely run 100+ node jobs using a mishmash of slurm, bash, python, etc.
No, not really. If(?) they want to increase adoption, they need to convince scientists to write their simulation programs in it. Realistically, that's not going to happen via HPE/Cray people having lunch meetings with individual scientists.
I can believe that, but I think CERN is not particularly representative of HPC. Mostly it's individual researchers in universities writing code (with the researcher or immediate supervisor making the decision which programming language to use) and then going to the university cluster or national supercomputing center when they need more oomph. A Cray marketroid having lunch with the director of the national supercomputing center is going to do squat all for convincing a researcher in a university somewhere to pick a particular programming language.
> I was in a meeting organised by Apple trying to sell us how great it would be to adopt OS X and X server back in 2004.
Yeah, and look what a smashing success Apple is in HPC.. ;)
To be fair, the language is developed by Cray. So my instant assumption to the question "why Chapel?" is "because programming supercomputers is hard".
> I guess it's fine if they never want users
I think this not far from the truth. It's not that they don't need users, but that they don't need pedestrian users. Supercomputing is a niche market, so I'm sure the marketing is more about networking at conferences.
Put another way, you're going to pick up Chapel at work, not at home.
Their presentation here explicitly talks about who they're targeting, and their very first target group is "recent graduates" who want "something similar to what I used in school: Python, Matlab, Java".
If this front page makes it look like their position is "supercomputers are hard, this is for pros", that's completely misrepresenting the rest of the website.
In their defense, if you don't already have a pretty good idea of the "why?" from what is on their homepage, you're not going to be a Cray customer anytime soon and you're unlikely to find yourself working for one.
In your defense, maybe if they cared about mindshare and community beyond the people who give them money, enough people would have given them money that they wouldn't now be a subsidiary of HPE.
I never could figure out (2000's-era) Cray. Their office was in my neighborhood and a friend-of-a-friend worked there and it sounded like interesting work, so I checked out their jobs page. Almost all of the jobs were sales, and their most junior engineering position required something like 10-15 years HPC experience.
I've seen successful niche technical industries (Fluke comes to mind), and Cray didn't even look like a niche industry. It looked like a dying one.
There's a graver mortal sin, no code samples on the front page. Python, Ruby, D, Go they all have this in common. I think Rust used to, and Racket used to have an awesome set of examples before they redid their site now I think it's different examples. Syntax tells me everything about the language.
use CyclicDist; // use the Cyclic distribution library
config const n = 100; // use --n=<val> when executing to override this default
forall i in {1..n} dmapped Cyclic(startIdx=1) do
writeln("Hello from iteration ", i, " of ", n, " running on node ", here.id);
> Why do so few of these small programming language projects have a "why x?" section?
Because their target audience gets the “Why X?” for solutions from other sources, and then goes to the website of a tool for the meat, not the sales pitch.
I sympathize with the grandparaent comment. The first three aren't exactly unique. Many languages are parallel and portable and productive.
Listing adjectives isn't a "why". A "why" would be: "Chapel is a language built for distributed memory systems. Unlike X or Y, Chapel has first class language concepts for distributed memory management, sharded storage…" etc. etc. (I just made that up.)
Then you know right off the bat whether this language is the one you need for the problem you have.
What you refer to as a silly meme might also be a legitimate critique that surfaces again and again when hackers/engineers build things that solve a problem they have, think it is cool or interesting, but aren't able to communicate the value to others.
It's not unreasonable to ask, at the very least, for a simple "why does this exist?" (An entirely reasonable answer to which might be, "because I thought it was cool!")
«Chapel has the goal of supporting any parallel algorithm you can conceive of on any parallel hardware you want to target. In particular, you should never hit a point where you think “Well, that was fun while it lasted, but now that I want to do x, I’d better go back to MPI.»
https://www.cray.com/blog/chapel-productive-parallel-program...
It would be such a low hanging fruit to put a concise rationale there. That’s not spoon feeding, but giving a minimal amount of opinionated context so a visitor isn’t completely lost when unfamiliar with the technology.
Surely anyone who works on this project could tell me why it exists, why it's better than rolling slurm/bash scripts. That feels like a bare minimum sales pitch. Instead the homepage is essentially buzzwords with links to watch the talk or read the docs. I'm sure anyone who uses this could say, "well, it makes x task much easier/more concise! This is much more difficult to accomplish using y" or something similar.
I guess a better question would why is it better at those things? A lot of languages claim to be all about performance, scalability, productivity and portability. Those are pretty much what every mainstream language aims for. So why would this be better at those things? Why was it created and what does it do that others can't?
I don't think things necessarily need a reason to exist, but I think asking those questions is still relevant when it comes to a programming language. They are mostly tools used to solve problems, after all.
@mardifoufs: I realize that your point is that the Chapel webpage didn't answer this question clearly / concisely for you and agree that we could and should improve that. The observations in this thread have definitely helped given me insights about how we could position ourselves better for the non-HPC audience (and I already have a longstanding intention to make the code sample on the page more compelling using Asciinema that I need to find the time for).
But to answer your specific question here: I'd say that most mainstream languages (e.g., C, C++, C#, Java, Python, Rust, Swift, ...) don't aspire to scalability in the same sense as Chapel and High Performance Computing want it, in the sense of being able to run efficiently on tens of thousands of processors with distributed memory where inter-processor communication and coordination is required. And even when they do aspire to it, it's rarely through the language itself, but through communication libraries, pragmas, and extensions. The result (in my opinion) is rarely as productive, general-purpose, and performant Chapel achieves.
[0] https://chapel-lang.org/press.html