23 ms·

Haskell is our first choice for building production software systems

269 points by Albert_Camus 6y ago

jcelerier 6y ago
> Many programmers encounter statically typed languages like Java or C++ and find that the compiler feels like an annoyance. By contrast, Haskell’s static type system, in conjunction with compile-type time checking, acts as an invaluable pair-programming buddy that gives instantaneous feedback during development. the reason they "find that the compiler feels like an annoyance" is because their first exposure to Java / C++ is in school where they have an assignment due for tonight and the compiler won't stop banging pages of errors about std::__1::basic_string<char, std::__1::allocator<char>> and what the fuck is that shit I just want to make games !!11!1! In contrast Haskell is often self-taught which gives a very different set of incentives and motivations. As a mostly C++ programmer making sure that I get compiler errors as often as possible by encoding most preconditions in the type system is one of the most important part of my job and make the language very easy to use when you use an IDE which allows to click on an error and going to the right place in the code.
- Blikkentrekker 6y ago
  I learned both Haskell and Rust self-taught an still find the latter's type system a bit of a cage for it's lack of higher kinded types, frankness be. I know not much of Java, but my sentiments concerning C++ are even worse. I do not regularly program in Haskell and far more often in Rust.
  - platinumrad 6y ago
    "I don't know much about this thing but I don't like it, and I know even less about this other thing and I like it even less!" For what it's worth, C++ has HKTs in the form of template template parameters, making it possible to write, e.g., monad transformers, which cannot be done in Rust, last I checked. Now as for whether you'd actually want to do this in a production codebase...
  - marcosdumay 6y ago
    Rust metadata (not just types) have an habit of getting in your way. It is all for good reason, you can't ditch the GC and have control over the memory structure without the compiler complaining about details here and there. But fixing those strings versus slices and iterator type mistakes is really annoying.
- js8 6y ago
  Actually, the reason why I found static typing annoying in the past (and why I felt more productive in Python) were the types are really low level (missing basic things like tuples) and lack of type inference. You have to repeat the type information, a lot. And also you have to declare lot of intermediate data structures. In Python, this became easier and one could focus on the data transformations, thinking about the code a level higher. But then I learned a bit of Haskell 5 years ago, and with type inference, this problem goes away. So it convinced me back to benefits of static typing. (Although I still feel the most productive in Python, their library APIs are IMHO unmatched in any language. But Haskell is catching up.)
  - jcelerier 6y ago
    > the types are really low level (missing basic things like tuples) and lack of type inference how far ago was this in the past ? C++ had tuples and type inference for ten+ years officially now - gcc 4.4 had it in 2009
    - mjburgess 6y ago
      There's also the culture around the language to fold in. A culture of writing code assuming inference and structural typing is quite different than it merely being available.
      - sfg 6y ago
        So, OCaml or something? Or has Haskell added structural typing?
        mjburgess 6y ago
        Haskell is structurally typed...
        tome 6y ago
        Hmm, what do you mean? Haskell is generally considered nominally typed (or rather types introduced by its newtype and data declarations are ...). "Structural typing" typically refers to things like polymorphic row types and polymorphic variants.
- avl999 6y ago
  > the reason they "find that the compiler feels like an annoyance" is because their first exposure to Java / C++ is in school where they have an assignment due for tonight and the compiler won't stop banging pages of errors about std::__1::basic_string<char, std::__1::allocator<char>> and what the fuck is that shit I just want to make games !!11!1! Well I can't imagine how much more annoyed they'd be when using an interpreted language which lets the code run just fine but then fails at runtime in mysterious and subtle ways requiring hours of manually scanning though code and print statements when the compiler would have caught a decent subset of those errors with helpful messages about the exact line they need to fix.
  - bird_monster 6y ago
    > Well I can't imagine how much more annoyed they'd be when using an interpreted language which lets the code run just fine but then fails at runtime in mysterious and subtle ways requiring hours of manually scanning though code and print statements when the compiler would have caught a decent subset of those errors with helpful messages about the exact line they need to fix. You cannot get mad at errors you don't know about. Also letting the user find and report the error allows you to mark your tickets "done" and move on, which makes management happy.
  - ZephyrBlu 6y ago
    In my experience, you quickly develop an intuition for where things are going wrong with interpreted languages. Ex: "Oh, cannot access property x of undefined? Something must be going wrong in y object" Python definitely feels a lot more helpful than JS though. Can't speak for other interpreted languages like Ruby.
    - cjfd 6y ago
      The thing is, though, that you mostly only get errors for code that is actually executed. So, your program is only fully type checked when all code paths are executed. In the case of python one can ameliorate this situation a bit by using mypy. At my job I see very often code being broken because, e.g., the signature of a function was changed but not in all places and so on. Now somebody will say that the IDE can solve that but these colleagues who are regularly breaking the code are actually using IDEs and it somehow still does not help. I have come to think that code that is not compiled and/or otherwise type checked is just not very serious and certainly not worthy of production environments.
- corty 6y ago
  Annoyance about C++ errors isn't only about the error occuring. With me, it is predominantly about the utter unusability of the error messages. C++ has postprocessors you can use to get your 20 page STL errors down to a few lines just by reversing the expansion the compiler did to show you mere mortal something that you might recognize as your code instead of template-cthulhu. Haskell has such situations as well, but usually far less verbose. Getting something to typecheck because you wrote down something incompatible uninferable still sucks. But far less than C++.
  - Rompect 6y ago
    In contrast, Rust's compiler sometimes gives suggestions for changes which can often just be copied.
    - emteycz 6y ago
      That's not entirely true. It gives suggestions in the cases where the C++ compiler does too. There are more than a few very cryptic errors you can encounter with Rust. I like it though, just needs more work.
      - 3836293648 6y ago
        Depends on the compiler. In my very limited experience I've found that Clang is far superior to GCC in this matter (but rustc is better still, apart from iterator errors)
        srean 6y ago
        I am curious about which GCC, G++ version you have in mind. Clang definitely took the lead, but by GCC caught up and I prefer GCC's do Clang. But even I am behind the bleeding edge quite a bit so not sure how things stand now.
      - leshow 6y ago
        It's been a while since I used C++ but I have never seen suggestions of the same quality that the rust compiler produces. Do you have a link that shows the error messages you're talking about? For sure though, not every error has a great message and some can be cryptic. But those cases are relatively rare these days IMO
- slifin 6y ago
  "acts as an invaluable pair-programming buddy that gives instantaneous feedback during development." This is the key bit, this is called static analysis, you don't need a type system in your language to do this, and you don't need to force doing it at compile time Most developers appear to conflate the two, uncoupling static analysis and type systems would benefit most workflows
  - mrkeen 6y ago
    > you don't need to force doing it at compile time What assembly instructions should the compiler emit if you write sum ["foo", "bar"] ?
- dsign 6y ago
  Amen to that. I love dearly both C++ and Haskell, but I remember those times when I wanted to cry because the C++ error message broke the OS clipboard when I was trying to copy it to a text editor so that I could write a program to analyze it and find which "const" didn't match in the jungle of type names. I have never had that situation with Haskell.
  - Vosporos 6y ago
    Oh dear :o
- mlthoughts2018 6y ago
  I find the compiler an annoyance in Haskell just as much as C++ - it just forces me to write more code (more liability) and leads to overly rigid type system designs, like modeling behavior with classes or traits/type classes. I’ve only found these ways of writing software to be universally worse than simple module-oriented programming, writing C-like code in languages like Python or Ruby and only selectively using C extensions for isolated cases where speed provably matters. Compilers do not offer compensating benefits, like catching bugs or ensuring behavioral correctness, that justify all the extra rigidity, slowness, and especially liability of all the extra code (even in Haskell).
- cogman10 6y ago
  I run into the same thing with Java. Code that always upsets me is something like `Map<String, Object>` where a concrete type would work so much better (and faster). Using a statically typed language, the most important thing you can do is USE IT. Let the type system save you from problems. Encode whatever you can in the types. Bypassing it by casting always causes headaches.
- portal_narlish 6y ago
  Strong point! As a non-CS engineering student learning C++ for the first time, the compiler all but turned me off from wanting to be a programmer. No one explained why the compiler was even there, it just seemed like an annoying hindrance stopping me from getting good grades on the homework. Fast forward a decade and I'm evangelizing statically typed FP at conferences. The value of the compiler is redeemed after self-teaching and learning the "Whys".
