10 ms·

There is a growing number of stories in the wild of companies who were burned for using Haskell. Common patterns of struggle are emerging. You aren't reading

by Dowwie 7y ago

There is a growing number of stories in the wild of companies who were burned for using Haskell. Common patterns of struggle are emerging. You aren't reading about them because people aren't eager to share their failures with the world, just yet. Proceed with caution, especially in the startup realm.

padraic7a 7y ago
That's an intruiging comment. I can understand why you can't name specific companies but it would be interesteing to hear something about these common patterns of struggle.
goto11 7y ago
What are the common patterns of struggle?
- martincmartin 7y ago
  I've heard lazy evaluation makes performance problems a nightmare to track down: some seemingly innocent piece of code turns out to trigger evaluation. In other words, the lines of code in the diff that introduces the performance regression, can be very far from the lines that do the heavy lifting, and both can be far from the line that actually needs to be changed to fix the problem.
  - mokus 7y ago
    One flip side of this is when undefined behavior in one library invalidates critical assumptions underlying the correctness of another, and tracking it down is a nightmare. I’d much rather, in general, get predictable and understandable semantics and have to struggle for performance than get predictable and understandable performance and struggle for semantics. Even more so, I’d rather use software that faced that profile of challenges. You can see when the program is slow at runtime, but you often can’t see when it’s wrong at runtime.
misja 7y ago
Could you lift some of veil of the mystery and perhaps give a hint which those burned companies are?
seddona 7y ago
As a counterpoint - at CircuitHub, we migrated from NodeJS / Angular to Haskell / Elm and couldn't be happier. I think a core reason for our success is that we built our team from experienced developers that had built large applications in other languages. Then arrived at Haskell as a better solution. I have heard some negative experiences that I would attribute to a few different factors. 1. Lack of Haskell experience in the early team. 2. Lack of experience building large real-world applications (too academic) 3. The startup/group didn't achieve product-market fit, and Haskell was scapegoated. None of these problems are Haskell specific, just run of the mill team issues.
- sokoloff 7y ago
  How common is it for the same person to have both strong Haskell experience and experience building large real-world applications? I’ve tried to find a way to use Haskell (lacking strong experience there, but with lots of large app experience), and I’ve not managed to find a situation where pulling the trigger makes sense because of the risk of getting “stuck” with a poor path out.
  - FpUser 7y ago
    In tech world languages are like a religion. Their choice does not really have to make sense. Hence unless it is 100% total proven failure the affiliates will try any means to protect/advocate/spread whatever language they like.
    - Koshkin 7y ago
      This is an inconvenient truth.
  - seddona 7y ago
    Maybe try contributing to a large Haskell codebase first to get a feel for what Haskell is like in in-the-large and gain some comfort. I'll add this problem is not at all Haskell specific. If you put an experienced Java developer to work architecting a large Python application where they have no prior Python experience you are going to experience similar problems. I'd say the problem is perhaps a bit more acute with Haskell as the paradigm is likely more different to the prior language. So if possible get at least one person on your team that has experience with a large Haskell app and pair them up with other devs.
IAmEveryone 7y ago
This essay I recently saw on HN comes to mind: https://lexi-lambda.github.io/blog/2019/10/19/empathy-and-subjective-experience-in-programming-languages/ https://lexi-lambda.github.io/blog/2019/10/19/empathy-and-su...
- axilmar 7y ago
  If everything is subjective and we don't bring counter arguments to one's arguments, then science cannot go on. In programming, we need to know if objectively one programming language is better than the others, so as that we use it to our benefit.
  - seddona 7y ago
    I don't see any claim in that article about everything being subjective, it's very specifically about programming languages. I would argue that programming languages are subjective. There are many different equally viable ways to model the world and programmers should pick the one that aligns with how their brain works. I'm not convinced it's possible to objectively rank programming languages from best to worse. They are not fundamental properties of the universe simply mental models devised by humans for humans.
    - galangalalgol 7y ago
      We can objectively talk about whether a language is suited to the use it is being put to.
      - wolco 7y ago
        Can we? Expectations around what a language can do are dymanic. I saw something really cool on the weekend. PHP on the client side as a compiled wasm. This allows someone to go severless and run a cms in the client. That's a new use for an existing language.. is it suitable for everything? Not until it is.
  - galaxyLogic 7y ago
unhammer 7y ago
Haskell must be getting popular, if so many projects are being started in it that the proportion of them that fail are "a growing number" :) That said, anyone know of a writeup / "post-mortem" of such a failure?
- SiempreViernes 7y ago
  The statement seems to be about the absolute number of failures, not a proportion out a total. So I guess their comment is simply that the number of failures have increased with time...
  - lostcolony 7y ago
    So if the total number of Haskell projects is not also going up, then we must conjecture that people are getting worse and worse at Haskell. Occam's razor seems to apply here; it seems more likely that more people are trying Haskell for real world projects, if the statement that failures are increasing is true.
    - SiempreViernes 7y ago
      Well, presumable some people actually finish their old haskell projects and then start new ones, so it's not necessary that the total number of users is growing. The old users are also starting new projects that could fail.
