The first typed programming language where I've seen pipe operator |> in action was in F#. You can write something like:
sum 1 2
|> multiply 3
and it works because |> pushes the output of the left expression as the last parameter into the right-hand function. multiply has to be defined as:
let multiply b c = b \* c
so that b becomes 3, and c receives the result of sum 1 2.
RHS can also be a lambda too:
sum 1 2 |> (fun x -> multiply 3 x)
|> is not a syntactic sugar but is actually defined in the standard library as:
let (|>) x f = f x
For function composition, F# provides >> (forward composition) and << (backward composition), defined respectively as:
let (>>) f g x = g (f x)
let (<<) f g x = f (g x)
We can use them to build reusable composed functions:
let add1 x = x + 1
let multiply2 x = x \* 2
let composed = add1 >> multiply2
F# is a beautiful language. Sad that M$ stopped investing into this language long back and there's not much interest in (typed) functional programming languages in general.
F# is excellent. It’s tooling, ecosystem, and compile times are the reason I don’t use it. I learned it alongside OCaml, and OCaml’s compilation speed spoiled me.
It is indeed a shame that F# never became a first class citizen.
There are also ||> and |||> for automatically destructuring tuples and passing each part as a separate value along.
And there are also the reverse pipes (<|, <|| and <|||)
F# is, for me, the single most ergonomic language to work in. But yeah, M$ isn't investing in it, so there are very few oppurtunities to actually work with f# in the industry either.
It's kind of wild that PHP gets a pipe(line) operator before JS finalizes its' version... of course they've had multiple competing proposals, of which I liked the F# inspired one the most... I've stopped relying on the likes of Babel (too much bloat) or I'd like to be able to use it. I used it for years for async functions and module syntax before they were implemented in node and browsers. Now it's hard to justify.
What makes you believe Haskell is dead or even dying? New versions of GHC are coming out, and in my experience, developing Haskell has never been smoother (that’s not to say it is completely smooth).
I think of languages as falling in roughly 3 popularity buckets:
1. A dominant conservative choice. These are ones you never have to justify to your CTO, the "no one ever got fired for buying IBM" languages. That's Java, Python, etc.
2. A well-known but deliberate choice. These are the languages where there is enough ecosystem and knowledge to be able to justify choosing them, but where doing so still feels like a deliberate engineering choice with some trade-offs and risk. Or languages where they are a dominant choice in one domain but less so in others. Ruby, Scala, Swift, Kotlin.
3. Everything else. These are the ones you'd have to fight to use professionally. They are either new and innovative or old and dying.
In 2020, Haskell was close to Kotlin, Rust, and Dart. They were in the 3rd bucket but their vector pointed towards the second. In 2025, Kotlin and Dart have pulled ahead into the second bucket, but Haskell is moving in the other direction. It's behind Perl, and Perl itself is not exactly doing great.
None of this is to say that Haskell is a bad language. There are many wonderful languages that aren't widely used. Popularity is hard and hinges on many extrinsic factors more than the merits of the language itself. Otherwise JavaScript wouldn't be at the top of the list.
> In 2020, Haskell was close to Kotlin, Rust, and Dart. [...] In 2025, Kotlin and Dart have pulled ahead into the second bucket, but Haskell is moving in the other direction.
> It's behind Perl, and Perl itself is not exactly doing great.
Your comment reminded me of gamers who "play games" by watching "letsplay" videos on youtube.
And yet, while PHPs, Javas, and even nicher/newer languages like Kotlin, Clojure or Scala have plenty of killer software (software that makes it worth learning a language just to use that library/framework) Haskell has none after 30 years. Zero.
Mind you, I know and like Haskell, but its issues are highly tied to the failure of the simple haskell initiative (also the dreadful state of its tooling).
There are lots of great libraries, like repa, servant, megaparsec, gloss, yampa… as well as bindings to lots of standard stuff. I consider parsing to be one of Haskell’s killer strengths and I would definitely use it to write a compiler.
There is also some popular user facing software like Pandoc, written in Haskell. And companies using it internally.
yea I agree. haskell was my primary language for several years in the 00s. it's since had almost zero industry uptake. Don't come at me with jane street or the one off startup.
I thought for a while I'd be able to focus on getting jobs that liked haskell. it never happened.
I certainly wouldn't focus on getting a Haskell job. Yet they are out there; e.g. my current job is Haskell, and happens to be in the same sector (public transport) as my last job (which was mostly Scala).
Also, I've found Haskell appropriate for some one-off tasks over the years, e.g.
- Extracting a load of cross-referenced data from a huge XML file. I tried a few of our "common" languages/systems, but they all ran out of memory. Haskell let me quickly write something efficient-enough. Not sure if that's ever been used since (if so then it's definitely tech debt).
- Testing a new system matched certain behaviours of the system it was replacing. This was a one-person task, and was thrown away once the old system was replaced; so no tech debt. In fact, this was at a PHP shop :)
Yea of course, its not really the focus for me either way. my point was that how great haskell seemed in grad school didn't match up with the real world interest.
I use spark for most tasks like that now. Guido stole enough from haskell that pyspark is actually quite appealing for a lot of these tasks.
> Guido stole enough from haskell that pyspark is actually quite appealing for a lot of these tasks.
He didn't do his homework. Guido or whoever runs things around the python language committee nowadays didn't have enough mental capacity to realize that the `match` must be a variable bindable expression and never a statement to prevent type-diverging case branches. They also refuse to admit that a non-blocking descriptor on sockets has to be a default property of runtime and never assigned a language syntax for, despite even Java folks proving it by example.
FYI instig007 is not part of the Haskell community but seems to occasionally lambast people about Haskell, risking giving the Haskell community a bad name: https://news.ycombinator.com/item?id=44199980
> but seems to occasionally lambast people about Haskell
If you are to add community notes to my comments, at least add the part that clarifies that I only lambast incompetence and lies.
> risking giving the Haskell community a bad name
as opposed to those that spread FUD, I suppose? It's not the first time I'm asking this question, so what's your take on people who inflate their credibility by telling lies about the tech they clearly don't know?
And yet I, who am kinda dumb, have managed to find some of each. There's hope out there, beloved Latinists and Haskellers. Never let the fire in your heart burn out.
RHS can also be a lambda too:
|> is not a syntactic sugar but is actually defined in the standard library as: For function composition, F# provides >> (forward composition) and << (backward composition), defined respectively as: We can use them to build reusable composed functions: F# is a beautiful language. Sad that M$ stopped investing into this language long back and there's not much interest in (typed) functional programming languages in general.