21 ms·

Haskell in Production

200 points by allenleein 7y ago

KirinDave 7y ago
This is a great guide and sound advice. And hopefully in a year we'll see the community converge on Polysemy (or fused-effects for performance) to make this strategy even more natural.
- madhadron 7y ago
  I've been out of the Haskell game for a while, so I hadn't seen Polysemy. Another thing on my reading list...
- runeks 7y ago
  Polysemy still appears mysterious to me. I would absolutely love an article that translates the “Designing Testable Components”[1] part of this article into its Polysemy equivalent. [1] http://felixmulder.com/writing/2019/10/05/Designing-testable-components.html http://felixmulder.com/writing/2019/10/05/Designing-testable...
digb 7y ago
If I remember correctly, Co-Star, the horoscope app, runs Haskell on the backend.
- Mathnerd314 7y ago
  https://medium.com/co-star-engineering/continuous-improvement-with-hlint-code-smells-e490886558a1 https://medium.com/co-star-engineering/continuous-improvemen...
- senderista 7y ago
  Boy those guys must be laughing at their customers.
- banuguler 7y ago
  we're hiring --> costarastrology.com/jobs ;)
gip 7y ago
> Haskell is great for business and great in production I disagree. It's a beautiful language but it lacks a lot of features to make it useable at scale. And in my experience Haskell engineers are extremely smart but the environment/culture they create makes it difficult to foster team spirit. I've been in 2 companies in the last 4 years who initially used Haskell in production. One has transitioned to Go and the other is rewriting the codebase in Rust.
- verttii 7y ago
  > it lacks a lot of features to make it useable at scale. Can you elaborate on this?
- danharaj 7y ago
  Hey you. I'm pretty sure I know who you are :) I hope everything's going well! I definitely agree that there are many examples of ineffective Haskell culture. As a Haskell contractor I get to see how a lot of different shops do things. One thing I can't really tease apart is that most startups have a lot of engineering culture problems, and picking Haskell doesn't inoculate you from that effect. The main cultural issue I see specific to Haskell shops is that frequently rabbit holes aren't discouraged. By that, I mean there is too much of a tinkerer mentality where engineers are allowed to or even encouraged to experiment with untested ideas instead of known effective solutions. That is a habit I had to deprogram myself from too. It's very fun! In your spare time. I hope we get to work together again! But I'm usually only called in if there's trouble, so maybe I shouldn't :^)
  - dukerutledge 7y ago
    This is pretty sound advice for any language. You always want most of your code to be dumb. You save high abstraction for things that have a sensible interface and are common enough to need DRYing. Haskell has a higher abstraction ceiling than most languages and there is less trodden ground, so there may be more opportunity to get lost down the rabbit hole. However Haskell2010 is a beautifully simple language that can solve all your problems (maybe with a bit more code than enabling 20 extensions will afford you).
Mathnerd314 7y ago
All the interesting code is in the next post, http://felixmulder.com/writing/2019/10/05/Designing-testable-components.html http://felixmulder.com/writing/2019/10/05/Designing-testable.... I'm not sure why they use a generic monad rather than ST, they don't need continuations for this. The Reader monad with a big record is standard Haskell, it's basically what GHC uses: https://github.com/ghc/ghc/blob/1219f8e8a3d1b58263bea76822322b746a632778/compiler/utils/IOEnv.hs#L55 https://github.com/ghc/ghc/blob/1219f8e8a3d1b58263bea7682232... data-has is less standard, it only seems to have been used seriously by one project, which has a bug on file to stop using it: https://github.com/myfreeweb/magicbane/issues/20 https://github.com/myfreeweb/magicbane/issues/20 But overall it's interesting, we'll see where the series goes.
- microtherion 7y ago
  It's always good to see examples of how a language is actually used, rather than just assertions of its superiority. That said, if Haskell programmers truly consider this a superior and readable way to write code would tend to reinforce my preconception of them as an insular community elevating arcane jargon to a virtue (not unlike the APL programmers of yore).
  - jeremyjh 7y ago
    Its strange how code written in unfamiliar languages is ... unfamiliar? The Haskell in that post is bog-standard. The definition of "arcane" is not "I don't know it".
    - microtherion 7y ago
      I've worked in a pretty wide range of languages. I think I know "unfamiliar" and I can tell it apart from "arcane". OP claims that "this article will emphasize writing easy to grok, maintainable code". The definition of "easy to grok" is not "once you've bought into the entire mindset, this will be obvious to you".
      - jeremyjh 7y ago
