8 ms·

Haskell in Production: Channable

148 points by aroccoli 4y ago

shrubble 4y ago
My question is, 'how much of this work could have been shoved into an SQL database which would give you the type checking and referential integrity needed' , with then a relatively thin layer of non-SQL programming on top to handle the ETL tasks mentioned?
pregnenolone 4y ago
I don't know why but the first thing that came into my mind was this video. Btw I love Haskell. https://www.youtube.com/watch?v=ADqLBc1vFwI https://www.youtube.com/watch?v=ADqLBc1vFwI
aroccoli 4y ago
If you liked this interview, we have plenty more interviews with practical Haskell users on our blog! https://serokell.io/blog/haskell-in-production https://serokell.io/blog/haskell-in-production
newaccount2021 4y ago
Every seven years or so now, a new generation gets suckered into believing Haskell is the Right Way
- youerbt 4y ago
  It is not. It is just sometimes better than the alternatives.
- crispyalmond 4y ago
  What is it that makes it so bad?
  - hobo_mark 4y ago
    Being productive with it requires rewiring your brain, which depending on what kind of business you run might not be worth it more often than not (same applies to the crab language).
    - My104thaccount 4y ago
  - newaccount2021 4y ago
    Like it or not, most problems you will want to solve are not "purely functional" but rely on sound management of shared mutable state. Haskell advocates will say shared mutable state is done better in Haskell than other languages. They will trot out blog posts claiming that Haskell is also a better imperative language than other imperative languages. It isn't. Just look at all of the theoretical mumbo-jumbo associated with something like Lenses...now look at the utterly trivial problem they solve. Even for a FP tool, Haskell is riddled with cruft. Look at the set of compiler pragmas that are pretty much required to be in any useful Haskell. Including basic crap like overloading the String type. These are hacks, pure and simple. You could go on and on and on. Most of the original Haskell advocates from the initial explosion of advocacy around ten years ago have moved on to Rust and other language communities. They gave up, and they were the gurus. Anyway, like most programming hype, there is no stopping it...you just need to get on the Haskell hype wagon for a while, realize it is a waste of time, then get off and try to inform others.
    - agentultra 4y ago
      I dunno. It's not a perfect language but it's sufficient. The bar is pretty low. Type classes were first proposed around 1989 and Haskell adopted them early on. They made parametric polymorphism tractable. C++ finally adopted Concepts in C++20. There's literally cruft in any useful language that has been around long enough. Keep searching for that diamond though. It's out there somewhere.
    - johnday 4y ago
      > Like it or not, most problems you will want to solve are not "purely functional" but rely on sound management of shared mutable state. This is a claim which is certainly not true in all domains. For example, web applications and compilers, two of Haskell's "killer problem domains", do not heavily rely on shared mutable state. That said, Haskell's approach to shared mutable state is no less sensible than the rest of the language. > Just look at all of the theoretical mumbo-jumbo associated with something like Lenses...now look at the utterly trivial problem they solve. With all due respect if you believe this then I'm not sure you fully appreciate the problem that they solve. The terminology is indeed obtuse though. > Even for a FP tool, Haskell is riddled with cruft. Look at the set of compiler pragmas that are pretty much required to be in any useful Haskell. Including basic crap like overloading the String type. These are hacks, pure and simple. That's not fair. Haskell is a language that is (de facto) defined as a basis, the Report, plus a set of modernising features which have been implemented since. They're not hacks, they are deliberate optional language features. It's a different approach to most modern languages but no worse. A combined set of such features, called GHC2021, is the new "standard" and enables a huge swath of them by default. If anything I'd say there is very little hype around Haskell. People look at it and think it's cool, but that's not because of people hyping it up. In fact every post/article I've read about Haskell has been extremely measured and open about its shortcomings. Sorry if you just wanted to get something off your chest, but it makes me sad to see a perfectly fine language disparaged unfairly.
  - zarzavat 4y ago
    It’s an academic language, designed as a substrate to grow papers in. If JS infamously has dozens of build systems, Haskell has almost nobody working on tooling. Instead you get many smart people writing libraries for building super abstract spaghetti code - which is great for research and advancing the state of the art (sometimes the wacko abstractions turn out to be good ideas that trickle down into regular programming languages), but would someone please write some tooling as well. I love Haskell, it’s fun, mind-expanding and absolutely worth learning. Maybe one day it will be ready for prime time, but until then I’d suggest an ML for “real” software.
    - welterde 4y ago
      Not sure I would say that all aspects of tooling are bad though. Stackage for example is great and I wish there was anything even close to it in other languages.
    - troppl 4y ago
      An ML, like SML or OCaml? Neither of these has any better tooling. Really the only viable candidate would be F#, no?
