PostgREST is written in Haskell and quite popular: https://postgrest.org/en/v7.0.0/
Shellcheck has become a very important tool to many people writing shell scripts: https://github.com/koalaman/shellcheck
GitHub's semantic analysis is written in Haskell: https://github.com/github/semantic
I'm not sure why Pandoc doesn't count.
I think it is definitely the case that most examples of successful Haskell are technical programs of interest to hackers. I don't think that's much of a problem myself.
In New Haskell Foundation to Foster Haskell Adoption, Raises 200k USDgithub
semantic
Haskell2019–2025
github / semantic · Archived
semantic
Parsing, analyzing, and comparing source code across many languages
29Distinct people
36Mentions
0Explicit recommenders
9KGitHub stars
What to know before exploring
What it is
Parsing, analyzing, and comparing source code across many languages
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 6:01:08 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year36 dated mentions
Observed mentions: 2019-05-31 15:57:18 UTC to 2025-01-08 22:53:51 UTC.
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 |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 13 | 6 | 7 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 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 | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
NOTE: This repository is no longer supported or updated by GitHub. If you wish to continue to develop this code yourself, we recommend you fork it.
Semantic
semantic is a Haskell library and command line tool for parsing, analyzing, and comparing source code.
In a hurry? Check out our documentation of example uses for the semantic command line tool.
Table of Contents
Usage
Language support
Development
Technology and architecture
Licensing
Usage
Run semantic --help for complete list of up-to-date options.
Parse
Usage: semantic parse [--sexpression | (--json-symbols|--symbols) |
--proto-symbols | --show | --quiet] [FILES...]
Generate parse trees for path(s)
Available options:
--sexpression Output s-expression parse trees (default)
--json-symbols,--symbols Output JSON symbol list
--proto-symbols Output protobufs symbol list
--show Output using the Show instance (debug only, format
subject to change without notice)
--quiet Don't produce output, but show timing stats
-h,--help Show this help text
Language support
Language
Parse
AST Symbols†
Stack graphs
Ruby
✅
✅
JavaScript
✅
✅
TypeScript
✅
✅
🚧
Python
✅
✅
🚧
Go
✅
✅
PHP
✅
✅
Java
🚧
✅
JSON
✅
⬜️
⬜️
JSX
✅
✅
TSX
✅
✅
CodeQL
✅
✅
Haskell
🚧
🚧
† Used for code navigation on github.com.
✅ — Supported
🔶 — Partial support
🚧 — Under development
⬜ - N/A ️
Development
semantic requires at least GHC 8.10.1 and Cabal 3.0. We strongly recommend using ghcup to sandbox GHC versions, as GHC packages installed through your OS's package manager may not install statically-linked versions of the GHC boot libraries. semantic currently builds only on Unix systems; users of other operating systems may wish to use the Docker images.
We use cabal's Nix-style local builds for development. To get started quickly:
git clone git@github.com:github/semantic.git
cd semantic
script/bootstrap
cabal v2-build all
cabal v2-run semantic:test
cabal v2-run semantic:semantic -- --help
You can also use the Bazel build system for development. To learn more about Bazel and why it might give you a better development experience, check the build documentation.
git clone git@github.com:github/semantic.git
cd semantic
script/bootstrap-bazel
bazel build //...
stack as a build tool is not officially supported; there is unofficial stack.yaml support available, though we cannot make guarantees as to its stability.
Technology and architecture
Architecturally, semantic:
Generates per-language Haskell syntax types based on tree-sitter grammar definitions.
Reads blobs from a filesystem or provided via a protocol buffer request.
Returns blobs or performs analysis.
Renders output in one of many supported formats.
Throughout its lifecycle, semantic has leveraged a number of interesting algorithms and techniques, including:
Myers' algorithm (SES) as described in the paper An O(ND) Difference Algorithm and Its Variations
RWS as described in the paper RWS-Diff: Flexible and Efficient Change Detection in Hierarchical Data.
Open unions and data types à la carte.
An implementation of Abstracting Definitional Interpreters extended to work with an à la carte representation of syntax terms.
Contributions
Contributions are welcome! Please see our contribution
guidelines and our code of conduct for
details on how to participate in our community.
Licensing
Semantic is licensed under the MIT license.
Read the full README on GitHubWhat Hacker News says
7 sourcesThere is an initiative[1][2] to create a tree-sitter parser and GitHub Semantic support for COBOL.
[1] https://github.com/Neppord/tree-sitter-cobol
[2] https://github.com/github/semantic/issues/452
In GnuCOBOL 3.1.1Github are using it https://github.com/github/semantic
Facebook and many others.
In Real World HaskellIf someone wants to help with more COBOL code analysis adding[1] it's support in GitHub Semantic would be awesome. The first step would be to finish the Tree-Sitter parser[2] for it. Then it would require to add support in Haskell bindings [3].
[1] https://github.com/github/semantic/issues/452
[2] https://github.com/Neppord/tree-sitter-cobol
[3] https://github.com/tree-sitter/haskell-tree-sitter
In IBM Watson's Next Challenge: Modernize Legacy CodeGitHub semantic powers goto definition in GitHub IIRC. Here's why they use Haskell:
https://github.com/github/semantic/blob/master/docs/why-hask...
In What killed Haskell, could kill Rust, tooHaskell library (semantic): https://github.com/github/semantic
In GitHub: Code Navigation for Go, Python, Ruby (Also: JavaScript, PHP, TypeScript)> and also in advancing the state-of-the-art in the software industry, which is another worthy goal, but a very different one.
The state of the art doesn't advance until practitioners share the results of adopting new techniques and tools. How else would the SWEBOK guide [0] have a section on unit testing if, in study, we don't have results that correlate the practice of TDD with a reduction in software errors, productivity, or some form of correctness? Is it irrational of us to practice TDD anyway?
How do we know formal methods are effective if there hasn't been a large scale study?
An interesting example of this balance between research and practice came to me from learning about the construction of cathedrals, particularly the funicular system of Guadi [1]. Instead of conventional drawings he used hanging models of the structures. It w
Read the rest
as not widely practiced or a proven method but it enabled him to reduce his models to 1:10th the scale and accurately model the forces in complex curves. As he shared his work and others studied it the state of the art advanced.
> .. or at all.
> I think Haskell is OK -- not much better or much worse than most languages, but not my cup of tea -- and Lean is very interesting for those interested in formal logic, but offers little to engineers
I think we're at, or approaching, the point where we're talking past each other.
I heard the talk from the Semantic team at Github on their experience report with algebraic effects sounded positive [2]. They are probably the largest production deployment of a code base exploiting algebraic effects. Their primary area of focus is in semantic analysis of ASTs. And yet they would like to continue pushing the state of the art with algebraic effects because, in their words, In Haskell, control flow is not dictated by the language, but by the data structures used. Algebraic effect interpreters enable them to interpret and analyze unsafe code without having to maintain buggy, difficult to reason about exception-based work flows. They say this singular feature alone is essential for rapid development.
Yes, they're doing research. However their research isn't in answering hypothesis about effect interpreters. It's directly contributing to an interesting feature in one of the largest code-sharing platforms in the world. They were able to exploit algebraic effects so they could focus on their research, their real-world problem, without having to fuss around with the limitations of conventional mainstream languages.
I do wish more companies using Haskell would share their experiences with it. It would go a long way to dispelling the pervasive view that Haskell is only good for research. It's not: it's a practical, production ready language, run time, and ecosystem that can help anyone interested in using it to tackle hard problems.
In a similar fashion I think dependent types would make working with types in Haskell easier. Instead of having to learn the different mix of language extensions you need to enable in order to work with inductive type families, it could be more like Lean, where it's a normal data declaration. Haskell introduces a lot of extra concepts at the type level because it has two different languages. I can simplify a lot of code in libraries I've written if Haskell had dependent types (and I'm working on libraries in Lean that may eventually prove it).
It may take a while but I think Haskell will eventually get there. The community has been discussing and researching it for years. It's going at the pace it is because the Haskell community is not focused on pure research: there are a lot of production applications and libraries out there and they don't want to break compatibility for the sake of answering interesting research questions. Despite your opinions on type theory there's a real, practical reason I might exploit Rank-2 types or Generalized Algebraic Data Types and it's not simply to answer a pressing hypothetical question: I've used these in anger.
I hope some of this answers your questions as to why get there at all?
[0] https://www.computer.org/education/bodies-of-knowledge/softw...
[1] https://en.wikipedia.org/wiki/Church_of_Col%C3%B2nia_G%C3%BC...
[2] https://github.com/github/semantic/blob/master/docs/why-hask...