- labawi 6y ago
  > As a mostly C++ programmer making sure that I get compiler errors as often as possible by encoding most preconditions in the type system .. When selecting a language for a recent project, that needed to run correctly, without extensive debugging that would be hard to simulate (too many states and interactions), I had a couple of important criteria: 0) checked static typing 1) ADTs (that are reasonably easy to use, read and write) 2) pattern matching (no way I'll get all the if/else right) 3) reasonably easy to write static const (pure functional) code 4) memory-safe I've considered rust, but settled on haskell, as I needed it fast and I know haskell. While technically any Turing-complete language would work, I don't think C++ would be a fit for must-work code, even disregarding (4). While I haven't used C++ in a while, it seems to me, encoding the constraints would be 3-10x as much code, or even more, with many checks/cracks left, and a lot of readability gone. Clean and correct functional haskell code took a bit longer to write than say happy-path imperative python, but after fixing 2 or so bugs that manifested on pretty much the first (partial) use (like incorrect "<" vs. ">" and a bad constant), it has been running happily ever since. I didn't even bother simulating a full system configuration before a real-world customer acceptance test, because components worked on 1-2 inputs I tried, setting up a system would take a couple of hours and I couldn't think of reasonable failure scenarios. I haven't experienced similar correctness in other languages.
unicornmama 6y ago
Good luck scaling this to organization of 100+ engineers. You will soon learn the tradeoff between writing and reading code. And the stark realities of the dev hiring markets and the thing called a learning curve.
- nix23 6y ago
  Ever heard of Pandoc? With your logic, python is the only reasonable language.
  - detaro 6y ago
    I don't think "have you heard of this project with <5 main contributors" is a useful response to questioning if it scales to large groups.
- infinityplus1 6y ago
  Someone has to take the first step to solve the chicken and egg problem. If there are jobs requiring Haskell, it might get more users.
  - st1x7 6y ago
    I don't think that it's wise to sabotage your own future and productivity as a company just so you can pave the way for some language to become more popular.
    - mjburgess 6y ago
      It isn't, of course. But the crowd of other people want you to do that. It's the role of applause (and in your case, downvotes). The crowd throws cheap adulation at individuals who act against their own interests.
      - oblio 6y ago
        The peanut gallery :-))
deleted 6y ago
[deleted]
coldtea 6y ago
Why Haskell is our first choice for building production software systems: a rationalization of our excitement to get to write Haskell in production Here, I've fixed the title
- tome 6y ago
  Would you say that you've engaged in good faith with the point the author was trying to make?
  - jamil7 6y ago
    Eh, I kind of agree with the parent comment. The author didn't bring up any compelling points that couldn't be found in other modern languages (granted these likely borrowed from Haskell). As an outsider to Haskell I was hoping for some more concrete use cases for picking the language.
    - weego 6y ago
      Honestly there are no compelling arguments for picking Haskell over other languages in the same domain. Limited open-source to leverage, incredibly limited and costly hiring opportunities, not that great tooling and integrations. Any upside you can sell from a pure programming point of view (there are some very valid ones) pale in comparison to the negatives it brings to your overall business.
  - coldtea 6y ago
    Absolutely
  - FpUser 6y ago
    I've found article arguments incorrect - what they describe as Haskell's features and more are easily available in other languages as well. Strictly enforcing function style on the other hand looks to me as un-feature. From my long experience strictly enforcing any particular paradigm/style in programming is amounts to plugging round holes with the square pegs.
jrh206 6y ago
Haskell is nice and all, but I'm not a huge fan of this take. I can't help but think that many of the arguments boil down to something like 'you can write types so that the compiler checks things for you' (not a quote), whilst the author disregarded the Java/C++ compiler as "an annoyance" (a quote). The rest of the article is mostly a comparison between Haskell and PHP/Python/JavaScript, and most laid out benefits boil down to static typing. Sure, Haskell's type system is nicer, and the error messages are, I'm sure, more helpful (although the Java/C++ ones make sense when you learn what they mean). There is an example of domain modelling in Haskell: type Dollars = Int data CustomerInvoice = CustomerInvoice { invoiceNumber :: Int , amountDue :: Dollars , tax :: Dollars , billableItems :: [String] , status :: InvoiceStatus , createdAt :: UTCTime , dueDate :: Day } data InvoiceStatus = Issued | Paid | Canceled The syntax is nice (ish, CustomerInvoice is a bit ugly), and terse. But, I've seen this a million times in Java, and that works fine. Quote: Modeling domain rules in the type system like this (e.g. the status of an invoice is either Issued, Paid, or Canceled) results in these rules getting enforced at compile time, as described in the earlier section on static typing. This is a much stronger set of guarantees than encoding similar rules in class methods, as one might do in an object oriented language that does not have sum types. With the type above, it becomes impossible to define CustomerInvoice that doesn’t have an amount due, for example. It’s also impossible to define a InvoiceStatus that is anything other than one of the three aforementioned values. All of this is table stakes in Java/C++ too. Other brief rebuttals: Haskell has a large number of mature, high-quality libraries No way this beats Java. I don't know the C++ ecosystem well, but I assume C++ wins too. Haskell enables domain-specific languages, which foster expressiveness and reduce boilerplate Be careful what you wish for. Haskell has a large community filled with smart and friendly people I think at the end of the day Haskell just feels fun to write, if you're the sort of person that likes it. That's fine. But I don't think going all-in on Haskell is the right call for most companies.
- willtim 6y ago
  > But, I've seen this a million times in Java Perhaps when Java gets record types, sealed classes, pattern matching and other features. But right now, Domain Modelling in Java (and C++) is really painful compared to a higher-level language like Haskell.
dmitriid 6y ago
I dislike Haskell. But this article goes out of its way to make the worst possible case for Haskell imaginable. > Many programmers encounter statically typed languages like Java or C++ and find that the compiler feels like an annoyance. By contrast, Haskell’s static type system, in conjunction with compile-type time checking, acts as an invaluable pair-programming buddy that gives instantaneous feedback during development. Many programmers find that Java or C++'s static type system, in conjunction with with compile-type time checking feels like an annoyance. Unlike... the very same statement about Haskell? That's... that's quite a weak claim, to say the least. > a signature like Int -> Int -> Bool indicates that a function takes two integers and returns a boolean value... this allows a programmer reading Haskell code to look only at type signatures when getting a sense of what a certain piece of code does. For example, one would not use the type signature above when looking for a function that manipulates strings, decodes JSON, or queries a database. So... Type signature `Int -> Int -> Bool` can be used for a function that does any of the following things: manipulates strings, decodes JSON, or queries a database? How does that make it easier to deduce what a function does by "looking only at type signature"? > Another feature of a pure functional programming paradigm is higher-order functions, which are functions that take functions as parameters. As in: available in almost any language these days, and not exclusive to a "pure functional programming paradigm". > One of the common development workflows we employ is relies on a tool called ghcid, a simple command line tool that relies on the Haskell repl to automatically watch code for changes and incrementally recompile. This allows us to see any compiler errors in our code immediately after saving changes to a file. It’s not uncommon for us to open only a terminal with a text editor and ghcid while developing applications in Haskell. As in: Modern IDEs don't require you to run external tools to monitor your code for changes and highlight errors. > a common refactoring workflow is to make a desired change in one location and then fix one compiler error at a time until the program compiles again. As in: Modern IDEs let you do large-scale refactoring in one go, at a press of a button. > The type system can protect us from making mistakes when changing the rules of our domain. It can't. The example provided can't stop you from doing `case status of Paid -> delete invoiceNumber`. You have to invest significantly in a type-based DSL to prevent that from happening. But then, who will test your DSL? > Haskell enables domain-specific languages, which foster expressiveness and reduce boilerplate DSLs where all the rage 5-10 years ago. In reality, they are overhyped and are used very sparingly, for obvious reasons: DSLs are languages. They have to be designed, developed, maintained. Errors in your DSL will most likely harder to find and debug than in your regular program.
IfOnlyYouKnew 6y ago
No, sorry, it has very little to do with technology. There's at least a dozen languages you could have chosen, and that others have chosen for any given use case. within some bounds, it makes very little difference.[0] The reason you've chosen Haskell and, by the way, also the TLD ".system", is that you've constructed your identity in such a way that "advanced language with a steep learning curve" is something that fits. There's absolutely nothing wrong with that. It's a bit emotional, but those exist for a reason. If you consider that idea libellous, you can always cite PR motives for plausible deniability and point at this HN story as evidence. [0]: Elm, by the way, strikes me as borderline with regards to the bounds of reasonableness, considering the state that community is in. As such, it's more evidence your left (right?) metaphorical hemisphere may have had a finger on the scale.
- FlyingSnake 6y ago
  > The reason you've chosen Haskell and, by the way, also the TLD ".system", is that you've constructed your identity in such a way that "advanced language with a steep learning curve" is something that fits. I think you're projecting too much on them. They found Haskell performant and are promoting it, I don't see any problem with it. How is any different from all the Rust evangelism HN sees all the time?
  - oblio 6y ago
    I think his point is that there are N languages that are performant and they could have probably chosen any of them to achieve their goal, so the choice is primarily aesthetic.
    - thedmstdmstdmst 6y ago
      The article doesn't say they have exhausted all languages, just that it is their first choice. Not their only choice but first choice.
  - IfOnlyYouKnew 6y ago
    I really don't have a problem with their choice–I wasn't being ironic. It's perfectly acceptable to make "I like it" or "it works for us" choices. I do believe, very very mildly, that there's a strain of thinking among the tech crowd that glorifies this Spock-like emotional detachment and I'm-so-rational mindset. Two issues, actually: First, such a mindset is neither possible nor would do much good. There are stroke victims that survive with full mental capabilities with regards to logical reasoning but entirely devoid of emotions. These patients can still ace the SAT, but they fail spectacularly at daily life. As it turns out, you just cannot decide on a doctor's appointment without emotions. They'll spent hours vacillating between two good choices. Emotions are incredibly well-tuned heuristics that cut down your mental load to manageable levels. As any part of being human, they are sometimes ill-fitting for modern times: there's absolutely no reason to make me flinch when I spill hot coffee over my hand. But mostly they just work. Second, it's slightly annoying when people deny that they are subject to emotions, and it gets up to Ryanair-levels of discomfort when they announce that it makes them superior to all those emotional social science majors, illogical politicians, women "throwing a fit", superficial designers etc. If I got a KDE theme every time someone accused Apple users of being blinded by eye candy, I'd still be left with only half of what Kubuntu ships. But Rust is cool.