slaymaker1907 7y ago
I really wish Java had associated types and static methods as parts of interfaces (i.e. constructors as part of the interface). Those two features make complex architectures much easier to design and use.
- chrisseaton 7y ago
  Interfaces can have static methods.
  - james-mcelwain 7y ago
    I believe they mean static methods as part of the interface signature, e.g. to define constructor/factory methods. AFAIK there are issues with how Java handles dynamic dispatch that prevent this.
    - chrisseaton 7y ago
      What would calling such a method look like?
      - TheCoelacanth 7y ago
        Imagine that Collection had a static method `empty` that created an empty collection of the appropriate type depending on the type you are assigning it to, e.g. `List list = Collection.empty();` would create a list, `Set set = Collection.empty();` would create a set, and so on. This would be fairly similar to how things work in Haskell.
        chrisseaton 7y ago
        If you know you’re creating a List (it’s there on the LHS) why not write List.empty()?
        james-mcelwain 7y ago
verttii 7y ago
This is an incredibly good series. Just what I've been looking for. I'm writing a Servant API myself and this really explains a lot of the fundamental concepts in plain English.
rpmisms 7y ago
The more I see it in use, the more I want to learn Haskell, but I can't think of a practical reason to do so.
- worldsayshi 7y ago
  I think the reason should/could be abstraction. If you find yourself doing kind of the same thing over and over but don't see how you could extract the repetative part in a scalable way in a language with less type support then there may be a good use case for Haskell there.
- rawburt 7y ago
  Compilers
- sullyj3 7y ago
  I don't know about you, but sometimes I do things just because I want to.
- mbrodersen 7y ago
  Learning things is how you keep your brain sharp.
  - rpmisms 7y ago
    I need to get halfway fluent in JS first, but good point.
    - mbrodersen 7y ago
      Once you get there I recommend then learning Typescript (Javascript with types) and compare the experience with Javascript.
MuffinFlavored 7y ago
> Haskell is great for business and great in production. Hot take: no it isn't. It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and I question the payoff immensely. I question the well-being of anybody who subjects themselves to the pain and torture that is Haskell. If I stood up in a corporate business boardroom meeting for tech analysis on a new project and said "I want to write it in Haskell", I'd get laughed + kicked out.
- rifung 7y ago
  > It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and I agree with your other points but what's wrong with the syntax? I actually really like the syntax for the most part
  - epsolos 7y ago
    Most people that have worked as developers/programmers/etc. that don't have a lot of exposure to or training in fp find it painfully hard to learn. This could be one of those cases.
    - brokencode 7y ago
      To them, I would suggest that they remember back to when they learned their first imperative language like Java or C. For me, that was really difficult to wrap my mind around at the time, but now those languages are second nature to me. I kind of suspect that if everyone were exposed to a functional language first, there would be a lot fewer people who think they are extremely hard to learn.
      - journalctl 7y ago
        I fondly remember being confused by “return” for weeks (granted, I was 9). What are you returning? And to where? And why was it only one thing? And where did it go when it got there? It’s easy to forget how hard something was to learn once you already know it.
MisterOctober 7y ago
Always nice to see Haskell at work. I haven't learned the language myself yet, but I absolutely love postgREST, which is implemented in Haskell.
leshow 7y ago
I'm not sure why this post is getting so much hate, it's well written and I really enjoyed reading it. Thanks!
- rawburt 7y ago
  People seem to hate Haskell because it's not [popular-language-that-they-use]. To think that Haskell is used, liked, and works, seems to upset people who don't like, use, or understand Haskell. Or, so it seems.
deleted 7y ago
[deleted]
dmitriid 7y ago
How long does it take the “new programmers who have not worked with Haskell before” to learn and understand all the ASCII-art in the example code? How $ differs from <$ differs from & differs from . On top of trying to remember that <> is string concatenation and >>= and <- have something to do with monads.
- shantly 7y ago
  I still can't understand why Perl is easily dismissed as "LOL line noise" but Haskell's apparently fine. At least dipping into Perl you can take on the line noise slowly so you have time to absorb each new technique, and you can write it just fine with hardly any of that if you want, and it won't hurt a thing—Haskell seems to dump all that on you up front, and it seems to require it, idiomatically. It's very off-putting.
  - tome 7y ago
    It's because Haskell's type system at least helps you avoid getting the line noise wrong. If you have to refactor some complicated line noise then the compiler holds your hand.
    - dmitriid 7y ago
      What would an error look like if I misused $ or &? And yes, compilers hold a user’s hand in most languages (including PHP with type hints :) ).
      - lalaithion 7y ago
        • Couldn't match expected type ‘([Integer] -> [Integer]) -> [b]’ with actual type ‘[Integer]’ • Possible cause: ‘map’ is applied to too many arguments In the second argument of ‘(&)’, namely ‘map (* 2) [1, 2, 3]’ In the second argument of ‘($)’, namely ‘map (+ 2) & map (* 2) [1, 2, 3]’ In the expression: map (+ 2) $ map (+ 2) & map (* 2) [1, 2, 3]
