Haskell Weekly

>> Hey there Haskell weekly listeners. Welcome to another episode of the Haskell weekly podcast. I'm your host Taylor Fausak. I am the director of software engineering at ACI Learning. And

>> I'm Cameron Gera. I am a senior software engineer at caribou, which is a fantastic place to be and no longer it pro, but it's okay. We're still doing the podcast here and, uh, excited to be here today. How's it going today?

>> It's going good. Glad to be back on a new episode with you cam, we took a few weeks off there around Thanksgiving. Things are going well. Yeah. It seems

>> like we do that. We get like two weeks pretty good in a row. And then all of a sudden it's like two, three weeks. We're like, oh yeah, Nope. Hasn't happened. So, uh, we've got the holidays coming up as well. So we'll see how, uh, the rest of this, uh, time goes

>> for the rest of this year. I think in retrospect, calling it high school weekly was a mistake on my part. It should have been Haskell semi-weekly. Haskell sometimes. But yeah. Um, so yeah, we'll be probably off a little bit around the holidays, so prepare yourself for that. Uh, but this week we're going to be reviewing the Haskell survey results. Um, I published the survey results just after they, the survey closed, which was, uh, in the first half of November. But, uh, we haven't got a chance to go over them here on the podcast. So I figured we'd do that today? Yeah. Yeah. I think

>> it's, uh, got some fascinating insights. Um, you know, this. It was actually lower response than previous. Um, and I'm also a guilty party for not actually have done it. So, uh, whoops. It's, uh, you know, we have little over 1100 responses, um, which is just a few hundred down from last year. So, uh, you know, a little less, uh, participation, but still great fascinations. Trying to make some rhymes here.

>> I'm not too concerned about the dip in participation this year. It doesn't portend anything to me. I think it just waxes and wanes and we've had it go up a little bit and now it's gone back down. Um, also before we get into looking at the results, um, the Haskell foundation is actually hiring a data scientist to come through these and provide. Better, I would say second or third level, you know, analysis of these things. So rather than looking at one question in isolation, looking at some types of things, like if they answered one question this way, how does that impact their, the way they answered these other questions? And in particular, that could be really useful, um, by splitting people up based on their experience level or, you know, any number of facets.

>> Dang. That's pretty cool. And this next year is going to be probably something the Haskell foundation runs

>> correct? I think so. That's my goal is to hand off this survey, I've done it for five years now and I have got it down to the point where I don't have to spend a lot of time doing it, but that means also that. Really actively working on continually improving it. You know, I'll make little changes and tweaks here and there, but for the most part, I just ask the same questions every year and post the same, um, results formatted in the same way. Right.

>> Cool. Yeah. So, uh, I guess with that, we can get started what's uh, what was one of the first things that kind of caught you by surprise?

>> Something that got me by surprise. It wasn't necessarily new this year, but that I want to call out and just appreciate is there were a good chunk of people who took the survey, who don't currently use Haskell. And that's both people that used it in the past and don't anymore or people that have never used it. And I'm really curious how those people that never used it ended up taking the survey, but I appreciate their viewpoint. And I also appreciate the viewpoint of people who used it in the past and kind of either left it for whatever reason or gave up on it or whatever it is. Those are really valuable viewpoints. So I just want to thank the people that have done that and who, you know, I wouldn't expect them to be listeners of the podcast, but maybe they are. Yeah. Maybe they're

>> just dreaming to get into Haskell more, you know, providing their feedback, whether they don't have any experience or if they have had experience in the past and it's, they left for some reason. Uh, so yeah, I think that's been pretty interesting. Um, you know, I think. Looking at the breakdown. Obviously there's a lot of variation in, in the demographic that we, that are filling this out. Um, whether it's experience or it's, um, you know, kind of frequency or, or the reason to use Haskell or, you know, what be it. Um, but I did also like that, the fact that like, you know, Tying into your people who used to use Haskell, or may not even use Haskell and filling this out. Like the question about, do you use Haskell at work like 36, 33. 36% of the people who answered the question were like, no, but I'd like to, you know, which is more than the, yes, most of the time, you know? Uh, so that was kind of interesting.

>> Um, yeah, that's huge. And I really wish I had an answer for those people of like, how can you use Haskell at work? You know, is it a problem with Haskell? Is it a problem with the company or is it not really a problem at all? It's just the way the chips fell. That would be an interesting thing to dig into and get some qualitative answers from those people rather than the quantitative numbers. Yeah.