fegu 6y ago
If you want to get a feel of the productivity using Haskell in production start with a simple CRUD app and use IHP (https://ihp.digitallyinduced.com/ https://ihp.digitallyinduced.com/) to build it. You will have something usable within a day - GUI and all. Then move further down the rabbit hole from there.
- kreetx 6y ago
  How about servant, and some popular js framework on top of that? IHP might be putting a lot of effort into the project, but the code generation part... I (personally) don't like that at all. And it's not common practice in haskell.
  - hardwaresofton 6y ago
    Second this -- Servant is one of the best examples of server-side haskell there is, and from what I understand IHP is relatively new in comparison (correct me if I'm wrong). Servant is one of the best if not the best example of how haskell's higher level abstractions can benefit practical bread and butter programming (which making APIs is these days) tasks, and where type safety is a huge benefit. Writing servant handlers can also feel mostly imperative depending on how much you use `do`.
  - _query 6y ago
    IHP is very opinionated in the way how it approaches building web applications (Code Gen, Project structure, Naming, ..). But exactly this kind of opinionated design makes it possible to be very productive, compared to doing everything yourselves.
    - kreetx 6y ago
      IHP is opinionated in the sense that it does state on the server side and uses (something similar to) turbolinks to make it look fast. But generating additional types for SomeDataType like ViewSomeDataType etc - my gut feeling tells me these should be implemented trough type classes instead. New data types shouldn't be generated for cases like this. Disclaimer: I've only looked at the docs of IHP, but this was what it looked like it was doing.
gregorygoc 6y ago
I think most programmers nowadays face no interesting problems to solve. They crave for a mental challenge, but instead of looking for a job that requires solving hard engineering problems, they believe they can satisfy their mental needs with coding in “somewhat” hard language.
- deleted 6y ago
  [deleted]
- Tade0 6y ago
  As a front-end developer whose job is is to write configurations(so not even actual code) for a form library I picked up Rust for this specific reason. Could've been any other language, but this one scratches my personal itch.
- dbattaglia 6y ago
  I think you make a valid point in general about coding professionally at most jobs, and I know I've fallen into this desire myself while working on endless CRUD apps over the years. That said, I do think the article brings up some good points about domain modeling. After becoming somewhat proficient in Scala I've found these same features (ADTs) mentioned in the article helpful for the important part of these boring CRUD apps: modeling data at the various application boundaries (API, domain layer, database layer, etc). I now find using weaker type systems and/or imperative code to be either more error prone or more verbose (due to validation + extra tests). Of course there are other parts of Scala, Haskell and similar that require more mental gymnastics than I'd like, such as composing asynchronous operations; flatMap and monad transformers may be "elegant" once you really understand them but damn is async/await easier to just write and move on with your life.
kensai 6y ago
Has anyone had a look or knows of production systems made with a Haskell-like language named Curry? (https://curry-lang.org/ https://curry-lang.org/) Sounds a lot like Haskell with Prolog... “ Curry is a declarative multi-paradigm programming language which combines in a seamless way features from functional programming (nested expressions, higher-order functions, strong typing, lazy evaluation) and logic programming (non-determinism, built-in search, free variables, partial data structures). Compared to the single programming paradigms, Curry provides additional features, like optimal evaluation for logic-oriented computations and flexible, non-deterministic pattern matching with user-defined functions.”
- tome 6y ago
  Tangentially, did you actually manage to make an HTTPS connection to that site? I can only manage HTTP.
- chriswarbo 6y ago
  I've played with it, using the kics2 implementation. I made a rough package for Nix, which might be useful if you have problems installing it: http://chriswarbo.net/git/warbo-packages/git/branches/master/packages/kics2.nix.raw.html http://chriswarbo.net/git/warbo-packages/git/branches/master... You might like the Mercury language too: https://mercurylang.org/ https://mercurylang.org/
- iso8859-1 6y ago
  You can already have Prolog embedded in Haskell, using LogicT. Here is the paper by Kiselyov: http://okmij.org/ftp/papers/LogicT.pdf http://okmij.org/ftp/papers/LogicT.pdf
thedonkeycometh 6y ago
tldr; We love Haskell, that's why.
unnouinceput 6y ago
Quote: "GHC, the most commonly used Haskell compiler, produces extremely fast executables, especially when compared against other languages commonly used for application development, such as PHP or Python" Really? You comparing apples with oranges? Why not, if you're at the step of comparing compiled versus interpreted languages, compare it with Java too? Now, do the same comparison versus C++, let's see who wins when talking about speed.
johndoe42377 6y ago
Unfortunately, the Haskell ecosystem has been ruined (well, almost) by unnecessary, redundant abstractions and narcissistic idiots who pushes them. I recently tried to compile haskell-language-server and stack from sources. 157 and 168 (or something) dependencies, full of redundant esoteric bullshit, compat packages, lifted crap, etc. It is even worse than J2EE where it was the same redundant wrapping and indirection, but brain-dead straightforward verbose crap. To use Haskell correctly, like the classic xmonad and similar projects, requires discipline, knowledge and good taste for just right abstractions, like Go stdlib or Scala3 standard library. Yes, it doubles development time, which must be spent on understanding anyway, but fast food fp code, full of redundant abstractions, is a worst nightmare to maintain.
- hardwaresofton 6y ago
  This article might be a bit overeager and overzealous, but how you use haskell is up to you -- don't use those underlying packages that disgust you if you don't like them. Haskell offers benefit at every level of abstraction. There are many ways to write Haskell and you do not need a bunch of the higher level stuff. 99% of the time you are just fine with the data modeling (simple Algebraic Data Types) and type classes, along with a cursory understanding of monads via "do" notation. This comment reads like someone seeing the worst of J2EE, and going back to C++. I'd characterize haskell as having the type system that Java wishes it did. Why are you trying to judge how haskell should be written for your use case by looking at haskell-language-server, stack, and xmonad? Those are the domains of haskell experts -- one is a language server, the other is one of the pre-eminent build tools, and the other is tiling manager.... Are any of those your use-case? There are real problems with haskell, and forcing you into complexity is not one of them -- a steep learning curve (for certain concepts), hard to debug space leaks, and a relatively small ecosystem are the biggest issues.
  - throwaway894345 6y ago
    > how you use haskell is up to you -- don't use those underlying packages that disgust you if you don't like them These kinds of arguments are particularly lazy. Of course, Haskell's ecosystem is not so large that it's trivial to find a well-maintained, high-quality version of a library that meets one's other criteria. Programmers of a particular language are at the mercy of that language's ecosystem. This line of reasoning reminds me of how C++ programmers would deflect criticisms of problematic features by arguing that one could use only the features that one wanted (thereby effectually creating or curating their own sub-language) and only choosing dependencies that were equally written in that sub-language. So easy!
fooyc 6y ago
Sounds like "Haskell is cool because it is typed, and it is the only typed language I know"
wombat23 6y ago
What I'd like to understand: When/why does one choose Haskell over other functional languages e.g. F# or OCaml? It looks to me like they would satisfy the same points that the article makes. Edit: just did a quick comparison of the last 2 SO developer surveys, and it looks like Haskell "replaced" F# in their popularity ranking last year.
- nudpiedo 6y ago
  all them are equally competent languages. F# with corporative support and a giant ecosysten, ocaml being very fast and portable and haskell being very... special and pure.
  - wombat23 6y ago
    Thanks for your reply! I see the corporate aspect of F#, but can you elaborate on what you mean by "special" about Haskell?
- chriswarbo 6y ago
  Haskell's laziness and purity can make it a bit trickier to use constructs that are common in ML-like (or Scheme-like) languages, like mutable variables. This nudges Haskell libraries in a slightly different direction, e.g. making more use of control structures like monads, arrows, continuations, etc. which authors in other languages wouldn't reach for so readily. This has an effect on the ecosystem, since people want their systems and libraries to be compatible with each other's APIs. The result is that "the Haskell way" can seem a little more intimidating than the more "pragmatic" approach of MLs. (I write this as someone who writes a lot of Haskell, and dabbles in StandardML!)
fooyc 6y ago
> Haskell programs have stellar performance, leading to faster applications and lower hardware costs [...] PHP $244 [...] Haskell $15 This is overlooking the cost of developers, which greatly outweights the hardware's unless you are Facebook.
- vp8989 6y ago
  No it isn't, it's a simple matter of fact statement that running code on runtime A appeared to be cheaper in terms of hardware costs than runtime B. The "overlooking" part you filled in yourself in bad faith and bad reading comprehension, as the author actually does acknowledge that the observed hardware savings are small compared to the cost of hiring programmers.
hardwaresofton 6y ago
Haskell is an excellent language, and you are free to choose not to drown yourself in the most complex uses of it. Haskell has the type system Java wishes it did, and half of the reason languages like Rust are interesting is because they've learned from Haskell (which is the point of Haskell, a research langage, though it happens to also be a pretty darn good language for building practical things). Simple basic data types like `Maybe t` and `Either l r` are such a revelation that you wonder how you lived without them. I've shared this anecdote before, but Option<T> in Java is an example of the blub paradox[0], and discovering Haskell and finding out about Algebraic Data Types (ADTs) and the Maybe type cured my blub. The crux was this: Option<T>s seems to "infect" any codebase you use it on, because you realize that anything can fail and be null -- living in java land made it seem like it was out of place it's actually Option<T> that is right -- if you allow nullable types in your code base, or you do operations that can fail, properly representing that failure is the right decision. Without over stating some of the best features of Haskell are: - Compile time type checking (this cannot be understated) and non-nullable types - Expressive and simple data type creation via `data`, `type` - An excellent system for attaching functionality and composing functionality to data types via `typeclass`es and `Constraint`s. - An emphasis on errors as values (unfortunately exceptions are in the language too, but you can't really stop them from existing) - Forced delineation between code with side-effects and code without (this results in some complexity if you come from a world with side-effects everywhere and no control) - Fantastic runtime system with good support for concurrency, parallelism and shared memory management. - Very easy refactoring (if you're not adding any complexity/abstraction) because you can just change what you want and let the compiler guide you the rest of the way. Haskell has it's warts (hard to debug space leaks, relatively small ecosystem, the ability to drown yourself and your team in abstraction), but it's just about the most production-ready research language I've seen. Whether or not you like it, the likelihood it's already improved your life in whatever language you're using is very high.
- Twisol 6y ago
  You dropped this: [0] http://paulgraham.com/avg.html http://paulgraham.com/avg.html (Scroll to "The Blub Paradox", about a third of the way down.)
Kototama 6y ago
Biggest problem I had with Haskell was once you know the language you also need to learn a pile of extensions that any serious project is using. Also there is a tendency in the community to always look for the "best" (abstract) solution. It makes the whole ecosystem fast changing. I would prefer a more stable platform designed for engineers , something like Clojure but with types. Ocaml has a small community and Scala brings unnecessary complexity with its support for OOP.
bsenftner 6y ago
I'm at a technology research company that is primarily using C++ as the main company tool. The development team is small, and the code is the result of 22 years of constant revision by PhDs. One of our Never To Be Violated Rules, simply because the number of hidden landmines is far to numerous, is template programming. When generic programming is required we use a web language like PHP where the type of something is contextual and one can be free and loose and sloppy if they want. Between the two extremes of our formal as fuck C++ base and the anything goes generic web languages we maintain surprisingly high levels of productivity, with very low bug counts. Having a tiny team helps, as we all know the code based inside out.
aardvark1 6y ago
This company looks to be a team of three (probably very smart) engineers who build cool custom software for likely relatively small clients. The software is likely only supported and modified by them. In that scenario something like Haskell makes sense - however once you need to scale your engineering footprint beyond 5-10 people it becomes virtually impossible to rationalize using a niche language like Haskell.
- sesuximo 6y ago
  Also unclear how long they’ve been doing this... I’m unable to find any info about provide projects other than very high level blog style stuff
- ivanbakel 6y ago
  What is that claim based on? Plenty of companies use Haskell to great success scaling to well beyond 10 people. It may be a niche language, but in a remote-working world, and with a truly massive number of developers in the workforce, there still end up being a sizeable number of professional Haskell developers available to most companies.
StreamBright 6y ago
Most of these apply to F#. The only difference that there are much more libraries available for that ecosystem than to Haskell’s.
jjice 6y ago
Haskell seems extremely neat, and I do like the ML family for compiler development, but Haskell just seems like such a steep learning curve. The amount of operators I've seen boggles my mind, are they user defined? Is there a good way to learn Haskell that preferably skips over some common functional concepts?
- lallysingh 6y ago
  I'll put the learning curve around the same level as C++, with the qualifier that most of what you learn aren't parts of the language, but patterns and formalisms you can use in any language.
elephantum 6y ago
It seems like you can substitute Haskell to Rust in almost every point they make. (Or with many other great options)
- adamch 6y ago
  Yes, this was my immediate thought too. I love writing Haskell, but Rust has become my daily driver, both at work (Cloudflare) and personal projects. It gives me the excellent type system, better domain modelling, great ecosystem (serde, actix-web, rayon, reqwest, diesel, tokio) and performance. I've basically traded away some nice abstractions (functors, monoids etc) for the ability to debug error messages more easily, and not have to convince people to learn/support an obscure language. Good deal IMO.
Areading314 6y ago
It is absolute nonsense to say that using Haskell will improve productivity or maintainability. There are problems like bad libraries, complicated performance profiles, virtually no developer adoption, limited ghc build targets, package management, lack of tooling, slow compile times. Choosing Haskell is likely a terrible choice despite the type system, which seems to be its only advantage.
darksaints 6y ago
Okay, so this is admittedly snarky but we've seen this sort of blog post so much that it has practically become an Onion article: Why Haskell Is Our Secret Weapon, by Startup You've Never Heard Of. And then when someone points out that nobody knows who they are or what they've built, we get commenters talking about how company X, Y, and Z are also using Haskell. And those claims also come up short...most of them can't say where or how it is being used because they don't know...just that at some point in the past, someone emails were exchanged between someone@bignamecompany.com and someone@haskell.org, and now there is a piece of copy on the Haskell website that disingenuously claims BigNameCompany is powered by Haskell!. Who cares how pervasivly it is used...if someone writes a config parser with Haskell, all of a sudden we can claim that BigNameCompany would fall over on its face if Haskell wasn't there protecting it. Come on. Nobody cares that Haskell is your secret weapon if you've never overcome an opponent with it. Or built an entire profitable company on its back. All these types of posts do is fake an authority so you can jump straight to your fallacious argument by authority. If you want to argue the merits of your favorite language, then do it. Don't make us sit through an argument about how your language makes you special when you aren't even noteworthy enough for a 10 sentence Wikipedia blurb. There are a lot of valid and powerful technical arguments in this article, but they're ruined by framing them all around the premise that we care about how it makes you and your startup special.
- andai 6y ago
  I don't think the article warrants such a harsh reaction. Was it the word "our" in the title? They're just writing from their perspective.
- warcher 6y ago
  I'm not really a haskell fan, but the lion's share of that effect more that likely comes from the small sample size of companies using haskell. Even if it were somehow superior, there just are enough people trying it to be coming up with a unicorn startup or two. Now, the lack of skilled haskell programmers on the other hand, that's a pretty scary proposition if you're starting a company and may find yourself riding on a rocket, needing as many able hands as you can possibly find.
- 6y ago
waterheater 6y ago
According to a friend who worked there, Kitty Hawk's flying car flight controller is written in Haskell. Gotta love those MIT researchers.
Geminidog 6y ago
Haskell does not actually get rid of side effects in practice. I find that tons of Haskell code involves do notation which is basically code that embraces monadic side effects which sort of defeats the purpose that this article says of pushing side effects to the edge. Really in order to “push side effect to the edge” people need to avoid using monadic composition as much as possible which I see Haskell programmers rarely doing in practice.
- willtim 6y ago
  Monadic composition is used everywhere from simple failure (Maybe or Either) through to genuine side effects such as IO. The presence of monads does not necessarily mean side effects. Haskell never claimed to "get rid of side effects", the idea is make them explicit in the types and to be able to reason about them.
  - Geminidog 6y ago
    Right, but the article says that Haskell pushes these side effects to the edge. I am not saying haskell claims this, I'm saying the article claims this. Haskell actually doesn't do this in practice as tons of people use do notation and state monads. The more people use do notation, the more they are embracing side effects. Literally I've seen haskell code where all function definitions had some form of do notation which is basically against the claim made by this article. To push side effects to the edge you have to only use do notation and monads when you absolutely have no choice, which is not done in practice with haskell. >The presence of monads does not necessarily mean side effects The presence of a functor does not mean side effects. The presence of a monad implies composition and binding which does imply a side effect. Even maybe monads composed have side effects that can produce output that the function itself can never produce on it's own. For example let's say I have a maybe monad that will never produce "Nothing." b :: int -> Maybe Int b x = Just x but I can produce a side effect by binding it with Nothing. Nothing >>= b The above yields "Nothing," even though it is not part of the definition of b. It is a contextual side effect passed on through monadic composition. Normal composition outside of monadic composition usually does not have this property.
revskill 6y ago
I spent 1 year to focus on learning Haskell. It's a brain-hacking language, too hard to master. But in the end, i've got some nice basics on doing functional programming the right way. Immutability, composable abstraction lies in the heart of a maintainable software i'll produce.
FlyingSnake 6y ago
I simply don't get the hate this article is getting, are some HN readers really that bad at reading comprehension? The authors clearly mention it is "our first choice" and then they go on to present their findings with great clarity. Nowhere do they evangelize Haskell like other language like Rust for example. I never see such comments on threads on other languages, even though some of articles posted are of subpar quality. In the end the insecurities and failures of snarky commentators don't matter to others who are in the arena solving real problems in production with an unsexy language.
ezoe 6y ago
There is a serious risk using a programming language that is too different from majority of languages. Like Haskell, Erlang, Lisp variants. It requires a lot of effort to learn, development tools are scarce, and you can't easily hire a new worker simply because it's minor. Eventually, original developer left the company for one way or other, leaving a code and half baked documents only the early developer fully understand. Good luck maintaining those software. You can't. It's either abandoned or replaced.

269 points by Albert_Camus 6y ago

> Many programmers encounter statically typed languages like Java or C++ and find that the compiler feels like an annoyance. By contrast, Haskell’s static type system, in conjunction with compile-type time checking, acts as an invaluable pair-programming buddy that gives instantaneous feedback during development. the reason they "find that the compiler feels like an annoyance" is because their first exposure to Java / C++ is in school where they have an assignment due for tonight and the compiler won't stop banging pages of errors about std::__1::basic_string<char, std::__1::allocator<char>> and what the fuck is that shit I just want to make games !!11!1! In contrast Haskell is often self-taught which gives a very different set of incentives and motivations. As a mostly C++ programmer making sure that I get compiler errors as often as possible by encoding most preconditions in the type system is one of the most important part of my job and make the language very easy to use when you use an IDE which allows to click on an error and going to the right place in the code.

Blikkentrekker 6y ago
I learned both Haskell and Rust self-taught an still find the latter's type system a bit of a cage for it's lack of higher kinded types, frankness be. I know not much of Java, but my sentiments concerning C++ are even worse. I do not regularly program in Haskell and far more often in Rust.
- platinumrad 6y ago
  "I don't know much about this thing but I don't like it, and I know even less about this other thing and I like it even less!" For what it's worth, C++ has HKTs in the form of template template parameters, making it possible to write, e.g., monad transformers, which cannot be done in Rust, last I checked. Now as for whether you'd actually want to do this in a production codebase...
- marcosdumay 6y ago
  Rust metadata (not just types) have an habit of getting in your way. It is all for good reason, you can't ditch the GC and have control over the memory structure without the compiler complaining about details here and there. But fixing those strings versus slices and iterator type mistakes is really annoying.
js8 6y ago
Actually, the reason why I found static typing annoying in the past (and why I felt more productive in Python) were the types are really low level (missing basic things like tuples) and lack of type inference. You have to repeat the type information, a lot. And also you have to declare lot of intermediate data structures. In Python, this became easier and one could focus on the data transformations, thinking about the code a level higher. But then I learned a bit of Haskell 5 years ago, and with type inference, this problem goes away. So it convinced me back to benefits of static typing. (Although I still feel the most productive in Python, their library APIs are IMHO unmatched in any language. But Haskell is catching up.)
- jcelerier 6y ago
  > the types are really low level (missing basic things like tuples) and lack of type inference how far ago was this in the past ? C++ had tuples and type inference for ten+ years officially now - gcc 4.4 had it in 2009
  - mjburgess 6y ago
    There's also the culture around the language to fold in. A culture of writing code assuming inference and structural typing is quite different than it merely being available.
    - sfg 6y ago
      So, OCaml or something? Or has Haskell added structural typing?
      - mjburgess 6y ago
        Haskell is structurally typed...
        tome 6y ago
        Hmm, what do you mean? Haskell is generally considered nominally typed (or rather types introduced by its newtype and data declarations are ...). "Structural typing" typically refers to things like polymorphic row types and polymorphic variants.
avl999 6y ago
> the reason they "find that the compiler feels like an annoyance" is because their first exposure to Java / C++ is in school where they have an assignment due for tonight and the compiler won't stop banging pages of errors about std::__1::basic_string<char, std::__1::allocator<char>> and what the fuck is that shit I just want to make games !!11!1! Well I can't imagine how much more annoyed they'd be when using an interpreted language which lets the code run just fine but then fails at runtime in mysterious and subtle ways requiring hours of manually scanning though code and print statements when the compiler would have caught a decent subset of those errors with helpful messages about the exact line they need to fix.
- bird_monster 6y ago
  > Well I can't imagine how much more annoyed they'd be when using an interpreted language which lets the code run just fine but then fails at runtime in mysterious and subtle ways requiring hours of manually scanning though code and print statements when the compiler would have caught a decent subset of those errors with helpful messages about the exact line they need to fix. You cannot get mad at errors you don't know about. Also letting the user find and report the error allows you to mark your tickets "done" and move on, which makes management happy.
- ZephyrBlu 6y ago
  In my experience, you quickly develop an intuition for where things are going wrong with interpreted languages. Ex: "Oh, cannot access property x of undefined? Something must be going wrong in y object" Python definitely feels a lot more helpful than JS though. Can't speak for other interpreted languages like Ruby.
  - cjfd 6y ago
    The thing is, though, that you mostly only get errors for code that is actually executed. So, your program is only fully type checked when all code paths are executed. In the case of python one can ameliorate this situation a bit by using mypy. At my job I see very often code being broken because, e.g., the signature of a function was changed but not in all places and so on. Now somebody will say that the IDE can solve that but these colleagues who are regularly breaking the code are actually using IDEs and it somehow still does not help. I have come to think that code that is not compiled and/or otherwise type checked is just not very serious and certainly not worthy of production environments.
corty 6y ago
Annoyance about C++ errors isn't only about the error occuring. With me, it is predominantly about the utter unusability of the error messages. C++ has postprocessors you can use to get your 20 page STL errors down to a few lines just by reversing the expansion the compiler did to show you mere mortal something that you might recognize as your code instead of template-cthulhu. Haskell has such situations as well, but usually far less verbose. Getting something to typecheck because you wrote down something incompatible uninferable still sucks. But far less than C++.
- Rompect 6y ago
  In contrast, Rust's compiler sometimes gives suggestions for changes which can often just be copied.
  - emteycz 6y ago
    That's not entirely true. It gives suggestions in the cases where the C++ compiler does too. There are more than a few very cryptic errors you can encounter with Rust. I like it though, just needs more work.
    - 3836293648 6y ago
      Depends on the compiler. In my very limited experience I've found that Clang is far superior to GCC in this matter (but rustc is better still, apart from iterator errors)
      - srean 6y ago
        I am curious about which GCC, G++ version you have in mind. Clang definitely took the lead, but by GCC caught up and I prefer GCC's do Clang. But even I am behind the bleeding edge quite a bit so not sure how things stand now.
    - leshow 6y ago
      It's been a while since I used C++ but I have never seen suggestions of the same quality that the rust compiler produces. Do you have a link that shows the error messages you're talking about? For sure though, not every error has a great message and some can be cryptic. But those cases are relatively rare these days IMO
slifin 6y ago
"acts as an invaluable pair-programming buddy that gives instantaneous feedback during development." This is the key bit, this is called static analysis, you don't need a type system in your language to do this, and you don't need to force doing it at compile time Most developers appear to conflate the two, uncoupling static analysis and type systems would benefit most workflows
- mrkeen 6y ago
  > you don't need to force doing it at compile time What assembly instructions should the compiler emit if you write sum ["foo", "bar"] ?
dsign 6y ago
Amen to that. I love dearly both C++ and Haskell, but I remember those times when I wanted to cry because the C++ error message broke the OS clipboard when I was trying to copy it to a text editor so that I could write a program to analyze it and find which "const" didn't match in the jungle of type names. I have never had that situation with Haskell.
- Vosporos 6y ago
  Oh dear :o
mlthoughts2018 6y ago
I find the compiler an annoyance in Haskell just as much as C++ - it just forces me to write more code (more liability) and leads to overly rigid type system designs, like modeling behavior with classes or traits/type classes. I’ve only found these ways of writing software to be universally worse than simple module-oriented programming, writing C-like code in languages like Python or Ruby and only selectively using C extensions for isolated cases where speed provably matters. Compilers do not offer compensating benefits, like catching bugs or ensuring behavioral correctness, that justify all the extra rigidity, slowness, and especially liability of all the extra code (even in Haskell).
cogman10 6y ago
I run into the same thing with Java. Code that always upsets me is something like `Map<String, Object>` where a concrete type would work so much better (and faster). Using a statically typed language, the most important thing you can do is USE IT. Let the type system save you from problems. Encode whatever you can in the types. Bypassing it by casting always causes headaches.
portal_narlish 6y ago
Strong point! As a non-CS engineering student learning C++ for the first time, the compiler all but turned me off from wanting to be a programmer. No one explained why the compiler was even there, it just seemed like an annoying hindrance stopping me from getting good grades on the homework. Fast forward a decade and I'm evangelizing statically typed FP at conferences. The value of the compiler is redeemed after self-teaching and learning the "Whys".
labawi 6y ago
> As a mostly C++ programmer making sure that I get compiler errors as often as possible by encoding most preconditions in the type system .. When selecting a language for a recent project, that needed to run correctly, without extensive debugging that would be hard to simulate (too many states and interactions), I had a couple of important criteria: 0) checked static typing 1) ADTs (that are reasonably easy to use, read and write) 2) pattern matching (no way I'll get all the if/else right) 3) reasonably easy to write static const (pure functional) code 4) memory-safe I've considered rust, but settled on haskell, as I needed it fast and I know haskell. While technically any Turing-complete language would work, I don't think C++ would be a fit for must-work code, even disregarding (4). While I haven't used C++ in a while, it seems to me, encoding the constraints would be 3-10x as much code, or even more, with many checks/cracks left, and a lot of readability gone. Clean and correct functional haskell code took a bit longer to write than say happy-path imperative python, but after fixing 2 or so bugs that manifested on pretty much the first (partial) use (like incorrect "<" vs. ">" and a bad constant), it has been running happily ever since. I didn't even bother simulating a full system configuration before a real-world customer acceptance test, because components worked on 1-2 inputs I tried, setting up a system would take a couple of hours and I couldn't think of reasonable failure scenarios. I haven't experienced similar correctness in other languages.

unicornmama 6y ago

Good luck scaling this to organization of 100+ engineers. You will soon learn the tradeoff between writing and reading code. And the stark realities of the dev hiring markets and the thing called a learning curve.

nix23 6y ago
Ever heard of Pandoc? With your logic, python is the only reasonable language.
- detaro 6y ago
  I don't think "have you heard of this project with <5 main contributors" is a useful response to questioning if it scales to large groups.
infinityplus1 6y ago
Someone has to take the first step to solve the chicken and egg problem. If there are jobs requiring Haskell, it might get more users.
- st1x7 6y ago
  I don't think that it's wise to sabotage your own future and productivity as a company just so you can pave the way for some language to become more popular.
  - mjburgess 6y ago
    It isn't, of course. But the crowd of other people want you to do that. It's the role of applause (and in your case, downvotes). The crowd throws cheap adulation at individuals who act against their own interests.
    - oblio 6y ago
      The peanut gallery :-))

