SBTB 2023: Avi Press, Why Haskell is a Terrible Choice for Startups (And Why We Picked It Anyway)
all right thanks everyone for being here um yeah so the stock is why has is a ter terrible choice for startups so why are we picked it anyway um despite the incendiary click baity title I'll try to give kind of a balanced view on four years of hasal and production and how that's gone um just to you know introduce myself here really quickly um some the founder and CEO of scarf and what we do is uh usage analytics and sales intelligence for open- Source software companies um the whole backend um is hascal um it's definitely running at scale serving almost 200 million software package uh downloads globally every month um and that's now about 350,000 lines of hcll code in that code base um but I've personally been a hcll developer for quite a while now um and this is kind of how it's played out in practice of building a big project with it so when you know when we're trying to evaluate like what is a good language choice in a startup I think it's just important to start with well what what do we actually care about if we're trying to pick technology for a startup environment um and I think my personal opinions on this really evolved from being an engineer into being you know a a founder and CEO of a company the criteria has kind of shifted a lot from that perspective um but you know really when you're trying to get a company off the ground number one number one thing is that you're trying to find product Market fit um and build that business as quickly as you can like the the clock is running the bank account is dipping and you're you're trying to move as fast as you possibly can to find a product that you know brings value to your customers and so the speed that you are shipping code is really really important um and also the your agility you know of your product that you can adapt to changes quickly uh may make or break your success you're going to start out with something that you know may look very different from the thing that you find that's actually successful you know when you find product Market fit of course it's not just building a product but you're also trying to build a great team very fast as well so maybe you have a great Network that you're starting uh with maybe you don't uh but one way or another you need to get really good Engineers uh on board once you do have that team and you have the product or even before the product you need to you need to focus just on your Tri priorities and nothing else and keep costs down while you're doing it and all of this is a lot of work um and so making sure that you're doing this in a sustainable fashion not burning yourself out is also very key um and you know a lot of things that I think we traditionally talk about when we talk about you know programming or you know just I don't know developer philosophies that may not matter as much here in this context you know things like correctness and finding Perfect extractions and beautiful code you know all things that we like to talk about and care a lot about you know in terms of our craft as developers but you know those things typically are not really going to make or break the company as much as we like might like like to think um and so you know ultimately I think the the things that we often focus on when we are talking about programming when you zoom out on your business and you're trying to figure out whether your business is going to be successful it's not actually really all that important um and you know I think you know grain of saltier I have you know much more radical opinions on this after kind of four years of of of getting a company off the ground um and so when I was trying to get when I was trying to get scarf started um hll is my favorite language and you know of course let's just use hll like how hard really is it going to be um but you know we we found out the hard way and here here's all the lessons from that um and so you know I think the first the first um you know thing that comes up a lot when we talk about hll in a company is is the topic of hiring um I think it's is a pretty nuanced topic uh with a lot of pros and cons here and so you know when we first when we first um you know raised money and were originally trying to hire our first Engineers we could literally just put a a job J listing up on Hacker News and we get about a hundred really really good applicants is super easy because people would rush to you that there's a h job I want that hcal job and you get developer showing up um just because the tech stack is hcal and that's awesome um and you know the other good thing is that you know when people apply like hasal I feel like is already a pretty decent first pass it attracts really great Engineers it has a steep learning curve which actually works to your advantage here that people have already gone through that um um you know and and a lot of people who care enough to learn hll probably care really deeply about the craft of programming and doing it well um you know I mean obviously generalizations it doesn't apply to everyone but like in the agregate this this has been true for us um on the flip side though uh you know we have to have the perspective of of ecosystem size and the reality is the the the the talent pool for hll is very very small um um we were getting scarf uh started in the middle of the pandemic and so you know the fact that we were kind of pushed to do a fully remote business was you know I think there were a lot of factors that led to us doing that um but I think even if we had started scarf at a time where the uh you know covid was not happening this probably basically would have forced our hand to be a remote company it's very hard to find um hosal developers specifically in your area even in the Bay Area we very rarely get applicants from the bay um you know and I think the other thing here too is just that the your average cost uh per engineer is probably going to be higher um that might be okay right like you can get you can definitely have a team of very experienced Haso developers and get a lot done with very few people um but if you're trying to keep costs down if you want to have a team that's kind of you know c collocated um hll might not be the best choice um I think kind of one of the more obvious uh drawbacks to picking a language like hll is that you're going to run into missing libraries you're going to run into incomplete libraries and so one thing that we've been experiencing a lot um at at scarf is that sometimes the the you know the the technology choices that you want to pick or the vendors that you want to work with um it may really conflict with your choice of hll right like if you want to get Bill you know payment set up if you want to you know run particular database providers that you you know that that you want to work with you may find yourself having to write the libraries yourself um you may find yourself adopting a library that's really incomplete um poorly maintained um and so you know that that's that's a really tricky thing to to to work with and so like we've had to write you know we we've used Rock DB and so we had to publish Rock DB hassle because that didn't exist um and that's a thing that you will run into often and I think it's not just the fact that it's not just the fact that the the the librar is may be missing but it's the fact that you have to make this decision every time you run into this of you know do we pick a vendor that we don't really you know want to use just because it's going to interact better with Haskell are we really going to pick this database purely because the hascal bindings are better and you know each time you have that discussion internally that's kind of detracting from the thing that you're actually trying to do and you know when it comes to the actual ecosystem sizes I think this graph can really show that like despite the fact that I think hll has a lot of really great libraries the overall size is just really really small when you zoom out and see what the bigger picture actually looks like and so you know I as a you know when I was writing code at scarf there were times where I was literally having to work late just to patch the stripe library and at the time you know this has changed a lot since but at the time the stripe library was using type families it would take forever to compile just to add like one API endpoint to this library that we're like working late doing doing this stuff that is really not the core thing that I'm trying to do and solve and so um you know the reality working in a startup is that you are working a lot um you're working all the time and when you are and this takes time out of your life to you know do things that really are not the core thing that you're trying to do um which I think you know it sounds you know that that may or may not sound compelling in practice but in reality this has a real impact on your life as someone trying to start a business um and I think a thing that comes up a lot with this of just kind of doing this kind of extra work that has been solved in other uh programming communities is things that things like we are still missing a lot of the tools that you know come with rails and D Jango and these really batteries included web Frameworks I think a really great example of this um is an admin panel you know a lot of a lot of uh batteries included web Frameworks have an admin panel where you can go and just you know modify the data structure or you know the the data that you have and kind of you know do the administering of your web app um you kind of have to build this from scratch in general in Hell although the caveat here is I think ihp is is uh making a lot of progress on this and so I'm really rooting for that uh web framework but this is just one example this kind of stuff comes up a lot where you know something that is kind of already solved in another in another ecosystem you're going to have to probably do it yourself in Haso um you know another I think very common issue uh is that you're just the the compilation times in hascol I think there's a few pieces to that so one is just the fact that fetching dependencies in high school takes a really long time and so you know onboarding new Engineers if you you know if if you don't have uh if for whatever reason the cash has been blown away you're just sitting around and waiting for a a while um we had to do a really significant amount of work on our uh CI Pipeline and you know have kind of since largely solve this problem for us internally but I think a lot of companies will have to go through kind of their own flavor of how you get your you know compilation times um down how you get your caching situation in order but it doesn't really stop there because you have to kind of continually have a lot of discipline to make sure that you're not adding you know GHC extensions that are going to you know take a huge slam on your build time you know so especially if you start to get into some of the fancier uh type features a lot of those things do not compile very quickly um and I think the you know the other piece of this is that it has and this is why I think you know there's a lot of uh you know hcll projects that turn to Nyx or basil or these other kind of things that are better incremental caching um but those come with a lot of upfront investment as well and I think you know one of the points that I'm trying to make with all of this stuff is that while these are solvable problems in the long run these are solvable problems if you have a lot of skill to do these things on your team in a start start up you don't have the long run like your business may die very soon and you may never get to the point where these kind of long-term initiatives that will save you time in the long run ever come to to bear fruit because you didn't get your business in a spot where it was actually you know gaining traction or you know uh revenue and funding and all those kinds of things and so these things like build times you know for us we had a really long discussion internally about like do we switch to nxs do we not switch to nxs um and it involves a really long migration over to it and in the end it like wasn't super successful and we kind of rolled back how much Nicks we were doing we were like kind of going all out on it and and walked it back a little bit to have a little bit of other um tools in the mix um I think the other thing here that I'll say about this as well this is one thing that is also making a lot of improvements just kind of in the ecosystem when we started we had to use self-hosted CI Runners because GitHub actions for instance like didn't have uh Runners with enough memory to like build even a pretty simple hll application and so you know while some of these pieces maybe getting solved over time I think at large you're still going to be dealing with a lot more complexity just in making sure that your build is in like you have a very tight feedback loop as a developer um so another really common thing is that dependency upgrades are going to be are likely to be very painful um for us I think you know uh many of the folks that are writing hassal here may may remember the whole ason uh upgrade thing that you know you from GHC upgrades to library upgrades that you depend on um one of the drawbacks to having you know this really robust type system is that sometimes that causes brittleness things break eagerly because you know that's kind of part of the philosophy things should break if things you know if they're not exactly how the types have been designed um but with that comes brittleness and so you know for us what this what this looked like was you know ason gets bumped up um you know we have to upgrade GHC we have to do this whole migration and this is the kind of thing that a lot of you know in a lot of other ecosystems these kinds of things don't happen because there's stronger backwards compatibility guarantees um I think go is a really great example of this where they give really specific uh promises about what things will remain backwards compatible and for how long and which things are kind of um you know on the table to break and that would be a really useful thing to have in the hasal world but we don't currently have that today and I think that you know this was just kind of another time of just you know ason gets bumped up like you're going to have a very maybe a very sad dog looking at you while you are coding very late at night uh one of those things where it doesn't maybe sound like it doesn't matter but in practice this is your life you know as a as a Founder as a programmer whatever it is like the this this draws from your quality of life this is going to make you burn out quicker this is going to you know this jeopardizes the company it really really does um you know I think we like to think in the hasal world that the you know that the types are kind of this you know this ground truth and everything inside of our hosal code base is pure and type safe and um you know everything is nice but the reality is that takes a lot of work to do and sometimes you know if you have those kind of like very stringly typed functions um sometimes you're just you really need to get something out the door and you move on to the next thing and you know it's just another place where you can incur quite a bit of tech debt um and even if you spend all of this time you know making sure that you have really really sound um really sound types uh a really sound model of your problem it still doesn't really extend to the real world like one typo in the column name in your model and you're going to have a runtime error um you know you might have typesafe routes in your API but like ins servant it still matters the order that you list those things and there's lots of like very real world spots where those types don't actually you know make it all the way you know to your front end or to whatever it is that you're building um and I think like we dealt with this so many times um you know one of the spots is like you know you may need to parse a uu ID somewhere and in one spot you're lazy and you just you just make it a string and you move on and like those kinds of things those kinds of paper cuts to your code base happen over and over and over and I think it's just much more pronounced that kind of tech debt uh in the hasar world because we want to you know assume that we have these good types because we've you know taken all the pain to use hascal um and yet you're still kind of wrestling with do I ship this thing really quickly and move on or do I like take the time to make sure these types are really really good and so I think like ultimately we've seen in a lot of spots um you know the really good type safety you'll still have a lot of bugs and things that just break in ways that you wish was not the case and so I think you know when it comes to you know this talking point of correctness um I think you know one thing is like how much does that actually matter in the first place right like how much does correctness really matter in our um you know in in our space you might be working on life and death software and in that case I feel like hcll is a really really great thing to use um but if you're trying to get product Market fit for a company very quickly you need to ship as fast as possible and that's really kind of the reality of the situation that you might be in um and so you know correctness is a nice thing to have but it's not always the best goal in a startup environment as much as we would like to pretend it is um and there's you know a really uh you may have seen this kind of very um prolific quote out there that you know if you aren't embarrassed by your first uh product you ship too late um and I think there's a lot of truth to this uh we you know it's really compelling to want to you know polish your product a lot and just make it perfect and then get it out the the door and be really proud of what you shipped um but in the reality at a at a really early stage company is that's not like that's a recipe for failure you probably don't actually know all the details of what you need to build until you talk to lots of customers and see them use it in practice um when scarf first launched it was a package manager it was a system package manager that would kind of collect these stats of uh of things that people would install on their machine and you know would kind of report things like you know crashes and codes and flags and the developers could uh you know see those stats and use them what we work on today is super different and by and the only way that we learned these things was by putting things out there talking to people who are using them and iterating um and so it would have been a huge mistake to really polish up that code and you know make everything really nice rather than shipping and talking to customers um another thing that we talk this is kind of like a a a a a term that has been coined internally at scarf of of hascal brain um and what I what we mean by this is that there's a lot of things about hasle that can encourage um developers to seek really beautiful and elegant Solutions rather than pragmatic ones I think this is I mean this is something that I think you'll see in any language it's not unique to hll but I think hll kind of naturally pushes you towards this kind of thinking sometimes it's sometimes really compelling to come up with the perfect way to model your problem problem and um you know once it compiles at works you have this kind of really um enjoyable programming experience but that's not necessarily the right way to solve problems for the business um and so you know you you may come upon something and someone says we can model this with typ families but you know then your then your build starts to take a super long time um you know you may be seeing a lot of problems with your with your CI pipeline thinking okay we can actually have a purely functional build and it's going to be lovely and we tried we did this we wasted a lot of time doing this and the reality is it just did not solve our problems and it actually just wasted a lot of time um you know there's the the really common uh you know make a legal states unrepresentable and that's a lovely idea um but you may still have exceptions at runtime even though we might like to pretend that's not going to happen and so you might be really proud of your solution it just crashes um or it just doesn't handle a case that you didn't think of and you I think that's a really important uh piece of this because hll can be a really great tool for building what you spec but sometimes the spec is wrong um sometimes the spec did not cover some other case you didn't understand your domain as well as you thought there was an edge case you didn't realize was there um and even though you thought you had you know had considered every case and every corner case uh you probably didn't um and so you know we when we see internally when we see people kind of you know jumping into like a very complex elegant solution kind of the the joke of H brain comes up another problem I think is that um there's really not one way to write hll um this comes up a lot with the monad Transformer topic of like what's the right way to do monad Transformers in hll you know do you do MTL do you do free monads which what is the effect system does your or should we just stick it all in the ioad and just move on with our lives um you know this is one of those things where you might look at this and say oh well you know just pick something and and move on you know have have good engineers and you know move on um but not only is it a problem to you know have having this conversation takes time right you you might you might make a decision and then a year later this topic will come back up and you need to rehash it because there's an engineer that's really you know um a huge fan of freeone ads or whatever it might look like and having all of these different ways to do stuff um in some ways is really nice there's a lot of ways to solve your problem but it also means that there's a lot of ways to solve your problem you have to choose again and I think just decision fatigue can really uh quickly become a problem but overall this it looks like maybe there might be some changes in this kind of thing I know you know like the hll foundation existing I think is is is definitely going to be a really good Force um there are companies that are working on certifications for writing hasal and I think these kinds of initiatives can help establish more standards here and so I think that um this critique of having kind of no one way to do this may be getting better and better over time but I think you know the the the overall like ask here is that if we had better kind of agreed upon right ways to write hascal it gives team something to fall back on if if there's decisions that are not really ultimately very important for your business but maybe people care about a lot just check in time um yeah and so you know I think other other drawbacks that we've seen you know practically I think that uh so so these are these are just quotes from Engineers that uh at scarf that I was kind of asking about like you know what's what's been bothering you about hll um this this was another quote from Alex our team this is a GHC contributor um you know still having having these times where you just feel like ah I you know we have so much code it it all needs to do you know we need to log stuff everywhere like observability of a production system is really important and so you need to log stuff everywhere and so now everywhere doesn't really look much like pure functional programming anymore um you know query you know you might need to hit the database in spots you didn't necessarily expect to and before you know it you don't really have all that much pure code and you're just kind of back to to writing imperative imperative code and the other thing is just hll is hard you know I I think um it's fun to get good at it's it's fun to write um but even even really experienced hcal Engineers are still not always going to know if you should fold l or fold R they're not always going to know if something should be strict or lazy um if a space leak comes up it's still really hard to pin it down um and I think that's just something where you know again like there the more standards for how to write good hcal will help um you know obviously a bigger pool of Engineers will help but we have at scarf it's only senior and above Engineers like these are really experienced people who've been writing hll for a long time um and still in practice these Engineers are sometimes feeling like they're kind of fighting uh fighting hll to get their work done um not that that wouldn't be the case in some other language but it's also the case here too and so I think like overall you're going to be dealing with more accidental or unexpected complexity like you want to pick some tech but it just doesn't have the hascal bindings you want or you want to pick a vendor but they don't have a hascal SDK um you know the build the the picking these kinds of things these are all these are all things that detract from what you're really trying to do um they'll all make you have to work a little bit later every time you encounter them and those things add up in practice when that's the life that you are living and so yeah so like why why did we pick hasal that's this is a lot of complaints like why why do we pick it and why do and why have we stayed with it um after all this time and I think one thing that is really important here you know on the the you know the original points I was making about what what is a reasonable criteria um agility and being able to refactor your code quickly is extremely useful you know like I said we had a very different product when we started and many many iterations uh are taken to get towards a product that you know has customers that has people wanting to buy it and people wanting to stick with it and so being able to have your system in production make changes to to them let the compiler guide you through those refactors um and then just have it immediately be working is a really incredible experience and I've never worked in a language that had it that that that had that kind of effect to the degree that hasal does where I could really take a step back look at our types re you know switch the types around to map to kind of the new reality of you know based on something that we learn from customers and and and ship and move on um and so the refactoring story in Hol I think is world class and so if you don't really know exactly all the details of what it is that you are trying to build um has is one of the best choices that you can pick for that particular criteria another thing is um the types and the documentation um when I was first learning Hol I really really I I loathed hadak and hackage um you know my my initial impression was like why why are there no examples here like how am I there's hardly any docs how am I supposed to learn how to use a h library and the more you know the the better High School I got the more I learned to really really love the the system that we have um with hadock and and and hackage you can literally just read the type signatures and you basically know how to use the library um which I think another piece where there's a bit of a learning curve to get to that point but once you are it basically means that most of the libraries that you want to use you have a pretty good sense of how to use them just from just from looking at a couple function signatures and you're good to go not only that you don't even need to go to hackage you can just generate these kinds of things locally um and that's a really powerful tool in the tool chain if you're especially if you're you know getting started with a code base and you you know just want to kind of check out a really high level what the modules look like and what functions are and where the entry points are you can just you know run hadock Loc Al and you are good to go and so even if you spend zero time writing docs which you probably are at an early stage company you have actually some good docs and new developers are not going to be you know totally um you know out in the cold having no idea what to do because you have great types and you have great type signatures and you have documentation from that you can always write more um but it gives that kind of the the minimum threshold of documentation that you have is pretty good but if I'm being really honest about why we picked hll it's because it's fun it's because I like it um hll is a very uh fun language to write um and for anyone who's ever played the game Dwarf Fortress losing is fun there's a million ways to die in Dwarf Fortress but all of them are quite fun and I think that's a really apt analogy for hasell um it's just it's you know I think you know the refactoring having things kind of work pretty soon after they compile this is just a fun experience erience of coding it keeps the day a bit more enjoyable um you know and I think startups are a lot of hard work and if you can have something that makes them more fun I think that's actually quite valuable and so you know really I did a lot of complaining here um and so my asks my constructive asks for the Hol community at large for how we can how we can fix lot or fix some of these problems is that ultimately the high school Community needs to prioritize adoption um that means prior prioritizing you know uh tutorials and you know the the the on-ramp for beginners and the learning curve the marketing materials these are all really really important things we also need to prioritize compatibility and backwards compatibility and theability of the language currently if I write hll today I have very little confidence that that code is just going to run if I come back in three years I bet it won't it probably will not um that's not a good characteristic if you're trying to convince companies to bet their their this is this is our livelihoods that are that are impacted by this code working always um and so I think by prioritizing backwards compatibility uh much more we will I think we will see more adoption uh in the industry I think making more good libraries is is another really important thing I think there could be entire you know companies and Dev shops that just build libraries for hll um you'd have one customer uh with us right away if you started doing that and then establishing more standards about how to write good hll I think will go very far um for helping you know hire and have things to fall back on and not have to make a lot of you know decisions internally about how you write hle so I'm like right at time here so to to to wrap up ultimately I think that your choice of programming language is not really going to make or break the success of your company but it can really impact your happiness while you do it and so ultimately choosing hustle will probably slow you down in the short run I think it's very likely to slow you down and you can't really reason about the long term because you haven't proved that there is a long term yet you're trying to you're trying to make the case that there is a longterm to optimize for at a startup um and so if you pick Tech that is too much front loaded on the investment um that's not going that may not be a very wise choice um but you know I think there's a lot of there's a lot that we can do here to make hascol a very compelling choice for industry adoption but the community needs to prioritize these initiatives we need to prioritize backwards compatibility we to prioritize having more libraries and the onramp and the learning curve we need to actually care and invest in it um and ultimately You know despite all these flaws um hll is a very fun language and if you have a team that's very good at it you can you can definitely get away with it thank you so much