The State of PureScript Survey 2022 - The Results Are In!

mikesol · March 31, 2022, 5:45pm

The first PureScript survey results are in! Here is a link to the full result set for your perusal. However, as it’s unlikely everyone has time to read 47 pages of survey results, we’re also writing up this short, somewhat-opinionated post with what we believe to be relevant learnings from the survey.

Our take on the survey

First and foremost, THANK YOU to everyone who filled out our survey. We had 660 respondents - a great showing for a first year and a solid baseline for years to come.

Participation

The first thing to highlight is that participation was skewed towards non-PureScripters (43.6%) and those who stopped using PureScript either temporarily or permanently (29.98%). Only 26.42% of survey respondents currently use PureScript.

One takeaway is that those who stopped using PureScript likely did so temporarily. We can reasonably infer this from the data - since only 11.52% selected the “to provide feedback on why I stopped using PureScript” reason while a much larger 44.24% indicated they plan to “either start or return to using PureScript”, it is likely that a majority of those who stopped using PureScript only did so temporarily, not permanently. However, there is bias in this interpretation: if someone stopped using PureScript, they may not have cared to fill it out and thus indicated “to provide feedback on why I stoppd using PureScript”.

A second takeaway is that a lot of new people are interested in PureScript. 43.6% have never used PureScript and 59.48% took the survey out of curiosity. Similarly, 64 people out of 126 responses (~50%) indicated that they first started to use PureScript because they were curious.

A third takeaway is that the main PureScript community is small. Only 26.42% currently use PureScript and an even smaller 11.9% took the survey because they “consider themselves to be a part of the community”. We (those responsible for the survey’s managment) notified the PureScript community primarily via PureScript’s Discourse forum and Discord chatroom. Some refuse to engage in these platforms due to privacy concerns, and thus may not have been notified. However, due to posting in other widely-read places, this possibility is improbable.

Still, to address this issue in future iterations, we’re going to take the following steps:

Make more of an effort to reach out to companies and institutions that are using PureScript, finding ways to engage their teams so that we get more responses.
Looking for other statistical indicators of PureScript usage. For example, we will look into keeping stats of package downloads from the registry as well as other aggregators that are a proxy for how much PureScript is used in the wild.

PureScript adoption

Before we get to why PureScript is used, we had some questions to determine why it isn’t used. The answers tended to reflect an apprehension about the size of the community and its industrial adoption more than intrinsic features of the language or its documentation.

The write-in answers tended to reflect this trend. Very few of them pointed to issues with the language or FP paradigm, but many of them expressed concerns about performance, tooling, roadmap, bundle size, and other industrial factors.

The good news is that we have found that organizing collaboration around working groups is succeeding. Supporting ES modules in the compiler gained momentum due to the working group; this long-requested feature will be included in the upcoming v0.15.0 PureScript release. Similarly, the revamped registry has been making steady progress via working groups.

PureScript users really use PureScript

Of the 163 respondents that are using PureScript, 128 indicated how often they use it. We’re not entirely sure why these two numbers are different by 35 responses. Regardless, of those 128, at least 77% use PureScript weekly and 59% can review and write production-level code. The rest (41%) are likely still figuring out best practices in an FP world.

We also saw an effect of consolidation in the tooling and libraries:

JavaScript is overwhelmingly the most popular backend
spago is overwhelmingly the most popular package manager
spec and quickcheck are overwhelmingly the most popular testing packages
halogen is the clear frontrunner for web development
vscode is the clear frontrunner for IDEs
Most of the community is using a recent version of the compiler
Most of the community is using the version of the compiler provided by the core team on NPM

Inversely, we saw a flurry of packages imported through the FFI. This presented us with an interesting dilemma: while JS interop concerns seemed to be a common hesitation amongst those not using PureScript, it’s clear that amongst those who are using it, there’s an incredible diversity of FFI packages.

Debugging

One interesting result was the lack of a debugging culture: only 16% of respondents use source maps and, as one free-form respondent put it, “It’s not possible to debug PureScript programs, sourcemaps are broken and when they worked you’d get stuck in Aff evaluation.”

In spite of the fact that the browser is the most popular PureScript target and the fact that there are a wealth of browser-based debugging tools, the community still overwhelmingly uses console logging to debug programs.

Compiler issues and PRs

Respondents gave feedback on how strongly or little they wanted certain compiler issues (16 issues; 119 responses) and compiler PRs (7 PRs; 116 responses) resolved.

The high number of “no opinion” responses may indicate that the community doesn’t care about the compiler. However, we think a better conclusion is that different segments of the community care about different things. For example, those who write a lot of type-level programming (i.e. proof-checking code that runs during compilation) may be interested in advanced features that others simply don’t need for their programming style.

First, there are some contextual reasons. The survey did not include every issue or PR. Perhaps this particular set just wasn’t the issue or PR that respondents cared. Moreover, the title of an issue or PR may not reflect the heart of the issue. What starts off as one request may evolve and reveal a different underlying need; the title isn’t always updated to reflect that.

