HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
leonoel
missionary
Clojure2021–2026
leonoel / missionary

missionary

A functional effect and streaming system for Clojure/Script

6Distinct people
12Mentions
0Explicit recommenders
802GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A functional effect and streaming system for Clojure/Script

GitHub

Where it is used

No documented product use has been verified yet.

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, 5:04:57 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 year12 dated mentions

Observed mentions: 2021-01-20 18:30:00 UTC to 2026-01-16 02:17:36 UTC.

0123452021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 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
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC413
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC505
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
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

What Hacker News says

12 sources
I'm a big fan of Dustin, I think the programming interface electric presents is very compelling, and the benefits are really impressive. The killer feature, for me, of electric is that it makes the network _transparent_ to me, the programmer, and makes solving complex problems concise. I see electric as a kind of emacs - an excellent operating system that lacks a decent front-end. Reactive programming is hard, and it really ought to be way more visual, and electric should give me those tools. I find the frontend side of the electric somewhat obtuse, and it's easy to go off the rails, needing to understand the underlying reactive layer https://github.com/leonoel/missionary. Why should I target this bizarre DSL when there are millions of React, Angular, JQuery apps out there that work, and would be too onerous to adapt to this style of prog
Read the rest
ramming, and too annoying to carry a second framework in prod (even if you bundle an electric app in your existing one, the runtime can be very big by web standards). I would love to see a framework built on top of electric that interfaces with any existing frontend as easily as it does now for any backend (Datomic is just one target of many for the spreadsheet Dustin built). I may try to explore this idea myself. But is the business of Hyperfiddle building instances of this new hypermedia, or the hypermedia system itself? I don't understand exactly what Dustin is selling me, at the end. Trying to sell this particular spreadsheet as a solution, or is it access to the runtime (electric 3)? How am I supposed to buy into a new programming model if I cannot use it?
In A Datomic entity browser for prod [video]
Repping team Hyperfiddle here, we are super proud of: https://github.com/hyperfiddle/electric – a fully reactive Clojure dialect for web development that uses a compiler to infer the frontend/backend boundary. (BTW, Electric v3: Differential Electric is nearly here – Differential Dataflow for UI) https://github.com/leonoel/missionary – Supervised dataflow programming for Clojure/Script. For full-stack web developers who struggle to build correct and glitch-free applications, Missionary is a reactive programming toolkit based on process supervision, that lets you build massively concurrent, fine-grained reactive systems on both frontend and backend. Unlike promises and go-routines that make it easy to write a broken program, Missionary’s combinators provide the right set of constraints to let you build a fully composable program that is al
Read the rest
so correct and bug-free.
In Ask HN: What's the state of Clojure's ecosystem and community these days?
electric has been a team effort, developed primarily by Geoffrey, Peter and especially Leo of https://github.com/leonoel/missionary who is the lead developer. the thing predating Electric is in prod at a series B startup, a series A startup is going live with a prod support app in a few weeks, and a seed stage startup is planning a rewrite of a consumer facing productivity tool onto electric after serious evaluation. Plus many serious POCs i’ve seen maybe 2-3 dozen repos this summer. (we only see them when they have a question)
In Electric Y Combinator – Electric Clojure
You're right, over-abstracting is a primary risk and has been top of mind for us since project conception in ~2012. ORM, for example, is a nightmare of over-abstraction (remember Spring Framework's AbstractSingletonProxyFactoryBean?). In fact, studying the O/R impedance mismatch from first principles back in ~2010 was what led me to functional programming in 2011. Electric is an attempt to find exactly the right level of abstraction. The goal is to remove and flatten layers, not add them, thus decreasing abstraction weight in the end if we succeed. Maybe we fail, but first let me share some details about how we think about this: 1. I've personally failed to build this project several times, Electric Clojure is something like the 7th attempt. 2. strong composition model as a starting point, based on category theory generalization of "funct
Read the rest
ion" -> "async function" -> "reactive function" -> "stream function" -> "distributed function". ORM does not have this. (This rigor is in response to the past failures.) 3. Functional effect system (monad stuff) at the bottom, which provides strong semantics guarantees about glitch-free reactive propagation, process supervision (like Erlang) (transparent propagation of cancellation and failure), strong resource cleanup guarantees (DOM nodes can never be left hanging, event handlers can never fail to be detached and disposed). Already this results in tighter operational semantics than we have ever achieved with manual resource management (and, again, we tried, see past failures). Our functional effects library: https://github.com/leonoel/missionary 4. Electric affords the programmer trapdoors to the underlying FRP/concurrency primitives. Electric is essentially a Clojure-to-FRP compiler, so if you code raw concurrency and effect management, that actually typechecks with what Electric generates, allowing seamless transition in and out of the abstraction. 5. 3k LOC + 3k test LOC is the size of Electric today (includes a rewrite of the Clojure analyzer). Spring Framework is, let me go check, 59k just for `spring-core/src/main/java`, and there are like 20 other modules I excluded. Indeed it is not a fair comparison but certainly we have complexity budget to spare.
In Electric Clojure – A signals DSL for full-stack web UI
(Founder here; I'll address the debugging concern in a separate comment) Here's a demo of React.js interop via Reagent, the wrapper is 25 LOC: https://gist.github.com/dustingetz/9854d23037b55bfab3845539f... Our DOM module is only 300 LOC - it's bare metal DOM point writes + Electric (reactive language) + macros for JSX-y syntax. When the programming language itself is reactive, DOM rendering falls out for free. Mechanically, Electric is comparable to Solid.js except the reactive engine is general purpose, not coupled to DOM rendering, which is a special case of incremental view maintenance. Electric's reactive engine is https://github.com/leonoel/missionary ; Electric can be seen as a Clojure to Missionary compiler (if you ignore the distribution stuff - which btw is optional). Missionary is cross-platform functional effect and streaming
Read the rest
system that today is tested on JVM, Node and Browser platforms. Missionary was created by Léo Noel, who is also the architect of Electric.
In Electric Clojure – A signals DSL for full-stack web UI
I can't remember where but Rich Hickey at one point said himself web development isn't a solved problem If you agree web development isn't a solved problem, do you want to couple your entire language to a massive framework that is committed to solving an un-solved problem in the general sense using technique X that presumably will need to be replaced Y years down the line? Or not work in situation Z Personally I don't want that for Clojure, instead I see lots of different approaches in Clojure (and some outside) that could be the next big thing: - https://www.hyperfiddle.net/ - https://github.com/whamtet/ctmx - https://github.com/leonoel/missionary - Unison Ultimately I want to go long on my programming language and short on "the one true framework" until we have a one size fits all approach for solving the general problem of web developm
Read the rest
ent, until then give me low coupling libraries that I can mix and match And that's exactly what Clojure is doing right now, maybe in the end it will be something like chatgpt just mix and matching the approaches for you but for now I'm personally not looking for a framework to be the only way to use Clojure
In Structuring Clojure applications
Multi-threaded code is normally not implemented in an async style, but instead is done where each thread of execution is synchronous. Async style comes into play generally for languages that lack real threads, or as a way to manage callbacks (even if single threaded), or in order to wait for blocking IO without the need for a real thread. So ya, it's idiomatic to use blocking to coordinate between different threads in Clojure, same as Java. Java decided to work on making stackful coroutines instead of stackless like C#. That requires a lot more work, but should be coming eventually to Java. At that point, your "blocking" code in Clojure will no longer block a real thread, but a lightweight fiber instead. But patience is needed for it. In the meantime, if you're dealing with non-blocking IO that operates with callback semantics or other ca
Read the rest
llback style code, what you can do in Clojure to make working with that easier is use one of: > core.async - https://github.com/clojure/core.async > Promesa - https://github.com/funcool/promesa > Missionary - https://github.com/leonoel/missionary > Missionary's lower level coroutine lib - https://github.com/leonoel/cloroutine/blob/master/doc/02-asy...
In Six Years of Professional Clojure
Clojure's lispyness is massively underrated. At Hyperfiddle we have a fully reactive Clojure/Script dialect, backed by a functional effect system https://github.com/leonoel/missionary. Our reactive clojure can also distribute across the client/server system, like distributed map reduce. Imagine React.js but full stack, incremental view maintenance all the way from database views to DOM views as one streaming computation. We implement a custom analyser like core.async for full compatibility with host clojure, including preexisting macros, so it gets destructuring, control flow, higher order logic, it's a first class Clojure in every way. What you are measuring I think is that metaprogramming is hard, the books and papers about it are hard, the intersection of metaprogramming with functional programming isn't even well understood in researc
Read the rest
h, and businesses don't invest in hard things so you won't get paid to learn any of this.
In Data notation in Clojure

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.