12 Reasons Why Haskell is a Terrible Choice for Startups (and why we picked it anyway)
12 Reasons Why Haskell is a Terrible Choice for Startups (and why we picked it anyway)
1. Haskell is both good and bad for hiring. It works well in that you will get high-quality, enthusiastic applicants. It's bad in that your hiring pool is very small and spread across the globe.
2. You will run into missing and incomplete libraries with Haskell, and in a startup environment, this will slow you down and dictate your other technology choices more than you will want.
3. Batteries-included web frameworks are a massive win for early-stage products, and we still have a long way to go towards getting to something like Rails/Django/etc. We're all rooting for IHP from @digitallyinduce. Don't fool yourself into thinking this doesn't matter.
4. You will need to put substantial effort into optimizing your build times, and it will require discipline to keep your builds fast. Like everything above, this slows you down from work that actually matters to your customers.
5. Dependency upgrades will be painful.
6. Haskell is great for type safety, but good type safety is still a lot of work, so in practice your types are often a lie.
7. For most new businesses, correctness is not nearly as important as we Haskellers may like to think. It's probably not a good thing to optimize for early on. You will probably change your product significantly in the early days.
8. We need more standards for how to write Haskell. Every time your engineering team discusses MTL vs free monads vs effect systems, you are wasting very precious time.
9. Haskell in practice means dealing with a bit more accidental complexity than other languages, especially as you're getting started.
10. Haskell is world-class for helping you be agile, and confidently refactor as you figure out your business and requirements change. This is a huge win.
11. Auto generation of documentation just from your types is amazing, especially early on when you probably aren't writing too many docs.
12. Haskell is very fun. Startups are an absolutely insane amount of work, and if you can make your development more pleasant, that is not to be underestimated.
For more context on this topic, watch Avi Press' original talk at Scale by the Bay 2023.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
Unordered list
Bold text
Emphasis
Superscript
Subscript
Published
May 7, 2024
This article was originally posted on
Hackernoon
1. Haskell is both good and bad for hiring. It works well in that you will get high-quality, enthusiastic applicants. It's bad in that your hiring pool is very small and spread across the globe.
2. You will run into missing and incomplete libraries with Haskell, and in a startup environment, this will slow you down and dictate your other technology choices more than you will want.
3. Batteries-included web frameworks are a massive win for early-stage products, and we still have a long way to go towards getting to something like Rails/Django/etc. We're all rooting for IHP from @digitallyinduce. Don't fool yourself into thinking this doesn't matter.
4. You will need to put substantial effort into optimizing your build times, and it will require discipline to keep your builds fast. Like everything above, this slows you down from work that actually matters to your customers.
5. Dependency upgrades will be painful.
6. Haskell is great for type safety, but good type safety is still a lot of work, so in practice your types are often a lie.
7. For most new businesses, correctness is not nearly as important as we Haskellers may like to think. It's probably not a good thing to optimize for early on. You will probably change your product significantly in the early days.
8. We need more standards for how to write Haskell. Every time your engineering team discusses MTL vs free monads vs effect systems, you are wasting very precious time.
9. Haskell in practice means dealing with a bit more accidental complexity than other languages, especially as you're getting started.
10. Haskell is world-class for helping you be agile, and confidently refactor as you figure out your business and requirements change. This is a huge win.
11. Auto generation of documentation just from your types is amazing, especially early on when you probably aren't writing too many docs.
12. Haskell is very fun. Startups are an absolutely insane amount of work, and if you can make your development more pleasant, that is not to be underestimated.
For more context on this topic, watch Avi Press' original talk at Scale by the Bay 2023.
Tools and strategies modern teams need to help their companies grow.
.avif)
.svg)
.svg)
.svg)
.svg)
1. Haskell is both good and bad for hiring. It works well in that you will get high-quality, enthusiastic applicants. It's bad in that your hiring pool is very small and spread across the globe.
2. You will run into missing and incomplete libraries with Haskell, and in a startup environment, this will slow you down and dictate your other technology choices more than you will want.
3. Batteries-included web frameworks are a massive win for early-stage products, and we still have a long way to go towards getting to something like Rails/Django/etc. We're all rooting for IHP from @digitallyinduce. Don't fool yourself into thinking this doesn't matter.
4. You will need to put substantial effort into optimizing your build times, and it will require discipline to keep your builds fast. Like everything above, this slows you down from work that actually matters to your customers.
5. Dependency upgrades will be painful.
6. Haskell is great for type safety, but good type safety is still a lot of work, so in practice your types are often a lie.
7. For most new businesses, correctness is not nearly as important as we Haskellers may like to think. It's probably not a good thing to optimize for early on. You will probably change your product significantly in the early days.
8. We need more standards for how to write Haskell. Every time your engineering team discusses MTL vs free monads vs effect systems, you are wasting very precious time.
9. Haskell in practice means dealing with a bit more accidental complexity than other languages, especially as you're getting started.
10. Haskell is world-class for helping you be agile, and confidently refactor as you figure out your business and requirements change. This is a huge win.
11. Auto generation of documentation just from your types is amazing, especially early on when you probably aren't writing too many docs.
12. Haskell is very fun. Startups are an absolutely insane amount of work, and if you can make your development more pleasant, that is not to be underestimated.
For more context on this topic, watch Avi Press' original talk at Scale by the Bay 2023.
.png)
.png)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
.avif)