Second, recall that of the 127 people who rated their PureScript expertise, 52 still struggled with writing/reviewing production code. The average number of “no opinion” on the issues (64) and PRs (57) may be partially represented by these still-growing PureScript developers. If so, such developers may not yet know or care about these things. For example, if one is still learning about pattern matching or the Either monad, is an advanced feature like visible type applications relevant? Still, one of the issues had 79 “no opinion” responses, so there are definitely people who really have “no opinion” on the given matter.

Third and coming from a different angle, 113 respondents expressed an interest in at least one compiler issue or PR. Of those responses, support deriving via was the clear front-runner, with 70 respondents (62% of the 113) indicating at least a ‘somewhat’ level of interest.
The following issues and PR had relatively high support, all with interest bases around 50%. Each is also briefly described for those unfamiliar with them:

Visible Type Applications
- Enables the value-level @TypeName syntax in functionName @TypeName arg1 arg2 arg.
- Useful for ad-hoc usages of polymorphic functions:
  - id @Int means this usage of id has a type signature of Int -> Int rather than forall a. a -> a
  - Simpler, more performant type-level programming: get @"foo" advancedRecordExpr rather than get (Proxy :: Proxy "foo") advancedRecordExpr
  - Shortens needed type annotation syntax: Right @Int "foo" rather than (Right "foo" :: Either Int String)
Color compiler warnings and errors
- purescript-psa already implements this feature outside of the compiler, but this PR starts to add some of that functionality to the compiler itself.
Support for existentials
- The dual/opposite of forall/∀: exists/∃
- Allows one to use the real implementation internally while exposing an interface to the outside world publicy that hides that implementation.
- Would make the current workarounds used to simulate this feature more readable.

On the other end, to give a sense of range, allow U+0009 (tab) in source files received the least interest, with 8 respondents (7%) indicating any interest. (The maintainers are generally against mixing tabs and spaces, but there is an accessibility argument for allowing tabs which has stopped us from closing the issue outright.) This issue was an outlier among the issues and PRs we asked about; the remainder of the issues and PRs had support ranging from 25–50%.

