“Clojure concurrency” talk transcript (Rich Hickey, 2008)
2 points · Open discussionmatthiasn
talk-transcripts
Languages & Compilers2014–2026
matthiasn / talk-transcripts
talk-transcripts
Transcripts of Clojure-related talks
69Distinct people
102Mentions
3Explicit recommenders
3.1KGitHub stars
What to know before exploring
What it is
Transcripts of Clojure-related talks
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
This is tangentially related to Puzzles-vs-Problems in Rich Hickey's Effective Programs > Eventually I got back to scheduling and again wrote a new kind of scheduling system in…
ndr used a recommendation phrase. 3 indexed comments match. 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, 3:30:57 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 year102 dated mentions
Observed mentions: 2014-10-30 13:16:39 UTC to 2026-09-04 09:57:52 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 |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 5 | 2 | 3 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 13 | 2 | 11 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 11 | 9 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 12 | 5 | 7 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 11 | 1 | 10 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 8 | 2 | 6 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 13 | 1 | 12 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 6 | 2 | 4 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
talk-transcripts
This is a compilation of transcripts of talks that I find interesting. I learn better when I read something rather than hearing it, and I have a hunch that I'm not the only one who feels that way. So I thought I'd make the talks more accessible to anyone for whom listening to the talks might not be the most viable or simply not the most preferred option.
Please, if you read any of the transcripts and find that a URL is mentioned in the talk and you go look it up, can you submit a pull request turning that into an actual link in the transcript? It is really simple, just click on the pencil button above the document and turn the mention in the text into a markdown-style link like this: **[blah.com or whatever was in the transcript](http://blah.com)**. Thanks, you're making the transcripts more useful.
For more information on this project, please read this blog post.
Read the full README on GitHubWhat Hacker News says
12 sourcesRich Hickey: Clojure for Java Programmers (2008)
2 points · Open discussionTranscript for this and many other talks is available in this repository: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
In Clojure: Effective Programs (Rich Hickey, 2017)That's great. It reminds me of a comment by Rich Hickey, the inventor of Clojure:
" Before we had all this high falutin' opinions of ourselves as programmers and computer scientists and stuff like that, programming used to be called data processing.
How many people actually do data processing in their programs? You can raise your hands. We all do, right? This is what most programs do. You take some information in, somebody typed some stuff, somebody sends you a message, you put it somewhere. Later you try to find it. You put it on the screen. You send it to somebody else.
That is what most programs do most of the time. Sure, there is a computational aspect to programs. There is quality of implementation issues to this, but there is nothing wrong with saying: programs process data. Because data is information. Information systems ... this
Read the rest
should be what we are doing, right?
We are the stewards of the world's information. And information is just data. It is not a complex thing. It is not an elaborate thing. It is a simple thing, until we programmers start touching it.
So we have data processing. Most programs do this. There are very few programs that do not.
And data is a fundamentally simple thing. Data is just raw immutable information. So that is the first point. Data is immutable. If you make a data structure, you can start messing with that, but actual data is immutable. So if you have a representation for it that is also immutable, you are capturing its essence better than if you start fiddling around.
And that is what happens. Languages fiddle around. They elaborate on data. They add types. They add methods. They make data active. They make data mutable. They make data movable. They turn it into an agent, or some active thing. And at that point they are ruining it. At least, they are moving it away from what it is."
https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
Disclaimer: I don’t think it’s _flawed_. It’s simple and useful But it has some flaws in some situations - I would describe it as “less than ideal”. Rich Hickey describes some problems here: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
In Why async fn in traits are hardDoes anyone know where/when this talk was given? It looks fairly similar to another one Rich Hickey gave at QCon 2012 on Datomic, with a transcript and link to video for that talk available here: https://github.com/matthiasn/talk-transcripts/blob/master/Hi... but note that the slides and talk are not identical to that one, and that recording is missing a few minutes at the beginning.
In Datomic with Rich HickeyProblem Solving and Clojure 1.9 (2018)
95 points · Open discussionHow to Think about Parallel Programming: Not (Guy Steele, Strangeloop, 2010)
2 points · Open discussionA somewhat nicer transcript here: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
plus a bunch more Rich Hickey talk transcripts in the same repository, with links to videos if you prefer, in that same Github repo.
In Clojure for Lisp Programmers (2008)Simple != Easy
I highly recommend this Rich Hickey talk (transcription):
https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
In Agile Lite: Agile without all the burnoutNever used Lisp, but huge Clojure user, the real innovation is the immutable data structures:
RICH HICKEY: Ok, so, problem number one on that list was place oriented programming. Absolutely, this is the problem. Almost all the programs I wrote, lots of the things on that list were multi-threaded programs, you know, they're crazy hard in C++. Just impossible to get right, when you adopt a normal mutability approach, you know, mutable objects. So, this is the number one self-inflicted programming problem. It seemed, you know, clear to me that the answer was to make functional programming and immutable data the default idiom. So the challenge I had was, were there data structures that would be fast enough to say, "we could swap this for that". And the objective I had, the goal I had was to get within 2x for reads and 4x for writes. And I did
Read the rest
a lot of work on this, this was actually the main research work behind Clojure, was about these persistent data structures. Eventually I found...you know I looked at Okasaki's stuff and, you know, the fully functional approach and none of that gets here. And then I found Bagwell's structures were not persistent, but I realized could be made so, and they just have tremendously great characteristics combining the persistence with the way they're laid out, the way memory works. They made it. They made this bar, and I was able to get my friend to try my programming language. You know, we (?) have large library of pure functions to support this, and, you know, immutable local bindings. Basically if you fall into Clojure, your first hurdle is not the parentheses, right? It's this, this functional paradigm, everything is gone, there's no mutable variables, there's no state, there's no mutable collections and everything else, but there's a lot of support, there's a big library. You just have to, you know, sort of learn the idioms. So I think this was straight-forward, the critical thing that's different about Clojure is, by the time I was doing Clojure, the people who invented this stuff had adopted a lot more, right? I think most of the adherents in the functional programming community considered functional programming to be about typed functional programming, statically typed functional programming is functional programming. And I don't think so, I think that this is, you know, this falls clearly in the 80/20 rule. And I think the split here is more like 99/1. The value props are all on this side, and I think Clojure users get a sense of that, they get a feel for that. This is the thing that makes you sleep at night.
https://github.com/matthiasn/talk-transcripts/blob/master/Hi...