Jason Fry and Taylor Fausak compare frontend and backend languages, including PureScript and Elm.
Episode 3 was published on 2019-03-25.
[MUSIC] Hi, and welcome to the Haskell weekly podcast. This show is about Haskell, a purely functional programming language. He's your host, Taylor Fausak.
>> And he's the lead engineer at ITProTV. With him today is me, Jason Fry. I'm one of the engineers here like a pro as well, thanks for me joining you today.
>> Thanks for joining me Jason and for introducing yourself.
>> Yeah, we think it's fun for the host not to introduce himself, so what are we talking about today?
>> Well, I know that last week you were asking me a little about the languages that we use everyday here at ITPro and kind of why we chose them. For context the languages that we use on the back end is mostly Haskell, and on the front end is mostly Elm. And there's a lot of choices, especially on the front end of which language you want to use and you were wondering why do we use Elm?
>> It's true, it's true.
>> Yeah, wow, that is a lot, okay.
>> And the number in my head for Elm is for a small app you're talking about kilobytes.
>> So that is a pretty big difference. Okay, that makes sense.
>> So a little more about GHCJS, is there anything else that's sort of lacking there? Or is that just sort of, that's basically it?
>> Okay, so let's compare those two then. If the comparison is no longer with Haskell, like we're just always using Haskell on the back end. Then on the front end PeerScript versus Elm pros cons, we went with Elm. We really like Elm, but I do sometimes wonder, because I'm just curious about PeerScript if we were just going to make the decision differently a year and a half ago. But you answered that what would we do today we probably still use Haskell and Elm. So lets just compare them, PureScript is pretty great you talk highly of it. Sure, I really like using Purescript. I used it kind of recreationally for a while.
>> Yeah, I don't think we were using rust. We weren't that cool back then. But yeah, Angular one point, something or other and Go and I feel like we have a TypeScript file in there somewhere.
>> Elm is nice because it is very simple, especially in comparison to Haskell. And because of that simplicity, it has the ability to produce very helpful and illuminating error messages. When you do something wrong in Haskell, not you specifically, but anybody on the team, often the error message that it spits out is inscrutable.
>> And I have frequently seen team members completely stumped by an error message and call me over, and I have to say, well, what it's really telling you is this, and here's how you may want to fix it. Versus when something goes wrong in Elm that's almost literally what the Elm compiler tells you. It says, hey, I saw you did this. I was expecting this. Here's how you might fix it. And that's super useful when so many other things are changing, because Elm forces you into this weird architecture, weird from the perspective of an angular developer, it's completely foreign. And it's a strange syntax, and it's a different compiler. All of these things changed, it's really nice to have that helpful compiler there at your side.
>> Absolutely. It's one of the things that we really like, and with Elm 19, it's an even friendlier compiler. Took me out to dinner last night.
>> Complete gentlemen. But for when we started Elm a year and a half ago, it was really helpful to get those that sort of helpful feedback. But we still were pretty new and even with it being a friendly compiler, we still were stumped much more often. But now we have some more people in our company that are coming in and learning Elm. More of our design team is starting to learn Elm and that highlights it even more for us, is that they have repeatedly said my goodness this compiler is so helpful. So that is really cool to hear them say that and for us to be reminded. Cuz we begin to take it for granted and especially because we compare it to the Haskell compiler. Which just today had some issue that I thought when we compiled it was going to complain because a parens was in the wrong spot and it gave some really gnarly output. I was like I don't know what you were saying, put a parens there and my kinda gut just tells that's what is is, sure enough that's what it was.
>> But if I had not already suspected I was gonna have a parens issue I don't know long I would've looked at that output not knowing what to do.
>> Yeah, I often find that the GHT compiler is more useful at telling me that there is an error rather than what exactly the error is. Usually I'm like, well, I probably know what it is already.
>> Thanks for letting me know Haskell.
>> Yeah, so we love Elm's compiler. Purescripts' compiler just isn't quite as friendly, it sort of as a couple tattoos, smokes or something.
>> Not nearly as friendly. In fact, when you compare Elm to Haskell, and you see how much better Elam is, I feel that when you compare Haskell to Purescript, you see how much better Haskell is.
>> So that bad? Yeah, granted, my perspective of the Purescript compiler is woefully out of date. I used it maybe two or three years ago, and I I am confident that in the meantime things have gotten better. But it feels a lot like it technically tells you what the problem is. But it drowns you in a bunch of contexts and weird variable names and other things and weird terms. From my point of view, I wouldn't be super comfortable throwing a junior developer in front of the Purescript compiler and having confidence that they could figure things out. Or not a junior developer, but our front end team. If they were working on a PureScript application, I would expect to be called over there frequently, having to puzzle out some output from the PureScript compiler.
>> I would say why, why do I have this mandate.
>> Nice. Similarly, strings in Haskell are notoriously a linked list of characters, which is one of the worst representations you could come up with.
>> I feel like I could come up with a worst one, but sure.
>> Yeah, yeah. Okay, so Purescript does the anonymous records, which reduces a lot of boiler plate. So if you have a user record with a name and an age and an occupation, and blood type or whatever, sure, and you want a subset of that record for some other purpose, so you have your master record. And then you have well here, I just want these three fields, but there, I want these five fields. That's what you're talking about with anonymous records?
>> Exactly. As an example from our code base, we have the fully fledged user type that has those fields you were talking about. Not blood type, we don't capture that about our users.
>> But we also have a minimal user, which is useful when we're writing tests, or when we want to add a new user, and we don't have all of their information yet. And we don't care, we don't have their address or their billing information, or any of that stuff.
>> Their shirt size.
>> Their shirt size, exactly. With Haskell we have to explicitly make a user, a minimal user, a slightly more minimal user, a slightly less minimal user, user with a bunch of other fields tacked on. And in Purescript you can make all of those a little more implicitly, a little more off the cuff. And as we frequently experienc, one of the hardest things in day-to-day software engineering is naming things.
>> And when you have to make new Explicit types of everything, you have to make names for them. And this sounds kind of like a petty concern, but it's honestly hard to do. Because if you have a user and you have a user with two different fields, they're both users. So which one, you have to call one user and one something else. It's frustrating.
>> User prime.
>> User prime prime.
>> Please don't do that.
>> User prime prime prime.
>> We don't allow primes here.
>> No primes.
>> No primes. Yeah, so I like that, I can certainly hear someone who prefers the Haskell way of doing it, though. Because arguably, those are different things, and different things who have different names.
>> Very true.
>> But in the day-to-day, it is just kind of inconvenient. So is there anything else that comes to mind, Purescript being better, maybe than Haskell in some way, or some other benefits to it? I think that it has a lot of well thought out type level features. This isn't something we typically work with in our work at ITPro. We try to stay in the value level as much as possible. But Haskell is moving in this direction where it's getting closer and closer to having dependent types where your type signatures and your type computations can depend on the values themselves. And the classic example of this is a list where you know how many elements are in that list. And so you could group, for instance, with a map operation, that you don't change the number of elements. I don't really wanna get into dependent types. But suffice to say that I think Purescript has a has a lot more niceties in the type system that, to get them done in Haskell, you have to turn on a bunch of language extensions and jump through some weird hoops and do some things that aren't very comfortable. So to bring it back home, I think you original question was, if we weren't using Haskell on the back end, what would we be using on the back end?
>> Yeah, yeah. Let's talk about that.
>> Okay, that multithreading constraint sounds pretty significant. Because a lot of what a back end is going to do at some point, maybe not a lot of what it does, but frequently you're going to be doing something like that, where you're wanting to handle something asynchronously send off an email.
>> Yeah, almost all the time.
>> Yeah. Always sending emails. So that makes a lot of sense. Purescript sounds great. But if you can do, if you can use Haskell, it sounds like you should.
>> You should.
>> Of course, that's our opinion because that's literally what we're doing. But I start to see that a little bit better now. Thank you.
>> So we're choosing Haskell on the back end over Purescript because Haskell just has more tooling like asynchronicity, whereas PureScript is a little more complicated. It's easier to deploy because Haskell just has the binary that you deploy that. Whereas PureScript, a lot more points of failure there. Again these things tend to be solved problems but there's always cracks in that so just nicer, simpler to think about. Simpler to handle. So that's Haskell versus Purescript on the back end just quickly. On the-
>> And to jump in for just a second, I would love to use Elm on the back end, but it's not currently an option. And I feel like Elm is doing very well at targeting the front end and its particular niche that it wants to dominate. I'm very happy that they're doing that. If I could use it on the back end, I would love to, but-
>> Really? That's the first I've heard of this. Elm on the back end, Haskell on the front end.
>> [LAUGH] You heard it here first.
>> Precisely. So, Elm over Purescript, primarily because of the compiler. Purescript has a lot more complexity, a lot more robustness in some areas. But you don't need those strictly. They're really quite helpful in some cases, so maybe your use case, you really do need those things. But for most people of of the time, Elm totally targets single page apps. They are focused on that, and they're doing it quite well. The compiler makes it really easy to pick up this new paradigm of functional programming, a new syntax. It has, we didn't talk about this, but something that we like a lot here at ITPro is, it has this architecture built right in to the language itself. And it's nice to not have to think about that or worry about that, it's just there.
>> The tooling's really good. It's an opinionated formatter, so you don't have formatting wars or arguments. So, those are some of the reasons that you mentioned and then I just threw on top of that of Elm over Purescript. It's like Purescript seems really good, but Haskell might just be a little better than it in a lot of cases on the back end and Elm might be just a little better than it In a lot of the cases in the front end. But I just need to use it recreational like you used to.
>> Is what I need to do.
>> Thanks for being on the show with me today, Jason.
>> Thank you.
>> It was great to have you here talking about Haskell versus Elm versus Purescript. A fight for the ages.
>> Versus a bunch of other things.
>> We don't talk about them too much. [LAUGH] And thank you for listening to the Haskell weekly podcast. This has been episode three. If you liked our show, find out more at our website, haskellweekly.news. Thanks again for listening. I've been your host Taylor Fausak, and we'll see you again next week.
>> Bye. [MUSIC]