dmix 7y ago
> We tried a lot of different patterns - readers, handlers, MTL, and tagless final. Is there any books or long form articles digging into these different approaches? I know basic Haskell and heard of these different patterns a few times. I'm curious how it looks in a larger Haskell project and what the pros/cons are of each, and general popularity. Edit: I see the next article in the series has more real code examples
seddona 7y ago
We are a YC company doing very well, all our back end code is written in Haskell. We have produced a lot of functionality with a relatively small team. I would say we are existence proof that Haskell is good for business.
- wolco 7y ago
  What happens when you need to scale up or if one or more of the gurus quits? Do you think Haskell will still be primarily used when you grow?
  - mbrodersen 7y ago
    Ask Facebook. They are running Haskell at massive scale.
    - g_delgado14 7y ago
      For what business units? For which use cases? Also, they invest a lot into recruiting. My suspicion is that they give a considerable degree of freedom (often to the detriment of the organization in ways such as information silos) to engineering teams to help with recruiting.
- StreamBright 7y ago
  For the problem you are solving and at your scale. Things start to change when you need to hire n+1 teams or engineers quickly.
  - dllthomas 7y ago
    They... might? I worked at a Haskell start-up for a bit. Hiring wasn't easy. But it doesn't seem to be easier at the mostly-JS start-up I'm working at now.
    - StreamBright 7y ago
      I think so. https://insights.stackoverflow.com/survey/2019#technology https://insights.stackoverflow.com/survey/2019#technology
wellpast 7y ago
I will probably get stomped on for this but to me it's a giant elephant in the room. When that one purist on the team proposes mandating having 100%, 80%, or any hard number of unit test coverage, most sane people tend to disagree and understand its wild impracticality and counter-productivity. However - when one (ie, a Haskeller) says that the code must universally pass 100% strong static type verification coverage -- arguably SO MUCH worse cost/benefit than unit testing -- and you say "no that's impractical" it's suddenly a different game. The elephant in the room is this. Haskell and strongly typed languages are highly impractical, academic pursuits. They do not at all respect the dynamism of the real world. You can certainly build production systems in any language including Haskell but by picking Haskell you are throwing sticks between your legs unnecessarily.
- astuary 7y ago
  Just because an expressive static type system is available, doesn't mean you have to use all of its expressive power. There's nothing stopping you from writing your system using little more than String, Int, lists, IO etc. Of course, you probably have a higher chance of bugs, but that might be the right tradeoff for your usecase. I agree that haskellers have a tendency to disregard the cost of using sophisticated type machinery. Which is unfortunate because haskell's greatest strength (IMO) is its ability to opt in to strong static verification for the 10% of code where it provides the most value.
  - wellpast 7y ago
    > Just because an expressive static type system is available, doesn't mean you have to use all of its expressive power. There's nothing stopping you from writing your system using little more than String, Int, lists, IO etc. Of course, you probably have a higher chance of bugs, but that might be the right tradeoff for your usecase. This is not accurate or prove me wrong. Opting out of Haskell's type system may be "do-able" but only in a sense. And even so the programming ergonomics will be terrible vs. a language designed with typelessness in mind.
    - rawburt 7y ago
jonny383 7y ago
Advice for people using Haskell in "production": Don't. Save not only yourself the disappoint, but every other stakeholder around you. Use something tried and tested.
- mbrodersen 7y ago
  Let me guess: you have never programmed in Haskell?
  - jonny383 7y ago
    I have programmed in Haskell. I have programmed in assembly. I have programmed in just about every language in-between. Haskell is at best, a sophisticated toy suited to a small subdomain of problems. Have you ever tried to roll Haskell into production, when compared with something like C# or Java?
    - g_delgado14 7y ago
      What was your experience like rolling Haskell into production?
      - jonny383 7y ago
        Cabal is probably the most unsuited packaging system for production software. It has no useful test integration nor freezing ability. Tried to change profiling? You're in for a bad time. What about deployment. Want git? Nope. You can't. Want to build artifacts? What is this, TypeScript?
c3534l 7y ago
Everyone in the comments either doesn't like Haskell, because it's hard and different or niche or whatever, so they think Haskell is bad for production even though they don't code in it and haven't worked at a place that used it extensively. The other group of people in the comments are people who love Haskell and are happy to have validation from the OP. But I'm not really any wiser. I like Haskell, but I work in DevOps and the language simply isn't relevant there.
- platinumrad 7y ago
  Everyone... except for the top comment?