deleted 6y ago

[deleted]

coldtea 6y ago

Why Haskell is our first choice for building production software systems: a rationalization of our excitement to get to write Haskell in production Here, I've fixed the title

tome 6y ago
Would you say that you've engaged in good faith with the point the author was trying to make?
- jamil7 6y ago
  Eh, I kind of agree with the parent comment. The author didn't bring up any compelling points that couldn't be found in other modern languages (granted these likely borrowed from Haskell). As an outsider to Haskell I was hoping for some more concrete use cases for picking the language.
  - weego 6y ago
    Honestly there are no compelling arguments for picking Haskell over other languages in the same domain. Limited open-source to leverage, incredibly limited and costly hiring opportunities, not that great tooling and integrations. Any upside you can sell from a pure programming point of view (there are some very valid ones) pale in comparison to the negatives it brings to your overall business.
- coldtea 6y ago
  Absolutely
- FpUser 6y ago
  I've found article arguments incorrect - what they describe as Haskell's features and more are easily available in other languages as well. Strictly enforcing function style on the other hand looks to me as un-feature. From my long experience strictly enforcing any particular paradigm/style in programming is amounts to plugging round holes with the square pegs.

jrh206 6y ago

Haskell is nice and all, but I'm not a huge fan of this take. I can't help but think that many of the arguments boil down to something like 'you can write types so that the compiler checks things for you' (not a quote), whilst the author disregarded the Java/C++ compiler as "an annoyance" (a quote). The rest of the article is mostly a comparison between Haskell and PHP/Python/JavaScript, and most laid out benefits boil down to static typing. Sure, Haskell's type system is nicer, and the error messages are, I'm sure, more helpful (although the Java/C++ ones make sense when you learn what they mean). There is an example of domain modelling in Haskell: type Dollars = Int data CustomerInvoice = CustomerInvoice { invoiceNumber :: Int , amountDue :: Dollars , tax :: Dollars , billableItems :: [String] , status :: InvoiceStatus , createdAt :: UTCTime , dueDate :: Day } data InvoiceStatus = Issued | Paid | Canceled The syntax is nice (ish, CustomerInvoice is a bit ugly), and terse. But, I've seen this a million times in Java, and that works fine. Quote: Modeling domain rules in the type system like this (e.g. the status of an invoice is either Issued, Paid, or Canceled) results in these rules getting enforced at compile time, as described in the earlier section on static typing. This is a much stronger set of guarantees than encoding similar rules in class methods, as one might do in an object oriented language that does not have sum types. With the type above, it becomes impossible to define CustomerInvoice that doesn’t have an amount due, for example. It’s also impossible to define a InvoiceStatus that is anything other than one of the three aforementioned values. All of this is table stakes in Java/C++ too. Other brief rebuttals: Haskell has a large number of mature, high-quality libraries No way this beats Java. I don't know the C++ ecosystem well, but I assume C++ wins too. Haskell enables domain-specific languages, which foster expressiveness and reduce boilerplate Be careful what you wish for. Haskell has a large community filled with smart and friendly people I think at the end of the day Haskell just feels fun to write, if you're the sort of person that likes it. That's fine. But I don't think going all-in on Haskell is the right call for most companies.