>> And I think too, that like, yeah, it's that barrier of entry, is it there's that too high? Um, you know, is there something like my, my recommendation for those people would be like, just see if there's some way. Have a spike of a Haskell project and kind of show the power. I think that's something here at caribou we've done is that we've kind of showed how powerful, you know, Haskell can be for both like speed and, you know, consistency and performance and all these things. And so we've really created a nice kind of, we advocated well for the language in our job. But I just kind of starting with little things and seeing the payoff there. So you know, that would give you my recommendation to those who would like to it, just say like, Hey, you know, you guys have a company hackathon or something comes up and you're like, Hey, let me, can I, can I try this with Haskell and just see, um, you know, and I feel like there's a lot of resources out there too for, you know, higher ups who you're trying to convince. You can work with them, kind of say, Hey, okay. Hey, here's. Here's the parameters for success. And, you know, we're going to try to, you know, spend a month on this, you know, and hopefully with that month, you have the opportunity to kind of really expand your knowledge and the company's knowledge of Haskell and, uh, you know, create a great product out of it as well.

>> I agree. I think that's great advice and it's worth reiterating, or maybe not even reiterating, just if you weren't aware with ACI Learning, which, um, I came from the it pro TV side of ACI Learning and ITProTV, wasn't always a Haskell shop. It actually started as a WordPress site. So PHP and then had a, not too brief stint as a Node JS shop using Sails JS. And very briefly used Golang and then got over to Haskell. So I think people may have this impression that in order to use Haskell at a company, it has to be founded by somebody who is. Gung-ho about using Haskell and that's not the case. It wasn't the case for us.

>> Yeah. Yeah. I mean, and I'm currently in a place where we're a Ruby and TypeScript shop, so it's kind of like, you know, pushing our way through. Um, and you know, we have a lot of people in the organization who are interested in what we're doing on our team, um, since that's where our Haskell is currently, but we're gonna continue to do book clubs and things like that to spread Haskell through the rest of the organization. And we're hoping that. We're kind of going to a microservice architecture as it is. Cause they kinda got their wires crossed and uh, you know, when you're in a startup, you're trying to get a product out there. So there's choices made that kind of created a lot of coupling and, and things. So I know we're trying to spend some time to clean that up and then ideally pull some of that, you know, those things out into maybe services. And, you know, there, there's an opportunity there to also use Haskell, you know?

>> So, yeah. That's one of the benefits of microservices is that you. A small piece of your infrastructure written in a different language and, uh, just try it out, see how it works. Yep. So moving on a little bit, uh, one of the other questions that's interesting to me, I don't know if I'd call it surprising. Is the, how many years have you been using Haskell? And I, I guess I was surprised to see that a lot of people that answered this survey had been using Haskell for less than two years. Which means there's a big group of people that are really new to Haskell. And for me as someone who's been using it for several years, like on, in the five to 10 range at this point, it's easy to forget what it felt like to be, you know, in year one of learning Haskell. And I think so much of the, um, material in the community blogposts and stuff like. Caters to those experts, the people who've been using it forever and really want to push it to its limits. But it's important to remember a big chunk of the community is new and just needs help with the basics and, you know, comparative analysis. How, how do you do something and how do you choose which way to do something? How do you choose a library? All those things are challenging. And there, there isn't a lot of material written for that.

>> Yeah. Yeah. And I think, I mean, I would have those same questions and, um, Almost at the three-year mark. So it's kind of that like finding the resources that give the beginner a chance. Um, and that's kind of, you know, I think if you're going into an organization that has high school, a lot of, I mean, I think it depends on what they're doing, but you can kind of find a niche of simple Haskell and kind of keep to that so that as you're bringing on new hires and you're bringing in interns or whoever they may. They have a little easier handhold into Haskell. Cause it's not, you know, crazy bind syntax that you're trying to figure out, okay, this applicatives to this and what, and I left bind and arrow star ship. Oh my goodness. You know, there, there's a lot of, you know, operators in Haskell that can create confusion. And there's also, I mean, I've, I feel like that's in any language you can write things to be confusing. So um choosing to kind of fight for simple Haskell is going to help those beginners you know really feel confident in the language and, and probably take that next step of, okay, now I understand the basics. What do I need to do to get to the next level? I've got to be a 10 X developer. Yo.

