Travis Whitton [9:02 AM]
Morning folks, I have a general question about the status of PureScript. I got into the language about 4 months ago, and I’ve been absolutely loving it. I know that Phil retired from actively developing the language, and I’m curious if anyone can speak to the overall health of the community and future of PureScript in general. The PureScript reddit is pretty quiet, but I see active commits to the compiler on Github coming in at a regular interval. Is there any sense of whether the community is growing, shrinking, staying the same, and is the language itself actively moving forward, or is it more in a maintenance mode since Phil has left the project?
hyperisco [9:20 AM]
This is just my perspective from having worked with PureScript for over a year. The community of core contributors is small and I have not witnessed it growing. However, I have also benefited from the consistent progress those people are making. There are community outreach programs running which I think @chexxor is largely responsible for.
joelmccracken [9:24 AM]
I can say that I personally just joined the community
dariooddenino [9:27 AM]
I think the language is in a pretty sweet spot already. Some things can be improved, but I don’t see any deal breakers
hyperisco [9:27 AM]
Outside the people who poke their heads in here, I do not know anyone else in the community so I have a poor grasp of its true magnitude. Perhaps if we had something like hackagebot we could feel the heartbeat of the PureScript community.
reactormonk [9:28 AM]
We’re using it in production, and the ability to FFI into JS allows us to offset the size of the PS community
m4farrel [9:28 AM]
@Travis Whitton Have you attended conferences like LambdaConf before?
Travis Whitton [9:31 AM]
I agree that the language is in a good spot. I like the Haskell motto of avoid success at all costs, and I’m not concerned with PureScript taking over the world or anything like that. Rather, I’m just hoping it has a long-term future/outlook and a strong enough base of maintainers to keep the language healthy for the foreseeable future.
kritzcreek [9:31 AM]
The language/compiler change rate has been slowing down for 2 years or so, but that’s primarily because at this point it does everything (mostly) we’d like it do. The focus has been on polishing, improving error messaging, compiler performance and other quality of life improvements. It’s only natural that you attract less contributors when the changes that are being made/accepted require lots of work but aren’t flashy when merged.
I don’t have hard numbers, but my feeling has been that the community is growing slowly as it always has, but I’m seeing the rate of commercial adoption pick up. I’ve been using only PureScript at my day job for the last 2 years and it’s never been an impediment that stopped me from doing what I needed to do.
Chloé [9:32 AM]
The first 80% are fun, the last 20% are boring. 
chexxor [9:32 AM]
I think PureScript occupies a pretty important and unique spot in the set of language options, so it’s not likely to be outright deprecated in favor of a better solution. From what I see, the core maintainers are stretched thin but have consistently, over the years, supported the language development such that it stays reliable and reasonable. I wouldn’t be surprised to see the PS user-base and health grow quite a bit if there was more educational resources (docs, tutorials, conf talks) which show how to apply it to real-world apps and how its abilities compares to other solutions.
Travis Whitton [9:32 AM]
I’m also curious how decisions are made about future enhancements. Is there a committee or a lead maintainer or some democratic process to decide what goes in and what doesn’t? Most of my research shows Phil approving or denying change requests historically.
@m4farrel I’m aware of LambdaConf, and I know that there are PureScript talks at the conference, but no, I haven’t had an opportunity to attend. I’d like to go one of these years. Just need to find the time…
chexxor [9:35 AM]
As I understand it, it’s “open an issue to discuss a change”, then if there is general approval someone can submit a patch and expect it to be reviewed and merged. No roadmap or guiding principles right now.
Travis Whitton [9:35 AM]
@chexxor I agree that it fills a really unique niche.
dustinwhitney [9:36 AM]
Phil’s departure hasn’t seemed to have much of a negative effect on the community (maybe some tears), but I think it’s still pretty healthy. There are still quite a few updates and new projects on pursuit
kritzcreek [9:38 AM]
Fwiw Phil is a commercial user and the company he’s working at is producing/maintaining the react-basic library which has been a nice option for people that integrate with existing React apps/components
Travis Whitton [9:38 AM]
I find it interesting. You look at the Elm community, and there’s some pretty serious (potentially merited) zealotry about the promises that the language brings. PureScript clearly solves a lot of the issues that folks complain about in the Elm world. Namely, dictatorial control, openness, transparency, and some technical issues as well (typeclasses, etc).
Travis Whitton [9:41 AM]
But at the same time, it feels like PureScript is kind of quietly sitting on the sideline without a lot of great marketing behind it–and maybe marketing is not the goal of the language at all–but it feels like there’s a whole lot there with PureScript. It’s like this Lamborghini of a language that clearly a ton of effort has gone into, and not a lot of folks know about it.
Feels kind of paradoxical.
The react-basic library is fantastic BTW.
hyperisco [9:42 AM]
Tell that to a Haskell developer.
Travis Whitton [9:43 AM]
But even there–if there was a project illustrating how to leverage the benefits of react-basic alongside an elm-style architecture (like… a canonical react/redux framework), it’d probably improve the approachability of the language to new users substantially.
joelmccracken [8 hours ago]
like this? https://github.com/f-f/purescript-react-basic-todomvc
kritzcreek [9:43 AM]
The popularity of Elm has been a blessing for PS in my opinion ^^ We have a constant influx of people who tried to solve their problem with Elm but hit the language ceiling. And so when they then reach for the next (more powerful) thing they get to PureScript, but they already have a concrete problem they want solving. So they don’t get stuck in the “I have no motivation for these abstractions” pit.
hyperisco [9:44 AM]
My two favourite libraries are Aff and (latest) Halogen. I’d argue the language is worth using just to receive those two gifts.
kritzcreek [9:44 AM]
Also almost all of their knowledge about how to write functional programs in Elm translates over to PS
Travis Whitton [9:44 AM]
@kritzcreek Agree with that 100%. I’m suggesting that could be leveraged further by making more beginner friendly entry points.
Like–here’s something that looks like TEA–oh, BTW, you also get to leverage the entire React ecosystem.
joelmccracken [9:45 AM]
did you see my reply above? I think it fits that
kritzcreek [9:46 AM]
I think that’s a false dichotomy unfortunately. Only a very small part of the React ecosystem is compatible with TEA
Travis Whitton [9:46 AM]
@kritzcreek that’s fair. Only the stateless pieces.
hyperisco [9:46 AM]
Everyone knows there is heaps of reference material to create and update. Yet speed in that direction is slow. Developers are generally not thrilled to write manuals over writing more code.
Travis Whitton [9:47 AM]
FWIW - https://github.com/jasonzoladz/purescript-rx-state
That person was off to a good start.
joelmccracken [9:47 AM]
my path personally went elm, then haskell, then purescript. Elm was a nice “beginners” typed FP lang, for me
Travis Whitton [9:47 AM]
I went haskell (didn’t understand it) -> elm (everything clicked) -> back to haskell (it clicked) -> purescript (bringing it to the front-end)
hyperisco [9:48 AM]
Bring it to the Node.js backend too.
Travis Whitton [9:48 AM]
Yeah, that’s the other huge benefit. Vertical integration frontend/backend.
I dunno, I just think there are a lot of really niches that the language can fill/exploit, as it really does fit into a pretty sweet spot. Example: having some solid docs on how to use PureScript for serverless stuff (new language / no hosting paradigm) and making it a premier choice for those use cases seems pretty great.
hyperisco [9:51 AM]
So how about it Travis? Will you help us create these reference materials?
Travis Whitton [9:51 AM]
I started a blog late last year with the intent to try.
Haven’t made significant progress yet, but I definitely have some ideas.
kritzcreek [9:52 AM]
Sounds great 
Do you have a twitter where you post upgrades?
Travis Whitton [9:52 AM]
Not yet.
I’ve been off the social networks for a while.
But that’s a good idea.
kritzcreek [9:52 AM]
Good for you, bad for us 
Maybe you could just announce things here then: https://discourse.purescript.org/
Travis Whitton [9:52 AM]
Definitely.
kritzcreek [9:53 AM]
We’ve been using that as our “persistent” content collection
Travis Whitton [9:53 AM]
Noted. I’ll drop by and keep everyone abreast of any progress I’m making.
FWIW-and I hear that TEA isn’t a great fit for a big swath of the React ecosystem… I still think there’s a solid opportunity there.
Bucklescript seems to be hyping that pretty hard.
So at least some people seem to be excited about that.
kritzcreek [9:55 AM]
In BuckleScript the types probably work out (because effectful/stateful stuff doesn’t appear in the types)
so you can make the types work out while you pretend you’re doing “TEA”
Travis Whitton [9:55 AM]
Ah-that makes sense.
kritzcreek [9:55 AM]
yet hiding state in components ^^
Travis Whitton [9:57 AM]
What’s the goto for you guys? Spork/Hedwig/Halogen? Those seem like the they’re at the forefront.
kritzcreek [9:58 AM]
Halogen and react-basic are what I’d recommend to a commercial user
for everyone else… knock yourself out
hyperisco [9:59 AM]
Specifically the latetst/master version of Halogen is excellent.
Travis Whitton [9:59 AM]
Sounds good. Appreciate the info, and it was nice speaking with everyone.
I’ll drop back by sometime soon.
kritzcreek [9:59 AM]
Pleasure to meet you
Travis Whitton [9:59 AM]
Likewise!
reactormonk [10:00 AM]
Considering sdom, any good?
kritzcreek [10:00 AM]
for experiments, sure. But it hasn’t gone through any battletesting
hyperisco [10:01 AM]
Last I looked it did not support Effect, so that made it difficult to use in practice.
But ultimately I would fear what requirement changes will come down the road. Today SDOM may fit the problem, but it may not fit tomorrow’s problem.
If VDOM is too slow then investigate alternatives. Otherwise, why lose the generality? That is my reasoning. That said, there is nothing wrong with exploring the concept of SDOM.
The one true solution, by my guesstimation, actually lies in incremental computation and not these particulars about DOMs. Paf was also working on that (see Jets) but it is incomplete work. I tried to complete it and became so knotted in confusion I gave up.
There is also Panda, I think it is called, made by @i-am-tom which, by my understanding, employs a plethora of incremental change algebras. It seems to me somewhere between incremental computation and these *DOM efforts.
i-am-tom [10:43 AM]
helloo
Yes, Panda is in need of a lot of love, and I need to sketch server-side rendering before I can get it into work code to battle-test
dustinwhitney [11:09 AM]
Panda excites me
natefaubion [11:31 AM]
replied to a thread:
FWIW, the core contributors work at different companies that all use PS heavily, and use it to make actual money We have a pretty good motivation to keep it maintained and moving forward.