- 414owen 4y ago
  I think almost everyone who writes Haskell has in the past written in other languages, and clearly those who stick with it prefer it. I'm personally far more productive in Haskell than in any other language I've tried. I don't know what's the Right Way, but it's the Best Way I've found so far.
- whateveracct 4y ago
  I program Haskell for all projects because it's fun - not because there's some obvious engineering value-proposition. I'd rather not waste my consciousness-hours on boring languages.
nickelpro 4y ago
Glad to see the cave-man like debugging is brought up. Haskell stops many classes of bugs, but lord help you if you've made a complex logical mistake somewhere along the line and are trying to figure out where you went wrong. It's high school printf debugging all over again except you can't even reason about order of execution due to lazy evaluation. I'm reasonably proficient in a number of languages, including Python, JS, C, C++, Prolog, Java, I even have a decent amount of Forth under my belt. Nowhere else have I experienced the complete dearth of tooling that is the Haskell ecosystem. The LSP is a step in the right direction but merely a first step.
- pjmlp 4y ago
  Well, Leksah used to be a good experience in regards to debugging. https://github.com/leksah/leksah https://github.com/leksah/leksah
- chopin 4y ago
  I think you can enforce eager evaluation in Haskell.
  - pharmakom 4y ago
    But then you can’t take advantage of the library ecosystem that assumes lazy eval.
    - rowanG077 4y ago
      You can enforce it per module, per function, per datatype or even just at a single site. Enforcing it wholesale is using a nuclear bomb when you need a scalpel.
- parentheses 4y ago
  … and rampantly introducing the IO monad only to remove it once the culprit is found.
  - nequo 4y ago
ilovecaching 4y ago
Haskell is fun to learn and play with, but it's almost never the right choice for a real business. Using a language you can hire for, that your employees can google solutions for because it's already a popular production language, and has the most popular packages and frameworks for your use case, is far more important than terseness and safety in 99% of cases.
- logicchains 4y ago
  >Using a language you can hire for, A language like Haskell is much easier to hire for because you can get higher quality employees at a lower price, due to the high demand for Haskell programming jobs and low supply of such jobs. If you got for a language like Java, a double digit percentage of the candidates are the kind that can't even solve fizzbuzz without help, so you have to waste much more time weeding out mediocre candidates.
- rprospero 4y ago
  I appreciate your point, but I also remember hearing that exact argument being used against Python in 2001. A Perl developer was explaining how Python was a nice language, but would never be able to make in-roads into business. It was too hard to find a Python developer and most programmers don't to want to learn a new language. Furthermore, CPAN provided such a wealth of packages that Python developers would have to implement for themselves. He did concede that Python code did tend to have fewer bugs, but the previous mentioned advantages, alongside the fact that it was much easier to write Perl than Python, meant that Python would never make business sense and Perl would settle into being the Lingua France of the development community. The guy's site even required a Netscape plugin that allowed him to script pages in Perl instead of JavaScript, which he stated was merely a stopgap until Netscape officially added a Perl interpreter into the browser. This was about five years after industry representatives argued that my school should stop teaching C or C++ and focus on the more modern Visual Basic. They explained that, by the year 2005, there would be more COBOL jobs than C jobs. Meanwhile, a semester of Visual Basic experience would guarantee the students a lifetime of employment without learning a new language. I'm under no delusions that Haskell will be the next Python or that Python itself will go the way of VB, but it always makes me take these "industry" arguments with a grain of salt.