willtim 6y ago
> But, I've seen this a million times in Java Perhaps when Java gets record types, sealed classes, pattern matching and other features. But right now, Domain Modelling in Java (and C++) is really painful compared to a higher-level language like Haskell.

dmitriid 6y ago

I dislike Haskell. But this article goes out of its way to make the worst possible case for Haskell imaginable. > Many programmers encounter statically typed languages like Java or C++ and find that the compiler feels like an annoyance. By contrast, Haskell’s static type system, in conjunction with compile-type time checking, acts as an invaluable pair-programming buddy that gives instantaneous feedback during development. Many programmers find that Java or C++'s static type system, in conjunction with with compile-type time checking feels like an annoyance. Unlike... the very same statement about Haskell? That's... that's quite a weak claim, to say the least. > a signature like Int -> Int -> Bool indicates that a function takes two integers and returns a boolean value... this allows a programmer reading Haskell code to look only at type signatures when getting a sense of what a certain piece of code does. For example, one would not use the type signature above when looking for a function that manipulates strings, decodes JSON, or queries a database. So... Type signature `Int -> Int -> Bool` can be used for a function that does any of the following things: manipulates strings, decodes JSON, or queries a database? How does that make it easier to deduce what a function does by "looking only at type signature"? > Another feature of a pure functional programming paradigm is higher-order functions, which are functions that take functions as parameters. As in: available in almost any language these days, and not exclusive to a "pure functional programming paradigm". > One of the common development workflows we employ is relies on a tool called ghcid, a simple command line tool that relies on the Haskell repl to automatically watch code for changes and incrementally recompile. This allows us to see any compiler errors in our code immediately after saving changes to a file. It’s not uncommon for us to open only a terminal with a text editor and ghcid while developing applications in Haskell. As in: Modern IDEs don't require you to run external tools to monitor your code for changes and highlight errors. > a common refactoring workflow is to make a desired change in one location and then fix one compiler error at a time until the program compiles again. As in: Modern IDEs let you do large-scale refactoring in one go, at a press of a button. > The type system can protect us from making mistakes when changing the rules of our domain. It can't. The example provided can't stop you from doing `case status of Paid -> delete invoiceNumber`. You have to invest significantly in a type-based DSL to prevent that from happening. But then, who will test your DSL? > Haskell enables domain-specific languages, which foster expressiveness and reduce boilerplate DSLs where all the rage 5-10 years ago. In reality, they are overhyped and are used very sparingly, for obvious reasons: DSLs are languages. They have to be designed, developed, maintained. Errors in your DSL will most likely harder to find and debug than in your regular program.