Notably, color compiler warnings and errors (#4190) received a lot of support from respondents who only expressed interest in a small number of issues, whereas the other issues received more support from respondents who expressed interest in a wider range of issues. #4190 might be a priority goal for a segment of the community not as invested in advanced compiler features.

Our community

Our community comes mostly from other functional programming settings, like Haskell or Elm, with the specific goal of having a Haskell-like developer experience for browser-based applications.

In general, the community is eager to consume PureScript-related content (over 72%) and learn through building real-world applications. The community seems slightly less active on social media and through channels like Discourse and Discord. In future surveys, it would be good to double down on this and better understand preferences for consumption of educational/informational content versus discussion.

We received solid scores on our community’s inclusiveness and welcoming environment. From the free-form responses, it’s clear that, in general, those who are in the PureScript community love being part of it.

That said, there were a few pieces of write-in feedback that can help us create a more welcoming environment:

We have few avenues for non-native English speakers and can do a better job providing channels where people can ask and answer questions or consume content in a language more comfortable for them.
There are a few people that left the community because they were put off by a specific individual’s communication style or an individual moderator’s decision on a forum. We need to make it clear where people can turn so that leaving is not the only option if they feel unwelcome.
Sometimes, a lack of responsiveness to issues and PRs in libraries or the compiler leads folks to disengage.

Furthermore, there are certain responses that should be 0%. The fact that 13% of respondents felt that, at times or often, being part of an underrepresented or marginalized group made it difficult to participate in our community is something we should address and improve.

The community’s biggest concerns are similar to those of the folks that are not using PureScript:

Not enough usage in industry (57%)
Developers/maintainers of the language are not properly supported (53%)

PureScript for fun and profit

PureScript developers using PureScript at work tend to be senior (>= 10 years experience) and tend to have a functional-programming background. Furthermore, more than 95% responded that PureScript “provides a real benefit over other programming languages.” Most people coming to the PureScript community are coming after having used and evaluated other languages like Haskell and Elm, so their comparison to other languages carries weight. 112 of 115 respondents find the language fun to use, which is an accomplishment the entire community should be proud of.

In general, these teams are all-in on PureScript - it seems that there is no significant “casual usage” cohort.

The vast majority of our user base works in web development. While their reasons for using PureScript are diverse, the strongest reason for PureScript adoption is that teams enjoy using the language.

Developers are happy with most aspects of PureScript’s performance as a compiler and deployed language. The only aspects of PureScript that received less-than-favorable reviews were compile times and bundle size.

Easter eggs

What category best describe(s) the tech domain(s) you currently write or design software in?

boring line of business applications

When did you start using PureScript?

I’m garyb

Conclusion

Thanks to all who responded to our first annual survey! It helps us know what to prioritize and plan next actions. Perhaps the biggest takeaway of all is that those who use PureScript enjoy using PureScript. Life is short and is ultimately comprised of that which we do during the day, so we should enjoy doing it. The fact that PureScript can bring joy to many people is a precious accomplishment, and we should focus on preserving that for years to come

mikesol · March 31, 2022, 6:57pm

On a personal note, I’d like to thank the core team for their guidance throughout this process and for their helpful edits to the document above. I’d also like to thank our Chinese and Japanese-language translators Tao and @kayhide for their contributions. When we started the survey process, @thomashoneyman and I had a call with Ryan from the Rust team, and we also used the Haskell survey for inspiration, so many thanks to those communities. Finally, a big thanks to everyone who took the survey and everyone from the PureScript community, as y’all made this survey worth taking!

In terms of “what next”, there are several things underway.

The core team is already analyzing and discussing the results, which will lead to opinions being formed and decisions being made about the future evolution of PureScript.
If you have thoughts about the survey results that you’d like to share, please write them down as a comment here!
If you’re a member of any communities that may find these results of interest, please invite folks to read this post and comment on it.

Onwards and upwards!

cdepillabout · April 4, 2022, 1:57am

Thanks a lot for putting the survey together! I can only image it was a huge amount of work, but I think it is something really helpful to see the current state of the community. I also really enjoyed reading your summary of the results.

I had a couple questions I was really interested in but I didn’t see in your summary:

Did you notice any interesting regional differences? For instance, is there more PureScript usage in the US, or in Europe?
Were there any interesting differences between answers from different translations of the Survey? For instance, do people answering the Japanese version of the survey tend to use PureScript for personal projects, while people answering the English version of the survey tend to use PureScript for professional projects?
Do you think it was worth it having Chinese and Japanese translations of the survey? I thought the idea of having translations of the survey into other languages was really interesting (and something I hadn’t seen in other surveys, like the Haskell community survey or the NixOS community survey), but I was wondering if PureScript is used enough in Japan/China/Taiwan to warrant putting the work into translating it.

mikesol · April 4, 2022, 6:07am

Thanks for the feedback!

Here are some responses.

We had a tough time knowing how to present the answer to this question, so we decided to omit the data from the published results. Because of the small number of responses in certain countries, it is easy to triangulate and figure out certain individuals’ responses, and we opted to be conservative in preserving folks’ privacy (to the best of our abilities, we didn’t necessarily always get it right). However, what I can comfortably say is that, of 304 respondents, 25% of respondents were from America, 10% from the UK, and 9% from France. Below that and we start getting into sub-20-people territory.
The survey’s translation was only translated for the “did not use PureScript” questions, and here, no one answered the survey in its translated iteration. People from China and Japan did respond, but they all opted to fill out the English-language survey. My learning here is that it’s not worth it to translate the survey for next year’s survey unless we get an unexpected influx of non-English speakers.
In terms of our process, it was hard for me personally to organize the translations. While we got a good start and did some good initial work, it was tough to get certain questions over the line in the tying-things-up phase. Here, what I learned is that, in situations where there is a deadline, it’s tricky to rely on volunteers: it’s already generous of them to donate their time, and I found myself in the uncomfortable position of pushing so that they finish something to stay on track schedule-wise. I say “uncomfortable” only as a personal observation - I’m sure some people have the skill to meet deadlines with volunteers gracefully, but I’m not that good at it: I tend to go into running-a-business-mode, which doesn’t feel right in this context. So I’d recommend that, if we do decide to bring in translations for a future iteration, we pay those people or we align incentives so that those people are also somehow in charge of the survey’s timetable.

evdlaar · April 4, 2022, 7:48pm

Thanks so much for running the survey! This is really valuable information.

I’m trying to drill down into the result for “What libraries or frameworks do you use for testing PureScript code?” (page 9). You state:

I am a bit confused by the numbers/chart though:

88 responses
6 + 2 + 52 + 2 + 14 + 53 + 21 + 7 = 157 times chosen (I suppose the response could include multiple libs/frameworks…)
“spec” was chosen 52 times out of 157 (52/157) * 100 = 33.1%
“quickcheck” was chosen 53 out of 157 (53/157) * 100 = 33.7%
…
59.09% + 60.23% is already more than 100%.

Can you clarify?

I’m considering porting the Exercism exercises from test-unit to something more popular. Most likely purescript-spec as it resembles test-unit the most. Whereas purescript-quickcheck is more a property based testing framework.

Thanks!

mikesol · April 5, 2022, 5:57am

The question allowed for multiple responses - looking over the results, I realized that I didn’t indicate that in the export - my bad!

JordanMartinez · April 5, 2022, 12:55pm

I would use spec unless the solution is better tested via a property test.

spicydonuts · April 7, 2022, 3:49am

that was brutal lol