>> Yeah, that's absolutely true. And I think even simple Haskell is already a much more powerful and expressive language than many other programming. Like. That you would do well, just sticking to that and yeah, there's going to be edge cases here and there that you can't that feel like they should be able to be prevented, uh, like from the type level to turn them into compiler errors, but the price you'd have to pay to turn them into compile errors is pretty high. So just deal with the runtime error or potential runtime error and keep the code simple for awhile. And then eventually you and your team will have enough experience to be able to say, are we comfortable um, increasing the complexity in order to also increase the safety or the guarantees we get from the code. Right.

>> Take advantage of some of those deeper things. Yeah.

>> Cool. So, which is the next question that stood out to you Cam?

>> Um, yeah, well, I was just looking through and kind of perusing here, but, uh, it's interesting to me that. 62% of the participants answered that they develop command line programs with Haskell. Uh, that was kind of interesting to me. I mean, I definitely can see why it would be that way. I was just expecting API services to kind of run the roost there, but you know, everybody's got, you know, different ways of, of using it. So I thought that was pretty interesting. Um, have you, like, I know you've done some stuff with kind of CLI. And Haskell, um, with your rocket league parser, right?

>> Yeah. Uh, and I'm in the same boat as you. My, you know, I programmed API services for most of my professional career. And so that's my bias and that's what I expected to see at the top of the list here. But, um, I think command line programs are probably the least common denominator. Like even though I typically write API services, I also write command line programs and. Right libraries, you you'll also probably write some command line programs. So it's like everything else involves some manner of that. So that's probably why it's up at the top. Um, but as to like my experience writing command line programs with Haskell, I found it to be a very nice programming language for it. And it, you know, works well and gets out of your way. Um, I'm not sure. What else to say about it? Like there, there are good libraries for parsing command line arguments, um, optparse-applicative, or optparse-generic are both pretty good. Uh, and there's actually a module built into the base library. That's just a reimplementation of getopt, which is a common C or C++ way to parse command line flags. And it's not very like, uh, Advanced or nice to use, but it gets the job done. So if you're trying to avoid dependencies for whatever reason, there is something in base that can let you do that.

>> Hmm. Nice. Um, yeah. W what was the next question that kind of stood out to you?

>> Yeah, I'm still looking around. Um, there's a couple that are not surprising, but I want to highlight, which are that most people develop on Linux and most people deploy to Linux. So that's been true every year. I've done this and I suspect it will continue to be true for a long time. But, um, one thing I've said before about this, that was probably a little controversial is that if you're trying to build some tooling for Haskell. And you feel like you may not be able to make headway or support all three major operating systems, Linux, Mac, and windows at the same time. Just build it for Linux at first. And then if it catches on and the community seems to like it. Yeah, go ahead and also make it work on Mac and windows, but don't feel obligated to do that out of the gate because you're going to hit almost, I don't know, 80%. So four out of five Haskell developers you'll hit with just getting Linux.

>> Yeah, I think that's definitely something that's pretty cool. Uh, yeah, the next one I wanted to dive into, if you're okay with jumping into it is the language extensions, which one people would like enabled by default and lo and behold, our, uh, our Lambda cases up at the top. Which is interesting to me.

>> I mean, I guess why is that interesting? It's just because it's

>> something I've never really used or try to use, uh, because it's, I don't know, seems like it can create a little more confusion and chaos than it's worth, but, uh, you know, I know there's obviously use cases for it. It's just interesting that that was like the one that most people wanted. Instead of, you know, enabled instead of disabled.

>> Um, yeah, I have an opinion about Lambda case, but before I launch into it, um, a quick note, if you're listening to this and you go look at the results on the website, because there will be a link in the show notes. Um, I want to explain briefly the visualization here, because I had a question about it. Uh, with all of the other questions, it was just like a bar chart for who, how many responses did I get for each answer choice in this one, there are kind of two bar charts at once, because for each question or for each language extension, people were able to select, yes, I want this enabled by default or no. I don't want to, I don't want this enabled by default, or I would resist a proposal to enable this by default. Um, and that lets us say, okay, like Lambda case. Um, we had a lot of votes in favor of enabling it by default and almost no votes opposed to enabling it by default. So that means it's widely, uh, a lot of people like it and not too many people dislike it. So if you go look at these results online, that's what the two bars mean. The blue one means yes. And the orange one means no. Gotcha. So with that caveat out of the way Lambda case, um, I feel like I see why so many people voted for this. It's just a pure syntactic sugar thing that lets you write expressions that. More or less on ambiguous and avoid naming variables. Um, but I personally dislike it cause I feel like it complicates the grammar for such a small benefit. Like to me, the downside of writing backslash X arrow case X of, I have no desire to replace that with backslash case, like, okay, I saved a couple of keystrokes, but it doesn't really change anything.