IfOnlyYouKnew 6y ago

No, sorry, it has very little to do with technology. There's at least a dozen languages you could have chosen, and that others have chosen for any given use case. within some bounds, it makes very little difference.[0] The reason you've chosen Haskell and, by the way, also the TLD ".system", is that you've constructed your identity in such a way that "advanced language with a steep learning curve" is something that fits. There's absolutely nothing wrong with that. It's a bit emotional, but those exist for a reason. If you consider that idea libellous, you can always cite PR motives for plausible deniability and point at this HN story as evidence. [0]: Elm, by the way, strikes me as borderline with regards to the bounds of reasonableness, considering the state that community is in. As such, it's more evidence your left (right?) metaphorical hemisphere may have had a finger on the scale.

FlyingSnake 6y ago
> The reason you've chosen Haskell and, by the way, also the TLD ".system", is that you've constructed your identity in such a way that "advanced language with a steep learning curve" is something that fits. I think you're projecting too much on them. They found Haskell performant and are promoting it, I don't see any problem with it. How is any different from all the Rust evangelism HN sees all the time?
- oblio 6y ago
  I think his point is that there are N languages that are performant and they could have probably chosen any of them to achieve their goal, so the choice is primarily aesthetic.
  - thedmstdmstdmst 6y ago
    The article doesn't say they have exhausted all languages, just that it is their first choice. Not their only choice but first choice.
- IfOnlyYouKnew 6y ago
  I really don't have a problem with their choice–I wasn't being ironic. It's perfectly acceptable to make "I like it" or "it works for us" choices. I do believe, very very mildly, that there's a strain of thinking among the tech crowd that glorifies this Spock-like emotional detachment and I'm-so-rational mindset. Two issues, actually: First, such a mindset is neither possible nor would do much good. There are stroke victims that survive with full mental capabilities with regards to logical reasoning but entirely devoid of emotions. These patients can still ace the SAT, but they fail spectacularly at daily life. As it turns out, you just cannot decide on a doctor's appointment without emotions. They'll spent hours vacillating between two good choices. Emotions are incredibly well-tuned heuristics that cut down your mental load to manageable levels. As any part of being human, they are sometimes ill-fitting for modern times: there's absolutely no reason to make me flinch when I spill hot coffee over my hand. But mostly they just work. Second, it's slightly annoying when people deny that they are subject to emotions, and it gets up to Ryanair-levels of discomfort when they announce that it makes them superior to all those emotional social science majors, illogical politicians, women "throwing a fit", superficial designers etc. If I got a KDE theme every time someone accused Apple users of being blinded by eye candy, I'd still be left with only half of what Kubuntu ships. But Rust is cool.