whalabi 7y ago
How is such an obscure language - with associated difficulty in finding talented engineers - ever going to be a better choice than a more mainstream language, which probably has many of the same features?
- mbrodersen 7y ago
  > with associated difficulty in finding talented engineers This is a myth. There are now many experienced developers who currently can't use Haskell in their day job but would love to. If I decided to start another business, picking Haskell would give me access to a lot of top talent who would otherwise not be interested.
- whateveracct 7y ago
  It's actually not that hard to find talented engineers, especially if you are a distributed/remote team. I've interviewed & given a thumbs up to a constant stream of Haskell candidates (either with Haskell experience or interest in learning). That said, I've also seen a lot of Haskell engineers go through the interview pipeline & get thumbs up from all interviewers _except_ a single person in leadership who would later push to move away from Haskell for "hiring reasons" :eyeroll:
axilmar 7y ago
The amount of knowledge required just to have a clean design o the simplest of things, i.e. a few functions that add and delete users is very big; almost all of Haskell's important parts need to be known. Is that good? for me, it's an obstacle. I can't expect all the developers that come and go to have a perfect understanding of monads in order to use/debug/extend such code. And what did Haskell actually buys us here? my apologies for being skeptical, but it doesn't seem to buy us anything...in other languages, such things as creating a user, deleting a user, logging actions requires a lot less boilerplate and complexity.
mcmayer 7y ago
It's interesting to watch the wonderfully meandering train of thought(s) triggered by a success report of using a non-mainstream programming language. So let's meander some more... The strong reactions are understandable. New programming languages are added to the zoo faster than ever before. And within each language there's a steady influx of new frameworks (angular1, angular2, react, vue, ...) each with a learning curve. It's a challenging environment, and it feels like it's getting exponentially harder as time progresses. One must resist the trap of following every silly new idea. So why bother spending even an afternoon with Haskell? Spend an afternoon playing with Python and you'll be writing code the next morning. Spend a day with Haskell and you'll have more questions than answers. The fundamental problem is, most likely, the new paradigm. Functional programming takes some time getting used to. Sure, the functional style is creeping into mainstream languages, so most of us have seen and used it already. But pure functional programming is another level. Broadly speaking, everything is a function, a function in the mathematical sense: Same input, same output. Everything is immutable, it's all about chaining pure functions. Crazy, right? Why would you subject yourself to such rigour? I'll argue that pure functional programming has something to offer that is more relevant than ever. 1. Pure functions are easy to test. Same input, same output, that is a strong guarantee. It'll still be a challenge to thoroughly test every single function, but at least each test is meaningful because there are no interactions with anything outside the function. 2. Pure functions are easy to compose and parallelize. Single-thread performance is hardly ever a relevant benchmark anymore. Sure, C is faster, but good luck trying to parallelize a complex C program. (The worst thing I can imagine is having to debug messed-up, multi-threaded C++ code.) 3. There is structure in how to compose pure functions, and it's structure in the mathematical sense, not in the fuzzy Gang of Four pattern sense. Much of the 'arcane', 'academic' jibber jabber is exactly about these mathematical structures. The power of having a rigorous method for structuring programs is immense. It really is. The hurdle is not a high as it may seem (unless you have a low affinity to maths - im which case you probably shouldn't be programming computers anyway). 4. Pure functions are easy to refactor. (See below.) I'll also argue that strong typing has a lot to offer and will become more mainstream. 1. Make the compiler your friend, not your enemy. Strong types glue the functions together in just the right way and prevent me from making silly mistakes. 2. Business logic can be encoded in a compact and transparent way. Changes to the business logic (and it always does change, doesn't it?) are also compact and transparent. 3. Refactoring is just ... wonderful. Strong types combined with pure functions, that is a magical combination. Change the type and let the compiler tell you what the implacations are. As there are no side effects code can be refactored with confidence. It is a vastly different experience from any OO language. Now, finally, to Haskell: It can be characterized as a strongly typed, lazy-evaluated, garbage-collected, pure functional programming language. (Lazy evaluation hasn't been mentioned, yet. It's something that needs to be understood and considered in order to write efficient code.) In "language design space", something like Haskell must exist and will always exist. (I say 'always' because maths has something eternal about it and pure functional programming and strong typing have solid mathematical underpinnings.) And in this "language design space" Haskell dominates. Contrast this with the compiled, weakly typed, imperative, low-level languages like C, C++, Golang, Rust. I have a hard time picking amongst those, but I believe everyone should know at least one of them. So is it worth learning Haskell? I tried to argue that it's not a fad and the concepts are fundamental and increasingly important. To me, personally, it looks like a an investment I can benefit from for decades to come. As a business, do the advantages outweigh the costs and risks? We all know that corporate culture often stands in the way of change. One root cause is the asymmetric payoff: A thank you if it goes well, and job-loss if it goes badly. In such an environment inertia is the rational choice. - But if your company truly believes to be an innovator, or leader in the field, or seeks to gain an edge over the competition, then Haskell should be on the list of things to try.