BrainVirus 4y ago
There is little information in this interview about why they chose Haskell except the general notion that they liked it and maybe that it was faster than Python for their particular task. (I say "maybe", because rewrites generally tend to be faster, since you understand the domain much better.) Needless to say, there are many languages out there that are faster than Python. An obvious question should have been "why Haskell instead of C#/F#/Go/Rust, all of which can be made very performant and have better tooling". For that matter, why not Pharo? Or D? Or Factor? Again, the article hasn't really identified any specifics except "we like it" and "there is a university that teaches Haskell nearby". I find such articles (and HN gets a lot of them) vaguely disturbing. They are PR pieces rather than engineering material written to influence rather than inform.
- aroccoli 4y ago
  > why Haskell instead of C#/F#/Go/Rust Thank you, I'll keep that question in mind for future interviews to keep it more specific for some of the people here. :) As to the rest -- our interviews are created as much to share information between Haskellers as to inform other people about Haskell.
- arianvanp 4y ago
  Check out the hyperlink in that paragraph to the original blogpost for some more background. But I don't think it will be more satisfying as it was still a rather arbitrary choice I will admit (https://www.channable.com/tech/how-we-secretly-introduced-haskell-and-got-away-with-it https://www.channable.com/tech/how-we-secretly-introduced-ha...) The answer mostly is: Because I liked Haskell and knew it well; and I and a colleague wanted wanted to rewrite the job scheduling system and just picked it. But as soon as we started on the project we were extremely productive and were able to launch a proof of concept within days. That really got us excited and showed us a lot of potential in continuing with this approach. Especially things like QuickCheck and testing of pure functions allowed us to write code quickly and correctly with ease. Also most developers (and also leadership) in our team at the time already followed 1 or maybe even multiple university courses involving Haskell so we had quite a bit of 'hidden' expertise. For the next project; the API gateway; I honestly felt it was an even better fit. Haskell's Web Application Interface and its ecosystem of middleware is top notch and makes it really easy to write very performant web proxies and servers. Though if I'd have to make the same decision today I'd probably pick Go over Haskell given Go has an even wider ecosystem of middleware; and has a way stronger story surrounding cryptography in which Haskell is severely lacking
wirrbel 4y ago
Has the crypto crowd moved on from Haskell alread?
ed25519FUUU 4y ago
> we also encountered some quadratic runtime algorithms in the memory allocator of the RTS – and even compact regions didn’t help then. We documented that particular bug and have since provided a fix for it as well. Just like you never want to be the smartest person in a room, you never want to be the one pushing a language to its limits. IMHO when you’re providing language patches you probably choose the wrong language.
- WJW 4y ago
  That is the most business-efficient course, but it is also an excellent way to ensure you have no true expertise in your company when a gnarly problem eventually strikes. Avoiding the hardest problems does not attract the kind of people who like solving hard problems, after all.
- rkrzr 4y ago
  > Just like you never want to be the smartest person in a room, you never want to be the one pushing a language to its limits. (Channable co-founder here) If everybody took this view, then a language could never improve. I have actually been very impressed with how far we have been able to take Haskell before having to push its limits. Anecdotally, we previously were using Scala (and Spark) and ran into issues much earlier. In those cases we were pushing the limits of Spark, but underlying those were the limits of the JVM. > IMHO when you’re providing language patches you probably choose the wrong language. This is a very myopic view. There is much more to consider when choosing a language (what kind of team do you have, what kind of problems are you working on, maintainability, performance, ecosystem, hiring, etc.).
  - DonaldPShimoda 4y ago
    I really appreciate your view on all this, and I totally agree with you that the other commenter has a very nearsighted perception of things. I think the go-to example of a group taking this to the extreme is Jane Street with OCaml. For many intents and purposes, Jane Street are really the major shepherds of the language these days. They contribute tons of compiler fixes and improvements, and have written their own replacement of the standard library (which is used by many people). I think it'd be silly to say that they "chose the wrong language"; rather, they've invested in a language ecosystem that benefits them and reflects their needs, while at the same time growing and improving a whole language community. That's an awesome feat.

