How one programmer's pet project changed how we think about software

For a long time, we had an ongoing joke that we'd misread a fortune cookie, that he'd received a fortune cookie that said, "You will be rich and famous, and that we thought it meant he'd be wealthy." But no, it meant that he was already named rich, and that he would be famous doing open- source software, which nobody would ever pay for. I think what makes programming languages interesting and also difficult to an extent is that a programming language is an encoding of a philosophy of how to think about code and closure definitely has a philosophy that is different than other languages. Fundamentally what is closure about? Can we make programs out of simpler stuff? It introduced a whole community of developers to an idea that you can build a program out of pure functions on immutable data structures. So I I'm trying to provoke you today to just reconsider some fundamental things. I just didn't get it. So my first experiences this is a crazy language made by a lisp fanatic for other lisp hobbyists. I really didn't take it seriously. Closure is the language for cranky, tired, old programmers. Open source means a lot of different things to different people. When you open source something, you don't owe anybody anything. Like, you're giving something away for free. I did make it for myself, which I think is an important thing to do. It's just different. It's different from what people expected from programming language projects. My name is Richiki and I'm the creator of Closure. I got into programming for music using computers for recording was still before you were able to record audio in a computer. But I was definitely intrigued by the software that was being used and eventually taught myself how to make similar software and taught myself C and started programming. It was a great time to be an enthusiast in programming languages. There weren't languages that were dominant. There were articles, you know, about lisp and prologue and various languages that would never become mainstream because it was still sort of an open field. It wasn't as entrenched as it's become now in terms of there's a few very dominant programming languages. Around 2000, I got a proper common list environment, Lisp Works. I was just blown away. I I basically thought to myself, what have I been doing, you know, with my with my life, with my time? My name is Eric Thorson. My organization was the earliest adopters of closure. I used to work for this chain of music stores and Rich was setting up a recording studio. One of the things you get to do when you start a new recording studio from scratch is buy a lot of gear. And he worked at a music store, uh, the nearest music store to my studio. We got to talking and he casually mentions that he's writing some editing software for this digital sampler which kind of blew my mind because I thought only like companies could do those kinds of things you know they had to be like Yamaha to do something like that. So I was very impressed. He was doing some database programming, dbase I think at the time and I was teaching myself C, you know, because I got intrigued by the music software I was using in the studio and eventually sort of got to know each other as programmers as we both became programmers. At some point, I had the courage to pick up the phone and I called him up and I asked him to tell me everything he was reading, which he did. Uh and that became uh the beginning of a a long-term friendship that I've had for uh almost four decades now. What's some of your uh uh background uh in in computing and language design and that kind of thing? Uh I've been working as a professional programmer for a couple of decades uh specializing mostly in broadcast automation and scheduling systems. Um also the national exipole and various uh machine listening kinds of problems. At some point he started getting into lisp told me to get the on list book by Paul Graham and I had actually thought at that time I knew rich probably for 15 years he sort of lost his mind like I mean it's so far off of anything that's commercially viable. Why is why is he looking at that? At the time I was working on yield management systems and other you know schedulers uh for from music software. It was much better being able to be focusing on the problem and not trying to get the language to do what I wanted. Coming up to 2005, I was working more and more as a consultant and I started to do some of the consulting work in common list. It was so easy to do. The problem was having written something on common lisp the my client the radio software company said we have no one who knows common lisp and we don't want any common lisp and I actually ended up taking this yield management system and having the common lisp code generate SQL code uh which they were familiar with and they were ready to to run and I encountered that a few times on a project I'd design something in common lisp and they'd say okay that looks great can you give it to us in C++ because that's what we know. And so I was rewriting things from common list into C++. And even though I was an expert in C++ and sort of a newcomer to common lisp, it took me longer to rewrite in C++ than it did to write it the first time in common list. And I said, this is this is a definite problem. That friction between how easy it was to express what he wanted to in lisp and how hard it was to do that in C++ at the time is part of what happened with closure. He was solving a separate problem but he was so frustrated by that he's like I want to have what I get from lisp into something I can use commercially. Uh when I started uh doing closure uh in 2005 I had already been programming for 18 years. So I had had it. I was done. I was tired of it. So I had done a few projects to try to bridge the gap to make it so that I could use common list but somehow connect to something my clients were willing to run. One wasp which was a lisp interpreter that targeted net cuz we were doing net development. And then jfly was a way to embed the java virtual machine in common lisp. And then foil was a way to have common list talk over a wire to Java or the CLR to the net runtime. I didn't know how he was going to make this work. And then when he started to tell me he was going to build these translators where he's going to have a lisp dialect and then have it generate Java code and another one generate C# code. These all let me write common Lisp code and interact with something that clients wanted. But the client still didn't want want that. And so I started thinking about how could I maybe compile this language into the JVM's by code or into the CLR. And that was the initial impetus for maybe I should write a programming language. There's no reason to write a new programming language unless you're going to try to take on some problems. You should look at what the problems are. I mean, why was I unhappy as a programmer after 18 years and said, "If I can't switch to something like common list, I am going to switch careers." Why am I saying that? I'm Stephanie Hickeyi. I'm Rich's wife and I've been his partner for about 20 years. My first impression of Rich was that he was very sweet with a super strong core of integrity, strength, principle. He's very smart, very thoughtful. um I would say old-fashioned in the best way. Having thought of maybe I should write a programming language, I found myself possibly able to take some time to do that. I have some money I could use for my retirement or I could use to sort of fund a sbatical, a self-funded sbatical. And I decided I would I would take two years and work on whatever I thought made sense to me. It wasn't a surprise to me. It was very consistent with who he was and what he um aspired to which sort of to be a serial inventor and to have the freedom to invent. You really need to be literally free to invent and and just to have this the headsp space to work on whatever was compelling was really important. Um at the same time, you know, oh my god, that's a big leap of faith. So these are the papers that comprise the research for closure. I've divided them up into a few subject areas. This whole column is papers about lisps and lisp techniques, equality, binding, arity, closures, a little stream fusion. This is a set of papers about other programming languages. self and small talk, Lua uh Scheme, Haskell, Erlang. The set of papers is about the JVM and compiling to the JVM bike code also other languages and how they did it and what their experience was. This the biggest of all piles is about dispatch type classes dynamic dispatch predicate dispatch common list object system and what's interesting about this is that this was all in support of something I decided not to do in the end which was give closure and object system but I read all this before I decided it was a bad idea this set of papers is all about the persistent data structures are really about functional data structures and finally the Phil Bagwell paper which was the inspiration for closures persistent data structures and finally this whole column was research behind software transactional memory and a lot obviously of Haskell papers on that was all the things I read on the hammock working is about the thinking time more so than the typing it in time. One of the great things about having taken a sbatical was I was able to say I don't care about the outcome and not being outcome oriented lets you examine everything because you're not prejudging it by its you know validity in terms of what it could mean to other people. for the whole development process of closure. We talked so so much. What Steph did for me that was just the most valuable gift possible was she was willing to listen to me go on and on. It was a funny time because if I said, "How are you? What are you thinking about? What did what did you do today?" We really This is what we talked about at breakfast, at lunch, at dinner. I needed that. I needed to be able to talk about what I was engaged with. and she was willing, which was a major gift. I got a master's degree at night and it was moderately helpful for my career, but I would say it was super helpful for my marriage. And we had a joke, if you remember the old Mastercard commercials, master's degree, $30,000, understanding what your husband's talking about, priceless. What nobody else will ever see is that I probably have 25,000 hours invested in closure without touching anything ever. Just learning enough that I could be hopefully a support and a sounding board. I knew the storytelling around closure had to be such that even though it was a functional language, it had to have a credible story for doing mutation and the things programmers in the at the end of the day they need to do to get their jobs done. So software transactional memory seemed to be uh a thing that would cover their needs. It ends up that once you start programming in a functional manner, you don't need it that much. But at the time I couldn't know that whether or not it would work, you know, there sort of two levels. Does it work technically? Does it do what it's supposed to do? And you know, would anybody be interested in trying it? The latter I was definitely unsure of. In fact, pretty sure it would be it would be forever a very very small set of people, if any, that would try it. Well, guys, welcome to Lispen NYC. Tonight we have uh Rich Hickey. He's going to be talking about closure. A couple nights ago, I walked down to Lisp NYC in the East Village to hear Rich Hickey talk about closure, his new lisplike language. To be honest, I wasn't expecting much. Another lisp. Ho h. I'm sure it's very clever and cool and all, but not something I can actually use. Instead, I was blown away by Rich's presentation. Closure might just be the lisp I've been waiting for. My name is Rich Hickey. I'm just a regular old software developer. I've been doing it for about 20 years. I'm Alisandra Sierra. I was an early uh participant in the Closure community and I wrote some of the libraries that eventually became part of the Closure Standard Library. Lispen NYC used to meet in a small church on the Lower East Side of Manhattan and a bunch of nerdy people would get together once a month and talk about Lisp. The nature of the meetup was lisp programmers and it was actually quite common for people to come by and show their pet lisp, you know, their toy lisp or something that they had built. His talk was probably more polished and prepared than a lot of the hey look at my new language talks that people did. And there was definitely a lot of interest and uh excitement in the room. There's a phrase called talk-driven development. And talk driven development is when you agree to a speaking engagement and the thing you agree to speak about isn't yet finished. So it was a very busy, you know, 6 weeks in there or whatever it was between when I agreed and when I gave the talk. Well, first, why don't you just tell me what closure is? Closure is a a dynamic language. Um, it's a dialect of lisp and it's really founded on four four ideas. You know, if you're going to say closure has four legs, it's functional programming, lisp, uh being hosted on Java, and the fourth is uh concurrency. I'm Alex Miller. I have been on the closure core team since 2013, and I work as the Closure team lead at New Bank. The first time I saw or heard about Closure was Stuart Halloway's blog series looking for the next Java, investigating different languages on the JVM that were all sort of coming out at that time. My name is Stuart Halloway and I am an architect in global platforms at New Bank and I've been working in closure since 2008 in the mid 2000s. You know, languages had kind of fragmented. We'd gone from like everybody must work in C or C++ and Java to there were a lot of things out there that were possible. I had become aware of the possibility of using a lisp uh reading Paul Graham. I think a lot of people read Paul Graham in those days. Beating the Averages and Revenge of the Nerds essays about you know what matters in a programming language. People say that they don't like Lisp because you know it doesn't talk to the operating system or it's not they can't hire people with programming in it. Maybe it's just that they're terrified of they look at the programming and think oh my god you know um I don't know I don't know and it really matters. I'm not sure what to do about this. I'm Showzer and I'm co-author of Joy of Closure and have been using Closure since very nearly the beginning. I've always been hunting for a language that uh you know checked all the boxes the things that I wanted it to be able to do. Pols on list book really convinced me that I I wanted to use a lisp but common lisp didn't work well for me for the project I was trying to do. It didn't have the libraries that I wanted at least I couldn't find them. My name is Mike Fogus. Uh I am a member of the core team working on closure uh on a daily basis. I was looking to get into a lisp. I was looking to discover that mystical side that that that Paul Graham was talking about. And so I'd looked at common lisp and was trying to figure out, you know, how do I actually take that and like get it rolling somewhere and then I noticed on a mailing list or somewhere, I don't even remember, somebody had created a lisp that was targeting the Java virtual machine. And so now it's like you don't have to solve the problem about how do I run this, right? In Java, everybody's a JAR file. doesn't really it doesn't really matter you know where it came from. So that part of the question was solved and so I started looking at uh closure and at the same time I looked at other languages that were offering more expressivity on the JVM closure and groovy and scala and ruby were all coming onto the scene and people were like maybe there's other ways to do these things and I felt like all just for a little bit the world kind of opened up and people were trying things. So everybody has different languages and groovy and whatnot and they love the differences between these languages and I want you to focus on the similarities between these languages which is they're all single dispatch stateful object-oriented languages. I did a series of blog posts called java.next next where I was trying out a bunch of different languages and I had originally intended to do I don't know some arbitrarily large and lengthy comparison but by the time I got through the fourth blog post I just stopped thinking about the other languages and kind of committed myself to closure. If you rewind the software world to 2007 and say, you know what, I have a solution for you. It's a dynamic functional hosted lisp. Asked for no one ever. Nobody was looking for that. My name is David Nolan. I am the lead developer of Closure Script. What I liked about Closure, especially like the standard library, you sort of see the entire language being built up from a very simple thing and by the end you get all the language features. And then closure took that and added this innovation which was like you know very nicely designed um persistent data structures to go along with all the good ideas that lisp already had. The cool thing about closure is that it's fully integrates with the Java programming language. I think one of the problems with lisps in the past is the lack of uh library support. Um but by um you know being on top of the JVM that problem is solved in closure. And Closure definitely has a lot of traction and quite a strong growing community. There's a lot of parentheses in Lisp and part of what was really nice about Closure is there was far fewer parenthesis and more use of other symbols to make the code a lot easier to understand. The other thing that was really exciting when I first started to use Closure is it always seemed to do what you wanted it to by default. The core ideas are building everything out of a small set of universal data structures. List, vector, map, and set, which covers a huge range of different kinds of things that you might want to represent or work with. I was doing a lot of work with concurrency at the time. We were getting these massively multi-core chips and we were trying to build programs that could leverage those things. And I had done a lot of concurrent programming in Java and it's something that's very errorprone. You have to use a lot of locking and know about a lot of techniques to make that safe and closure's approach was really to focus on immutable data which meant that whole classes of problems just didn't exist anymore. What is your favorite non-Java JVM language? Uh so that one's a pretty easy one and that's Closure. One of the things that closure forces you to think about ahead of time is resilience. You see that people are able to, you know, get a lot of work done with a surprisingly small amount of code, but then continue to evolve those systems as requirements and and goals change because of the the focus that closure uh sort of pushes on you of everything's going to change around you and you need to, you know, just accept that that's going to happen. The biggest thing I think the most desirable thing the most esoteric this is tough to get but boy when you have it your life is completely totally different thing is polymorphism alakart right closure protocols and hasll type classes um and and constructs like that um give you the ability to independently say I have data structures I have definitions of sets of functions and I can connect them together and those are three independent operations In other words, the generosity is not tied to anything in particular. It's available alakart. It also just seemed to be a practical language. It was designed for solving real problems. It wasn't a toy or an experiment. It was uh a real working language for working programmers. Closure is really fast. Um there's 10 times as much closure as I've shown you. Uh but it does fill a nice niche. There is no dynamic functional language on the JVM. Now there is it's closure and uh I've only been out for a little bit less than a year and uptake has been rapid extremely rapid. So when I first joined the IRC channel on Freode February 1st 2008 besides Rich and myself there was only one other person there. So I continued to work on closure and I would just have the IRC open all the time and whenever I was around people could hop in there and ask questions and I'd answer them and there was a lot of dialogue then with the very first few people who were there. I found it very exciting that there was an avenue for me to go and talk to the creator of the language and have an impact on the way that the language was was was evolving. Rich did take his time to sit on the IRC channel and talk to people and explain why the language was built the way that it was, what the value propositions were, and even at the time would take recommendations for functions that people felt were missing or or behaviors that they felt were not quite right. The Lisp community had a had a kind of a reputation of being not terribly welcoming is probably the easiest way I could say that. And I think he really wanted to make sure that this was nothing like that. any question that came up, he was on top of it all. It seemed like almost 24/7, like he was just monitoring the chats and making sure he was supporting people the whole way. Rich in no uncertain terms said that we were a community about support, mutual respect, actionable criticism, and we wouldn't tolerate anything less than that. Today, so many years later, just seeing that that still continues through the community is is kind of amazing. and and and through force of will, Rich brought that about and and I can't say the same about many other programming communities. Oracle and other people have adopted modified versions of this post to a mailing list uh as uh standards for how to behave in other communities. So I joined the RSC channel and it was kind of a great environment that all different types of programmers whether it was Java programmers, Python, Ruby programmers, C, C++, whatever. It was just like a interesting group of people with lots of different backgrounds and you know we were all in this channel being like how do we use this programming language and like functional programming cuz to be honest I would say that like not that many people that were trying closure at the time were like familiar with things like Haskell which has a much more rigorous approach to functional programming. So the early days of the community were really cool. There was a lot of knowledge sharing about like what's the best way to express this pattern. coming from imperative programming, there's just a lot of things to unlearn. It's one of the anecdotes of closure that, you know, we got to 100 people on the mailing list, which was a very high number. I thought that would be the maximum number of people who would find out about it and try it. But when I saw it reach that in the time frame it did, you know, I said to Steph, you know, we might get to 500 people on this list. And he's like, oh, maybe we'll get to 500, maybe we'll get to a,000. And I know I'm supposed to be the support of life, but I but I was very much like, don't count on it. This is niche software. Um yeah, don't count on it. And of course, he ended up at something like 30,000 followers and um yeah, a huge audience for his recorded talks. The other critical thing about simple as we've just described it right is if something is interled or not um that's sort of an objective thing you can probably go and look and see I don't see any connections I don't see anywhere where this twist was something else so simple is actually an objective notion that's also very important in deciding the difference between simple and easy closure popularity was really closely tied to Rich's ability as a communicator and his willingness to go and communicate in a bunch of places. He was talking at the time about the nature of time and identity and how software needs to reflect processes in the real world and what that means for identity and time and state. And I think that was an early who is this guy and where did he come from moment. The work that we're in is conceptual work. So when we talk start talking about something being outside of our capability, well, you know, it really starts trampling on our our egos in a big way. You do have to take um your great ideas and figure out if they're actually great. Unfortunately, I think we continue to use placeoriented programming um and the rationale is gone. And the the sadder thing is we continue to make new things that are like this, brand new programming languages and brand new databases. A big part of the adoption of closure were the sets of talks that I had given and you know that started with the first lisp NYC group but over the first you know year or so I had about nine talks that I was invited to give and then the talks became you know keynote talks uh at various places including strange loop and the simple made easy talk. I invited Rich to Strange Loop because I knew that he was a great speaker and that he had a vision that he was really trying to bring to the world of programming. I was there to see simple made easy. That was a huge huge talk. I constantly come back to that. And the critical thing to distinguish it from simple is that easy is relative, right? Playing the violin and reading German are really hard for me. They're easy for other people, certain other people. Uh so unlike simple where we can go and look for interleings, look for braiding, easy is always going to be, you know, easy for whom or hard for whom. It's a relative term. Before I got on the plane to fly out to the conference, I I did not like it. I don't really know why because it ends up I didn't change it much. He's just like, "It's not that strong. It's not that insightful. It's not that technical." I was going to be the last talk of the conference and so for 3 days I was holed up in my hotel room missing the conference sort of finessing the talk wondering you know if it made sense to someone other than me. user is not looking at our software and they don't actually care very much about how good a time we had when we were writing it, right? What they care about is what the program does and the and if it works well, it will it will be related to whether or not um the output of those constructs more simple. In other words, what what complexity do they yield? When there is complexity there, um we're going to call that incidental complexity, right? It wasn't part of what the user asked us to do. We chose the tool. It had some inherent complexity in it. Um it's incidental to the problem. I didn't put the definition in here. Um but um incidental is Latin for your fault. The people that were there were looking for something. They were seeking you know languages and ideas. So it was just that perfect confluence of uh the right right speaker and the right audience at the right time. People watch and they really love it. I think yeah I think that people really feel it within themselves that there's a lot of complexity in software and we have a lot of trouble managing it. In particular if you want everything to be familiar you will never learn anything new cuz it can't be significantly different from what you already know and not drift away from the familiarity. That talk is responsible for more people investigating closure than any other. It's certainly the most popular talk I've given by a lot. I have never watched this presentation and everybody has said this is the greatest presentation of all time. Simple made easy rich hickey 2011. I kind of feel like I've missed out on some lore here. If you take away two things from this talk, um one would be the difference between the word simple and easy. The other I would hope would be the fact that we can create precisely the same programs we're creating right now with these tools of complexity with dramatically drastically simpler tools. All of a sudden, I was a very in demand public speaker being asked to talk at all these conferences. Thanks very much for inviting me. I was told they uh they always like to have somebody who's really way outside of the community. So that would be me. It was exciting. It was quite exhausting. So I did it, you know, very intensely probably for five years. That was critical, I think, to expose Closure sideways. The creator of Closure is giving this talk. So maybe you look at closure if the talk is interesting. There's a huge number of benefits to to using values. We recognize them, right? Look at our information systems that we use for ourselves. We're proving we already know this. We don't overwrite our logs. We don't override our source control. We're already we're in the space age for ourselves, but we need to be in the space age for the businesses we're supporting. When you think about his talks, closure is in them often, but that's not what the talk is about. It's almost always about the problem space he's discussing and some often new approach or perspective and then he may introduce a feature of closure that may address this, but it's often about the bigger problem. Those early talks enabled people to engage with the set of ideas instead of just walking up to something that looked different and trying to figure out why those differences would matter. The bottom line is simplicity is a choice. It's your fault if you don't have a simple system. And and I I think we have a culture of complexity. To the extent we all continue to use these tools that have complex outputs, we're just in a rut. We're just self-reinforcing. around the time of the 1.0 release. It was definitely a big deal. It was a major milestone. Probably a lot of us never even thought it would get that far that there would be something that we could call a stable production release. I met Rich Hickey at the JVM language summit and I had already been following the closure community and Rich and I had been exchanging emails. So definitely went um with the intention of meeting him and getting to know him better, which I did. At some point, Stu came up to me and said, "Hi, I'm Stu Holloway and I want to write a book about closure." And I said, "Great." He kept working on the book and running stuff by me and trying things. And eventually, you know, he and the publisher said, "Boy, it would be great if this book targeted a 0 release version of Closure." I don't think it's necessarily critical that one came first versus the other, but I think it's important that they were reasonably close. The reason is that, you know, having a book is kind of like a small mark of validation for a programming language. We're back on the No Fluff Just Stuff 2009 tour and today I'm with Stuart Halloway and Stuart has a new book just uh coming out. Actually, it just came out on programming closure. Stu, why don't you uh share with us where you see the value ad with Closure within the JVM space? I went back and looked at the chat room logs around the time of Closure 1.0's release, and I had forgotten how much it was sort of teased, and we were talking about it for months before Rich decided we were there. I think I remember him saying, maybe not in the chat room, but talking about pouring concrete on it, right? Like before 1.0, we were still sort of okay making breaking changes, but uh after 1.0, know we wanted to sort of lock it down right so I released closure 1.0 May 4th 2009 announced it on the closure blog it was the point that solidified the language okay this is what closure is and there were obviously changes after that and a lot of additions but the core didn't really change again closure code written for version 1.0 0 almost certainly should still work today. Now, that 1.0 release was the last.0 release of closure because I'm not I'm not actually a big fan of uh version numbers and and what they mean, but uh it did matter a lot to the community. I think again when you talk about barriers to adoption, if a language isn't at 1.0, people think it's unfinished. I think the numbers are kind of arbitrary, but anyway, it was a it was a milestone and we we met it and uh yeah, most of the code that he put in that book still works. In 2011, I watched Simple Made Easy and I thought, well, this guy doesn't sound crazy. He doesn't really sound like a fanatic except maybe for simplicity and practicality. And you know, he's really not all that esoteric except for maybe those Latin definitions are a little esoteric, but all the rest was intensely practical. And so I thought I have to give this a try. So over the next couple of years, I was having fun playing around with Closure, but I wasn't really ready to commit. My name is Kristoff Newman, and I'm the Closure developer advocate on the Closure Core team. After several years of my friend telling me about closure, finally I said, "Okay, I have to make a project. I have to try this." So my very first serious closure project was for an esports production with a hard deadline and a a lot of attention. The project was for Heroes of the Storm, and I needed to create a tool for that competition. A lot of the people who were coming to Closure were people like myself who had worked on these giant complicated systems and were just tired of it and and Closure let them create systems in a way that that really did bring joy back to programming. But I love to tell the story of when I first introduced Closure to my team, right? These are a bunch of senior software guys who were had done a ton of Java, C++, C. It was really fun to watch my developers get wickedly excited about what they were able to express in such a small amount of code that they were like sharing these little puzzles like oh look look you do this look at this look at this it was like this this uh fever that was going on in my in my company that people were like I want to use this can we use this thing and of course it's plugged into Java so you can use it my name is Eric Normand I've been using Closure since 2008 so I like to read old papers like research papers and very often you'll read something from the ' 70s that's like I built this little thing and and here's how it works and in something like Java like I couldn't imagine writing it like it's too big too complicated I have to make classes for this class for that but in closure I could do it in 100 lines and just try it out right so it's it's like a language that gets out of your way and lets you uh express things really concisely, it basically opens up this world that's been forgotten because we're just moving so fast into the future in our industry. My name is Nathan Mars. I've been programming Closure primarily for 15 years. The reason I just really enjoy using it on a daily basis is that I feel like I'm always working on impactful code as opposed to just like code that just has to be there because of the restrictions of the language. If there's any sort of repetition in anything you're doing, you can abstract that away whether with a function, right? Or if you can't do it with a function, then you should be able to do it with a macro. Every line of code I write in closure matters. So I was trying to learn new ways of solving problems that I already knew how to solve, but the limitations of closure, the intentional limitations of closure made it so that those solutions were not really available. So I had to figure out new ways of solving a problem. And I had to do that on a deadline. And so some of those coding sessions were very long and very late. But I got it done. I went to the event and it was exhilarating. Fewer language constructs, fewer demands, less hoops you have to jump through. By separating time, state, and behavior, you don't have to hold all that in your head. So, it's a low cognitive load. The problem is central, not the language demands. We're talking to Aaron Bedra and he has a company called Relevance. Could you tell us a little bit about what your company does? Uh so relevance is a software consultancy uh started in 2003 by Stuart Hallow and Justin Gatland. It is a full service uh software shop uh Ruby Closure um and actually all kinds of different languages. I started at relevance in 2010 and it was still a small consulting company in North Carolina still mostly doing Ruby on Rails development to pay the bills. Stuart Halloway was the main driver toward really betting on Closure. He was the one who I think really pushed to start hiring people from the Closure community and try to build up this Closure development practice. Hi, I'm Stuart Halloway and we're going to talk about the Closure programming language. Justin and I at Relevance were looking for a way to invest in building something more than a consultancy. And we had actually been approached by venture capitalists saying, "Hey, you should be the Ruby and Rails shop." And our thought about that was, you know, there is a Ruby and Rails shop. DHH has a shop. You should go talk to him. By meeting Rich was an opportunity to start at the beginning with somebody who it was his thing. and Stu and Justin wanted to do something with me and we thought we'd be talking about doing a closure consultancy or closure corps or something like that. They were getting together. They had an agenda and the couple of days building up to it, Rich had been thinking about other things. And he was like, I'm just going to before we get to the agenda, present them with this idea and see what they think. Eventually, he came to Durham and we met a few blocks from where we're sitting right now. were in their big, you know, the relevance, you know, whiteboard room, which has a big whiteboard all on one wall and all on this other wall. And uh it was early in the day and I started up in one corner. I said, "Well, I I have this idea. I want to run by you." And I started writing on the board. And so then for like 2 hours, he unrolls this disquisition on databases and the history of databases and how with a closure mindset you could do uh something totally different. The left hand half, this yellow brick building is where we were when Rich Hickeyi came to town and Justin and Rich and I met to talk about building a consultancy around closure. And he surprised us with this idea about building a database that became Daymic. I mean, how many people think dealing with databases is easy and troublefree? Nice. Uh, most people don't. As he talked, our jaws just dropped and dropped and dropped. And I don't think we took very long deciding that we would build a database product using Closure and that that would be the thing that we would make together. They got it. They were they were interested in doing it. So we put together a small company called Metadata Partners, which was just sort of the first way we worked together. Fundamentally datomics a database and uh the overarching goal is to uh move away from a monolith monolithic notion of what constitutes a database to one where the facilities of a database are distributed in particular substantial portions of the power normally attributed to the server in the database are moved into your application servers themselves. I knew Daymic was something bigger than I could deliver by myself. So a lot of financial institutions, they like the idea of Daytomic. It has great auditability and tangible transactions and so you know how your database got to be the state it's in and you've lost nothing because it's it's uh append only or sort of accrete only. A significant portion of Daymic users chose the database first and the language second. Closure was new and different to people. Daytomic was even more new and different. And so we came to realize that we wanted to benefit from the connection between the consultancy building closure and datomic projects and datomic the product. And so that was how we decided to create cognit metadata partners and relevance became cognit and I joined cognite and the mission there was to do both datomic as a product and closure consulting as a service. I could see that Closure had grown to a point where they needed somebody who to really work on Closure and deal with managing the infrastructure for builds and the you know the tickets for problems and talk to the community and run the K and I happen to have the skills to do all of those different things. So I reached out to them and said I think you have a Mi-shaped hole in your organization and you should hire me to fill it. Because a big part of what Cognitech did through that time in addition to sort of building Dayic and having a consultancy was Cognitech was the sponsor of Closure. I mean basically Cognitech was paying my salary and the salary of anyone else who worked on Closure and also sponsoring you know development in the community. So we saw Alex's hire as an investment in the community. He was probably the first closure team member that was dedicated to closure at Cognitech. I think it was around 2013 2014 when closure started to feel like it had a lot more momentum behind it and there was a very brief window of time when it seemed like it might have been the next big thing. Being a modern girl, I wanted a modern lisp with all the bells and whistles and power. So, I wanted to do it in Closure. And Closure's got a lot of nice features. My name is Anthony Mar. Uh, I work at Walmart Labs as a closure developer. Um, and I'm going to talk a bit about closure at scale. We didn't see a path to VC money, you know, doing anything but putting a fire under the pursuit of growth, but then you have to figure out how do you exit? And that was not something we ever really felt comfortable about doing. We were often frustrated ourselves at what we were unable to do. We didn't have the resources to devote to advertising or big splashy conferences or something that you might expect from a Silicon Valley startup. I think we valued our independence over anything else. And given the people we are, that makes sense. When you have an open-source project, people arrive with whatever expectations they have. And if those expectations turn out not to be what they get, they might be frustrated or unhappy. The people who were in to closure because they thought it might be the next big thing very quickly got disappointed because it didn't have the same unbelievable pace of growth and development that viral projects had. I think some people learned how to deal with it or sort of made their peace with it and found their way to continue working and some people left and that was okay. you are going to probably have to interact with other humans while you write software. This is going to turn out to be more challenging than your interactions with the computer. I think the thing that has caused the most contention within the closure community is how contributions are handled. A lot of people were submitting patches expecting them to be approved and accepted and they put a lot of work into those patches and then you don't even hear anything. From a community perspective, it looks like they don't care. It meant that a lot of people had to accept that their role in the development of closure might not be what they had hoped it would be. A lot of people think open- source means that it is a communityrun project that if you meet some minimum bar of code quality or something that you can contribute and be a part of it, make decisions, submit patches for code, fix bugs. A lot of people expect that from anything that calls itself open- source. The hype around open-source software at the time had created this illusion that anyone could contribute at any time. But obviously that doesn't work if you're trying to maintain a coherent stable piece of software. So let's clarify something very important first. Everyone can contribute. You do not need to be a genius to contribute. Great hackers also generally insist on working on open-source software not just because it's better but because it gives them more control. To me, open source was about uh making, you know, closure in this case available to people in a way that maximized the their ability to use it, to give it and share it with people. And at the same time, I think there was a lot of culture and social media around open- source being a collaborative endeavor. I think that it can be, but I I do think that u an open-source project should be run in whatever way the people responsible for it think is best. And this is actually the title of a post that was sent to the closure community. Um, and the post started out f closure. There I said it and god it feels good. I say it with much admiration and respect to all the community members. Yeah. So the open source about you post was sort of a way to be more explicit, quite explicit about how I saw this distinction between open sourcing something and making it available and the community development model that people had expected. And I wanted to make it clear that when they expected, you know, a certain kind of development model, they were making expectations of me and the other people who were working on the project who are working pretty hard on it. It was certainly born of some frustration. I think that people who haven't run a large project with a lot of users don't kind of understand the emotional toll of having all the feedback funnel uh down uh to you and especially the fact that you know negative feedback has 10 times or more the impact of positive feedback in terms of your emotional state. I encourage everyone nashing their teeth with negativity at what they think they can't do. Instead, pick something positive they can do and do it. Beautiful line right there, Rich. PS, this is I mean, yeah, this is just you just do this on Twitter. Uh you your life will become a lot better if you just do that. His reactions were kind of raw and emotional, which was not usually how he communicated. I knew I had to protect my own emotional state and my creative process. And so that post was a way to sort of articulate this is how I see it working. And I think like all things I've said it had my name on it and it's still up and you know I said it and uh I don't retract it. Uh but I was certainly hurting at the time uh when I when I wrote it. Closure in many ways is a personal project, right? It was Rich Rich's personal project and in fact he designed the project in such a way that it could remain like more or less a personal project. it's going to be one or two or three people that work on the He wasn't working in that fully collaborative model that I think a lot of people were expecting open source to be. A good cohesive open source project does a lot of saying no. There's the obvious saying no, which is like idea comes in and it's bad, you say no. And then there's the what is surprising to people who haven't done it for a while, which is an idea comes in and it's good, you usually still say no, right? Because if you don't say no to most things, you get something that doesn't make sense in combination. This is a code retention diagram. So it shows when code has been introduced colored by year and then what happened to that code over time. So if the code got changed or removed, you would see that that band would diminish across time. And you can see I think what I would call a nice layer cake enclosure in that there's a high degree of stability. The internet is sort of tuned for a faster speed than we typically work at. So we have had challenges over over the years with uh trying to convey to people how we work and how we want to work with community early on. I don't think I could have argued, you know, for the fact that well, if if you take this tradeoff and you and you allow for a conservative process that doesn't take it doesn't say yes to everyone, um what you will get in the end is stability year on year. Our users expect that the code that they wrote 10 years ago runs for the next 10 years and it has and it will. and that purely fully collaborative open- source model is not the way that you get a language like that. I don't think we've made the best, you know, leverage out of our community that we could. I think there's a lot of smart people with great ideas and uh I would like to do more to to let them participate in in the process. Now we're on the other side of you know 18 years and uh if you ask people I think you'll find that a lot of people value the stability of closure quite highly and that's what makes it something that you can use for professional development because you know it will continue to behave and that the team that makes it is super concerned about stability. It's a trade-off for sure. And uh you know, we took we took this path. The early days, the biggest problem was getting other people to understand, especially both of our parents. Like my dad never got my plan. When I would explain, you know, what open source was and what a programming language was and that I didn't expect many people to use it and that I could never sell it. and he just didn't see how that added up to anything viable. But actually, I think some of our biggest challenges were much later. You know, we were had been doing Cognitech for a while and having, you know, spent down retirement savings early on. Uh we didn't really know how we would be how we would be able to retire. closure was successful and we were, you know, comfortably making a living but did not have a recipe for retiring, right? Comfortably making a living presuming we just kept working forever, right? But you had the reputation to do that, but yeah, there was no risk. There was no not working. Cognitech didn't really have an exit strategy. So, that was something Stu and Justin and I were working on when we uh started uh talking to New Bank. My name is Edward Wyel. I was a co-founder of New Bank back in 2013 and today I'm a distinguished engineer at New Bank. New Bank is a green field startup financial institution. It's a bank that started in Brazil. I'm Lucas Kavanchi. I am a distinguished software engineer at New Bank and I'm a senior architect as well. We started the company aiming at having 1 million customers in 5 years. We ended up reaching that goal in like 18 months and then we hit 10 million customers in another 2 years and then we changed again like to 100 million customers. 100 million is like half of Brazilian population. It's not clear that a legacy base of cobalt duct taped together from decades of mergers and acquisitions. It's not clear that that's the ideal platform to build a bank today, which which is is frankly a mass consumer technology product. We tried to think carefully about what we wanted to build and how we wanted to build it before we launched into typing. We actually didn't know about hammocks back then. We we used chairs and we sat down with a blank piece of paper and said, "What is the ideal platform for a bank if we were going to make a bank now?" And one of the things I did at that point in time was read this out of the tarpit paper by Ben Mosley and Peter Marx. They argue that mutable state is sort of the accidental complexity that makes systems really monstrously complex and difficult to debug eventually. And that led us on a research project that initially brought us to Dayic, ironically. And then DMIC brought us to closure. So Ed actually discovered DTOMIC and said, "Look, this is a database that looks like a ledger, right? It's a database where all the facts are still there. You can't throw things away. This sounds like a great fit for a bank that doesn't want to be an old school dinosaur bank." You might think, why does that matter? For a new startup, it's going to be small at the beginning, but the business strategy of New Bank was to become a retail bank. And there really aren't any successful tiny retail banks that reach the sort of scale that we were aiming for. So we were either going to get big or die trying. We have over 3,000 Daymic databases, some with over 100 billion datoms. We have 4,000 microservices with Kubernetes. We process 72 billion daily events via Kafka and we routinely handle millions of requests per second. The scaling was, I would say, violent. It was so fast. It almost poured concrete over whatever we had started with in the beginning. Had to be good enough because there was no time to go revisit that. So, it just scaled up and up and up. New bank was a customer of Dayic like like others. You know, we we just started noticing, you know, over time they they grew and grew and eventually they needed more support from us than ordinary. But we just realized that this level of involvement needed something more. The seeds of the acquisition were created uh when Stu went down to Closure South and met with the leadership at at New Bank. The the early idea of bringing the companies together is were really sown during that that time. Stu was going down there to act as a consultant and we started conversations about you know maybe we should join forces and their culture was built around trying to understand and apply in their context not just closure on the atomic but the values of the ecosystem. I felt like after that meeting it was kind of already a done deal. Acquisitions can carry some baggage concerns about control direction and values but in this case there was something deeper. There was actually alignment. New bankank had this mission to simplify banking for Brazilians and that resonated with Daytonic's philosophy of simplicity and software. It's a shared commitment to reducing complexity that made the partnership not only workable but powerful and beneficial. With New Bank acquiring Cognitech, there's a lot of uncertainty. you you never quite know what's going to happen, but there was a real sense that they were in with both feet and willing to support the language and the people who make the language. The riskiest part of it, I think having an independent company that's stewarding a community versus a bank that's stewarding a community is two different things. And I think the bank version of that is rare, right? Maybe unheard of in the history of technology. Millions of people trust us with their hard-earned money and we're helping millions of people be empowered with their money. New Bank is the biggest independent bank in the world and it runs on closure in Daytonic. Please welcome New Bank in celebration of its listing. To honor the occasion, they are ringing the opening bell of the New York Stock Exchange. My life really didn't actually change much through the acquisition. I continued to work on the same things I was working on with the same people in the same place, but we had more resources and over time we've been able to grow the team with new bank support. We've been able to put hundreds of thousands of dollars into supporting open- source closure developers. They're willing to really put monetary support into closure community projects. I think that that's been extremely beneficial for the the language. I think Rich's talks were really instrumental in attracting people to New Bank to be able to work with the concepts and the way like his clarity at laying out things like in simple made easy. It's clear that he was distilling a massive amount of experience into a very tiny subset of these are the things that really work best. And I think that that sort of let's do the best work of our lives. let's reach for the absolute best tool for the job that we're doing that is still alive in in the culture at New Bank today. I think Rich has a lot to do with that. So, I retired in 2023, a couple years ago. What I mean by retirement is I no longer work for money. Uh but it doesn't mean I no longer work. And in particular, I'm still actively working on closure. I work with the Closure team. I'm designing features. We meet every morning at the same time in the same online place and he knows where that is and if he wants to join he'll show up. He's retired now except you know it's I I had a conversation with Stephanie his wife and she says you know he kind of sits in the same place around the same gear kind of looks the same to me. So which which I thought was a great comment. So why would I do that? Well, I think because I'm able to is one reason, but a much more important reason is I do want to get back to that feeling I had when I gave myself that sbatical. The the feeling that I could pursue my ideas without concern for the outcome. He's likely going to be working on something else. Again, something he's passionate about, something he's really interested in, something he's going to do a lot of deep research on, likely around music. So, if you talk about it that way, then no, I don't think he's ever going to retire. I think it'll be interesting to see uh when Rich chooses to step down even more from uh his involvement in closure, presumably at some point in the future. I think we have um people already in the community who have the wisdom and bearing and interest to do a good job continuing to shepherd it. And uh the language itself really doesn't need to change that much for it to continue to be a platform for vibrant exploration of computer science ideas and um business ideas and whatever other programming things you want to do. Closure really introduced the joy of programming back into my life. We are software engineers at Netflix and today we're going to talk about a system that we work on built on uh closure and atomic. If you told me in 2007 that nearly 20 years later people would still be using Closure and that I would get to travel all over the world talking about it and working with other people, I would have thought you were absolutely out of your mind. I have a personal mission. I want to continue to take Closure outside the Closure community. I want developers to learn about how Closure loves the messy real world and I want them to be able to make bulletproof software that's fun to maintain. There are many many people that make Closure great. Um, but I personally um think Rich is one of the most important computer scientists of the last 20 years maybe ever. And it's really all about the way that he approaches problems and problem solving and making that the focus of everything. I think people underestimate maybe that the act of creation is a deeply human act that it's not I woke up one day and typed some stuff in. It's not that I happened on a thing. It involves a huge personal effort to explore the ideas, the problems that you're looking to solve, the possible solutions. It's a big investment of self particularly in this day and age where you can generate code, you can generate a novel. If you have something to say that that another person, an audience, a viewer, a user um is going to find impactful to them, that something to say is human and it is only human. Um, and that's a a view that I have on closure is that this was one person's vision and personal investment. And with all the vulnerability, it's not a a story of a thing. It's a story of a person. If I can advocate anything, do not be afraid. Especially do not be afraid of being wrong. for my work the most important thing is freedom you know sort of intellectual freedom and uh that's something you have to give yourself I don't think many people will pay you to have intellectual freedom and so I was very lucky to give myself that opportunity once and to now be at this end of my career and uh look at uh freedom all the way to the finish line. Closure to me means a bunch of things. It's a project and a product and a tool, something I made and something I created. I think it's a set of ideas which are bigger than it. It is a continuity of lisp and lisp tradition and it's a community and put together that's even more powerful. I think it's it's it's not something I envisioned as a whole when I started. I was thinking more about the thing I was making you know the thing and the fact that the thing is now part of an ecosystem and a community and a lineage. Uh yeah and a set of ideas you know is is big for me. It's just all those things holistically