200 points by allenleein 7y ago

This is a great guide and sound advice. And hopefully in a year we'll see the community converge on Polysemy (or fused-effects for performance) to make this strategy even more natural.

madhadron 7y ago
I've been out of the Haskell game for a while, so I hadn't seen Polysemy. Another thing on my reading list...
runeks 7y ago
Polysemy still appears mysterious to me. I would absolutely love an article that translates the “Designing Testable Components”[1] part of this article into its Polysemy equivalent. [1] http://felixmulder.com/writing/2019/10/05/Designing-testable-components.html http://felixmulder.com/writing/2019/10/05/Designing-testable...

digb 7y ago

If I remember correctly, Co-Star, the horoscope app, runs Haskell on the backend.

Mathnerd314 7y ago
https://medium.com/co-star-engineering/continuous-improvement-with-hlint-code-smells-e490886558a1 https://medium.com/co-star-engineering/continuous-improvemen...
senderista 7y ago
Boy those guys must be laughing at their customers.
banuguler 7y ago
we're hiring --> costarastrology.com/jobs ;)

gip 7y ago

> Haskell is great for business and great in production I disagree. It's a beautiful language but it lacks a lot of features to make it useable at scale. And in my experience Haskell engineers are extremely smart but the environment/culture they create makes it difficult to foster team spirit. I've been in 2 companies in the last 4 years who initially used Haskell in production. One has transitioned to Go and the other is rewriting the codebase in Rust.

verttii 7y ago
> it lacks a lot of features to make it useable at scale. Can you elaborate on this?
danharaj 7y ago
Hey you. I'm pretty sure I know who you are :) I hope everything's going well! I definitely agree that there are many examples of ineffective Haskell culture. As a Haskell contractor I get to see how a lot of different shops do things. One thing I can't really tease apart is that most startups have a lot of engineering culture problems, and picking Haskell doesn't inoculate you from that effect. The main cultural issue I see specific to Haskell shops is that frequently rabbit holes aren't discouraged. By that, I mean there is too much of a tinkerer mentality where engineers are allowed to or even encouraged to experiment with untested ideas instead of known effective solutions. That is a habit I had to deprogram myself from too. It's very fun! In your spare time. I hope we get to work together again! But I'm usually only called in if there's trouble, so maybe I shouldn't :^)
- dukerutledge 7y ago
  This is pretty sound advice for any language. You always want most of your code to be dumb. You save high abstraction for things that have a sensible interface and are common enough to need DRYing. Haskell has a higher abstraction ceiling than most languages and there is less trodden ground, so there may be more opportunity to get lost down the rabbit hole. However Haskell2010 is a beautifully simple language that can solve all your problems (maybe with a bit more code than enabling 20 extensions will afford you).

Mathnerd314 7y ago

All the interesting code is in the next post, http://felixmulder.com/writing/2019/10/05/Designing-testable-components.html http://felixmulder.com/writing/2019/10/05/Designing-testable.... I'm not sure why they use a generic monad rather than ST, they don't need continuations for this. The Reader monad with a big record is standard Haskell, it's basically what GHC uses: https://github.com/ghc/ghc/blob/1219f8e8a3d1b58263bea76822322b746a632778/compiler/utils/IOEnv.hs#L55 https://github.com/ghc/ghc/blob/1219f8e8a3d1b58263bea7682232... data-has is less standard, it only seems to have been used seriously by one project, which has a bug on file to stop using it: https://github.com/myfreeweb/magicbane/issues/20 https://github.com/myfreeweb/magicbane/issues/20 But overall it's interesting, we'll see where the series goes.

microtherion 7y ago
It's always good to see examples of how a language is actually used, rather than just assertions of its superiority. That said, if Haskell programmers truly consider this a superior and readable way to write code would tend to reinforce my preconception of them as an insular community elevating arcane jargon to a virtue (not unlike the APL programmers of yore).
- jeremyjh 7y ago
  Its strange how code written in unfamiliar languages is ... unfamiliar? The Haskell in that post is bog-standard. The definition of "arcane" is not "I don't know it".
  - microtherion 7y ago
    I've worked in a pretty wide range of languages. I think I know "unfamiliar" and I can tell it apart from "arcane". OP claims that "this article will emphasize writing easy to grok, maintainable code". The definition of "easy to grok" is not "once you've bought into the entire mindset, this will be obvious to you".
    - jeremyjh 7y ago

slaymaker1907 7y ago

I really wish Java had associated types and static methods as parts of interfaces (i.e. constructors as part of the interface). Those two features make complex architectures much easier to design and use.