fegu 6y ago

If you want to get a feel of the productivity using Haskell in production start with a simple CRUD app and use IHP (https://ihp.digitallyinduced.com/ https://ihp.digitallyinduced.com/) to build it. You will have something usable within a day - GUI and all. Then move further down the rabbit hole from there.

kreetx 6y ago
How about servant, and some popular js framework on top of that? IHP might be putting a lot of effort into the project, but the code generation part... I (personally) don't like that at all. And it's not common practice in haskell.
- hardwaresofton 6y ago
  Second this -- Servant is one of the best examples of server-side haskell there is, and from what I understand IHP is relatively new in comparison (correct me if I'm wrong). Servant is one of the best if not the best example of how haskell's higher level abstractions can benefit practical bread and butter programming (which making APIs is these days) tasks, and where type safety is a huge benefit. Writing servant handlers can also feel mostly imperative depending on how much you use `do`.
- _query 6y ago
  IHP is very opinionated in the way how it approaches building web applications (Code Gen, Project structure, Naming, ..). But exactly this kind of opinionated design makes it possible to be very productive, compared to doing everything yourselves.
  - kreetx 6y ago
    IHP is opinionated in the sense that it does state on the server side and uses (something similar to) turbolinks to make it look fast. But generating additional types for SomeDataType like ViewSomeDataType etc - my gut feeling tells me these should be implemented trough type classes instead. New data types shouldn't be generated for cases like this. Disclaimer: I've only looked at the docs of IHP, but this was what it looked like it was doing.

gregorygoc 6y ago

I think most programmers nowadays face no interesting problems to solve. They crave for a mental challenge, but instead of looking for a job that requires solving hard engineering problems, they believe they can satisfy their mental needs with coding in “somewhat” hard language.

deleted 6y ago
[deleted]
Tade0 6y ago
As a front-end developer whose job is is to write configurations(so not even actual code) for a form library I picked up Rust for this specific reason. Could've been any other language, but this one scratches my personal itch.
dbattaglia 6y ago
I think you make a valid point in general about coding professionally at most jobs, and I know I've fallen into this desire myself while working on endless CRUD apps over the years. That said, I do think the article brings up some good points about domain modeling. After becoming somewhat proficient in Scala I've found these same features (ADTs) mentioned in the article helpful for the important part of these boring CRUD apps: modeling data at the various application boundaries (API, domain layer, database layer, etc). I now find using weaker type systems and/or imperative code to be either more error prone or more verbose (due to validation + extra tests). Of course there are other parts of Scala, Haskell and similar that require more mental gymnastics than I'd like, such as composing asynchronous operations; flatMap and monad transformers may be "elegant" once you really understand them but damn is async/await easier to just write and move on with your life.

kensai 6y ago

Has anyone had a look or knows of production systems made with a Haskell-like language named Curry? (https://curry-lang.org/ https://curry-lang.org/) Sounds a lot like Haskell with Prolog... “ Curry is a declarative multi-paradigm programming language which combines in a seamless way features from functional programming (nested expressions, higher-order functions, strong typing, lazy evaluation) and logic programming (non-determinism, built-in search, free variables, partial data structures). Compared to the single programming paradigms, Curry provides additional features, like optimal evaluation for logic-oriented computations and flexible, non-deterministic pattern matching with user-defined functions.”

tome 6y ago
Tangentially, did you actually manage to make an HTTPS connection to that site? I can only manage HTTP.
chriswarbo 6y ago
I've played with it, using the kics2 implementation. I made a rough package for Nix, which might be useful if you have problems installing it: http://chriswarbo.net/git/warbo-packages/git/branches/master/packages/kics2.nix.raw.html http://chriswarbo.net/git/warbo-packages/git/branches/master... You might like the Mercury language too: https://mercurylang.org/ https://mercurylang.org/
iso8859-1 6y ago
You can already have Prolog embedded in Haskell, using LogicT. Here is the paper by Kiselyov: http://okmij.org/ftp/papers/LogicT.pdf http://okmij.org/ftp/papers/LogicT.pdf

thedonkeycometh 6y ago

tldr; We love Haskell, that's why.

unnouinceput 6y ago

Quote: "GHC, the most commonly used Haskell compiler, produces extremely fast executables, especially when compared against other languages commonly used for application development, such as PHP or Python" Really? You comparing apples with oranges? Why not, if you're at the step of comparing compiled versus interpreted languages, compare it with Java too? Now, do the same comparison versus C++, let's see who wins when talking about speed.

johndoe42377 6y ago

Unfortunately, the Haskell ecosystem has been ruined (well, almost) by unnecessary, redundant abstractions and narcissistic idiots who pushes them. I recently tried to compile haskell-language-server and stack from sources. 157 and 168 (or something) dependencies, full of redundant esoteric bullshit, compat packages, lifted crap, etc. It is even worse than J2EE where it was the same redundant wrapping and indirection, but brain-dead straightforward verbose crap. To use Haskell correctly, like the classic xmonad and similar projects, requires discipline, knowledge and good taste for just right abstractions, like Go stdlib or Scala3 standard library. Yes, it doubles development time, which must be spent on understanding anyway, but fast food fp code, full of redundant abstractions, is a worst nightmare to maintain.

hardwaresofton 6y ago
This article might be a bit overeager and overzealous, but how you use haskell is up to you -- don't use those underlying packages that disgust you if you don't like them. Haskell offers benefit at every level of abstraction. There are many ways to write Haskell and you do not need a bunch of the higher level stuff. 99% of the time you are just fine with the data modeling (simple Algebraic Data Types) and type classes, along with a cursory understanding of monads via "do" notation. This comment reads like someone seeing the worst of J2EE, and going back to C++. I'd characterize haskell as having the type system that Java wishes it did. Why are you trying to judge how haskell should be written for your use case by looking at haskell-language-server, stack, and xmonad? Those are the domains of haskell experts -- one is a language server, the other is one of the pre-eminent build tools, and the other is tiling manager.... Are any of those your use-case? There are real problems with haskell, and forcing you into complexity is not one of them -- a steep learning curve (for certain concepts), hard to debug space leaks, and a relatively small ecosystem are the biggest issues.
- throwaway894345 6y ago
  > how you use haskell is up to you -- don't use those underlying packages that disgust you if you don't like them These kinds of arguments are particularly lazy. Of course, Haskell's ecosystem is not so large that it's trivial to find a well-maintained, high-quality version of a library that meets one's other criteria. Programmers of a particular language are at the mercy of that language's ecosystem. This line of reasoning reminds me of how C++ programmers would deflect criticisms of problematic features by arguing that one could use only the features that one wanted (thereby effectually creating or curating their own sub-language) and only choosing dependencies that were equally written in that sub-language. So easy!

fooyc 6y ago

Sounds like "Haskell is cool because it is typed, and it is the only typed language I know"

wombat23 6y ago

What I'd like to understand: When/why does one choose Haskell over other functional languages e.g. F# or OCaml? It looks to me like they would satisfy the same points that the article makes. Edit: just did a quick comparison of the last 2 SO developer surveys, and it looks like Haskell "replaced" F# in their popularity ranking last year.

nudpiedo 6y ago
all them are equally competent languages. F# with corporative support and a giant ecosysten, ocaml being very fast and portable and haskell being very... special and pure.
- wombat23 6y ago
  Thanks for your reply! I see the corporate aspect of F#, but can you elaborate on what you mean by "special" about Haskell?
chriswarbo 6y ago
Haskell's laziness and purity can make it a bit trickier to use constructs that are common in ML-like (or Scheme-like) languages, like mutable variables. This nudges Haskell libraries in a slightly different direction, e.g. making more use of control structures like monads, arrows, continuations, etc. which authors in other languages wouldn't reach for so readily. This has an effect on the ecosystem, since people want their systems and libraries to be compatible with each other's APIs. The result is that "the Haskell way" can seem a little more intimidating than the more "pragmatic" approach of MLs. (I write this as someone who writes a lot of Haskell, and dabbles in StandardML!)

fooyc 6y ago

> Haskell programs have stellar performance, leading to faster applications and lower hardware costs [...] PHP $244 [...] Haskell $15 This is overlooking the cost of developers, which greatly outweights the hardware's unless you are Facebook.

vp8989 6y ago
No it isn't, it's a simple matter of fact statement that running code on runtime A appeared to be cheaper in terms of hardware costs than runtime B. The "overlooking" part you filled in yourself in bad faith and bad reading comprehension, as the author actually does acknowledge that the observed hardware savings are small compared to the cost of hiring programmers.

hardwaresofton 6y ago

Haskell is an excellent language, and you are free to choose not to drown yourself in the most complex uses of it. Haskell has the type system Java wishes it did, and half of the reason languages like Rust are interesting is because they've learned from Haskell (which is the point of Haskell, a research langage, though it happens to also be a pretty darn good language for building practical things). Simple basic data types like `Maybe t` and `Either l r` are such a revelation that you wonder how you lived without them. I've shared this anecdote before, but Option<T> in Java is an example of the blub paradox[0], and discovering Haskell and finding out about Algebraic Data Types (ADTs) and the Maybe type cured my blub. The crux was this: Option<T>s seems to "infect" any codebase you use it on, because you realize that anything can fail and be null -- living in java land made it seem like it was out of place it's actually Option<T> that is right -- if you allow nullable types in your code base, or you do operations that can fail, properly representing that failure is the right decision. Without over stating some of the best features of Haskell are: - Compile time type checking (this cannot be understated) and non-nullable types - Expressive and simple data type creation via `data`, `type` - An excellent system for attaching functionality and composing functionality to data types via `typeclass`es and `Constraint`s. - An emphasis on errors as values (unfortunately exceptions are in the language too, but you can't really stop them from existing) - Forced delineation between code with side-effects and code without (this results in some complexity if you come from a world with side-effects everywhere and no control) - Fantastic runtime system with good support for concurrency, parallelism and shared memory management. - Very easy refactoring (if you're not adding any complexity/abstraction) because you can just change what you want and let the compiler guide you the rest of the way. Haskell has it's warts (hard to debug space leaks, relatively small ecosystem, the ability to drown yourself and your team in abstraction), but it's just about the most production-ready research language I've seen. Whether or not you like it, the likelihood it's already improved your life in whatever language you're using is very high.

Twisol 6y ago
You dropped this: [0] http://paulgraham.com/avg.html http://paulgraham.com/avg.html (Scroll to "The Blub Paradox", about a third of the way down.)

Kototama 6y ago

Biggest problem I had with Haskell was once you know the language you also need to learn a pile of extensions that any serious project is using. Also there is a tendency in the community to always look for the "best" (abstract) solution. It makes the whole ecosystem fast changing. I would prefer a more stable platform designed for engineers , something like Clojure but with types. Ocaml has a small community and Scala brings unnecessary complexity with its support for OOP.

bsenftner 6y ago

I'm at a technology research company that is primarily using C++ as the main company tool. The development team is small, and the code is the result of 22 years of constant revision by PhDs. One of our Never To Be Violated Rules, simply because the number of hidden landmines is far to numerous, is template programming. When generic programming is required we use a web language like PHP where the type of something is contextual and one can be free and loose and sloppy if they want. Between the two extremes of our formal as fuck C++ base and the anything goes generic web languages we maintain surprisingly high levels of productivity, with very low bug counts. Having a tiny team helps, as we all know the code based inside out.

aardvark1 6y ago

This company looks to be a team of three (probably very smart) engineers who build cool custom software for likely relatively small clients. The software is likely only supported and modified by them. In that scenario something like Haskell makes sense - however once you need to scale your engineering footprint beyond 5-10 people it becomes virtually impossible to rationalize using a niche language like Haskell.

sesuximo 6y ago
Also unclear how long they’ve been doing this... I’m unable to find any info about provide projects other than very high level blog style stuff
ivanbakel 6y ago
What is that claim based on? Plenty of companies use Haskell to great success scaling to well beyond 10 people. It may be a niche language, but in a remote-working world, and with a truly massive number of developers in the workforce, there still end up being a sizeable number of professional Haskell developers available to most companies.

StreamBright 6y ago

Most of these apply to F#. The only difference that there are much more libraries available for that ecosystem than to Haskell’s.

jjice 6y ago

Haskell seems extremely neat, and I do like the ML family for compiler development, but Haskell just seems like such a steep learning curve. The amount of operators I've seen boggles my mind, are they user defined? Is there a good way to learn Haskell that preferably skips over some common functional concepts?

lallysingh 6y ago
I'll put the learning curve around the same level as C++, with the qualifier that most of what you learn aren't parts of the language, but patterns and formalisms you can use in any language.

elephantum 6y ago

It seems like you can substitute Haskell to Rust in almost every point they make. (Or with many other great options)

adamch 6y ago
Yes, this was my immediate thought too. I love writing Haskell, but Rust has become my daily driver, both at work (Cloudflare) and personal projects. It gives me the excellent type system, better domain modelling, great ecosystem (serde, actix-web, rayon, reqwest, diesel, tokio) and performance. I've basically traded away some nice abstractions (functors, monoids etc) for the ability to debug error messages more easily, and not have to convince people to learn/support an obscure language. Good deal IMO.

Areading314 6y ago

It is absolute nonsense to say that using Haskell will improve productivity or maintainability. There are problems like bad libraries, complicated performance profiles, virtually no developer adoption, limited ghc build targets, package management, lack of tooling, slow compile times. Choosing Haskell is likely a terrible choice despite the type system, which seems to be its only advantage.

darksaints 6y ago

Okay, so this is admittedly snarky but we've seen this sort of blog post so much that it has practically become an Onion article: Why Haskell Is Our Secret Weapon, by Startup You've Never Heard Of. And then when someone points out that nobody knows who they are or what they've built, we get commenters talking about how company X, Y, and Z are also using Haskell. And those claims also come up short...most of them can't say where or how it is being used because they don't know...just that at some point in the past, someone emails were exchanged between someone@bignamecompany.com and someone@haskell.org, and now there is a piece of copy on the Haskell website that disingenuously claims BigNameCompany is powered by Haskell!. Who cares how pervasivly it is used...if someone writes a config parser with Haskell, all of a sudden we can claim that BigNameCompany would fall over on its face if Haskell wasn't there protecting it. Come on. Nobody cares that Haskell is your secret weapon if you've never overcome an opponent with it. Or built an entire profitable company on its back. All these types of posts do is fake an authority so you can jump straight to your fallacious argument by authority. If you want to argue the merits of your favorite language, then do it. Don't make us sit through an argument about how your language makes you special when you aren't even noteworthy enough for a 10 sentence Wikipedia blurb. There are a lot of valid and powerful technical arguments in this article, but they're ruined by framing them all around the premise that we care about how it makes you and your startup special.

andai 6y ago
I don't think the article warrants such a harsh reaction. Was it the word "our" in the title? They're just writing from their perspective.
warcher 6y ago
I'm not really a haskell fan, but the lion's share of that effect more that likely comes from the small sample size of companies using haskell. Even if it were somehow superior, there just are enough people trying it to be coming up with a unicorn startup or two. Now, the lack of skilled haskell programmers on the other hand, that's a pretty scary proposition if you're starting a company and may find yourself riding on a rocket, needing as many able hands as you can possibly find.
6y ago

waterheater 6y ago

According to a friend who worked there, Kitty Hawk's flying car flight controller is written in Haskell. Gotta love those MIT researchers.

Geminidog 6y ago

Haskell does not actually get rid of side effects in practice. I find that tons of Haskell code involves do notation which is basically code that embraces monadic side effects which sort of defeats the purpose that this article says of pushing side effects to the edge. Really in order to “push side effect to the edge” people need to avoid using monadic composition as much as possible which I see Haskell programmers rarely doing in practice.

willtim 6y ago
Monadic composition is used everywhere from simple failure (Maybe or Either) through to genuine side effects such as IO. The presence of monads does not necessarily mean side effects. Haskell never claimed to "get rid of side effects", the idea is make them explicit in the types and to be able to reason about them.
- Geminidog 6y ago
  Right, but the article says that Haskell pushes these side effects to the edge. I am not saying haskell claims this, I'm saying the article claims this. Haskell actually doesn't do this in practice as tons of people use do notation and state monads. The more people use do notation, the more they are embracing side effects. Literally I've seen haskell code where all function definitions had some form of do notation which is basically against the claim made by this article. To push side effects to the edge you have to only use do notation and monads when you absolutely have no choice, which is not done in practice with haskell. >The presence of monads does not necessarily mean side effects The presence of a functor does not mean side effects. The presence of a monad implies composition and binding which does imply a side effect. Even maybe monads composed have side effects that can produce output that the function itself can never produce on it's own. For example let's say I have a maybe monad that will never produce "Nothing." b :: int -> Maybe Int b x = Just x but I can produce a side effect by binding it with Nothing. Nothing >>= b The above yields "Nothing," even though it is not part of the definition of b. It is a contextual side effect passed on through monadic composition. Normal composition outside of monadic composition usually does not have this property.

revskill 6y ago

I spent 1 year to focus on learning Haskell. It's a brain-hacking language, too hard to master. But in the end, i've got some nice basics on doing functional programming the right way. Immutability, composable abstraction lies in the heart of a maintainable software i'll produce.

FlyingSnake 6y ago

I simply don't get the hate this article is getting, are some HN readers really that bad at reading comprehension? The authors clearly mention it is "our first choice" and then they go on to present their findings with great clarity. Nowhere do they evangelize Haskell like other language like Rust for example. I never see such comments on threads on other languages, even though some of articles posted are of subpar quality. In the end the insecurities and failures of snarky commentators don't matter to others who are in the arena solving real problems in production with an unsexy language.

ezoe 6y ago

There is a serious risk using a programming language that is too different from majority of languages. Like Haskell, Erlang, Lisp variants. It requires a lot of effort to learn, development tools are scarce, and you can't easily hire a new worker simply because it's minor. Eventually, original developer left the company for one way or other, leaving a code and half baked documents only the early developer fully understand. Good luck maintaining those software. You can't. It's either abandoned or replaced.