Discombulator 7y ago
I think the real question is whether the failure rate of companies using Haskell is higher than those of companies using mainstream languages.
- seddona 7y ago
  That would be an interesting question to answer. I know of a few rapidly growing companies using Haskell that compete directly with non-Haskell companies. We'll have to see how things play out over the next few years but that might provide some data points.
  - UserIsUnused 7y ago
    Can you name them?
    - seddona 7y ago
      CircuitHub (a company I co-founded) and Habito (UK mortgage broker) stand out in my head as startups (in the PG sense of the word http://www.paulgraham.com/growth.html http://www.paulgraham.com/growth.html) that use primarily Haskell and have direct startup competition using more conventional stacks. We come across tons of others, I keep meaning to write down a list.
- wolco 7y ago
  If mainstream companies tried to hire and run projects in haskell problems would quickly surface. Not too many haskell bootcamps. There is a need for haskell but it is not the next language to take over it is missing key features.
  - the_af 7y ago
    I don't think the existence of bootcamps is a good measure. Which key features is Haskell missing?
    - deleted 7y ago
fsloth 7y ago
That probably means Haskell is becoming more popular. Most software projects and businesses, after all, fail. I wouldn't advice against Haskell. But I would advice against having a business with more than one non-boring component. And usually that non-boring component should be the solution to the client problem, not the tech stack used to implement it. If you start a business in a language stack none of the devs have done large scale production projects, you are basically begging for a world of trouble. If the devs are familiar with Haskell, I don't see any problem with choosing it, if it matches the problem domain. I wouldn't choose it for example for frontend development (although I suppose you can get it compiling there) or things where C, C++ or Fortran still have a strong legitimate foothold.
the_af 7y ago
Any examples? Which are these common patterns of struggle?
- Quekid5 7y ago
  Probably not. It's one of these responses we see on every Haskell/Idris/etc. post, except this time is formatted as a sort of Concern Troll. (I have no idea what would motivate a person to do such a thing, but people are weird.)
Quekid5 7y ago
Unless you're willing to be more concrete, I'm going to invoke one of my favorite aphorisms: "What can be asserted without evidence can also be dismissed without evidence." (Christopher Hitchens)

by Dowwie 7y ago

padraic7a 7y ago

That's an intruiging comment. I can understand why you can't name specific companies but it would be interesteing to hear something about these common patterns of struggle.

goto11 7y ago

What are the common patterns of struggle?

martincmartin 7y ago
I've heard lazy evaluation makes performance problems a nightmare to track down: some seemingly innocent piece of code turns out to trigger evaluation. In other words, the lines of code in the diff that introduces the performance regression, can be very far from the lines that do the heavy lifting, and both can be far from the line that actually needs to be changed to fix the problem.
- mokus 7y ago
  One flip side of this is when undefined behavior in one library invalidates critical assumptions underlying the correctness of another, and tracking it down is a nightmare. I’d much rather, in general, get predictable and understandable semantics and have to struggle for performance than get predictable and understandable performance and struggle for semantics. Even more so, I’d rather use software that faced that profile of challenges. You can see when the program is slow at runtime, but you often can’t see when it’s wrong at runtime.

misja 7y ago

Could you lift some of veil of the mystery and perhaps give a hint which those burned companies are?

seddona 7y ago

As a counterpoint - at CircuitHub, we migrated from NodeJS / Angular to Haskell / Elm and couldn't be happier. I think a core reason for our success is that we built our team from experienced developers that had built large applications in other languages. Then arrived at Haskell as a better solution. I have heard some negative experiences that I would attribute to a few different factors. 1. Lack of Haskell experience in the early team. 2. Lack of experience building large real-world applications (too academic) 3. The startup/group didn't achieve product-market fit, and Haskell was scapegoated. None of these problems are Haskell specific, just run of the mill team issues.

sokoloff 7y ago
How common is it for the same person to have both strong Haskell experience and experience building large real-world applications? I’ve tried to find a way to use Haskell (lacking strong experience there, but with lots of large app experience), and I’ve not managed to find a situation where pulling the trigger makes sense because of the risk of getting “stuck” with a poor path out.
- FpUser 7y ago
  In tech world languages are like a religion. Their choice does not really have to make sense. Hence unless it is 100% total proven failure the affiliates will try any means to protect/advocate/spread whatever language they like.
  - Koshkin 7y ago
    This is an inconvenient truth.
- seddona 7y ago
  Maybe try contributing to a large Haskell codebase first to get a feel for what Haskell is like in in-the-large and gain some comfort. I'll add this problem is not at all Haskell specific. If you put an experienced Java developer to work architecting a large Python application where they have no prior Python experience you are going to experience similar problems. I'd say the problem is perhaps a bit more acute with Haskell as the paradigm is likely more different to the prior language. So if possible get at least one person on your team that has experience with a large Haskell app and pair them up with other devs.

IAmEveryone 7y ago

This essay I recently saw on HN comes to mind: https://lexi-lambda.github.io/blog/2019/10/19/empathy-and-subjective-experience-in-programming-languages/ https://lexi-lambda.github.io/blog/2019/10/19/empathy-and-su...

axilmar 7y ago
If everything is subjective and we don't bring counter arguments to one's arguments, then science cannot go on. In programming, we need to know if objectively one programming language is better than the others, so as that we use it to our benefit.
- seddona 7y ago
  I don't see any claim in that article about everything being subjective, it's very specifically about programming languages. I would argue that programming languages are subjective. There are many different equally viable ways to model the world and programmers should pick the one that aligns with how their brain works. I'm not convinced it's possible to objectively rank programming languages from best to worse. They are not fundamental properties of the universe simply mental models devised by humans for humans.
  - galangalalgol 7y ago
    We can objectively talk about whether a language is suited to the use it is being put to.
    - wolco 7y ago
      Can we? Expectations around what a language can do are dymanic. I saw something really cool on the weekend. PHP on the client side as a compiled wasm. This allows someone to go severless and run a cms in the client. That's a new use for an existing language.. is it suitable for everything? Not until it is.
- galaxyLogic 7y ago

unhammer 7y ago

Haskell must be getting popular, if so many projects are being started in it that the proportion of them that fail are "a growing number" :) That said, anyone know of a writeup / "post-mortem" of such a failure?

