[1]: https://drops.dagstuhl.de/opus/volltexte/2019/10879/pdf/OASI...
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.
Of course, it's very possible for programmers without Chapel expertise to write and publish bad performance results in Chapel. The Chapel team is very interested in working with such users to help them understand where performance is being lost and to improve things to benefit future users. Most of our recent optimizations have been motivated by user feedback, and in practice we're typically able to help users get their codes to match or beat the performance of conventional approaches with reduced effort. A favorite recent example of mine can be seen in slides 6-16 of Nikhil Padmanabhan's talk at PAW-ATM 2019 [4].
A good way to keep up with Chapel performance improvements beyond whatever gets peppered into our talks is through the release notes that we publish every six months, e.g. [5], [6], [7].
[3]: https://chapel-lang.org/perf/16-node-xc/?configs=gnuugniqthr...
[4]: https://github.com/sourceryinstitute/PAW/raw/gh-pages/PAW-AT...
[5]: https://chapel-lang.org/releaseNotes/1.20/06-perf-opt.pdf [6]: https://chapel-lang.org/releaseNotes/1.19/05-benchmark-opts.... [7]: https://chapel-lang.org/releaseNotes.html