Purerl - have you used it?

If so, where/how and what do you like about it? :003:

Purerl is an Erlang backend for the PureScript compiler. PureScript is a small strongly typed programming language with expressive types, written in and inspired by Haskell; purerl is a PureScript backend targetting Erlang source.

3 Likes

I’ve not used it for anything yet but I’m a fan! I’ve spent quite a bit of time reading their libraries and OTP wrappers. Really cool to see how a typed OTP is being used in production.

4 Likes

We use purerl heavily, with live systems in production for something like 3 years now. The combination of the Erlang-VM with a strongly typed language on top is very powerful

5 Likes

What kind of apps/space are you using it in Steve? Were you already using PureScript?

1 Like

We’re in the media space - large scale, live, resilient streaming systems. Hadn’t done much purescript prior to starting with purerl, but had been exploring strongly typed systems on top of the BEAM for some time

2 Likes

@robashton
Thanks for chiming in on Erlang type system efforts

I was having a bit of trouble evangelizing Purerl because the status and maturity of the project is hard to discern from the github repos.

  1. The id3as repos are not linked on the Purerl repo. Some bindings (Ranch & Gun) are available only on id3as org. Would it be nice to have all the bindings listed on the Purerl repo so that someone weighing a shift would be encouraged by the availability of bindings for major libs ? It would also allow one to estimate how much effort needs to be put in to create new bindings and also prevent duplication of effort.
  2. There is a id3as/purescript-erl-stetson & purescript-erl-cowboy. Is there a recommendation on which one to use ?
  3. Are there any purerl libraries that have been published to hex ? How do you ensure versions of the underlying erlang deps and the bindings match ? Is there a case for pushing the erlang files generated by Purerl to hex ?
  4. Can you please share your thoughts on what could be done to get more folks to use it ? Roadmap ?
  5. I don’t necessarily see the dual compilation as a pain point but would you care to comment on the pain points one should expect while adopting purerl ? Would it be nice to put it up on the readme ?
2 Likes

I’m on my phone so I’ll be brief :slight_smile:

  1. they are not, maybe they should be - at the very least they need adding to https://purerl-cookbook.readthedocs.io - the Purerl org is ostensibly nothing to do with id3as and any additions to that are down to Nicholas who runs that org

  2. you use both, because Stetson is built on top of those direct Purescript bindings to cowboy - this isn’t the case for OTP and Pinto because low level ffi for OTP doesn’t really add much to the equation

  3. no, there aren’t. Purescript gets published to GitHub and used by spago/dhall package sets, the erlang to run those gets shipped with the purescript because it’s part of the package.

That’s not to say there isn’t a problem to be picked up on there - for example purescript-erl-cowboy depends on that erlang package Cowboy - the only way at present to specify that dependency is in the docs, “please add cowboy 2.8 to your rebar.config and app.src”, not a problem for us, but an obstacle to new users for sure.

  1. that’s a hard one because it suggests it’s an active goal - I’ve done my best to keep docs up to date and publish blog posts and such, but without a convenient single access point like Mix for Elixir, uptake is always going to be slow. Is this a huge problem? Perhaps not - one of the good things about Erlang IMO is that the barrier to entry is perceived as high and this weeds a lot of potential support effort out early on as most of the developers who make it through that are pretty self sufficient. That’s a fairly selfish answer I know, I’d prefer more people used purescript and erlang but the amount of effort required to lower that barrier of entry would be astronomical I think.

  2. the obvious pain point with dual compilation that springs to mind is that typeclass heavy code can result in Erlang code that is…. Less than idiomatic and the compiler can really struggle with it. There have been some positive efforts in that space lately, to reduce compile time of the worse offenders and indeed to optimise some of the obvious oddities out (why call Eq when you’re just a new type over Int for example).

The other issue is it’s “yet another tool chain and set of artifacts to learn and be aware of” in an ecosystem that is already complicated to get into - that brings us back to 4 doesn’t it.

5 Likes

Thanks for responding. Loved your talks up on youtube.

3 Likes