I worked on this project for a week during the FB team matching process.
I had previous Haskell experience, but what struck me was how irrelevant that was.
To their immense credit, they had managed to use Haskell to write an entirely entreprise focused, "boring" business rule backend serving millions of QPS, and people who were not Haskell fans could easily use its sensible DSL to accomplish their goals.
Way too many Haskell projects are about Haskell itself, so this was really fascinating to see.
Haskell could be a great practical language if some constraints were introduced, e.g. limiting the language extensions used. https://www.simplehaskell.org attempted to do this and, currently, https://neohaskell.org is going in the same direction. After all, Haskell '98 is not that hard.
Personally, I think Haskell, or something like Haskell, is going to be reasonably popular in the near future. Functional programming and an expressive type system are great for ML-powered synthesis. You provide the type signature, and the machine fills in the function body. Furthermore, with dependent or refinement types, the solution can be verified to be correct.
Maybe I'm completely wrong (as an outside than never touched anything ML other than OCaml), but Idris 2 does seem like a "clean Haskell" minus the laziness.
I'm not fully convinced. FP is such a different paradigm than the leading imperative/OO design that most are comfortable with. Other languages that are too different like lisp, forth, Apl, Haskell, and Prolog are just too different for the average person IMO. I've given Haskell/OCaml/F# a go a few times and enjoy learning new paradigms and it certainly didn't click for me. I have a feeling it'll be even harder with more normal people not into this as a hobby.
Here is how to read a text file in Haskell (I assume a standard way):
I could be biased, but it certainly seems like Python has a lot less conceptual hurdles here. You basically specify a filepath and then for loop through each line and print. The Haskell solution requires more steps and theory.
I know Haskell is a very awesome and cool language and super powerful for all kinds of uses that Python may be inferior at (example compilers). You'll get no argument there. I'm just pointing out that I think wide adoption may be difficult. I drank the koolaid and read dozens of blog posts and a couple of Haskell books and really wanted to make it work. I'm an engineer and like math and puzzles and learning new programming languages...and yet I couldn't make it that far (without sinking a whole lot more time into it than I had) and ultimately gave up.
It's not really that Haskell is "powerful", but the type system will catch a lot of errors for you and make refactoring much easier.
Also, I wouldn't recommend starting FP with Haskell. It's hard, mostly because of the monads (and laziness can make things more confusing too). Also the syntax which is confusing because indentation is meaningful in some places, but not others.
On the other hand, a language like Scheme is really super easy. Even OCaml is super simple if you stick to the classic ML subset of the language which can take you a very long way. These languages have been using to teach programming to complete beginners. Seriously, OCaml is arguably simpler than Python, and without doubt order of magnitude simpler than C++.
If you're familiar with things like lambda, closures and functions like map or filter in Python, you already know most of what you need to write OCaml code.
> FP is such a different paradigm than the leading imperative/OO design that most are comfortable with.
I don't think most of FP is at all hard for most programmers to understand. Hell I interviewed plenty of Javascript devs that couldn't solve a simple fizzbuzz level question because they didn't know how to do for loops - they only knew how to use `.forEach()`!
The hard bits in Haskell are:
1. Purity. I get it, but it definitely makes things harder.
2. Weird syntax: pervasive currying / single argument functions / lack of grouping syntax / waaaay too many operators, etc. E.g. from your link:
let singlewords = words contents
list = f singlewords
This is just a collection of words. No clue of what is a function call, what is a variable name, etc. Allow me to recreate the experience of reading Haskell, if you think the above is reasonable:
file read lines put
lines iter while cbr empty
for do <~> x IO::print
3. General unfriendliness to people who aren't hardcore Haskellers. E.g. suppose I want to match a regex. In Go, Python, Rust, Javascript, etc. there's one obvious way to do it. Haskell? How about you pick between 8 alternatives... https://wiki.haskell.org/index.php?title=Regular_expressions
There are other flaws, like global type inference & lazy IO, but I think those are the main ones.
Haskell doesn't have operators, it's based on expressions consisting of function compositions, some of which can be infix and look like operators.
> This is just a collection of words. No clue of what is a function call, what is a variable name, etc.
That's by design, because all of them are expressions that can either reduce immediately or require runtime data to reduce fully.
> How about you pick between 8 alternatives...
How about you pick either of those and start using for real, and then come to the point it either works well or you find inefficiencies to look specific alternatives for? It doesn't take much.
The Haskell version parses the contents of the file. One answer also explains how to lazily read the file to process it as it's read, using the ByteString package. I think part of the overhead here is due to this lazy processing, plus the fact that there are basically 3 String in Haskell: String, ByteString and Text.
The python version simply loads the whole file into memory. The equivalent Haskell would be to call Data.Text.IO.readFile. What would the python version of the lazy parsing / processing of a file look like ?
There were several Python versions shown at the link and the latter one that I was referring to does not read it all into memory. It loops through each line in only three lines of code, not like 1/4 of a page.
I tried just pasting the code into the window, but never learned how to format HN on mobile. Sorry for the confusion. After the colon there are indents, so 3 separate lines.
with open('testfile.txt') as f:
for line in f:
print(line.strip())
I think Haskell seems harder because it's built on another set of abstractions (laziness, typeclasses) where Python abstractions (iterators in this case, plus the with statement for resource acquisition/cleanup) are more common, but I could be wrong (I've been working with Scala for close to a decade now so functional style looks more familiar that imperative now.)
if you want the oop style you can just change "foo bar baz" to "bar `foo` baz" which is effectively the same thing as doing bar.foo(baz), because for some reason people are obsessed with passing an argument by putting a dot after it.
> The Haskell solution requires more steps and theory.
Really? The suggested Haskell solution is
main = do
contents <- readFile "test.txt"
print . map readInt . words $ contents
which is no more complex than the Python code. The entire file contents is read as a String into content. words breaks it into a list of words, and readInt parses each word into an Int. Finally the list of ints is printed.
yes, it looks all good, until you want to change it. For instance, to make the file name a CLI parameter, you need to understand things like type classes, specifically Monad, Functor and Applicative. You may need a long time to be at ease with these things and a superficial understanding will not take you very far. In Python, it'll take you a few minutes to do the same thing.
What do you mean by "long time"? Why wouldn't it apply just the same to some Python file that defines a Maybe with a bit of unwrap and bind and orElse or whatever?
Instead of things going boom and spewing a stack sometimes they just go Nothing instead, you don't need much more understanding than that. There is a lot of syntax in Haskell that is somewhat hard to understand at first but you don't actually need it to write stuff yourself.
This idea that you need to talk a particular way and be able to teach CS theory at uni and whatnot to build stuff in Haskell is probably not very healthy.
Long time, I mean possibly several weeks of full-time studying for an intermediate Python or C++ programmer.
I'm not saying you need any CS theory to write Haskell or that it's super hard. But I think the learning curve is pretty steep, and it's hard to write code without a good understanding of the concepts. Just tweaking until it type checks isn't going to cut it.
Consider this code. Generated from ChatGPT. This is supposed to be a simple command line option parsing. I don't think it's obvious what all the operators mean.
Sure, you can try to reuse this, and extend it. But I think sooner than later you'll be stuck with some undecipherable error messages and you'll have to sit down and understand what it all means.
data Options = Options
{ optVerbose :: Bool
, optInput :: String
} deriving Show
optionsParser :: Parser Options
optionsParser = Options
<$> switch
( long "verbose"
<> short 'v'
<> help "Enable verbose mode" )
<\*> strOption
( long "input"
<> short 'i'
<> metavar "FILENAME"
<> help "Input file name" )
This is a really good point. I have coworkers that don't really code, but can use ChatGPT to help them put together a Python app that does what they need with some common sense changes. I don't think I could even do the same with Haskell with a fair amount of coding experience+ reading up a lot on Haskell over the years. It may be obvious to those select few who are drawn to Haskell, but I think they greatly underestimate the challenges for the average person. That's the essence of what I've been saying to the parent thread that believes a subset of Haskell will become popular some day. I could be wrong, but just can't see it.
It is obvious, as long as you know what Functors and Semigroups for custom data types are. If you don't know it, you can still use it freely without fully understanding the meaning of `<>` and `<$>`, because they are written almost as plain bullet points of components to treat as a single whole.
I'd say a lot more is going on there conceptually than the Python code. Imagine through the eyes of a beginner. You have some main do thing, then you appear to read it all into memory and assign a variable, then you do a bunch of composition to words and readInt and map it to print?
With the python version, you see the file handle as a variable and then for loop on that iterable and you can print each line or parse it however you want. Even when I was learning to program and had no clue what an iterable object was, there seemed to be an obvious three line idiom for processing text files that was easy to use.
I think the issue that many people have with Haskell is the order of expression evaluation is not structured left-to-right and top-to-bottom. At least it's what makes it difficult to read Haskell for me. Compare it with F# (and OCaml family in general):
open System.IO
(File.ReadAllText "text.txt").Split()
|> Seq.map int
|> Seq.iter (printfn "%d")
It doesn't really matter on simple expressions but as you keep chaining the operations the reverse order gets more difficult to follow.
Haskell even on a bad day is radically more sane then all of these languages doing this bizarre obsession with foo.bar() instead of bar(foo), because they only allow overloading on the first arg. semantic indenting. type inference. automatic laziness. it's just another level.
Every time I try to work on someone's Haskell code, I'm confronted with a slew of custom infix operators, and I find my previous experience is completely irrelevant as I learn the new DSL the authors chose to write (which more often than not also involves flexing their brain as hard as they can).
But that's like half of computing.. every new tool the world inflicts on you, configured in Jojo's Awesome Configuration Language, with some arbitrary made up grammar punctuated by Tourette outbursts of special character line-noise.
That, or YAML, then a tool to template and generate the YAML, and then a stack of tools wrapped around that, ad infinitum.
A little learning is the cost of not having to write the thing yourself. On the other hand, hell is the non-composable tower of babel that is computing. Total employment by exponentially compounding incidental complexity.
The amount of arbitrary glue, configuration and "cool things" I need to learn-and-forget for every new project is an order of magnitude less than any other language I've used in anger.
The fact that people do it in the ordinary language, so you can click through to the operator definition and see immediately what it does, makes it a lot less taxing IMO. Even if the code is quite complex, figuring out what an actual function does is 10x easier than doing the same with a magic annotation, which is what you have to do in that situation in most other languages.
Right, now imagine the templated YAML mess implemented in Haskell together with the app. By someone smart enough to liberally use Haskell's most complicated features
I'm sure it is super cool and immediately comprehensible for an independent project. I'm actually really fascinated by programming languages like APL that take it even further, I'd like to try some of those out but I don't have a great fit for a project to use with them.
But all I can think of when I see custom operators professionally is how much of a nightmare it would be the second one has to onboard a junior developer onto the project.
It's super cool, but I'm not sure immediately comprehensible. I can't even read my own Haskell code after a few months away from it. You end up using other people's infix operators from the libraries and it's easy to forget what they are.
That's interesting, because Haskell is the only language in which I can easily read code written by others (and in "others" I include "myself three years ago").
> Way too many Haskell projects are about Haskell itself, so this was really fascinating to see.
It seems like Haskell is a good match for the requirements in this case, too. Implicit concurrency and enough robustness from the type system that new filters can be deployed directly to production plays to the strengths of the language. It doesn't feel like the usual solution in search of a problem.
Yes, (and so is OCaml) but less than in the past, mostly for specialized and older projets. Most engineers at Meta will not encounter these languages. It's costly to integrate them with the internal tools and arguably not worth the effort. On the other hand, Rust is increasingly popular and well-supported and approved by the company.
I think one of the most promising pitches for rust adoption is that it borrowed as much as possible from Haskell/ML without treading into the territory where it becomes "scary" for broadly-C-family language monoglots. A C++ or even Java programmer can look at Rust and think to themselves "this text has a comfortably familiar shape".
The differences between Haskell/OCaml and C-family languages are much more significant than syntax. Rust brings a lot (but not all) of the richness of these languages while staying within a broadly imperative paradigm.
That's neither my point nor OP's point. The soothing feeling of "this text has a comfortably familiar shape" is entirely about syntax, and indeed is only a soothing feeling because such programmer has not seen anything beyond it and is unwilling to get outside that comfort zone.
I do not hire anything who does not get outside of their comfort zone or who is intimated by syntax they haven't seen. If a programmer rejects Haskell or OCaml by giving me a good critique of say, Hindley Milner style type systems†, that's a good programmer I'm willing to hire even though I don't necessarily agree.
†: I've been asked exactly this question during an interview: to critique HM style type systems. As a candidate I felt this style of questions gave me a far better way to display my knowledge and experience than Leetcode style questions.
Do you put any weight on any factors beside the technical capabilities of the tools you're working with? Like, say, how easy they are to pick up or use, etc.?
The way your comment reads, it's like you're saying you'll never hire someone who rejects speaking to you in Esperanto unless they offer a good critique of its grammar.
I count myself among them. And I wouldn't say I am "otherwise solid". I am solid. Nix is just a weird custom footgun-laden language in a place where I don't want to have to learn a weird custom footgun-laden language. It has other serious issues too, like the fact that it is declarative makes discoverability extreeemely difficult. What does setting `foo: true` do? You can't go-to-definition on it. You can only hope it is well documented (it isn't) or try to find the place that reads that key ... somewhere... in all of Nix... Good luck.
Hell even if it were a perfectly designed language (it isn't) I still would be put off by it because I don't really want to be a professional full-time packaging engineer.
I think Bazel got a lot right by using a subset of Python. Basically nothing to learn language-wise.
This shallow dismissal pretty much proves OPs point.
For starters, you compared Nix the ecosystem to Starlark, perhaps the smallest aspect of Bazel. But Bazel (the ecosystem) has a horrendous documentation problem as well.
I grant that "Nix" is a very overloaded term, but it seems like you don't know which part of Nix you are even referring to. "Somewhere... in all of Nix" is not something that makes any sense.
I fully admit that Nix has a steep learning curve. Very steep. But I don't think you know enough to give a thoughtful critique.
> For starters, you compared Nix the ecosystem to Starlark
No I compared the Nix language to Starlark.
> but it seems like you don't know which part of Nix you are even referring to.
Incorrect. I was referring to the Nix language, as was hamandcheese. He literally said it explicitly. I don't know how you could miss that.
> I fully admit that Nix has a steep learning curve. Very steep. But I don't think you know enough to give a thoughtful critique.
You're proving my point here. The very steep learning curve and "you need to be an expert before you can use it" aspects of Nix (both the language and the package manager) are exactly the problem.
Let me put it another way. Imagine I gave you a vacuum cleaner, and you tried to turn it on but it had a very complicated startup sequence so you needed to read the manual... but the manual was written in Egyptian hieroglyphics. You take it back to the shop and they say "nah this is a perfectly good vacuum cleaner. Sure it has a steep learning curve but you just need to spend some time learning it before you can criticise it".
That's obviously stupid right? For most people package management is like vacuum cleaning. It's a necessary task they want to think about as little as possible.
Nix is written by a vacuum cleaner collection & restoration club, who assume that everyone in the world is as obsessively into vacuum cleaners as them.
> Incorrect. I was referring to the Nix language, as was hamandcheese.
I am hamandcheese. I replied to your comment. You didn't describe a single aspect of Nix-the-language. You wrote this:
> What does setting `foo: true` do? You can't go-to-definition on it. You can only hope it is well documented (it isn't) or try to find the place that reads that key ... somewhere... in all of Nix... Good luck.
It's appears (despite the wrong syntax, another clue that you are not particularly well informed) that you are referring to a NixOS module option. Or maybe a Home Manager module option. Either way, not a language feature.
The language feature I am talking about is that it is completely declarative. You can argue semantics if you want but Nix chose to use a completely declarative language for configuration and that was IMO a bad decision.
The fact that you say that haskell has operators and that you look for a distinction in syntax for functions and reduced values in the expression-driven language would be enough to say that you opine too strongly about things you don't have a solid understanding of. The same applies to your critique of Nix. If you ever tried recursive overrides of declarative definitions in, as you recommended, a subset of Python, you'd never claim that Nix is a footgun-laden language.
> The fact that you say that haskell has operators
Oh you mean the things that look like operator, behave like operators, and are commonly referred to as operators by Haskell programmers - even in the Haskell Wiki? Those operators?
You're a prime example of a person who reads a page on the Internet and takes it at a face value without understanding the meaning and the context behind the words:
> One of the most common operators, and source of initial confusion, is the $ operator. All this does is apply a function.
Did you miss the part that says "All this does is apply a function"?
whereas (+#) is defined as a bridge from unboxed ints provided by the runtime to their efficient low-level machine representation, accomodating all instances of a data type defined as `Int = I# Int#` (the left-hand side is the name of the type, the right-hand side is the name of a constructor that accepts a single value of type Int# - the low-level primitive provided by the GHC implementation).
The (+) in `I# x + I# y =` is a function definition in infix form. That's the same form you can use for any other infix function if you wish so:
ghci> a `iAmHelping` b = a b + b
ghci> :t iAmHelping
iAmHelping :: Num a => (a -> a) -> a -> a
> Oh you mean the things that look like operator, behave like operators
Let me see your regular operators do the following, then we talk:
plus = (+)
a = (2 +)
c = (2 `plus`)
c' = plus 2
d = (+) 2
d' = (+ 2)
e = 2 `plus` 2
f = 2 + 2
I'm glad that's the only thing you object to, though.
Ahah, if someone calls an infix function an operator it must be it, right? Do you also believe that Haskell functions return values because random articles on the Internet say that the functions return values via `return` "keyword"? Years of catering the invalid (but "familiar") terminology to outsiders so that they can land into the language must've done their job.
> I guess you're a prime example of someone that can't remember what the debate is.
There's no debate, you asked me why I said that you weren't solid. And I show you that you don't have a solid foundation in the tool that you opine on. You refuse the ground truth presented to you in code, and you opt to someone's verbal description of an infix function being an operator. You use a second-hand opinion to form your mental model about a thing, and then you opine on the thing with that invalid foundation that was made for you (by some believing individuals claiming it's the best approach), so that you don't feel intimidated from the get-go. No wonder you don't know why there's no distinctive difference between functions and reduced values in syntax. And that's not only Haskell, you also don't know Nix enough to understand how silly your take is about a subset of Python being better than a specialized language for the problem of cascading graph changes in build systems.
Wikipedia keyword search is the last resort of a mediocre engineer, thanks for confirming my words.
> Good to know you didn't have any real reasons to think I'm not a solid programmer anyway.
I'd easily demonstrate more reasons why you're not solid, I will probably do it in the future if I see more of your silly opinions on the things you don't know. But thankfully, in the context of Haskell the comments have already shown your true lack of any substantial knowledge. I hope you will at least obstain from commenting on Haskell and Nix in the future, don't embarrass yourself.
You are giving an extremely unfavourable impression of the Haskell community. If you care about the Haskell community, please stop interacting with people like this.
I don't care about Haskell community. If you've got anything to object to regarding my rebuttal of the OP's claims about Haskell and/or Nix (that are completely untrue and misleading), please state them instead of assuming that I speak on behalf of any community. I'm calling out someone's incompetence here, if you don't like it, that's on you.
You're right: I don't like it. It's on me? OK, fine by me. I'm glad if you're saying you don't believe your behaviour reflects on the Haskell community, and I hope everyone reading this thread takes that to heart. In my opinion this kind of superior, petty attitude is not welcome in the Haskell community.
Haha I was checking the comments precisely to see if this was the case. This happens nearly everywhere a language that isn't Java, Python, Ruby, Go, PHP, or JavaScript is used. IMO it has more to do with tech labor arbitrage[1] than anything technical. Even if a system is punching above its weight, over time, the Weird Language Choice spooks people enough that they get the rewrite bug.
Bleacher Report is a funny example: it used to be a darling example of Elixir, where a migration from Ruby -> Elixir claimed a move from "150 Ruby servers to 5 (probably overprovisioned) Elixir servers."[2] But then management and politics got scared, moved it all to more conventional tech, and the whole system suffered (see this legendary post[3]).
Fred Hebert describes a similar thing happening with a migration from Erlang deployments to Go/Docker/immutable, where you lose some pretty valuable capabilities by migrating to more conventional tech.[4]
I don't see this changing anytime soon -- we came of age when it was viable to attract investment with the promise of tech innovation. These days, those are liabilities because managers misunderstood the "Use Boring Technology" post the way consultants bartardized "Agile" (taking decent advice and misunderstanding it into something wholly different and horrifying). The result is you've got companies with customers in the 1000s using k8s, calling it "simple" and "Boring," whereas that same company would be called amateur if they did things like stateful deploys on-prem.[5]
Love your take on it. From a fellow prog languages enthusiast that matured, I can safely say that you are right.
I've coded in so many languages in my life, but the job market pull from Ruby always drags me back, with time, I began to really love and appreciate what Ruby is.
I still find Ruby a bit niche than other mainstream languages like Java and Python, I bet that if I had >5 years of Java, the Java market pull would be higher than Ruby and I'd be doing Java.
I recall hearing about this a while back, and how the team at Meta had implemented hotswapping to deploy new rules, without redeploying the entire executable, even though the rules were expressed in a Haskell DSL.
Unfortunately, I have never seen hotswapping of Haskell code anywhere else. All I can find is this library [0] by Simon Marlow.
Together with Cloud Haskell [1], hotwapping would allow to create pretty flexible distributed systems à la Erlang/OTP.
This article was written about the same time when I interviewed with this group. I was very enthusiastic about Haskell but a senior Haskell lead told me I needed much more Haskell experience but I was otherwise an interesting candidate and he offered to put me in touch with the other FB team doing a similar function, but in Java. I was only interested in learning Haskell, so nothing happened. Still it was very cool to be able to talk with a couple of famous Haskell folks.
If this article was about "fighting spam with C++ at Meta", would it make the front page? I doubt it. I learnt Haskell thinking that it would give me super-powers no other language has, but in the end my impression of the language was "meh". I like the syntax a lot, and I have adopted the monadic approach to error handling when I do Python, but Haskell itself doesn't give me an edge over other programmers.
Haskellers are proud of a few projects that use Haskell (pandoc, xmonad, etc.) and they boast about how they can achieve the same thing as i3 but in much fewer LoC. But frankly I don't think #LoC is a good metric for gauging a language's value.
I do think it's interesting how I've been hearing about how much people love Haskell and how elegant it is since middle school. Now I'm 10 years out of university and it's still notable when something is actually written in Haskell. That's got to tell you something about the language, the tooling, the docs, the community, or maybe some combination of those things.
Probably a combination of those things but also about the staying power or perception and stereotype from the broader programming community. (I’m not saying that Haskell is super pragmatic and industry-ready, only that the perception of it often lags behind its real usefulness — admittedly in part because other languages work well enough so why bother to engage with one that requires thinking differently?)
I had previous Haskell experience, but what struck me was how irrelevant that was.
To their immense credit, they had managed to use Haskell to write an entirely entreprise focused, "boring" business rule backend serving millions of QPS, and people who were not Haskell fans could easily use its sensible DSL to accomplish their goals.
Way too many Haskell projects are about Haskell itself, so this was really fascinating to see.