chrisseaton 7y ago
Interfaces can have static methods.
- james-mcelwain 7y ago
  I believe they mean static methods as part of the interface signature, e.g. to define constructor/factory methods. AFAIK there are issues with how Java handles dynamic dispatch that prevent this.
  - chrisseaton 7y ago
    What would calling such a method look like?
    - TheCoelacanth 7y ago
      Imagine that Collection had a static method `empty` that created an empty collection of the appropriate type depending on the type you are assigning it to, e.g. `List list = Collection.empty();` would create a list, `Set set = Collection.empty();` would create a set, and so on. This would be fairly similar to how things work in Haskell.
      - chrisseaton 7y ago
        If you know you’re creating a List (it’s there on the LHS) why not write List.empty()?
        james-mcelwain 7y ago

verttii 7y ago

This is an incredibly good series. Just what I've been looking for. I'm writing a Servant API myself and this really explains a lot of the fundamental concepts in plain English.

rpmisms 7y ago

The more I see it in use, the more I want to learn Haskell, but I can't think of a practical reason to do so.

worldsayshi 7y ago
I think the reason should/could be abstraction. If you find yourself doing kind of the same thing over and over but don't see how you could extract the repetative part in a scalable way in a language with less type support then there may be a good use case for Haskell there.
rawburt 7y ago
Compilers
sullyj3 7y ago
I don't know about you, but sometimes I do things just because I want to.
mbrodersen 7y ago
Learning things is how you keep your brain sharp.
- rpmisms 7y ago
  I need to get halfway fluent in JS first, but good point.
  - mbrodersen 7y ago
    Once you get there I recommend then learning Typescript (Javascript with types) and compare the experience with Javascript.

MuffinFlavored 7y ago

> Haskell is great for business and great in production. Hot take: no it isn't. It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and I question the payoff immensely. I question the well-being of anybody who subjects themselves to the pain and torture that is Haskell. If I stood up in a corporate business boardroom meeting for tech analysis on a new project and said "I want to write it in Haskell", I'd get laughed + kicked out.

rifung 7y ago
> It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and I agree with your other points but what's wrong with the syntax? I actually really like the syntax for the most part
- epsolos 7y ago
  Most people that have worked as developers/programmers/etc. that don't have a lot of exposure to or training in fp find it painfully hard to learn. This could be one of those cases.
  - brokencode 7y ago
    To them, I would suggest that they remember back to when they learned their first imperative language like Java or C. For me, that was really difficult to wrap my mind around at the time, but now those languages are second nature to me. I kind of suspect that if everyone were exposed to a functional language first, there would be a lot fewer people who think they are extremely hard to learn.
    - journalctl 7y ago
      I fondly remember being confused by “return” for weeks (granted, I was 9). What are you returning? And to where? And why was it only one thing? And where did it go when it got there? It’s easy to forget how hard something was to learn once you already know it.

MisterOctober 7y ago

Always nice to see Haskell at work. I haven't learned the language myself yet, but I absolutely love postgREST, which is implemented in Haskell.

leshow 7y ago

I'm not sure why this post is getting so much hate, it's well written and I really enjoyed reading it. Thanks!

rawburt 7y ago
People seem to hate Haskell because it's not [popular-language-that-they-use]. To think that Haskell is used, liked, and works, seems to upset people who don't like, use, or understand Haskell. Or, so it seems.

deleted 7y ago

[deleted]

dmitriid 7y ago

How long does it take the “new programmers who have not worked with Haskell before” to learn and understand all the ASCII-art in the example code? How $ differs from <$ differs from & differs from . On top of trying to remember that <> is string concatenation and >>= and <- have something to do with monads.

shantly 7y ago
I still can't understand why Perl is easily dismissed as "LOL line noise" but Haskell's apparently fine. At least dipping into Perl you can take on the line noise slowly so you have time to absorb each new technique, and you can write it just fine with hardly any of that if you want, and it won't hurt a thing—Haskell seems to dump all that on you up front, and it seems to require it, idiomatically. It's very off-putting.
- tome 7y ago
  It's because Haskell's type system at least helps you avoid getting the line noise wrong. If you have to refactor some complicated line noise then the compiler holds your hand.
  - dmitriid 7y ago
    What would an error look like if I misused $ or &? And yes, compilers hold a user’s hand in most languages (including PHP with type hints :) ).
    - lalaithion 7y ago
      • Couldn't match expected type ‘([Integer] -> [Integer]) -> [b]’ with actual type ‘[Integer]’ • Possible cause: ‘map’ is applied to too many arguments In the second argument of ‘(&)’, namely ‘map (* 2) [1, 2, 3]’ In the second argument of ‘($)’, namely ‘map (+ 2) & map (* 2) [1, 2, 3]’ In the expression: map (+ 2) $ map (+ 2) & map (* 2) [1, 2, 3]

