Good videos, with context.
"Transducers" by Rich Hickey

"Transducers" by Rich Hickey

Strange Loop Conference
6 HN recommenders · discussed 2014–2025
Open YouTube ↗

About this video

Rich Hickey introduces transducers in Clojure, a way to make map, filter and similar algorithms composable independent of the data source. This avoids duplicated implementations and intermediate collections across sequences, channels and streams.

Why it appears in the archive

HN treats it as the original and definitive explanation of transducers, recommended whenever the concept comes up.

AI-generated summary and labels from the source dataset; verify important details against the video. Source & credits.

From the Hacker News discussion

jwr · 2025-11 · strong rec

Transducers are IMHO one of the most under-appreciated features of Clojure. If you want a really good intro, watch Rich Hickey's talk about transducers: [VIDEO] (Rich is an excellent speaker and most of his talks are really worth watching, even if you don't use Clojure). The thing about transducers is that once you start using them, the abstractions click in your mind and you start using them more and more in your code. Many things our software does can be looked at as pipelines, and transducers let you write composable functions and put them together into pipelines. As you see more pipelines in your code, you will write those composable functions and reuse them in various places. Experienced Clojure programmers will rarely use loops, for me transducers are the #1 choice whenever I have to process a collection of any kind. Their efficiency (no intermediate collections!) is a nice bonus — you get both high-level composable code and efficiency, which is incredible. One thing I dislike about transducers is when I need a stateful one: these are hard to understand and very difficult to write. I rarely do this, except when I really want to stick to the transducer abstraction and I have a couple of hours to spend on a puzzle. But you rarely need to write your own stateful transducers, usually the built-in ones are enough (things like take/drop).

Read original comment ↗
rymohr · 2014-10 · rec

That and they're collection agnostic. I highly recommend watching Rich Hickey's talk for more background: [VIDEO]

Read original comment ↗
ultimape · 2014-11 · rec

Here's another video by Rick Hickey about transducers: [VIDEO] - it was referenced in this great post detailing the transducer notion with Clojure, Scala, and Haskell: [LINK]

Read original comment ↗
talkingtab · 2022-11 · rec

Transducers. See Richard Hickey's talk about transducers here: [VIDEO] You can implement transducers in JavaScript using generators. It was somewhat mind bending but fun.

Read original comment ↗
devin · 2023-09 · rec

Rich gave a talk on this, and there is an associated HN thread for the talk, but some of you may be interested in the original transducers presentation. You can view it here: [VIDEO]

Read original comment ↗
ThatGeoGuy · 2024-08 · rec

Quick nit/question. For the fold method, I don't think I've seen it called sentinel value. Usually it is seed or initial? I think in Scheme it is common to call it knil, mirroring how lists use nil as the "sentinel" value which marks the end of a proper list. I opted to name it sentinel in that article (and in the docs) for two reasons: 1. Sentinel values are a common topic in many languages [LINK] 2. Transducers necessarily abstract across a lot more than loops / lists. Lisps do a lot of really cool (and optimized) stuff with lists alone and Scheme is no different in this regard. However, because of how Scheme primarily exports list operations in (scheme base) is really easy to run into a situation where lists are used in an ad-hoc way where another data structure is more appropriate. This includes vectors, sets, mappings, hashmaps, etc. Transducers-the-library is meant to be general across operations that work on all of these types, so I chose language that intentionally departs from thinking in a list-focused way. Now, my main question. Transducer? I'm curious on the etymology of that word. By itself, I don't think I could ever guess what it was referencing. :( This is from Rich Hickey's presentation: [VIDEO] It's not a reducer, because they serve as higher-order functions that operate on reducers. Instead, the values they accept are transient through the function(s), so they transduce. You should watch the video, I think Rich explains the origins of his language very well

Read original comment ↗
asolove · 2014-10 · reference

Rich brought this up in his Strange Loop talk [1]. All the attempts he had seen either disallowed perfectly valid uses or allowed invalid ones. I believe to really guarantee early termination and a few other tricky invariants of reducers you would need a linear type system. [2] [1] [VIDEO] [2] [LINK]

Read original comment ↗
brandonbloom · 2014-10 · reference

This is interesting, but it's still missing some very important features of transducers. As you alluded, stateful operations [1] won't work at all in your Haskell model. Also, you've missed early termination [2], which Rich's talk [3] covered well. [1] [LINK] [2] [LINK] [3] [VIDEO]

Read original comment ↗