148 points by aroccoli 4y ago

My question is, 'how much of this work could have been shoved into an SQL database which would give you the type checking and referential integrity needed' , with then a relatively thin layer of non-SQL programming on top to handle the ETL tasks mentioned?

pregnenolone 4y ago

I don't know why but the first thing that came into my mind was this video. Btw I love Haskell. https://www.youtube.com/watch?v=ADqLBc1vFwI https://www.youtube.com/watch?v=ADqLBc1vFwI

aroccoli 4y ago

If you liked this interview, we have plenty more interviews with practical Haskell users on our blog! https://serokell.io/blog/haskell-in-production https://serokell.io/blog/haskell-in-production

newaccount2021 4y ago

Every seven years or so now, a new generation gets suckered into believing Haskell is the Right Way

youerbt 4y ago
It is not. It is just sometimes better than the alternatives.
crispyalmond 4y ago
What is it that makes it so bad?
- hobo_mark 4y ago
  Being productive with it requires rewiring your brain, which depending on what kind of business you run might not be worth it more often than not (same applies to the crab language).
  - My104thaccount 4y ago
- newaccount2021 4y ago
  Like it or not, most problems you will want to solve are not "purely functional" but rely on sound management of shared mutable state. Haskell advocates will say shared mutable state is done better in Haskell than other languages. They will trot out blog posts claiming that Haskell is also a better imperative language than other imperative languages. It isn't. Just look at all of the theoretical mumbo-jumbo associated with something like Lenses...now look at the utterly trivial problem they solve. Even for a FP tool, Haskell is riddled with cruft. Look at the set of compiler pragmas that are pretty much required to be in any useful Haskell. Including basic crap like overloading the String type. These are hacks, pure and simple. You could go on and on and on. Most of the original Haskell advocates from the initial explosion of advocacy around ten years ago have moved on to Rust and other language communities. They gave up, and they were the gurus. Anyway, like most programming hype, there is no stopping it...you just need to get on the Haskell hype wagon for a while, realize it is a waste of time, then get off and try to inform others.
  - agentultra 4y ago
    I dunno. It's not a perfect language but it's sufficient. The bar is pretty low. Type classes were first proposed around 1989 and Haskell adopted them early on. They made parametric polymorphism tractable. C++ finally adopted Concepts in C++20. There's literally cruft in any useful language that has been around long enough. Keep searching for that diamond though. It's out there somewhere.
  - johnday 4y ago
    > Like it or not, most problems you will want to solve are not "purely functional" but rely on sound management of shared mutable state. This is a claim which is certainly not true in all domains. For example, web applications and compilers, two of Haskell's "killer problem domains", do not heavily rely on shared mutable state. That said, Haskell's approach to shared mutable state is no less sensible than the rest of the language. > Just look at all of the theoretical mumbo-jumbo associated with something like Lenses...now look at the utterly trivial problem they solve. With all due respect if you believe this then I'm not sure you fully appreciate the problem that they solve. The terminology is indeed obtuse though. > Even for a FP tool, Haskell is riddled with cruft. Look at the set of compiler pragmas that are pretty much required to be in any useful Haskell. Including basic crap like overloading the String type. These are hacks, pure and simple. That's not fair. Haskell is a language that is (de facto) defined as a basis, the Report, plus a set of modernising features which have been implemented since. They're not hacks, they are deliberate optional language features. It's a different approach to most modern languages but no worse. A combined set of such features, called GHC2021, is the new "standard" and enables a huge swath of them by default. If anything I'd say there is very little hype around Haskell. People look at it and think it's cool, but that's not because of people hyping it up. In fact every post/article I've read about Haskell has been extremely measured and open about its shortcomings. Sorry if you just wanted to get something off your chest, but it makes me sad to see a perfectly fine language disparaged unfairly.
