HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
clojure
core.match
Clojure2012–2026
clojure / core.match

core.match

An optimized pattern matching library for Clojure

Languages & CompilersLibraries & SDKs
Explore on GitHubRead Hacker News discussions
25Distinct people
26Mentions
0Explicit recommenders
1.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

An optimized pattern matching library for Clojure

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

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:56:56 AM 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 year26 dated mentions

Observed mentions: 2012-02-03 08:14:40 UTC to 2026-04-30 05:34:43 UTC.

012342012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20122013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* 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
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC303
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC404
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC101
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC303
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC404
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC000
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC303
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC211
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC303
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
match An optimized pattern matching library for Clojure. It supports Clojure 1.5.1 and later as well as ClojureScript. You can find more detailed information here. Releases and dependency information This project follows the version scheme MAJOR.MINOR.PATCH where each component provides some relative indication of the size of the change, but does not follow semantic versioning. In general, all changes endeavor to be non-breaking (by moving to new names rather than by breaking existing names). Latest release: 1.1.1 All released versions CLI/deps.edn dependency information: org.clojure/core.match {:mvn/version "1.1.1"} Leiningen dependency information: [org.clojure/core.match "1.1.1"] Maven dependency information: <dependency> <groupId>org.clojure</groupId> <artifactId>core.match</artifactId> <version>1.1.1</version> </dependency> Example Usage From Clojure: (require '[clojure.core.match :refer [match]]) (doseq [n (range 1 101)] (println (match [(mod n 3) (mod n 5)] [0 0] "FizzBuzz" [0 _] "Fizz" [_ 0] "Buzz" :else n))) From ClojureScript: (ns foo.bar (:require [cljs.core.match :refer-macros [match]])) (doseq [n (range 1 101)] (println (match [(mod n 3) (mod n 5)] [0 0] "FizzBuzz" [0 _] "Fizz" [_ 0] "Buzz" :else n))) For more detailed descriptions of usage please refer to the wiki. Developer information Bug Tracker Continuous Integration Copyright and license Copyright © 2010-2023 David Nolen, Ambrose Bonnaire-Sergeant, Rich Hickey & contributors. Licensed under the EPL (see the file epl.html).
Read the full README on GitHub

What Hacker News says

26 sources
shirogane86x·Apr 30, 2026
I think the lisp situation is peculiar, for 3 main reasons: - most of them are dynamically typed (thus don't need sum types, as there are no types). The ones that do have gradual type systems likely either implement some form of them (off the top of my head I can only remember typed racket, and I think it implements them through union types) - not all lisps lean functional: I believe that's mostly a prerogative of scheme and clojure (and their descendants); something like CL is a lot more procedural, iirc - in most lisps, thanks to macros, you probably don't need the language to support some sort of match construct out of the box: just implement it as a macro [1] In general the "proper sum types" side of functional programming is just the statically typed one, but even in dynamically typed FP languages you end up adopting sum type-esque p
Read the rest
atterns, like elixir's error handling (which closely resembles the usual Either/Result type, just built out of tuples and atoms rather than a predefined type), and I assume many lisps adopt similar patterns as well [1] https://github.com/clojure/core.match
In Functional programmers need to take a look at Zig
socksy·Dec 14, 2024
Unfortunately (IMO), `core.match` in Clojure is a macro provided by a library you have to install, rather than a builtin function as in Scala or Python. It’s a really cool demonstration of the power of lisps, since macros basically let you edit the code at compile time, rather than at runtime, and match is maybe the most extreme example of this as it’s really compiling down the match statement into completely different code, rather than treating it like a cond statement (more info on the match algorithm here: https://github.com/clojure/core.match/wiki/Understanding-the...). However, when using macros there’s always some trade-offs — for example, you usually can’t treat them as a first class function, passing them around (although I’m not sure if that’s true for core.match tbf). Additionally, they can be confusing to debug because the code
Read the rest
that you’re writing doesn’t match the code that’s actually being run… stack traces can be particularly weird. Finally, by not being a builtin, it doesn’t really feel blessed as a language feature, and if it’s a choice between case, condp, or cond, I’m going to reach for one of those before core.match, simply because I don’t have to add a new library, I can be sure that I’ll understand the stack traces, and most importantly I can be sure that others will understand the code better. The fact that destructuring is built into Clojure means that you can get sort of half of the use cases for match in the first place, so it ends up being quite rare when you’ll actually reach for it. I’m not sure exactly what Dustin was referring to exactly, but those are my gripes with it. I think it’s a shame, because `match` is a more powerful construct every time I’ve encountered it in other languages, and it’s one of the few things I really miss as a built in part of Clojure.
In Idiomatic Errors in Clojure
fulafel·May 9, 2023
I think Clojure has benefited from matching being kept out of the built-in stdlib. https://github.com/clojure/core.match is a plug-in and as a result we've had lots of cool data traversal/matching DSLs come around and evolved user communities with time such as Meander and Datascript not to mention the parsing applications of the schema systems (spec & malli).
In Why Lisp?
tekacs·Jul 17, 2021
I'll also leave these here, in case the conversation inevitably turns to pattern-matched function definition in Elixir. :) https://github.com/clojure/core.match -- pattern matching as a library https://github.com/killme2008/defun -- using core.match to implement Elixir/Erlang-like function definition https://github.com/noprompt/meander -- advanced pattern matching, for some fun and flavor :) What's also fun is that core.match is implemented using a paper from INRIA on how to efficiently convert patterns into decision trees: https://github.com/clojure/core.match/wiki/Understanding-the...
In Elixir protocols vs. Clojure multimethods

Showing the 15 most recent of 26 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.