dmix 7y ago

> We tried a lot of different patterns - readers, handlers, MTL, and tagless final. Is there any books or long form articles digging into these different approaches? I know basic Haskell and heard of these different patterns a few times. I'm curious how it looks in a larger Haskell project and what the pros/cons are of each, and general popularity. Edit: I see the next article in the series has more real code examples

seddona 7y ago

We are a YC company doing very well, all our back end code is written in Haskell. We have produced a lot of functionality with a relatively small team. I would say we are existence proof that Haskell is good for business.

wolco 7y ago
What happens when you need to scale up or if one or more of the gurus quits? Do you think Haskell will still be primarily used when you grow?
- mbrodersen 7y ago
  Ask Facebook. They are running Haskell at massive scale.
  - g_delgado14 7y ago
    For what business units? For which use cases? Also, they invest a lot into recruiting. My suspicion is that they give a considerable degree of freedom (often to the detriment of the organization in ways such as information silos) to engineering teams to help with recruiting.
StreamBright 7y ago
For the problem you are solving and at your scale. Things start to change when you need to hire n+1 teams or engineers quickly.
- dllthomas 7y ago
  They... might? I worked at a Haskell start-up for a bit. Hiring wasn't easy. But it doesn't seem to be easier at the mostly-JS start-up I'm working at now.
  - StreamBright 7y ago
    I think so. https://insights.stackoverflow.com/survey/2019#technology https://insights.stackoverflow.com/survey/2019#technology

wellpast 7y ago

I will probably get stomped on for this but to me it's a giant elephant in the room. When that one purist on the team proposes mandating having 100%, 80%, or any hard number of unit test coverage, most sane people tend to disagree and understand its wild impracticality and counter-productivity. However - when one (ie, a Haskeller) says that the code must universally pass 100% strong static type verification coverage -- arguably SO MUCH worse cost/benefit than unit testing -- and you say "no that's impractical" it's suddenly a different game. The elephant in the room is this. Haskell and strongly typed languages are highly impractical, academic pursuits. They do not at all respect the dynamism of the real world. You can certainly build production systems in any language including Haskell but by picking Haskell you are throwing sticks between your legs unnecessarily.

astuary 7y ago
Just because an expressive static type system is available, doesn't mean you have to use all of its expressive power. There's nothing stopping you from writing your system using little more than String, Int, lists, IO etc. Of course, you probably have a higher chance of bugs, but that might be the right tradeoff for your usecase. I agree that haskellers have a tendency to disregard the cost of using sophisticated type machinery. Which is unfortunate because haskell's greatest strength (IMO) is its ability to opt in to strong static verification for the 10% of code where it provides the most value.
- wellpast 7y ago
  > Just because an expressive static type system is available, doesn't mean you have to use all of its expressive power. There's nothing stopping you from writing your system using little more than String, Int, lists, IO etc. Of course, you probably have a higher chance of bugs, but that might be the right tradeoff for your usecase. This is not accurate or prove me wrong. Opting out of Haskell's type system may be "do-able" but only in a sense. And even so the programming ergonomics will be terrible vs. a language designed with typelessness in mind.
  - rawburt 7y ago

jonny383 7y ago

Advice for people using Haskell in "production": Don't. Save not only yourself the disappoint, but every other stakeholder around you. Use something tried and tested.

mbrodersen 7y ago
Let me guess: you have never programmed in Haskell?
- jonny383 7y ago
  I have programmed in Haskell. I have programmed in assembly. I have programmed in just about every language in-between. Haskell is at best, a sophisticated toy suited to a small subdomain of problems. Have you ever tried to roll Haskell into production, when compared with something like C# or Java?
  - g_delgado14 7y ago
    What was your experience like rolling Haskell into production?
    - jonny383 7y ago
      Cabal is probably the most unsuited packaging system for production software. It has no useful test integration nor freezing ability. Tried to change profiling? You're in for a bad time. What about deployment. Want git? Nope. You can't. Want to build artifacts? What is this, TypeScript?

c3534l 7y ago

Everyone in the comments either doesn't like Haskell, because it's hard and different or niche or whatever, so they think Haskell is bad for production even though they don't code in it and haven't worked at a place that used it extensively. The other group of people in the comments are people who love Haskell and are happy to have validation from the OP. But I'm not really any wiser. I like Haskell, but I work in DevOps and the language simply isn't relevant there.

platinumrad 7y ago
Everyone... except for the top comment?

whalabi 7y ago

How is such an obscure language - with associated difficulty in finding talented engineers - ever going to be a better choice than a more mainstream language, which probably has many of the same features?

