At Channable, we have had a great experience introducing Haskell for our infrastructure projects. We have written a few blog posts about this which you can find on our tech blog[1].
- Jobmachine, an advanced job-scheduling system with dynamic dependency resolution[2]
- Vaultenv, a small open-source tool to get secrets from Hashicorp vault[3][4]
- alfred-margaret, a blazingly-fast Aho-Corasick implementation written in Haskell[5][6]
- Sharkmachine, our in-house replacement for Apache Spark[7]
It's amazing it's done in Haskell. I never knew this. I used it couple of times to convert docs. I also installed it many times with the gem bundler system for my rails, middleman app projects.
I work for a small data science consulting company whose major components of a machine learning pipeline were written in haskell. The company got bought by a large corporate and shortly after, all the haskell developers left, leaving a handful of people (including myself) who didn't know how to use or maintain the major components of a multi million dollar acquisition. It is in the process of being scrapped and replaced with a more typical software stack.
I bet you the new stack will have more bugs and be significantly more complex and harder to maintain. But you will find tons and tons of developers willing to continuously add technical debt to it.
While this is certainly a legitimate concern, we should also consider how much of that multi-million dollar value derived from the use of Haskell up to that point. Put another way, had a "more typical software stack" been used originally, would the acquired business still have achieved the same things and been as attractive for acquisition?
Why don't they hire Haskell developers to replace the ones who are leaving? If your company's Java developers were leaving, they'd be ridiculed for deciding to rewrite the codebase. Is it really that hard to hire Haskell developers?
Just curious, what was the reason that Haskell developer left?
I know 1 company where this happened, but there Haskell developers left because management decided to move to python (without them even knowing its under consideration).
I've seen this happen with Perl and Ruby (both replaced with Python). Being able to replace workers is not an insignificant business risk. A small company outside of a major tech hub just can't support the development of software in nonstandard languages. I love Haskell, but I couldn't tell my boss that we should invest time in learning yet another technology to train people in just because its my favorite language.
There is a growing number of stories in the wild of companies who were burned for using Haskell. Common patterns of struggle are emerging. You aren't reading about them because people aren't eager to share their failures with the world, just yet. Proceed with caution, especially in the startup realm.
As a counterpoint - at CircuitHub, we migrated from NodeJS / Angular to Haskell / Elm and couldn't be happier.
I think a core reason for our success is that we built our team from experienced developers that had built large applications in other languages. Then arrived at Haskell as a better solution.
I have heard some negative experiences that I would attribute to a few different factors.
1. Lack of Haskell experience in the early team.
2. Lack of experience building large real-world applications (too academic)
3. The startup/group didn't achieve product-market fit, and Haskell was scapegoated.
None of these problems are Haskell specific, just run of the mill team issues.
That's an intruiging comment. I can understand why you can't name specific companies but it would be interesteing to hear something about these common patterns of struggle.
That probably means Haskell is becoming more popular. Most software projects and businesses, after all, fail.
I wouldn't advice against Haskell. But I would advice against having a business with more than one non-boring component. And usually that non-boring component should be the solution to the client problem, not the tech stack used to implement it.
If you start a business in a language stack none of the devs have done large scale production projects, you are basically begging for a world of trouble. If the devs are familiar with Haskell, I don't see any problem with choosing it, if it matches the problem domain. I wouldn't choose it for example for frontend development (although I suppose you can get it compiling there) or things where C, C++ or Fortran still have a strong legitimate foothold.
I considered Hasura but went with postgraphile (https://github.com/graphile/postgraphile) because it's written in JavaScript with a plugin architecture, meaning I can easily add my own plugins into the system down the road. Creating a JavaScript plugin sounds much less daunting that looking into a mature Haskell codebase.
I also came to comment on Hasura. Without having looked into the code I can’t really comment on the quality, but certainly from the outside it’s rock solid.
For me, one of the biggest non-starters is a slow compiler, or rather a compiler that doesn't scale well. When people talk about how smart their type system or their compiler is, it immediately rings alarm bells for me.
This is one of the things that you may only learn the hard way, as your project grows in complexity. Nobody advertises how slow their compiler is.
So, my question is, how does GHC fare these days? How does it treat people that switched from a dynamic language, who are used to quick iteration?
I think quick iteration and feedback is one of Haskell's strong points :)
It has been argued before, in a fascinating but admittedly flawed experiment for the Naval Surface Warfare Center (US Navy) [1], that Haskell is a great prototyping language. This experiment is flawed for multiple reasons which the authors readily admit (e.g. the results from all contestants were self-reported, the requirements were vague [2], no code was actually run by the panel of judges, etc), but it's still tremendously interesting. It's also amusing that the judges couldn't believe the Haskell program was a working and complete implementation of the system, and thought it was either pseudocode or "too clever" for its own good (because of the use of higher-order functions)!
[2] though one could argue vague requirements are actually another point in favor of Haskell as a rapid prototyping language. It's often argued -- mistakenly -- that languages with static typing are not good for exploratory coding, which this experiment tends to show not to be true.
For quick iterations, you have ghci. You just edit your files, type :r and it will recompile only necessary files, which is really quick (and I miss it in most other REPLs). Similar with incremental compilation. But if you need to compile huge project always from scratch, of course, you will suffer.
There have been work on making haskell to have deterministic build to speed up compile time, and compare to scala, I find it way faster (in my current company, we use scala). But note that if you start using stuff like template haskell, your compilation will slow down.
It doesn't feel slow to me (compared to for example C++ compilation) and you can iterate quickly using cabal repl (:r) or ghcid[1] which both support partial recompilation of changed files.
Quick iteration means quick feedback and that is a major success-factor for software projects I believe. The purpose of compiler is to give you feedback about what you're doing wrong, but if that feedback is slow then it loses much of its value. Goal is to guide the programmer, not stop them.
While there are benefits of learning Haskell as a developer. I am curious about the professional benefits versus the time and effort required to master the language to the extent that you are employable and command a good salary compared to just focusing on mainstream languages where you probably have a lot more competition but also a lot more opportunities.
I have been looking around for Haskell jobs for a while because I would love to program in Haskell professionally, and what I've noticed that there are very few opportunities and the salaries are quite low.
You can expect to make much more as a Scala programmer, for instance.
The effort of learning Scala vs Haskell as at a professional level would be more or less equal.
To be fair, most asked questions about Haskell that people always have is if Haskell is so good and not just purely for academics then where is Haskell used in industry? Or is there really huge and complex software projects written in Haskell?
Let's talk in things that are more tangible. Haskell attempts to answer the question: "In the set of all possible programs that can be written to solve a certain problem domain how do I find the program that has the best modularity, best design and best safety?"
You would think that to answer the question above you would need a really expressive language. Haskell is a language that is actually less expressive and more restrictive than mainstream programming languages. You can be much more expressive in JAVA, C, C++, python, javascript and python then you can in haskell. For one you can mutate variables and re-assign them in mainstream languages and you can also have Loops. These things don't exist in Haskell.
Sounds really bad right? In actuality this is what makes haskell so powerful. Haskell is restricting the programmer to only be able to create a program that is much, much closer to answering the question above. The best design and the best modularity sort of exist has nebulous and instinctive concepts in most programmers. With haskell this concept comes closer to concreteness because Haskell simply doesn't allow you to write certain programs that are poorly designed or incorrect.
My first experience writing a non trivial haskell program was astonishing. Normally I program a little and test a little, then continuously add complexity to my programs through this iterative process of coding a little and testing a little.
With haskell I coded the entire program. Once it compiled it worked. No testing needed. I asked myself what was it that allowed me to do this in haskell? The answer was that it was because haskell prevented me from writing more programs that were incorrect. Errors and mistakes you would normally have to test for in other language can't even be compiled in Haskell. Nothing can totally eliminate testing but with haskell you can eliminate a huge portion of testing. So much so that programmers in haskell spend more time trying to get a program to compile than trying to test.
This power extends to refactoring. Most projects out there have problem domains that aren't fully defined and thus require refactoring changes in the future to better fit the problem domain. It's an inevitability. It often happens that such refactorings require massive and dangerous changes to code that has already accumulated immense complexity.
A common problem like this becomes trivial in haskell. Haskell forces your code to be modular so that such changes happen easily. The type system also ensures that if you do a change that is incorrect the compiler will catch it.
From a less tangible standpoint haskell also feels right. When you design things in other programming languages you're not sure where to cut your modules and how to correctly divide responsibility of your code and of course your mistakes become apparent over time. Haskell doesn't feel this way. It feels like the right approach to design and building primitives that snap together like legos. Over time this feeling will coalesce into understanding. You will completely understand why haskell programs are better designed then programs written in other languages.
I never mentioned performance. Although Haskell is very performant, haskell isn't suppose to answer the question of performance AND design (that's more rust) haskell just addresses design and safety. Additionally, it's not just haskell that has these qualities. It's actually the whole family of functional ML languages that haskell comes from that utilize Algebraic Data types and functional programming. You can achieve sort of the same philosophy I describe here by using something like Ocaml or Elm.
Also don't let the fact that haskell isn't mainstream put you off. Although it's not as practical, learning it is like taking the red pill. You'll never be the same.
[+] [-] rkrzr|6 years ago|reply
- Jobmachine, an advanced job-scheduling system with dynamic dependency resolution[2]
- Vaultenv, a small open-source tool to get secrets from Hashicorp vault[3][4]
- alfred-margaret, a blazingly-fast Aho-Corasick implementation written in Haskell[5][6]
- Sharkmachine, our in-house replacement for Apache Spark[7]
[1]: https://tech.channable.com/
[2]: https://tech.channable.com/posts/2017-02-24-how-we-secretly-...
[3]: https://tech.channable.com/posts/2017-07-06-introducing-vaul...
[4]: https://github.com/channable/vaultenv
[5]: https://tech.channable.com/posts/2019-03-13-how-we-made-hask...
[6]: https://github.com/channable/alfred-margaret
[7]: https://tech.channable.com/posts/2019-10-04-why-we-decided-t...
[+] [-] silvester23|6 years ago|reply
We are currently in the process of building something similar and it would have been interesting to see your approach in more detail.
[+] [-] RcouF1uZ4gsC|6 years ago|reply
https://pandoc.org/
Pandoc is an amazing piece of software that can convert between all kinds of document formats.
[+] [-] meerita|6 years ago|reply
[+] [-] dcl|6 years ago|reply
I work for a small data science consulting company whose major components of a machine learning pipeline were written in haskell. The company got bought by a large corporate and shortly after, all the haskell developers left, leaving a handful of people (including myself) who didn't know how to use or maintain the major components of a multi million dollar acquisition. It is in the process of being scrapped and replaced with a more typical software stack.
Hilarious times.
[+] [-] atopuzov|6 years ago|reply
[+] [-] baot|6 years ago|reply
[+] [-] moomin|6 years ago|reply
[+] [-] crimsonalucard|6 years ago|reply
[+] [-] Silhouette|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] rowanG077|6 years ago|reply
[+] [-] nicoburns|6 years ago|reply
[+] [-] mic47|6 years ago|reply
I know 1 company where this happened, but there Haskell developers left because management decided to move to python (without them even knowing its under consideration).
[+] [-] c3534l|6 years ago|reply
[+] [-] Dowwie|6 years ago|reply
[+] [-] seddona|6 years ago|reply
I think a core reason for our success is that we built our team from experienced developers that had built large applications in other languages. Then arrived at Haskell as a better solution.
I have heard some negative experiences that I would attribute to a few different factors.
1. Lack of Haskell experience in the early team. 2. Lack of experience building large real-world applications (too academic) 3. The startup/group didn't achieve product-market fit, and Haskell was scapegoated.
None of these problems are Haskell specific, just run of the mill team issues.
[+] [-] unhammer|6 years ago|reply
That said, anyone know of a writeup / "post-mortem" of such a failure?
[+] [-] padraic7a|6 years ago|reply
[+] [-] goto11|6 years ago|reply
[+] [-] Discombulator|6 years ago|reply
[+] [-] IAmEveryone|6 years ago|reply
[+] [-] fsloth|6 years ago|reply
I wouldn't advice against Haskell. But I would advice against having a business with more than one non-boring component. And usually that non-boring component should be the solution to the client problem, not the tech stack used to implement it.
If you start a business in a language stack none of the devs have done large scale production projects, you are basically begging for a world of trouble. If the devs are familiar with Haskell, I don't see any problem with choosing it, if it matches the problem domain. I wouldn't choose it for example for frontend development (although I suppose you can get it compiling there) or things where C, C++ or Fortran still have a strong legitimate foothold.
[+] [-] misja|6 years ago|reply
[+] [-] the_af|6 years ago|reply
[+] [-] Quekid5|6 years ago|reply
"What can be asserted without evidence can also be dismissed without evidence." (Christopher Hitchens)
[+] [-] unhammer|6 years ago|reply
- https://postgrest.org/
- https://www.shellcheck.net/
- https://xmonad.org/
- https://www.costarastrology.com/
[+] [-] atc|6 years ago|reply
[deleted]
[+] [-] devxpy|6 years ago|reply
[+] [-] markhalonen|6 years ago|reply
[+] [-] aidos|6 years ago|reply
[+] [-] Ezku|6 years ago|reply
[+] [-] ronanyeah|6 years ago|reply
[+] [-] gridlockd|6 years ago|reply
This is one of the things that you may only learn the hard way, as your project grows in complexity. Nobody advertises how slow their compiler is.
So, my question is, how does GHC fare these days? How does it treat people that switched from a dynamic language, who are used to quick iteration?
[+] [-] the_af|6 years ago|reply
It has been argued before, in a fascinating but admittedly flawed experiment for the Naval Surface Warfare Center (US Navy) [1], that Haskell is a great prototyping language. This experiment is flawed for multiple reasons which the authors readily admit (e.g. the results from all contestants were self-reported, the requirements were vague [2], no code was actually run by the panel of judges, etc), but it's still tremendously interesting. It's also amusing that the judges couldn't believe the Haskell program was a working and complete implementation of the system, and thought it was either pseudocode or "too clever" for its own good (because of the use of higher-order functions)!
[1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.368...
[2] though one could argue vague requirements are actually another point in favor of Haskell as a rapid prototyping language. It's often argued -- mistakenly -- that languages with static typing are not good for exploratory coding, which this experiment tends to show not to be true.
[+] [-] mic47|6 years ago|reply
There have been work on making haskell to have deterministic build to speed up compile time, and compare to scala, I find it way faster (in my current company, we use scala). But note that if you start using stuff like template haskell, your compilation will slow down.
[+] [-] flowless|6 years ago|reply
[1] https://github.com/ndmitchell/ghcid
[+] [-] galaxyLogic|6 years ago|reply
[+] [-] ar7hur|6 years ago|reply
[+] [-] jraph|6 years ago|reply
Come on. Why picking a girl specifically?
[+] [-] samtechie|6 years ago|reply
[+] [-] misja|6 years ago|reply
The effort of learning Scala vs Haskell as at a professional level would be more or less equal.
[+] [-] _pmf_|6 years ago|reply
[+] [-] UserIsUnused|6 years ago|reply
[+] [-] KibbutzDalia|6 years ago|reply
[+] [-] ardfard|6 years ago|reply
[+] [-] clSTophEjUdRanu|6 years ago|reply
[+] [-] marcosdumay|6 years ago|reply
[+] [-] gridlockd|6 years ago|reply
[+] [-] crimsonalucard|6 years ago|reply
You would think that to answer the question above you would need a really expressive language. Haskell is a language that is actually less expressive and more restrictive than mainstream programming languages. You can be much more expressive in JAVA, C, C++, python, javascript and python then you can in haskell. For one you can mutate variables and re-assign them in mainstream languages and you can also have Loops. These things don't exist in Haskell.
Sounds really bad right? In actuality this is what makes haskell so powerful. Haskell is restricting the programmer to only be able to create a program that is much, much closer to answering the question above. The best design and the best modularity sort of exist has nebulous and instinctive concepts in most programmers. With haskell this concept comes closer to concreteness because Haskell simply doesn't allow you to write certain programs that are poorly designed or incorrect.
My first experience writing a non trivial haskell program was astonishing. Normally I program a little and test a little, then continuously add complexity to my programs through this iterative process of coding a little and testing a little.
With haskell I coded the entire program. Once it compiled it worked. No testing needed. I asked myself what was it that allowed me to do this in haskell? The answer was that it was because haskell prevented me from writing more programs that were incorrect. Errors and mistakes you would normally have to test for in other language can't even be compiled in Haskell. Nothing can totally eliminate testing but with haskell you can eliminate a huge portion of testing. So much so that programmers in haskell spend more time trying to get a program to compile than trying to test.
This power extends to refactoring. Most projects out there have problem domains that aren't fully defined and thus require refactoring changes in the future to better fit the problem domain. It's an inevitability. It often happens that such refactorings require massive and dangerous changes to code that has already accumulated immense complexity.
A common problem like this becomes trivial in haskell. Haskell forces your code to be modular so that such changes happen easily. The type system also ensures that if you do a change that is incorrect the compiler will catch it.
From a less tangible standpoint haskell also feels right. When you design things in other programming languages you're not sure where to cut your modules and how to correctly divide responsibility of your code and of course your mistakes become apparent over time. Haskell doesn't feel this way. It feels like the right approach to design and building primitives that snap together like legos. Over time this feeling will coalesce into understanding. You will completely understand why haskell programs are better designed then programs written in other languages.
I never mentioned performance. Although Haskell is very performant, haskell isn't suppose to answer the question of performance AND design (that's more rust) haskell just addresses design and safety. Additionally, it's not just haskell that has these qualities. It's actually the whole family of functional ML languages that haskell comes from that utilize Algebraic Data types and functional programming. You can achieve sort of the same philosophy I describe here by using something like Ocaml or Elm.
Also don't let the fact that haskell isn't mainstream put you off. Although it's not as practical, learning it is like taking the red pill. You'll never be the same.