- zarzavat 4y ago
  It’s an academic language, designed as a substrate to grow papers in. If JS infamously has dozens of build systems, Haskell has almost nobody working on tooling. Instead you get many smart people writing libraries for building super abstract spaghetti code - which is great for research and advancing the state of the art (sometimes the wacko abstractions turn out to be good ideas that trickle down into regular programming languages), but would someone please write some tooling as well. I love Haskell, it’s fun, mind-expanding and absolutely worth learning. Maybe one day it will be ready for prime time, but until then I’d suggest an ML for “real” software.
  - welterde 4y ago
    Not sure I would say that all aspects of tooling are bad though. Stackage for example is great and I wish there was anything even close to it in other languages.
  - troppl 4y ago
    An ML, like SML or OCaml? Neither of these has any better tooling. Really the only viable candidate would be F#, no?
414owen 4y ago
I think almost everyone who writes Haskell has in the past written in other languages, and clearly those who stick with it prefer it. I'm personally far more productive in Haskell than in any other language I've tried. I don't know what's the Right Way, but it's the Best Way I've found so far.
whateveracct 4y ago
I program Haskell for all projects because it's fun - not because there's some obvious engineering value-proposition. I'd rather not waste my consciousness-hours on boring languages.

nickelpro 4y ago

Glad to see the cave-man like debugging is brought up. Haskell stops many classes of bugs, but lord help you if you've made a complex logical mistake somewhere along the line and are trying to figure out where you went wrong. It's high school printf debugging all over again except you can't even reason about order of execution due to lazy evaluation. I'm reasonably proficient in a number of languages, including Python, JS, C, C++, Prolog, Java, I even have a decent amount of Forth under my belt. Nowhere else have I experienced the complete dearth of tooling that is the Haskell ecosystem. The LSP is a step in the right direction but merely a first step.

pjmlp 4y ago
Well, Leksah used to be a good experience in regards to debugging. https://github.com/leksah/leksah https://github.com/leksah/leksah
chopin 4y ago
I think you can enforce eager evaluation in Haskell.
- pharmakom 4y ago
  But then you can’t take advantage of the library ecosystem that assumes lazy eval.
  - rowanG077 4y ago
    You can enforce it per module, per function, per datatype or even just at a single site. Enforcing it wholesale is using a nuclear bomb when you need a scalpel.
parentheses 4y ago
… and rampantly introducing the IO monad only to remove it once the culprit is found.
- nequo 4y ago

ilovecaching 4y ago

Haskell is fun to learn and play with, but it's almost never the right choice for a real business. Using a language you can hire for, that your employees can google solutions for because it's already a popular production language, and has the most popular packages and frameworks for your use case, is far more important than terseness and safety in 99% of cases.

logicchains 4y ago
>Using a language you can hire for, A language like Haskell is much easier to hire for because you can get higher quality employees at a lower price, due to the high demand for Haskell programming jobs and low supply of such jobs. If you got for a language like Java, a double digit percentage of the candidates are the kind that can't even solve fizzbuzz without help, so you have to waste much more time weeding out mediocre candidates.
rprospero 4y ago
I appreciate your point, but I also remember hearing that exact argument being used against Python in 2001. A Perl developer was explaining how Python was a nice language, but would never be able to make in-roads into business. It was too hard to find a Python developer and most programmers don't to want to learn a new language. Furthermore, CPAN provided such a wealth of packages that Python developers would have to implement for themselves. He did concede that Python code did tend to have fewer bugs, but the previous mentioned advantages, alongside the fact that it was much easier to write Perl than Python, meant that Python would never make business sense and Perl would settle into being the Lingua France of the development community. The guy's site even required a Netscape plugin that allowed him to script pages in Perl instead of JavaScript, which he stated was merely a stopgap until Netscape officially added a Perl interpreter into the browser. This was about five years after industry representatives argued that my school should stop teaching C or C++ and focus on the more modern Visual Basic. They explained that, by the year 2005, there would be more COBOL jobs than C jobs. Meanwhile, a semester of Visual Basic experience would guarantee the students a lifetime of employment without learning a new language. I'm under no delusions that Haskell will be the next Python or that Python itself will go the way of VB, but it always makes me take these "industry" arguments with a grain of salt.

