The Haskell Foundation is reviving @taylorfausak’s State of Haskell Survey. It’s been a few years and so we’re doing it a bit differently, but the plan is to start doing this yearly again so that we can collect longitudinal data on the Haskell community and ecosystem.
Please take the ~10 minutes to fill this out and share it with friends/colleagues/coworkers, whether or not they are users of Haskell.
I asked some non-Haskell colleagues, as directed, (a combination of data science people and software engineers - some who have tried Haskell others who haven’t) to do the survey and after the first page there were a lot of Haskell specific questions they couldn’t answer e.g I’m satisfied with stack or hackage.
Idk how these surveys are setup it might be good to have early exit after the generic part of the survey. Cause it was a little hard to get them to complete it.
I had intended to have folks that clicked “no, and I never have” to skip most of the Survey (the stuff that requires Haskell knowledge). It is now fixed (it only skipped some, not sure what happened).
There were also quite a few questions you were forced to fill out despite your previous answers, such as “how long did you use Haskell for before giving up” (sorry I don’t have the exact wording in front of me) despite answering “I still actively use Haskell” in a previous question. I worry that forcing people to answer such questions is going to lead to a fair chunk of junk answers, so you’ll need to be careful in your analysis of the results.
Likewise. We (a two-person research team) stopped using Haskell because all the cryptography and zero-knowledge proof libraries we wanted to use are written in Rust. Initially we did FFI to those libraries, but it became too much of a PITA, so we just switched to Rust ourselves.
I too am quite concerned about this particular situation (both the lack of libraries, and the loss of a team of users), and am specifically working to rectify it, though the road is long and the journey hard.
One of my goals this years is to establish a library for proper cryptographic abstractions, not just bindings to a foreign library, but that requires proper low-level memory support, which requires fixing or patching over legacy issues (stares at Num, Ord, and Bits why is it always you three causing problems?). As I said - a hard road.
You can imagine, this also flavored my response to the survey.
I wish you well on that road. Kind of too late for us on this project — but maybe a future one. I would also like to see a tool that would let one point at a Rust codebase, discover all the extern “C” functions and automatically build FFI wrappers for them and all the data types used as input or output of those functions. The data type part is tricky because one has to decide which data are OK to serialize back and forth and which ones should be a pointer (that needs to be freed in Rust). Bits-n-pieces of that infrastructure exists - but I (dreaming) want a “push button” tool!