SiempreViernes 7y ago
The statement seems to be about the absolute number of failures, not a proportion out a total. So I guess their comment is simply that the number of failures have increased with time...
- lostcolony 7y ago
  So if the total number of Haskell projects is not also going up, then we must conjecture that people are getting worse and worse at Haskell. Occam's razor seems to apply here; it seems more likely that more people are trying Haskell for real world projects, if the statement that failures are increasing is true.
  - SiempreViernes 7y ago
    Well, presumable some people actually finish their old haskell projects and then start new ones, so it's not necessary that the total number of users is growing. The old users are also starting new projects that could fail.

Discombulator 7y ago

I think the real question is whether the failure rate of companies using Haskell is higher than those of companies using mainstream languages.

seddona 7y ago
That would be an interesting question to answer. I know of a few rapidly growing companies using Haskell that compete directly with non-Haskell companies. We'll have to see how things play out over the next few years but that might provide some data points.
- UserIsUnused 7y ago
  Can you name them?
  - seddona 7y ago
    CircuitHub (a company I co-founded) and Habito (UK mortgage broker) stand out in my head as startups (in the PG sense of the word http://www.paulgraham.com/growth.html http://www.paulgraham.com/growth.html) that use primarily Haskell and have direct startup competition using more conventional stacks. We come across tons of others, I keep meaning to write down a list.
wolco 7y ago
If mainstream companies tried to hire and run projects in haskell problems would quickly surface. Not too many haskell bootcamps. There is a need for haskell but it is not the next language to take over it is missing key features.
- the_af 7y ago
  I don't think the existence of bootcamps is a good measure. Which key features is Haskell missing?
  - deleted 7y ago

fsloth 7y ago

That probably means Haskell is becoming more popular. Most software projects and businesses, after all, fail. I wouldn't advice against Haskell. But I would advice against having a business with more than one non-boring component. And usually that non-boring component should be the solution to the client problem, not the tech stack used to implement it. If you start a business in a language stack none of the devs have done large scale production projects, you are basically begging for a world of trouble. If the devs are familiar with Haskell, I don't see any problem with choosing it, if it matches the problem domain. I wouldn't choose it for example for frontend development (although I suppose you can get it compiling there) or things where C, C++ or Fortran still have a strong legitimate foothold.

the_af 7y ago

Any examples? Which are these common patterns of struggle?

Quekid5 7y ago
Probably not. It's one of these responses we see on every Haskell/Idris/etc. post, except this time is formatted as a sort of Concern Troll. (I have no idea what would motivate a person to do such a thing, but people are weird.)

Quekid5 7y ago

Unless you're willing to be more concrete, I'm going to invoke one of my favorite aphorisms: "What can be asserted without evidence can also be dismissed without evidence." (Christopher Hitchens)