BrainVirus 4y ago

There is little information in this interview about why they chose Haskell except the general notion that they liked it and maybe that it was faster than Python for their particular task. (I say "maybe", because rewrites generally tend to be faster, since you understand the domain much better.) Needless to say, there are many languages out there that are faster than Python. An obvious question should have been "why Haskell instead of C#/F#/Go/Rust, all of which can be made very performant and have better tooling". For that matter, why not Pharo? Or D? Or Factor? Again, the article hasn't really identified any specifics except "we like it" and "there is a university that teaches Haskell nearby". I find such articles (and HN gets a lot of them) vaguely disturbing. They are PR pieces rather than engineering material written to influence rather than inform.

aroccoli 4y ago
> why Haskell instead of C#/F#/Go/Rust Thank you, I'll keep that question in mind for future interviews to keep it more specific for some of the people here. :) As to the rest -- our interviews are created as much to share information between Haskellers as to inform other people about Haskell.
arianvanp 4y ago
Check out the hyperlink in that paragraph to the original blogpost for some more background. But I don't think it will be more satisfying as it was still a rather arbitrary choice I will admit (https://www.channable.com/tech/how-we-secretly-introduced-haskell-and-got-away-with-it https://www.channable.com/tech/how-we-secretly-introduced-ha...) The answer mostly is: Because I liked Haskell and knew it well; and I and a colleague wanted wanted to rewrite the job scheduling system and just picked it. But as soon as we started on the project we were extremely productive and were able to launch a proof of concept within days. That really got us excited and showed us a lot of potential in continuing with this approach. Especially things like QuickCheck and testing of pure functions allowed us to write code quickly and correctly with ease. Also most developers (and also leadership) in our team at the time already followed 1 or maybe even multiple university courses involving Haskell so we had quite a bit of 'hidden' expertise. For the next project; the API gateway; I honestly felt it was an even better fit. Haskell's Web Application Interface and its ecosystem of middleware is top notch and makes it really easy to write very performant web proxies and servers. Though if I'd have to make the same decision today I'd probably pick Go over Haskell given Go has an even wider ecosystem of middleware; and has a way stronger story surrounding cryptography in which Haskell is severely lacking

wirrbel 4y ago

Has the crypto crowd moved on from Haskell alread?

ed25519FUUU 4y ago

> we also encountered some quadratic runtime algorithms in the memory allocator of the RTS – and even compact regions didn’t help then. We documented that particular bug and have since provided a fix for it as well. Just like you never want to be the smartest person in a room, you never want to be the one pushing a language to its limits. IMHO when you’re providing language patches you probably choose the wrong language.

WJW 4y ago
That is the most business-efficient course, but it is also an excellent way to ensure you have no true expertise in your company when a gnarly problem eventually strikes. Avoiding the hardest problems does not attract the kind of people who like solving hard problems, after all.
rkrzr 4y ago
> Just like you never want to be the smartest person in a room, you never want to be the one pushing a language to its limits. (Channable co-founder here) If everybody took this view, then a language could never improve. I have actually been very impressed with how far we have been able to take Haskell before having to push its limits. Anecdotally, we previously were using Scala (and Spark) and ran into issues much earlier. In those cases we were pushing the limits of Spark, but underlying those were the limits of the JVM. > IMHO when you’re providing language patches you probably choose the wrong language. This is a very myopic view. There is much more to consider when choosing a language (what kind of team do you have, what kind of problems are you working on, maintainability, performance, ecosystem, hiring, etc.).
- DonaldPShimoda 4y ago
  I really appreciate your view on all this, and I totally agree with you that the other commenter has a very nearsighted perception of things. I think the go-to example of a group taking this to the extreme is Jane Street with OCaml. For many intents and purposes, Jane Street are really the major shepherds of the language these days. They contribute tons of compiler fixes and improvements, and have written their own replacement of the standard library (which is used by many people). I think it'd be silly to say that they "chose the wrong language"; rather, they've invested in a language ecosystem that benefits them and reflects their needs, while at the same time growing and improving a whole language community. That's an awesome feat.