mbrodersen 7y ago
> with associated difficulty in finding talented engineers This is a myth. There are now many experienced developers who currently can't use Haskell in their day job but would love to. If I decided to start another business, picking Haskell would give me access to a lot of top talent who would otherwise not be interested.
whateveracct 7y ago
It's actually not that hard to find talented engineers, especially if you are a distributed/remote team. I've interviewed & given a thumbs up to a constant stream of Haskell candidates (either with Haskell experience or interest in learning). That said, I've also seen a lot of Haskell engineers go through the interview pipeline & get thumbs up from all interviewers _except_ a single person in leadership who would later push to move away from Haskell for "hiring reasons" :eyeroll:

axilmar 7y ago

The amount of knowledge required just to have a clean design o the simplest of things, i.e. a few functions that add and delete users is very big; almost all of Haskell's important parts need to be known. Is that good? for me, it's an obstacle. I can't expect all the developers that come and go to have a perfect understanding of monads in order to use/debug/extend such code. And what did Haskell actually buys us here? my apologies for being skeptical, but it doesn't seem to buy us anything...in other languages, such things as creating a user, deleting a user, logging actions requires a lot less boilerplate and complexity.

mcmayer 7y ago

It's interesting to watch the wonderfully meandering train of thought(s) triggered by a success report of using a non-mainstream programming language. So let's meander some more... The strong reactions are understandable. New programming languages are added to the zoo faster than ever before. And within each language there's a steady influx of new frameworks (angular1, angular2, react, vue, ...) each with a learning curve. It's a challenging environment, and it feels like it's getting exponentially harder as time progresses. One must resist the trap of following every silly new idea. So why bother spending even an afternoon with Haskell? Spend an afternoon playing with Python and you'll be writing code the next morning. Spend a day with Haskell and you'll have more questions than answers. The fundamental problem is, most likely, the new paradigm. Functional programming takes some time getting used to. Sure, the functional style is creeping into mainstream languages, so most of us have seen and used it already. But pure functional programming is another level. Broadly speaking, everything is a function, a function in the mathematical sense: Same input, same output. Everything is immutable, it's all about chaining pure functions. Crazy, right? Why would you subject yourself to such rigour? I'll argue that pure functional programming has something to offer that is more relevant than ever. 1. Pure functions are easy to test. Same input, same output, that is a strong guarantee. It'll still be a challenge to thoroughly test every single function, but at least each test is meaningful because there are no interactions with anything outside the function. 2. Pure functions are easy to compose and parallelize. Single-thread performance is hardly ever a relevant benchmark anymore. Sure, C is faster, but good luck trying to parallelize a complex C program. (The worst thing I can imagine is having to debug messed-up, multi-threaded C++ code.) 3. There is structure in how to compose pure functions, and it's structure in the mathematical sense, not in the fuzzy Gang of Four pattern sense. Much of the 'arcane', 'academic' jibber jabber is exactly about these mathematical structures. The power of having a rigorous method for structuring programs is immense. It really is. The hurdle is not a high as it may seem (unless you have a low affinity to maths - im which case you probably shouldn't be programming computers anyway). 4. Pure functions are easy to refactor. (See below.) I'll also argue that strong typing has a lot to offer and will become more mainstream. 1. Make the compiler your friend, not your enemy. Strong types glue the functions together in just the right way and prevent me from making silly mistakes. 2. Business logic can be encoded in a compact and transparent way. Changes to the business logic (and it always does change, doesn't it?) are also compact and transparent. 3. Refactoring is just ... wonderful. Strong types combined with pure functions, that is a magical combination. Change the type and let the compiler tell you what the implacations are. As there are no side effects code can be refactored with confidence. It is a vastly different experience from any OO language. Now, finally, to Haskell: It can be characterized as a strongly typed, lazy-evaluated, garbage-collected, pure functional programming language. (Lazy evaluation hasn't been mentioned, yet. It's something that needs to be understood and considered in order to write efficient code.) In "language design space", something like Haskell must exist and will always exist. (I say 'always' because maths has something eternal about it and pure functional programming and strong typing have solid mathematical underpinnings.) And in this "language design space" Haskell dominates. Contrast this with the compiled, weakly typed, imperative, low-level languages like C, C++, Golang, Rust. I have a hard time picking amongst those, but I believe everyone should know at least one of them. So is it worth learning Haskell? I tried to argue that it's not a fad and the concepts are fundamental and increasingly important. To me, personally, it looks like a an investment I can benefit from for decades to come. As a business, do the advantages outweigh the costs and risks? We all know that corporate culture often stands in the way of change. One root cause is the asymmetric payoff: A thank you if it goes well, and job-loss if it goes badly. In such an environment inertia is the rational choice. - But if your company truly believes to be an innovator, or leader in the field, or seeks to gain an edge over the competition, then Haskell should be on the list of things to try.