>> Yeah. Yeah, and yeah, I haven't had, I haven't used it in anchor, so I wouldn't know if I would like it or not. Um, I think my opinion on that has been probably based on your opinion of that as well, just cause it's, you know, I was, you know, we worked together for so long. It was kind of like, Hey, I know a Lambda case isn't really worth it kind of thing. So that's probably where my opinion comes in. But I'm also the advocate for simple Haskell. So like, I feel like for the benefits, it just doesn't like. It's not worth

>> it in my opinion. Right? Because you have to teach people. Okay, well, there's this whole separate syntax now for when you have a Lambda that has one argument and you're just casing on that argument. You can get rid of all this stuff around it. And I feel like it's simpler to just say, if you don't care what the name of this argument is, just put an X in there and move on with your life. Um, and I feel like this kind of goes with the Haskell community's overall. Dislike of naming arguments. So there's a lot of, you know, writing stuff in point free syntax, lets you avoid naming arguments, um, currying or partially applying functions lets you avoid naming arguments. And I think those are all all right. But I try not to take them to the.

>> Yeah, simplify everything. Point free, nothing is variables. It's all you have one input to the system and then everything else is just point free.

>> Um, so one of the extensions that stood out to me was a little further down the list, which is applicative do, it's a relatively new extension where if you write a expression in, do notation. But you don't actually use any features that would require a Mon ad. It will infer an applicative constraint to that thing and rewrite it using the applicative operators, which are pure. And, um, people call it all kinds of different things, spaceship or a tie fighter, or a less than asterisk greater than anyway. Um, that's what applicative do. And I wanted to highlight it because it's one of the few language extensions that was really, really contentious. There were a lot of votes to enable it by default, but also a lot of votes not to enable it by default. And I don't really know why that is. Do you Cam?

>> I don't. Um, unless people are, are more focused on, I mean, I honestly have no idea. Uh, so can, can you kinda talk about like, Yeah, I guess for me, I'm, haven't really, I didn't even know this was really a language extension, so you know how cool I am. Um, but you know, what, what would be like a big downside to this?

>> I'm not well-versed in the downsides of applicative do I think probably, and this is true with many language extensions, probably, uh, Error messages get worse. If you have this turned on and you do something wrong because the implied constraint will be different than what you might expect. Um, also I think I have a memory, so this could be wrong, but I have a memory of when this was first rolled out, that it was buggy in certain circumstances. So like it, wasn't generally safe to enable, applicative do for an entire project because. Suddenly behave differently. Um, and maybe that's why, or even, uh, if your oper— or if your constraint is something that's a monad, but it relaxes it down to an applicative. That means things may happen in parallel when it looks like they should happen in sequence, because if your monad doesn't. Use the result of a previous binding, then applicative do will infer that those things can be done. You know, they don't really depend on each other, so they could be done at the same time or one before the other, whatever. And that may break programs that do depend on that, um, specific ordering of. Gotcha.

>> Cool. Yeah, no, I think, I feel like that's some valid concerns for, for people. I mean, so it makes sense that it would be such a tight race. Uh, and you know, I know. I mean, we we've talked about, uh, GHC 2021, many times on this podcast. Um, which is just this, for those who haven't, who don't know, it's a default set of language extensions that are going to ship with the language, uh, kind of like Haskell 2010 and Haskell 96 or

>> 98 90 is the first one. Yeah. So

>> you know that that's like a preset and you know, on here, we didn't like mark that, whether it's part of it or not, uh, But yeah, I think it was kind of interesting that like, Maybe the, maybe the committee who kind of decided what Haskell 20, 21, has they take a look at this? And if it has any like, correlation, like, okay. Yeah, we see a majority of people want tuple sections. All right. Well then we're going to maybe we'll consider that or maybe it's already in there. So,

>> um, yeah. And in fact, they did look at it last year as they were compiling the extension set for GHC 2021. This wasn't the only thing in the mix, but this was one data point a and they also took a look at. Packages on hackage to see which language extensions they enabled by default and which ones were enabled within modules, uh, explicitly. So, um, yeah, your, the people who responded to this survey, your voice was heard and it got incorporated into GHC 2021. And hopefully this will get incorporated into future versions of the Haskell language. It's not a standard now because that's not what GHC 2021 is, but like extension set, I don't know what to call it.

