Commenters debate whether Haskell's primary bottleneck is technical performance, such as compile time and incremental builds, or its lack of a coherent, polished ecosystem for building diverse applications like web and desktop software. While some argue that foundational libraries and better developer experience are the missing pieces, others contend that the language's utility is constrained by fragmented tooling and unclear positioning compared to more universal alternatives.
17 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4jgm
pandoc
Haskell2012–2026
jgm / pandoc
pandoc
Universal markup converter
56Distinct people
63Mentions
1Explicit recommenders
46.9KGitHub stars
What to know before exploring
What it is
Universal markup converter
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
I really hope that they borrow a lot if not everything from pandoc[1]. My only real complaint with pandoc is the table formatting, but I think fiddlosopher is adding org-mode…
dfc used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:49:33 PM UTC.
Mentions over time
HN mentions by year63 dated mentions
Observed mentions: 2012-02-25 18:15:18 UTC to 2026-10-01 15:56:48 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 7 | 1 | 6 |
What Hacker News says
3 sourcesCHchriswarbo·Oct 14, 2014
Pandoc doesn't seem as bad as you suggest. GHC, dependencies, etc. are only needed for compiling; according to http://johnmacfarlane.net/pandoc/installing.html Pandoc can be compiled into a standalone binary. The Windows build on https://github.com/jgm/pandoc/releases is 17.1MB and the Debian package in Wheezy is 18.9MB with reasonable-looking dependencies.
The scripts I've written (PanPipe and PanHandle) require a Haskell implementation and the Pandoc library in order to be compiled or interpreted. Once they're compiled with GHC, they're completely standalone.
My plan is to have my server recompile my site when changes are pushed to Git. I like having Emacs, GHC, etc. on my laptop, but not on my server.
I actually tried to integrate Babel with Hakyll originally, but hit a bunch of problems. I didn't include that in the page since I thou
Read the rest
ght it would be distracting. Most of it boils down to Org-mode's HTML exporter being awkward to invoke as part of a UNIX pipeline:
- Emacs can't handle stdio
- Org-mode has breaking changes between the version bundled in the latest stable Emacs (24.3) and that in ELPA (which I use)
- Syntax highlighting depends on the current Emacs theme
- Whole HTML pages are generated, which makes templating harder
- Anything which uses the filesystem leaves artifacts around
I did manage to hack together a shell script which created and switched to a temporary directory, saved /dev/stdin to a file, opened Emacs in batch mode, loaded Org-mode, opened the temp file, tangled the file, exported the file, exited Emacs, ran the result through some XSLT transformations and Python scripts to extract the data needed for templating, spliced the results through the templates, spat the result to /dev/stdout, switched out of the temp directory then deleted it. Needless to say, it was very fragile, and much more complex than writing these Pandoc filters!
Well, the original markdown.pl heavily uses regexps.
From having tilted at this windmill a little myself, I think:
1. It's tricky enough to handle correctly all the under-specified corner cases of basic markdown -- not to mention the popular extensions to it. The cognitive load of doing it with complex regexps gets heavy, quickly.
2. I'm incredibly impressed with all the work that John MacFarlane has put into the problem, for example in [Pandoc] and [Cheapskate].
[Pandoc]: https://github.com/jgm/pandoc
[Cheapskate]: https://github.com/jgm/cheapskate
In Show HN: Fast and Extensible Parser for Markdown in PHPShow me a BASIC program as impressive as any of:
- Elm's Time Travelling Debugger: http://debug.elm-lang.org/
- Pandoc: https://github.com/jgm/pandoc
- XMonad: http://xmonad.org/
- (GHC, should really count)
In Leaving Go