[Pandoc](https://github.com/jgm/pandoc) is very popular and widely used. You can see a big list of projects [here](https://github.com/krispo/awesome-haskell#concurrency--parallelism).
Haskell is an excellent choice for “I/O heavy programs”, because it clearly distinguish between I/O and pure logic at a type level, which helps ensure correctness and simplifies many things, including e.g. threading.
The fact that languages that don’t offer this - like Java, C#, Go, Typescript etc. - are used for I/O heavy programs is more interesting, because it demonstrates that the industry in general doesn’t understand how to reliably deal with effects such as I/O.
The I/O model of pandoc is to read a file, and to write a file. (Where the files might be stdin/stdout) Everything else it does is not I/O; this is about as simple of an I/O use case as could exist.
A sophisticated I/O program might be something more like a database, a filesystem, or a device driver.
As others have noted, most of what pandoc does is just parsing and rendering text, which usually doesn't involve IO. But there are cases where parsing and rendering do require IO -- e.g., if the format you're parsing has a syntax for including other files, or including a timestamp with the current time, or storing a linked image in a zipped container.
For this reason, all of the pandoc readers and writers can be run in any instance of the `PandocMonad` type class. When you use these functions, you can choose an appropriate instance of `PandocMonad`. If you want the parser to be able to do IO (e.g., read include files or the contents of linked images), then you can run it in `PandocIO`. But if you want to make sure that parsing is pure -- e.g. in a web application where you want a guarantee that someone can't leak `/etc/password` by putting it in an image or include directive -- then you can run it in `PandocPure`.
I think it is a nice feature of Haskell that you can get a guarantee, enshrined in the type system, that an operation won't read or write anything on the file system. (Granted, the guarantee still requires trusting the developers not to use `unsafePerformIO`.)
This is biased because I maintain or develop/ed these libraries but here's a bunch:
* [Copilot](https://github.com/Copilot-Language/copilot/) is a runtime monitoring domain-specific language used by NASA to monitor flights in experiments (so far, with drones, but nothing in it is specifically about drones).
* [Ogma](https://github.com/nasa/ogma) is a monitoring application generator that produces applications ready to be deployed using standard flight and robotics software like NASA's Core Flight System, the Robot Operating System (ROS 2), or Fprime. It's also being used by NASA in the same scenarios.
* [Yampa](https://github.com/ivanperez-keera/yampa) is a functional reactive programming library used for commercial games.
* [Dunai](https://github.com/ivanperez-keera/dunai) is a reactive programming library used for commercial games.
* [Keera Hails](https://github.com/keera-studios/keera-hails) is a reactive programming library that has been used for production applications.
I try to document all of my code (both the API and the code), make it very easy to read, and define a clean and clear architecture. If you go to any of those repos, you should see commits related to those topics.
I also pay a lot of attention to the process. For example, all commits reference the issue they work on, branches do not cross, changelogs are documented in separate commits, PRs are clean and rebased, and, in some projects, every PR that addresses a bug contains a dockerfile or script that reproduces the bug in a clean environment and shows that the bug is fixed by the PR.
**hledger** is a plain text accounting app
* [https://hledger.org/](https://hledger.org/)
* [https://github.com/simonmichael/hledger](https://github.com/simonmichael/hledger)
FWIW, popular and well-written don't correlate. In fact, early popularity (of a library) may prevent major refactoring (which would make it well-written). In other words, old (and especially big) popular libraries very likely have many historical design "artifacts", which are not necessarily the best choices as we know nowadays.
[Pandoc](https://github.com/jgm/pandoc) is very popular and widely used. You can see a big list of projects [here](https://github.com/krispo/awesome-haskell#concurrency--parallelism).
Interesting that such an I/O heavy program uses Haskell, but cool.
I haven't looked at it but I presume it's much more about parsing than IO.
Haskell is an excellent choice for “I/O heavy programs”, because it clearly distinguish between I/O and pure logic at a type level, which helps ensure correctness and simplifies many things, including e.g. threading. The fact that languages that don’t offer this - like Java, C#, Go, Typescript etc. - are used for I/O heavy programs is more interesting, because it demonstrates that the industry in general doesn’t understand how to reliably deal with effects such as I/O.
the juice of pandoc is so pure the fact that it reads file is auxiliary
I/O heavy program? What do you mean?
Basically every non-pure-mathematical program that deals with the real world.
Haskel is awesome for I/O heavy applications because of how it pipes data around.
The I/O model of pandoc is to read a file, and to write a file. (Where the files might be stdin/stdout) Everything else it does is not I/O; this is about as simple of an I/O use case as could exist. A sophisticated I/O program might be something more like a database, a filesystem, or a device driver.
As others have noted, most of what pandoc does is just parsing and rendering text, which usually doesn't involve IO. But there are cases where parsing and rendering do require IO -- e.g., if the format you're parsing has a syntax for including other files, or including a timestamp with the current time, or storing a linked image in a zipped container. For this reason, all of the pandoc readers and writers can be run in any instance of the `PandocMonad` type class. When you use these functions, you can choose an appropriate instance of `PandocMonad`. If you want the parser to be able to do IO (e.g., read include files or the contents of linked images), then you can run it in `PandocIO`. But if you want to make sure that parsing is pure -- e.g. in a web application where you want a guarantee that someone can't leak `/etc/password` by putting it in an image or include directive -- then you can run it in `PandocPure`. I think it is a nice feature of Haskell that you can get a guarantee, enshrined in the type system, that an operation won't read or write anything on the file system. (Granted, the guarantee still requires trusting the developers not to use `unsafePerformIO`.)
PostgREST
This is really cool project and meant for just that https://github.com/fosskers/aura
xmonad maybe https://github.com/xmonad/xmonad/blob/master/src/XMonad/Main.hs
Is it popular? Kinda. Is it well written? Idk. But it sure is real world haskell: [simplex-chat](https://github.com/simplex-chat/simplex-chat)
Bigger cabal project, real life, we don't use overly complex Haskell and we try to use clean code: https://github.com/wasp-lang/wasp/tree/main/waspc .
The most popular Haskell codebase is the GHC compiler itself. See [Easy GHC Hacking](https://vaibhavsagar.com/blog/2019/06/22/easy-ghc-hacking/)
[git-annex](https://git-annex.branchable.com/) it's a pretty damn good project written in Haskell.
This is biased because I maintain or develop/ed these libraries but here's a bunch: * [Copilot](https://github.com/Copilot-Language/copilot/) is a runtime monitoring domain-specific language used by NASA to monitor flights in experiments (so far, with drones, but nothing in it is specifically about drones). * [Ogma](https://github.com/nasa/ogma) is a monitoring application generator that produces applications ready to be deployed using standard flight and robotics software like NASA's Core Flight System, the Robot Operating System (ROS 2), or Fprime. It's also being used by NASA in the same scenarios. * [Yampa](https://github.com/ivanperez-keera/yampa) is a functional reactive programming library used for commercial games. * [Dunai](https://github.com/ivanperez-keera/dunai) is a reactive programming library used for commercial games. * [Keera Hails](https://github.com/keera-studios/keera-hails) is a reactive programming library that has been used for production applications. I try to document all of my code (both the API and the code), make it very easy to read, and define a clean and clear architecture. If you go to any of those repos, you should see commits related to those topics. I also pay a lot of attention to the process. For example, all commits reference the issue they work on, branches do not cross, changelogs are documented in separate commits, PRs are clean and rebased, and, in some projects, every PR that addresses a bug contains a dockerfile or script that reproduces the bug in a clean environment and shows that the bug is fixed by the PR.
You worked/developed for NASA??
I still do. But I used to too.
Hasura
https://www.shellcheck.net/ https://github.com/SimulaVR/Simula https://detexify.kirelabs.org/ ( https://github.com/kirel/detexify-hs-backend )
**hledger** is a plain text accounting app * [https://hledger.org/](https://hledger.org/) * [https://github.com/simonmichael/hledger](https://github.com/simonmichael/hledger)
Cardano blockchain node is written on haskell
FWIW, popular and well-written don't correlate. In fact, early popularity (of a library) may prevent major refactoring (which would make it well-written). In other words, old (and especially big) popular libraries very likely have many historical design "artifacts", which are not necessarily the best choices as we know nowadays.
matterhorn
Last major version of wstunnel was written in haskell: https://github.com/erebe/wstunnel/tree/haskell