>> Yeah. Like, uh, just kind of like a pre-packaged situation. So it's like, it's like you ordered it on Amazon and now it's at your front door in

>> two days. Yeah. Well, I'm sure we could talk about language extensions all day, but do you want to move on to another, another question? Um,

>> you know, I think one that probably gets a lot of conversation in the Haskell community as probably, I mean, I think there's a, quite a few, but I think one that is. Pretty common. It's probably tooling. It's like the question around tooling. And, um, I think in 2021, we had a huge kind of swing towards like some better tooling. Um, and that being in HLS, Haskell language server, I think that has really taken off. I think, you know, early in the year in 2020 as well, it was. To buggy, there's some issues with it. And so, you know, I think in 2021, it's really solidified as for me, my go-to IDE, um, you know, and I'll use GHG ID or I'll use just stack, um, sometimes, but really if I'm trying to iterate quickly, HLS is, you know, where I'm at. That's my bread and

>> butter. Yeah. I agree. It is both an amazing project and it has improved so much even just in the past. I feel like it's gained so many features and it's gotten much faster. So if you've looked at it before and had trouble with it, take another look. But most people have looked at it almost 65% of people that responded to the survey. Use HLS and that's huge.

>> Yeah. And I think too, it's funny that like, uh, you know, Adam, you know, I don't know what four, four years ago, five years ago, it was like one of the top editors in general. And now, you know, it's just 2% of people.

>> Yeah. And I think all those people switched over to vs code, which is now the most popular one, beaten out both VI and Emacs. So yeah.

>> Better not tell Jason or Cody.

>> And, uh, another big upset this year was the cabal overtook stack as the most popular build tool. And I think there were two big reasons for this one is that. Improved quite a bit. And with the newer versions of the cabal spec and cabal library and cabal install, command line tool, they've gotten a lot of nice new features. Um, but also I think the ghcup project helped with this because if you use ghcup, that can manage your GHC installation and then also install cabal for you. And then you're ready to go. Um, and for me that was one of the big upsides of stack. Was it managed GHC for me and just drop me in an environment that was ready to build stuff. And now I usually reach for ghcup and cabal rather than stack. So that's been a big change for me at work. We still use stack. So I'm still very comfortably switching between them, but for personal projects, I've tried it out and I liked it. So I'm sticking with it. Nice.

>> Yeah, I have not looked into ghcup so I'll have to check it out. We use stack uh, with templates. So we have a stack template that we generally build all of our Haskell projects with. Um, cool. So that's been pretty nice, especially for microservice architecture. which kind of gets the skeleton up and then we can, uh, hear it from there.

>> Yeah. One of the most popular things I've ever worked on in the Haskell community is. Stack template for setting up a new project that I called Haskeleton. Um, I'm not sure if it's still a stack template. I haven't worked on it in awhile, but yeah. Um,

>> Haskeleton were, were they're very, uh, I feel like the Haskell community is very good at naming.

>> Yes. hasql

>> hasql Hakyll? Well, the blog

>> HASQL HASQL. Yeah. I never know how to pronounce that one. It's a great name, but I don't know how to say it out loud. Yeah.

>> It's always fun. It's like, it makes it really easy to talk about.

>> Um, so related to tooling, another one of the things that really surprised me this year and every year is I ask which tools do you use to deploy Haskell applications? And many, many people say that they deploy static binary. But I'm not sure. I believe them. It's really hard to build a fully static binary for Haskell. And I think people are deploying mostly static binaries. So I don't know if that's a distinction worth making, but that surprised me. Yeah.

>> Yeah. I mean, from my, my experience it's been Docker images all the way.

>> Yeah. And those are very popular as well. But, um, I'm curious, like when people say static, binaries are. Building inside of Alpine and statically linking glibc or not glibc, but musl libc. Um, or are they statically linking everything except libc um, I'd be really curious to dig into that one.

>> Yeah. So if anybody answered that and has uh an example you want to be on the podcast, please reach out.

>> We'd love to have. You know, maybe they really are doing static binaries cause a good chunk of people use Nix and so nix can produce a static binary. So maybe that's how they're doing it. Yeah.

>> Still, could be a fun episode to dive into. Um, cool. Well, that was kind of a touch on infrastructure as well. Um, is there, I mean, we've got kind of community as a section here in the, in the, um, results on the survey and, uh, you know. I think one that's always interesting every year is the, which of the following topics would you like to see written more? Cause it's always like, okay. Like what could it be? Cause that's, you know, luckily it's a multi-select cause everybody has opinions on what they want to see more of. Um, what I'm surprised about those is really low that people are like, eh, it would be game development. I feel like it could be kind of fun to figure out if that's. A viable possibility using game, having game development.

>> Yeah. I mean, I think it would be fun, but also what's the, you know, the Venn diagram of people that are Haskell Haskell developers and game developers is probably pretty small. And that's actually one of the things I like about this question is that I think it gets to the heart of often people will write about things that are interesting to them, which is good. Cause it's easy to be jazzed up about that and write something good about it. Um, I think it'd be better to direct or, or maybe even pay for articles that focus on these things that people in the community want. So like best practices is far and away. The most popular thing that people wish there were things written about. So why, why doesn't anybody write about them? Or why do we not write enough about them? I guess would be the better question.

>> Yeah. The hard thing I feel like with best practices is it's all opinion-based, but hopefully, you know, with the Haskell foundation and the committee there and the team, it'd be nice to see if something from that foundation could kind of help lead the charge in the best practices, movement. And then, you know, kind of keep a series of blog posts or, you know, video series or something to kind of illustrate, you know, as a whole, like what's the Haskell foundation thinks about these things. Um,

>> yeah. I think best practices are inherently subjective. So it doesn't bother me too much that, you know, there, it best practices may change or may depend on who you ask, but I still think it'd be really valuable. And you know, I'm guilty of this as well. I run a team of Haskell developers and we haven't written much about what we do or why we do it, but, uh, we probably should. And maybe I'll try to make that a focus in the coming year.

>> Maybe so we'll have to keep, we can make Haskell weekly podcast, a accountability partner to that.

>> Yes, I like it. Yeah. Um, so the next big section of the survey results were for feelings and I feel like, uh, these haven't changed too much year over year. And the only thing I want to point out is that overall, when they're presented here in the survey results, they're sorted. So the ones that are most positive or that most people agree with are toward the top. And then the ones that people mostly disagree with are at the bottom. So as you scroll through things, get more and more bleak, and then you get down to the bottom and it's like, oh, I can find Haskell jobs. And I can reason about the performance of my Haskell code. Those are the things people disagree with the most.

>> Yeah. Well, I mean, if you're interested in a Haskell job, Caribou's hiring. So is ACI Learning, so there's Haskell jobs out there for you, if you want. you know, Hit

>> us up. Yeah, please do. All right, Cam, was there anything else in the survey results you wanted to talk about? Um,

>> I don't think so. I mean, I think this survey is really cool. I mean, thank you for kind of putting it all together and kind of, you know, keeping it organized and, you know, displaying results. I think that's a big Testament to. like, to just how much impact you have on the Haskell community. And we appreciate

>> that. Uh, thanks. I appreciate it. It's

>> nice to have someone who's willing to kind of take that on. Um, and for you to spearhead it for five years is impressive. Uh, needless to say. Um, so yeah, I don't, I don't think I have anything else on the survey. Do you have anything else you wanted to

>> share? No, that was it. And, uh, again, thanks for the kind words I enjoy running the survey, but I will also enjoy handing it off to the Haskell foundation if they want to pick it up and the secret to doing something like this from my point of view is automate as much as you can, because that's what lets you do it over and over again. Yep.

>> Yeah, it sounds like, uh, a good programmer's motto

>> for sure. Yeah. All right. Well, I think that'll do it for us this week. Is that right? Yeah. That'll,

>> that'll be it. Yeah. Thank you all for listening to the Haskell weekly podcast. Uh, I Camera Gera and Taylor, have been your hosts. Um, and if you are curious about where you can find Haskell weekly, just check out our website at haskellweekly.news, um, and also sign up for the weekly newsletter. And you can hear more about the articles we're talking about. Um, As my dog is running into this room. So,

>> um, your dog is so excited, wants to sign up for the newsletter

>> ready? So, um, but yeah,

>> toss it over to you. And this week, as every week, we are brought to you by my employer, ACI Learning. If you'd like to get started in IT training, head over to ITPro.TV and use promo code HaskellWeekly30 to get 30% off the lifetime of your subscription. That's ITPro.TV, promo code HaskellWeekly30. Awesome. Thanks for listening. And we'll see you next week, peace.