Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
1a156fe163a1 Nathan Marz
986 Plays8 days ago
Episode 1a156fe163a1 Nathan Marz
Where Nathan explains the lead up to Rama and explains some of its extraordinary powers.
References:
Grace Hopper on Letterman: https://youtu.be/oE2uls6iIEU?si=4x1PUPyffBE2DK9F
Red Planet Labs: https://redplanetlabs.com/
Introducing Rama: https://blog.redplanetlabs.com/2023/08/15/how-we-reduced-the-cost-of-building-twitter-at-twitter-scale-by-100x/
Rama Demos: https://github.com/redplanetlabs/rama-demo-gallery
Guest
- Nathan Marz
Hosts
- Josh Screaming Glover
- Ray Streaming McDermott
MP3 SHA
50a13ae13f39ee95101f174881f485168afac9eb2390df22e0b1738e5b38e503
UUID v5 from SHA + People
32be5bb2-9993-541c-b6ce-1a156fe163a1
Recommended
Transcript
Podcast Beginnings and Initial Chaos
00:00:25
Speaker
Yeah, maybe we should like start. Is everyone ready ready to kind of just start? Because, okay, when we should just start then. Okay. So ah here we are, another Deffen. This is like Deffen Nathan Mars, take two.
00:00:40
Speaker
Take two. The best take. Best take. Okay. Podcast cameras action. Nathan, welcome to Deffen.
00:00:51
Speaker
they say They say third time is a charm. I've never heard of second time is a charm. Well, we are on recording seven, let's not forget. So, you know, we can... Lucky seven. look seven of Seventh recording. I don't know.
00:01:04
Speaker
Yeah. I actually have a theory about what happened with the last recording. only Okay. Well, because like... They didn't use Brahma. No, no. think like if we're honest about the last recording, like...
00:01:19
Speaker
It was a bloodbath. Like you guys absolutely. It was brutal. Um, like I was man, like I, my head was spinning afterwards. I started drinking again. It it was, it was bad.
00:01:35
Speaker
Um, so like, but my theory, um is I don't think you lost the recording at all. I think you guys had so much fun tearing me apart that you just want to do it again. oh yeah. Yeah.
00:01:46
Speaker
yeah That could be true, yeah. I must so must admit that i i' am not on heroin today, so it could be better, yeah. Or worse, probably.
00:01:57
Speaker
Or worse, yeah, maybe it's worse, yeah. well We'll have to decide. I think the nice thing about it, though, is that because we've like teed it all up and we know that this is take two, it'll be very interesting for the listeners to try and work out where take two ends and where take one begins.
00:02:15
Speaker
You've got to listen right to the end. Exactly. there wasn war tap too I don't know. yeah it's It's going to be fun. yeah Yes. But yeah, Nathan, thanks so much for joining us again from scenic Honolulu, it is, right? Yeah, Honolulu.
00:02:34
Speaker
yeah Amazing that you would travel so far over the the the tubes to be on Zencastr with us. Well, he's on Deffen with us, actually. he Zencast is just a bullshit thing that ruined our first take, remember?
00:02:47
Speaker
Exactly. Ruined my life, actually. No, Nathan's life, because he started drinking. All right, my life is fine.
00:02:54
Speaker
Yeah. um So... It's really making us nervous now. what This is like... This is so much worse. We really whipped into him and the first time. It was so much better. Jesus Christ, Nathan, you've totally... yeah You've totally out psyched us.
00:03:10
Speaker
Yeah, set some expectations for the audience. They're expecting quite a performance from you guys this time.
Nathan's Programming Philosophy
00:03:17
Speaker
I think the thing that started the bloodbath was the the kind of legendary VJ question, Nathan. So I'll put it to you again, Emacs or some other shit. Yeah, i actually use, ah I have like the most primitive setup possible. I just use add-on, which isn't even supported anymore. It's like ceased development.
00:03:36
Speaker
and But it works fine for me. ah i just don't find that... Obviously, all the stuff in Emacs is nice. A lot of my employees use Emacs. like It's pretty fancy, all the stuff you can do with it.
00:03:47
Speaker
But I just find programming is mostly just sitting there and thinking. So um having the editor be... better doesn't hasn't really made that much of a difference for me when i've experimented with it so and that's interesting because there was that steve yeggy blog you know where he spent 16 000 words telling you that you need to learn how to type faster you lazy programmer and uh that always like i had the kind of same reaction as you just enunciated there which is like
00:04:18
Speaker
but typing is not the slow part of programming for me. It's my stupid brain trying to like figure out you know like how to solve the problem, not my fingers typing the characters.
00:04:30
Speaker
But Yegi was doing Java at that point, so you know maybe that explains it. Oh, I couldn't even imagine doing Java without an IDE support for it but Clojure is different for sure. Yeah, yeah.
00:04:40
Speaker
Also, I think there's a difference in terms of expressivity. it's It's interesting, like, you know, we we one of the things we're going to talk about is productivity and efficiency and stuff like that.
00:04:54
Speaker
So, i mean, let's just, like, think about it a little bit. So, if we're all thinking about stuff, and thinking is the big thing, I remember, I think there was a talk by Rich Hickey about that, about how to get better at thinking, you know, essentially, which was, you know, the the because that's the real problem. Um,
00:05:13
Speaker
so So what do we do? I mean, you know, if um if ah if Emacs isn't going to help us and typing, you know, 70 words a minute isn't going to help us, then, and yeah. what do we Do you have any thoughts about that, actually, Nathan, about like where thinking is going to help us? How do we get better at thinking?
00:05:35
Speaker
Well, I do think a programming language is like a reification of a philosophy of how to think about, of how to think about programming. and Right. Clojure and LISPs in general, they, I would say, offer a much more ah powerful way to think about programming. and Um, I would say the same thing about Rama too. It offers a much more powerful way to think about, um, backend development and data processing and data indexing and data ingestion.
00:06:08
Speaker
Um, so one way to get better at thinking is to use better tools, I guess, or use tools that embrace a better way of thinking that allows you to think in more powerful way.
00:06:19
Speaker
If you're sticking with, um, you know, JavaScript and Python, kind of these like traditional languages, so to speak, then you are going to be fundamentally limited into thinking in the ways that those languages have allow and encourage you to think.
00:06:37
Speaker
um So I think that would be step one. And I think that, you know, you are it's always been undermining. Sorry, go ahead, Nathan. Then I'll tell you why you're wrong. but yeah that's i I think that's something I've always personally been drawn to.
00:06:50
Speaker
It's just like, I've i've always been interested interested, like ever since I was like a child when I started programming and just like, um it was just so interesting to me that you could write programs that could help you write programs faster in the future, right?
00:07:05
Speaker
so so And so I was always interested in like languages and abstractions and stuff like that. um And so I've always been searching for that. I've always been drawn. mean, that's ultimately what drew me to but to Lesb in the first place.
00:07:18
Speaker
Well, actually, i think I think I would completely agree with Nathan about like Lisp because i mean we we definitely talked about this first time around as well, which is that I grew up, like like most programmers, of course, you know thinking about stuff like with C or Java or C++, plus plus imperative languages, class object-oriented languages, where...
00:07:44
Speaker
Obviously with C, immutability mutability and changing things and allocating memory and all this kind of stuff and being careful about that is something which you have to be precise about. And that inevitably all those bookkeeping activities just take up a lot of mental space, you know, essentially.
00:08:02
Speaker
um So then you get a garbage collected language like Java and it turns out like Lisp. um 1950 fucking nine. Anyway, um the yeah the the garbage collection frees you from a lot. i remember when I first had experienced Java,
00:08:19
Speaker
not having to think about, you know, alloc and free. And it was freeing, haha. Okay. but But again, you know, the that object orientation works is that you have to think about mutability differently. You have to think about essentially um having an interface for mutability.
00:08:37
Speaker
You know, you say, okay, do this thing on this object and that changes the state of the object. Um, So you're you're moving mutability into every single object that you design and managing state in every single object, which means, again, you're thinking about state all the time. You're thinking about mutability all the time.
00:08:58
Speaker
And then when you go to Clojure and you realize,
Rama's Innovative Data Handling
00:09:00
Speaker
oh, actually, with functional programming in general, you know which says actually mutability is a huge problem, so get rid of it. It does actually, I think to Nathan's point, it does's all those kind of things that you just drop off you know, whilst they may cost you some, they may cost you something in terms of raw power on a bit of metal, actually from a thinking perspective are incredibly enabling.
00:09:24
Speaker
Yeah. It's kind embrace, embrace that humans are, can only fit so much in their head at one time. Like embrace embrace your inherent stupidity. then you are like, once you have too much stuff to think about it, once you're you're going to fail to be able to think about it properly. So if you can reduce the amount you need to think about, you'll be able to do more stuff.
00:09:47
Speaker
I don't think that's everything. ah i don't think that describes programming in general, but I think that is a big part of it. And certainly that's a big reason why immutability is so powerful.
00:09:59
Speaker
It greatly reduced the amount you have to think about it. I was actually looking at a book that Dykstra wrote in 1976. um Fascinating to read.
00:10:11
Speaker
you know he you know he Obviously, he's a very um important person in the history of programming, but just absolutely fascinating to read how someone's writing about programming in 1976, when even the concept of structured programming was like still pretty new and and kind of controversial.
00:10:28
Speaker
Like not everyone read with it. And just read, ah I was specifically reading the part about him writing about global variables and he was talking about why they're harmful.
00:10:40
Speaker
um And you could kind of take that argument and copy and paste it for why mutability is harmful. Because he's he he's writing about how global variables, in order to to understand code locally, you have to understand all the code because anything can be touching them, which is the exact same reason why mutability is harmful so i thought that was uh interesting to read it's incredible yeah um and i think because he was a lot of people still talk about his algorithms don't they um about you know like the star algorithm and things like this for like finding the shortest distance and all that kind of stuff um
00:11:21
Speaker
but but i was most people Most people would know him from his algorithms, but he wrote a lot about just like programming. Yeah. so I mean, the famous go-to considered harmful, right? That was also Dykstra. Yes. i believe Similar to what you were just talking about. Yeah. Yeah. Yeah.
00:11:40
Speaker
Let's get back to your closure story because yeah this was this was um this was something that definitely was like super interesting ah to both of us when we heard it the first time around.
00:11:52
Speaker
I would say it started for me in, think it was 2004. So when I was in college and Paul Graham, he wrote an essay called Beating the Averages, just talking about um how he used Lisp at his startup and how it was instrumental to the startup success.
00:12:09
Speaker
And there was one line in particular that really stood out to me where it was some, I'm paraphrasing, but it was something to the effect of, Our company was doing things that no other company could do. And Lisp, you could do stuff in Lisp in programming that you couldn't do in any other language.
00:12:25
Speaker
And these two things are connected. So I found that really interesting, especially as I mentioned, like I was fascinated with, you know, programming languages and improving how you think and abstraction and stuff like that.
00:12:39
Speaker
so I got really interested in Lisp at that point. And, you know, that was just common Lisp back then. This is years before Clojure came out. Um, and actually it was to the point i was interested that, um, I knew that John McCarthy lived near campus.
00:12:53
Speaker
Um, you know, was a retired professor at that point. Um, so I found his, he just had his email on the website. So I emailed him, um, and was like, oh, know, I'm a sophomore and, uh, I'd love to just, uh, meet you and learn about your, your life and career.
00:13:08
Speaker
And he emailed me back. He was like, sure, come by next Tuesday 10 a.m. I didn't really, I really didn't appreciate the significance of that back then. I was too young for that.
00:13:20
Speaker
Yeah, yeah, yeah. Obviously, I knew that he had created Lisp and was obviously big in AI. I didn't know much more beyond that. but and it I didn't like understand anticipat like like the breadth of how foundational he was as a person to our entire field, like the entire craft. I biked over there. It was like a 10-minute bike ride away. um you know Knocked on the door. He he you know invited me in and we sat. and actually sat with him for two hours and was asking him.
00:13:50
Speaker
just you know He took me through all his time at you know MIT and Stanford and I wish I had a recording of the conversation because I don't remember. you know It's been more than 20 years at this point.
00:14:03
Speaker
but there There are a couple of things I remember very vividly. um One was that he was really confused of that I kept asking him about Lisp.
00:14:14
Speaker
it was like and and and And it occurred to me afterwards that he really didn't care very much about Lisp. Like what he cared about was AI and Lisp was just something that he created to help him with AI, his real passion. um Yeah. Yeah.
00:14:31
Speaker
And like, it's so crazy. Like when you look back at like what he just like generated, and I think it was 1957, 1958, something like that, when he first proposed Lisp. I don't think it was implemented until 1960.
00:14:46
Speaker
but like Yeah. I think the paper was 59, maybe. ah have that that stuck in my mind, but yeah. maybe Yeah, or maybe that's when it was published. But but yeah, I mean, symbolic manipulation and like GC as like a concept.
00:15:01
Speaker
Yeah, yeah, yeah. Again, we already mentioned Dijkstra was writing about Structured programming was controversial in the 70s still. 1959. He's already talking about Lisp and all the advanced stuff. like It's pretty um it's like unbelievable um what what he accomplished. her But anyway, he didn't care or he he he was he he he apparently didn't care. um and it actually It reminds me a lot of um Isaac Newton, actually.
00:15:35
Speaker
because Um, obviously invented calculus, very, very important milestone in mathematics, but he only did that for physics. That's what he actually cared about. Right. yeah Exactly. Yeah.
00:15:47
Speaker
I, I, for me, there's like a big parallel, um, between Isaac Newton and John McCarthy there although I think I think if I'm not wrong Isaac Newton did really give a fuck about calculus because he fought Leibniz over it's um the the you know he wanted credit for creating it there was a war between him and Leibniz where there wasn't such a you know there wasn't such a let's say controversy around lisp you know no one else was claiming to invent it or discover it I think So the the Leibniz Newton beef had more to do with um with religion than it did with mathematics, though, because, you know, Leibniz had this concept of the ether and monads that that was the thing he had. not
00:16:32
Speaker
No, not the mathematical sort of monad, but this monad was some kind of like... instantiation of God. And Newton was like, that sounds like some anti-Christian bullshit to me, bro. And Leibniz was like, come at me, bro. And then it went on like that.
00:16:48
Speaker
Probably in French at the time they would have been speaking French. So... um but anyway yes yeah no no that's latin probably no i think i think theology is a great direction for this podcast i think we should continue i mean so you you definitely you saw the light and came to to closure eventually yeah but how did the rest so i'll give a brief interlude to talk about myself because i love myself more than than even the calculus um
00:17:20
Speaker
So you mentioned Paul Graham, and I had the exact same um journey, like the first step into Clojure as you did. I read Hackers and Painters, which is a book of essays that had that beating the averages and and and a bunch other stuff.
00:17:37
Speaker
And um you know i I had taken common lisp in a programming languages course in university and been shocked and appalled by how awful it was.
00:17:48
Speaker
And I was convinced that Lisp was like pointless. And then I read this book of essays by this guy who was making sense. um And I was like, oh, well, maybe i was not as right as I thought I was. So I better look back into this. And ah When I looked, what I found was Scheme instead of Common Lisp. And ah the the simplicity of Scheme just spoke to me.
00:18:12
Speaker
um and and that really, you know, got me started on the whole journey. But um it just before I go further. further I do want to assure listeners that I think Paul Graham is an awful human being, but that doesn't make him wrong about everything. So anyway, Nathan, how did you move on from you know your interest in Common Lisp to Clojure?
00:18:36
Speaker
Um, so yeah, so after I graduated, um, I was working on like, I started my career, like working on big data stuff. So right when like Hadoop would starting to gain, uh, a lot of popularity and, uh, just doing a lot of like batch processing stuff.
00:18:53
Speaker
Um, and then I had this idea, i had learned data log in college from some college course. Um, and then I had this idea to do data log on MapReduce. So compile data log into a.
00:19:04
Speaker
you know, chains of MapReduce jobs. um And actually built um like a data log to MapReduce compiler. um And my first version was like literally just like data log as its own language with Lexer and parser. And just immediately ran into issues with that. Like it was immediately evident that but like you need to put in like custom logic in there, like custom functions as part of your data log workflows and, know,
00:19:32
Speaker
I had to build like a manual registration system for it. It was like very, very messy. um But I had come across, I had heard about Clojure, probably from Hacker News or something, just like in the ether.
00:19:45
Speaker
um And then it just like connected in my mind, like, oh, like it seems like Clojure would be really good for this. It's already on the JVM. You could use macros to form these datalog abstractions, which are obviously, they they execute differently than like a standard language, but you could smooth all that away through macros.
00:20:04
Speaker
um And so that's when I started with Clojure. And my my first... um or my my my goal or my motivation was what eventually became task log, right? So a data log like thing on top of ah MapReduce. The first project I did was, i did ah another project first just to get like the hang of Clojure.
00:20:23
Speaker
It was some sort of like, queuing system or something that I built. But my second project was Kaskalog, which was a very, very ambitious project for... yeah Exactly. yeah I wrote the Linux kernel as my first C project.
00:20:40
Speaker
Second. Second. second sorry yeah yeah The first first you do a, yeah, like Hello World, and then you do the Linux kernel. Yeah. That's basically what it was like for me. And so, yeah, my first, yeah, I didn't really know how to program Clojure well at that point, right? So certainly looking back, ah I would have, the implementation of Castle have been a lot better, but the API was beautiful. it was a really beautiful API.
00:21:05
Speaker
um and And then I, you know, and then I learned things from that, right? by By doing Datalog within Clojure, so doing it within the context of a full programming language, right?
00:21:18
Speaker
like you're not sacrificing the power of a programming language in the process of creating this other one, right? And then I learned very, very quickly, like that's really useful because it was really useful to write Clojure code, which would dynamically create Caskalog code.
00:21:34
Speaker
And it was completely trivial to do because I never sacrificed that in the first place, which is something that, programmers are all too quick to do, which is to just sacrifice programmability for no reason with, you know, like as soon as you do like a true DSL, which is actually like its own language, you have massive, made a massive sacrifice, which you may never fully appreciate because you never got to experience it if you hadn't sacrificed that. Right.
00:22:05
Speaker
Yeah. And like, obviously like SQL would be the, uh, prime example of that. Um, And it's like, it's fun, you know, if you want to use SQL from ah regular language, like it fundamentally comes down to just string manipulation, right?
00:22:23
Speaker
um Yeah. Yeah. Yeah. Anyway, ah that was a big, I think, lesson for me from building Castlog, which I think, which I definitely internalize and carry forward as just like ah as part of my philosophy for programming. Yeah.
00:22:38
Speaker
I think the the other thing to me about SQL that is it's kind of interesting, and it's ah it's ah instructive at least, is that um on the one hand, it feels like it's fairly universal, but on the other hand, we all know that it isn't.
00:22:53
Speaker
You know, that every single version of SQL beyond like select star from Emp is completely different. You know, they all have completely different affordances. you know left completely you know They have different extensions now, you know but even the core things don't seem to work very well together. And it's it's become more than just this declarative languages. It's all to do with way that you create schemas and manage schemas. And so the whole operationalization of SQL has become a huge problem.
00:23:26
Speaker
um You know, because it's it's one of these things which starts off again,
Developing Rama's Capabilities
00:23:31
Speaker
it's like, hello world. You know, it seems very simple to just make a SQL statement and to use SQL as forgetting all the string manipulation, just SQL itself just seems like, okay, I'll just walk up to this thing and,
00:23:44
Speaker
do some querying and relational technology in general seems really good. But yes, SQL as a sort of gateway into relational technology seems off, I would say. And I'm wondering what you think about like data log then, because data log is also like, it's very varied now. There's all, you know, there's a different, there's RDF and stuff like that, that have their own flavor of data log and In in like the closure world, we have Datomic and Juxt, and there's a whole bunch of other data logs as well, actually.
00:24:15
Speaker
can't remember the other one. Dat 11, I think. Dat 11. um There's a few other bits and pieces you know that have. So that's not a standard either. um Maybe it's just not important to have standards. I don't know.
00:24:31
Speaker
yeah it just check We all know the XKCD... ah cartoon about standards, right? You know, all of the 11 existing standards suck. So I'm going to produce a 12th to fix it.
00:24:42
Speaker
Right. Well, I have a lot of problems with SQL. um I mean, i have a lot of problems with just the, well, I mean, we'll talk about, we'll get into Rama, right? But just the whole concept of a fixed data model is really problematic.
00:24:59
Speaker
um And obviously relational database is the, I guess, most popular fixed data model that people use and have become the end the lines you know, basically since the 1980s, right? But I think it's...
00:25:13
Speaker
It's a fundamental problem to just even think about data indexing in terms of fixed data models. And that's that's one of the big things that Rama addresses.
00:25:27
Speaker
um And I think a lot of the problems with relational databases and through the usage of SQL stems from the fact that it it is a fixed data model. Yeah, I think it's kind of what we were talking about or what the kind of SQL people were talking about was sort of almost like the opposite of that, wasn't It was like that IBM back in the 60s, 70s, 80s, well, 60s and 70s, they had files and these files and these programs were difficult to
00:26:01
Speaker
difficult to get into, you know, like the file formats were all different. um So it made like it made it very difficult to write reusable programs when all of the files were different. So SQL was a sort of way to, let's say, normalize data representation.
00:26:20
Speaker
I mean, started with ISAM and stuff like that, and you know, other other VSAM and all these other sort of structures. but But in the end, relational technology kind of won in terms of like the lingua franca for sharing data or across different projects.
00:26:35
Speaker
So I think in that sense, it was sort of a success, you know, in the sense that it allowed you to write more reusable programs. Well, in 1980. Yeah. and ninety points in nineteen eighty s yeah the computing landscape was completely different than it is today. You had.
00:26:51
Speaker
Absolutely. Ear restrictions on CPU and memory and disk being available. um and's so And
00:27:00
Speaker
I think that you have to like analyze it in detail, but it's possible that a relational database was the best thing that could possibly be done at that time, given the resources. um But it's also insane to think that,
00:27:13
Speaker
that would be the best technology to use now when the computing landscape is not comparable at all. yeah So like, like ah basically what I'm saying is that it's possible that the best we could do was ah one fixed data model and everything built on top of that and have that be extremely highly optimized for the, for, for a low resource environment. and um But that is definitely, that is definitely not the case today.
00:27:36
Speaker
yeah I feel like, I think i just just before i want i want to quote i just want to out this Mark Fisher quote, which is like, ah the people find it easier to imagine the end of the world than the end of capitalism.
00:27:50
Speaker
And I feel like people feel like it's easier to manage the end of computing than it is to manage the is daughter to think about the end of the relational database. you know It feels a bit like that, kind of like, oh my God, we can't it's we're hooked on it now.
00:28:04
Speaker
We really are. The whole world is hooked on this stuff. yeah So yeah that's how it, I mean, regardless of you know right or wrong, it does feel like that's the kind of vibe that we're getting off the world of computing.
00:28:18
Speaker
Yeah, I mean, that's that's actually one of the interesting challenges that I'm facing, like directly. It's just like, now by which people have internalized that way of thinking, like that relationship-based centric way of thinking, and then just more generally like fixed data models and they can't get their heads out of it.
00:28:35
Speaker
um And I've created a tool which completely rejects that. It's a massive rethinking of programming. And so a lot of my challenge isn't so much getting people to learn Rama, but getting them to unlearn everything else. um Yeah. So it's like Rama is, I would say actually the unlearning curve to Rama is, might be bigger than the learning curve.
00:29:00
Speaker
Yeah. Yeah. Yeah. yeah Which is a kind of a interesting challenge. yeah That's some Zen type shit you're spitting there, Nathan. Yeah.
00:29:12
Speaker
but but But I do think in a lot of ways, someone who's, well, okay, I won't say someone who's never programmed before, but someone who's more naive in programming might have an easier time learning Rama because they're not hung up with all these preconceived notions.
00:29:29
Speaker
Yeah. In the first world. I've thought the same about Lisp itself, right? Like if, if you don't learn an algo 60 style language first, but you just learn Lisp, which, you know, is more mathematical, right? It's more like the arithmetic you learn in school.
00:29:45
Speaker
Um, wouldn't it be easier? So I did try that with my son. um unfortunately he never really got the programming
Rama's Paradigm Shift in Programming
00:29:53
Speaker
bugs. So I, can't, uh, claim that he, that list was easier, but,
00:29:59
Speaker
you know we've you've You've mentioned Rama a few times, and um I like that you know that snarky comment you made about, well, maybe that was the best we could do in 1980, but it's not the best we can do today. So what is the best we can do today, Nathan?
00:30:15
Speaker
Yeah. All right. Well, let me explain what Rama is. um So Rama, let let me start with just ah framing Rama in terms of existing concept of technologies that people already know.
00:30:31
Speaker
But let me just say up front that this is also not a good way to think of Rama because it limits you and and yeah and into just into thinking in terms of the limitations of those toolings, right? But you can kind of think of Rama as like a streaming, stream processing platform with a database built in.
00:30:52
Speaker
um or or maybe it's more accurate as a streaming platform with every database built in or or every possible database built in. um And so Rama, so whereas like traditional um A traditional architecture for building like a backend, you know, small or large, it doesn't matter. Like the the, the model of thinking would be you have your application layer and you have your database layer.
00:31:18
Speaker
Your database layer is the current state of the world and your application layer does reason rights to your database layer. Right. So Rama's model is fundamentally different. So Rama is based on event sourcing and materialized views.
00:31:33
Speaker
um And the idea is that you keep your data separate from the views which you use to support the queries of your application. um Data is append only.
00:31:44
Speaker
um So you're just always appending new data. And then you construct your views and you construct many views, as many views as you need um for however you need to be able to slice and dice through that data ah quickly.
00:31:59
Speaker
Um, that's the, that's the general model of Rama. Um, and so you have like, i already mentioned fixed data models a few times, right? Fixed data models would be like relational database, key value, document, graph, column oriented. And you know, there's, there's some more, um, so Rama, um, uh,
00:32:20
Speaker
So Rama, the views that you create in Rama are called pStates, which means partition state. um And every pState that you create, and you create as many as you need for your application, um can be whatever data model you want because pStates are expressed in terms of data structures, not data models.
00:32:39
Speaker
So data structures like maps, sets, and lists, and so on. um And any particular data model is just a particular combination of data structures, right? Key values, it's a map, documents, a map of maps,
00:32:50
Speaker
come oriented as a map of sorted maps and so on. um But then obviously with this simpler primitive of data structures, um you can express all the existing data modules plus infinite more.
00:33:02
Speaker
Cause you can fine tune the structure of your views to precisely what you need for your um application. And so you get, i would actually say a profound,
00:33:14
Speaker
ah profound amount of flexibility um to Like, whereas before you kind of always had impedance mismatches with your database, because ultimately the database, this data model is not going to fit perfectly for all your use cases. Um, the impedance mismatches are gone because you're always able to mold your indexes to precisely what you need for your application.
00:33:39
Speaker
um I actually would actually, think that's analogous to just like Lisp, right? Where with like Lisp, you're able to mold the language. to fit your application instead of having to force everything into just the constructs of the language. that's that That I would say is the the key thing that makes Lisp so powerful.
00:33:56
Speaker
um And I would say the same thing applies to Rama in terms of the way you're able to mold Rama to fit your application rather than having to twist your application to fit your tooling. So at a very high level, that's what Rama is and that's where its power comes from.
00:34:12
Speaker
so in terms of the like let's say you have you know we were talking about like why relational databases have occurred is that they wanted to share the same data for different applications and that's that's it's clear to me that that in your explanation that should be possible with rama as well you should be able to write three or four different applications or n applications with the same back end the same back end data as as so you should Your application, which is doing, let's say, ah say a classical kind of microservices pipeline where you've got, you know, a customer shopping cart and you've got the the catalog and you've got the sales process and the follow up.
00:34:55
Speaker
All of those things should be able to operate in Rama yeah with without kind of like fretting over the data structures at the back. Yeah. So it's Rama, like the mental model, you have your data coming in that comes into something called a depot, a deep on Rama. It's, it's's it's, it's, it's like Kafka, right? It's just a, it's a distributed queue. Right.
00:35:16
Speaker
Um, and then you have your P states of which you have as many as you need, right? Some applications will have maybe just one P state and other applications will need a hundred P states. Um, and then you write these things called topologies, which consume depot incoming like depot data as it arrives and then materializes your p states right and and the topology code is just code right it's we have um we have a java api for rama and a closure api and you just write your topology is just in java or closure right um with whatever logic you need um and then rama as a platform is inherently
00:35:54
Speaker
distributed and scalable. um And so the the the way topologies are programmed are inherently distributed and and scalable. um it It uses, um you you're program it with something called data flow.
00:36:09
Speaker
um Rama's not the first system, but not by a long shot to use data flow as a concept. um But I would say Rama takes data flow and expands upon it I would say to the maximum extent possible.
00:36:24
Speaker
um So Rama's data flow is exceptionally powerful to be able to do um distributed computations in a very expressive way. um And so like anything that you could imagine in the back end will fit into that model, right? Because it's completely arbitrary. Basically,
00:36:44
Speaker
um The way you can represent your data in depots, completely arbitrary. you can use any, and like you'll just use any type you want, right? Maybe you just use plain maps, maybe use JSON, maybe use closure records, or maybe you use something, maybe use thrift or protocol. It doesn't doesn't matter. It's completely up to you.
00:37:03
Speaker
Your p-states are completely arbitrary. They can be any shape you want. You can have any any number of them you want. And the topology code is also completely arbitrary. um You have absolutely no restrictions on what you can compute, how you compute it how you partition computations and data and so on.
00:37:18
Speaker
um And so Rama is like an extremely general... platform
00:37:24
Speaker
the The biggest thing ah or the biggest the biggest issue that I think we have in streaming in general in general is like consistency um and what should we say? um the your The ability to guarantee the the data that that you you put through the streaming pipeline goes from edge to edge and and you know all the bits in between.
00:37:49
Speaker
ah doing the right thing. Because classically in in Kafka Streams, you have this, this model where you can floss data through. It's not by default, it's not, um it's not ah what's the phrase, like, we have to cut this bullshit down.
00:38:10
Speaker
Whereas, ah, it's a like read once. sir It's not like that. It's what's it called? um
00:38:19
Speaker
At least once. Oh, no, it's exactly once. It's exactly once processing. God damn it. Walter, Walter, Walter, Walter.
00:38:30
Speaker
He's got me doing it. ah You have to cut that bit. um So, yeah, okay. The problem with Kafka Streams is exactly once programming. Now, they claim to fix this. They've got an option to do exactly once um message transmission.
00:38:44
Speaker
But whenever I've used it, it's like when the performances went to shit. um everything goes extremely slow. And also it seems to only operate between like one part of the top, one part of the overall system to another part, not, not the thing from end to end as you want to view it.
00:39:03
Speaker
Um, so how does Rama compare to that in terms of like the, the guarantees that it offers for the data? So Rama, so, um,
00:39:16
Speaker
Rama has two kinds of topologies you can create. but They're basically two different one two different ways of doing incremental processing. So one type of topology is called a stream topology. And that's the the the model of stream topology is that you just process data as it arrives. So you're processing data one at a time and it'll be processing many many things or or many and ah depot entries in parallel, right?
00:39:39
Speaker
But each one is kind of the way each one is processes independent from the others at a high level. how you think of it. It's like a map rather than a, yeah. Kind of yeah. Parallel mapping.
00:39:49
Speaker
Yeah. The other one's micro batching. Um, and micro batching, the idea behind micro batching is let's look at all the depots we're processing and all the partitions of the depots. We're going to see what data we haven't processed yet.
00:40:01
Speaker
And we're going to process that set of data as, as a batch, right? A so-called micro batch. Um, and what micro batching does basically with streaming, you can have either at least once processing guarantee or at most once processing guarantee.
00:40:15
Speaker
Right. And, uh, so if you're doing something like account, then that means you could have, um, errors, right. With at least with either of those at least once or at most once.
00:40:25
Speaker
Yeah. Micro batching, you can get a, um, Microbatch has an exactly once processing guarantee. It's actually really cool because it doesn't matter what your code is um for your Microbatch, the results, and doesn't matter how many failures that you have, the results in the P states are going to be ah exactly once in every case. And you don't have to do anything special to get that. basically Essentially what a Microbatch topology is, it's a cross partition transaction.
00:40:53
Speaker
In every case, no matter what your code is, you could be doing very complex things where um You're writing stuff to multiple petitions. You could be doing looping computations, maybe like graph computations.
00:41:05
Speaker
um All of it gets packaged together into essentially one atomic commit across every partition of every P state for the topology, which is very powerful. And also micro-batching, both streaming and micro-batching, I want to be very clear, um streaming has very high performance, very high throughput. Yeah, yeah.
00:41:23
Speaker
It has even higher throughput because there's no per-record overhead of processing. Because it's processing things as a batch, it's able to do things more efficiently. um So basically it's like even higher throughput, um super high throughput instead of just high throughput.
00:41:38
Speaker
I'm not familiar enough with the details of Kafka Streams to say why you would have getting been getting really bad performance um as you were seeing, but certainly Rama doesn't have those issues. Yeah. I mean, maybe, you know, I could be holding it wrong, but um I've done it on several projects now with several people and I've talked to other people on those projects that have been involved in it before and they've all had the same experience. So yeah,
00:42:01
Speaker
if you know if we're If we're all holding it wrong, then I feel like, okay, well, maybe it's a problem with the information or the design or whatever. Yeah. There's no inherent performance cost to that.
00:42:13
Speaker
um i can't comment on Calc. I'm not familiar why it would have been slow. There's no reason it should be. ah you You need to micro-batching to get the exactly once, right? So you cannot do push-based one-at-time processing. It has to be coordinated everything at once and don't move on.
00:42:26
Speaker
But basically, the works is that, yeah, Rama essentially is storing with the P states what ah so so basically every micro batch has an ID and it increases by one for every micro batch, right? So the first one is zero, the is one, right?
00:42:39
Speaker
And the first thing a micro batch does is it goes to see, okay, what's the new stuff on the depot? Right? um And then it will store and replicate first. What data are we going to read from the default for this micro batch, right?
00:42:52
Speaker
If we have retry it, we try the exact same set of depot records, right? So maybe for this depot for partition zero, we're going to read records from offset 1000 to 1900, let's say, right?
00:43:04
Speaker
And if fail, we're going to retry again. And the other thing you do is that the P states on disk are stored um as commits and every commit is for micro batch ID. um And so if we need to retry the micro batch, the first thing we do is we revert those revert those P states to whatever they were at the end of the last micro batch.
00:43:24
Speaker
right And that's how it's exactly once, right? Because if you revert to the exact same state where you were before, you process the exact same data, right? And you only move on, you've succeeded. And the whole result of this, um effectively, to like bring it into the database terminology, every micro batch, no matter what your computation is, and it's completely arbitrary logic that you're able to do, is a competition transaction in every case.
00:43:47
Speaker
um kind of on top of everything else. So it's very, very powerful computational tool. ah was one of the big ones for me, it was actually getting it to scale, because the first version of micro-batching,
00:43:58
Speaker
ah it was, did not scale. And it was like very disappointing because, um you know, we released, I'm sure a lot of listeners are familiar with this, but, you know, a year and a half ago, we announced Rama by rebuilding Mastodon from scratch and we made it scale to Twitter scale, right?
00:44:13
Speaker
And if you look at the chart, it's just a line, right? More nodes, higher tweets per second, and it's just linear and Twitter was like in the middle, right? We tested like way above Twitter scale. The first time ran that, it looked like, you know, Y equals log of X. It was like,
00:44:28
Speaker
not when harry it was bad. And now it had to do with the way that micro-matching was detecting like Completion of processing, right? It's like processing for micro batches distributed, right? And it's dynamic, right? So, um, the original, the original algorithm for that was similar to the storm algorithm, which turns out does not scale for micro batching.
00:44:52
Speaker
It's fine for streaming, but was not scalable for micro batching. And so I had to come up with some, something new for, for micro batching. Then, but then once I, and then it took a few iterations to get it like tuned correctly. And then it was like this nice linear chart. And that was, um,
00:45:09
Speaker
Yeah, that that was good to see. Yeah, I bet it was. yeah I think we had this discussion actually a bit in the offline chat about that because i I know I'd seen a talk that you mentioned about this, um the,
00:45:27
Speaker
the um what's it called? Like the probaistic probabilistic um algorithm that you're using for determining the success of the transactions where,
00:45:39
Speaker
You were essentially saying, and I can't remember the details of but essentially it was you were saying that that it was you you couldn't prove that it wouldn't work. No, you could prove it.
00:45:51
Speaker
You can explain it better. That was a big innovation for Storm, right? I figured out how to make stream processing guarantee data processing. And that's really the main reason Storm was successful, right? It was the first project to be able to do that. So you have arbitrarily dynamic distributed processing and guaranteed a data to be processed.
00:46:07
Speaker
Um, and essentially the way the algorithm worked is that, um, like you have an event and the event does some processing and then it generates outgoing events, which go to other nodes, right. Or maybe it's the same outcome events.
00:46:17
Speaker
Yes. And what's working is it would assign every node, um, a random 64 bit ID, right. So a random long. Right. Um, and then it would, um but um, essentially it was using XORing, right. So when events finished, they would send their.
00:46:34
Speaker
it was called the act value back to the the root where processing started and it would XOR. And every value that got generated ultimately would get XORed twice. Any value XORed with itself is zero.
00:46:45
Speaker
XORing is commutative. It doesn't matter which order they come back. And so once the root becomes zero, then you know processing is finished. But there is a small chance with every act because it're randomly generated that you accidentally becomes zero, right?
00:46:58
Speaker
But that probability so low that you can, oh like right? It would like, yeah it was something like at 10,000 acts per second, it would take like a million years before you had one fall back. And that would only be a problem if that happened to be one that failed, right?
00:47:14
Speaker
Yes. Yeah. Yeah. Which was also a financially Yeah. So the the probability was super low. Um, and so that's, that's why it was good. album And it was really cool because was very little information that needed to be additional information that needed to be passed on with every message.
00:47:27
Speaker
And it was only, it was very, very little information that needed to be stored at the root, right? Just one 64 bit number. Um, super, super efficient. So Rama uses the same, um, algorithm.
00:47:39
Speaker
um or the same approach, but it improves upon it. It's basically like twice as efficient. and And then for micro-batching, it's still the same idea for micro-batching, but the way the acts get propagated back to the root is different um ah in order to make it scalable. So that's that's what Ram is doing.
00:47:58
Speaker
Right, right. Nice, nice. So you mentioned Hadoop right at the top of how you got into Clojure and how you wrote Casca log and so on. um what What is the, um, there looks like a through line from watching the stuff you've done that it's a lot about big data processing.
00:48:19
Speaker
Like how did you get into that world? Well, that was just the first startup I joined was needed to do large scale processing. So that's how I got into it. And it was kind of the wild west back then. It was like you had to do, but people didn't really know what they were doing. Like, like the, the vocabulary was still being established.
00:48:37
Speaker
Um, so that was very interesting to me to, uh, to figure it out. Um, and yeah, I thought a lot about it and then got into closure, started doing stuff with that.
00:48:49
Speaker
probably got influenced by closure, like unconsciously, especially with immutability. after that, you know, I, I developed a lot of like ideas about like how to formalize this stuff. So that was like, I wrote a book about it, like land architecture, which became like a pretty well-known term.
00:49:03
Speaker
um which is really based upon like immutability as a way to simplify the construction of software systems, especially large scale. And the thing about Rama, like Rama is, um um you know can be used for large-scale data processing and some of our users are usually using it for that.
00:49:21
Speaker
um But it's not just a big data tool, right? Basically, like where Rama helps like reduce the cost of software development is two things. One is scale, just because scale scale adds so much complexity to to infrastructure.
00:49:34
Speaker
But the other one is... complex domain models. The more complex your domain model, the more you're going benefit from Rama because you're not going to have to twist your complex domain models to fit your database, right? You're able to mold Rama perfectly match um your domain model.
00:49:52
Speaker
um And that's, ah that can, you know, it simplifies things as a massive amount. um And so that's like, um that's why I'm not like, In the marketing of ROM, I'm not like describing it just as a big data tool, right? It's a tool for building backends at any scale.
00:50:09
Speaker
um this The scalability stuff is like the more like eye-catching stuff, um but um it is really good for small-scale stuff if you have a complex domain model.
00:50:21
Speaker
But okay, so I mean, but given given that, I think this is really, i mean, this is, um ah but like you said, super powerful. um And what what what's been interesting me interesting to me is that, like, we've talked about um the way of thinking and why productivity is important and efficiency and all these sort of things, um and how we we improve our thinking.
00:50:43
Speaker
But i remember when we first saw like the the marketing material for Rama was that, um you know, we were looking at like 100x performance, um which is ah obviously a significant jump in terms of what you can do with any technology. So it's a big claim.
00:51:03
Speaker
you know And know and were we're living in a world of big claims, like from OpenAI and various other AI companies who claim that, you know at least on on my version of GitHub, they're saying 38% more, my project can be 38% more efficient, whatever the fuck that means.
00:51:20
Speaker
but But, you know, that that's a sort of ah feels like, ah that feels like ah what we say, a lie? Yeah. um And i'm I'm hoping that you can tell me why why Rama is is not, like, in the same game as the the AI people when it comes to, like, their claims about productivity. know, where where but how can we get, like, more...
00:51:46
Speaker
how can we get more how How is it more convincing? How is Rama more convincing than some of these AI claims? Is that is that a fair question? I don't know. Yeah, it is a fair question.
00:51:56
Speaker
and and it's weird because like, so first of all, that the 100x didn't come out of thin air. it was No, no. mean, that's why we announced Rama the way we did, right?
00:52:06
Speaker
Yeah. We didn't just like announce like, oh, here's this event source and materialized views thing. And by the way, it's going to be a hundred x better than what you had before. that would be an insane thing to do, right? We've put a considerable effort to... to to First of all, it's not like we started with 100X and then produced a bunch of material to support that, but we did and we did the work, but basically the way we announced it, if anyone's unfamiliar.
00:52:30
Speaker
So we rebuilt Mastodon from scratch to be Twitter. So Mastodon is, Mastodon, it's but basically the same as the Twitter consumer product circa like 2015, before they added the algorithmic ah timeline to it, right? So it was just like the regular following timeline.
00:52:50
Speaker
right And you have a whole bunch of features there, who to follow and retweets and likes and favorites, muting and blocking and ah all the different features you have on Twitter. right we built the whole thing from scratch.
00:53:04
Speaker
um And then we we looked at the amount of code we had to write to build it from scratch on the backend. And we compared it against two things. We compared it against Mastodon's implementation, like the official open source implementation. And we compared it against Twitter's implementation of just the consumer product. Right.
00:53:22
Speaker
Right. And Twitter wrote over a million lines of code to build that product to scale. Um, Mastodon's backend was about 18,000 lines of code and our Rama based implementation was 10,000 lines of code.
00:53:36
Speaker
Um, and so if you divide a million by 10,000, you get a hundred X, right. It was a hundred X less code to write. Um, And then we, in our announcement blog posts, it was, think it was like 14,000 words. Like we, it was a very, very ah deep dive into, um,
00:53:57
Speaker
not just Rama, but into the mastermind implementation and how it works, what are the distributed systems and scaling challenges that you have to face when building that product at scale? And then how do you actually solve them with Rama?
00:54:10
Speaker
And the way we solved those data processing and scaling challenges is the same things that Twitter did. so just to like, Talk about a little bit about it, like to do that, like basically the challenge of that product is fan out.
00:54:24
Speaker
Right. So delivering tweets to the timelines of your followers. Right. Because essentially just amplifies the cost of every tweet, the average fan out on Twitter. I don't know what it is today, but ah five years ago or whatever, it was like 700.
00:54:39
Speaker
So that means one tweet, it's going to be on average 700 writes, right? um So it's an absolutely huge write load. And it turns out that the way to do that product efficiently is you keep the timelines First of all, you only keep like the last, uh, 5,000 entries on everyone's timeline or or something like that, or maybe it's only at last thousand entries.
00:55:00
Speaker
Um, and you keep them in memory and you keep them on unreplicated. Um, and what that does is it actually makes them unreliable. So if that's gene hosting that partition of timelines were to restart or go down, you lose all the timelines, right?
00:55:12
Speaker
um But what you take advantage of is the fact that um Twitter, the the way data indexed in Twitter is redundant because you can always reconstruct your timeline by looking and everything all the tweets of everyone you follow and you could reconstruct your timeline.
00:55:28
Speaker
And so the idea is that fan out, you make it much cheaper by keeping your timelines in memory and not replicating in them. And in the rare cases that you have failures, then you just reconstruct the timelines on read.
00:55:41
Speaker
So when the read happens, reconstruct it and then you continue with normal. So Twitter did that by building a whole bunch of custom infrastructure by scratch. With Rama, were able to do it by just composing Rama's much simpler primitives together in just a particular way for that application.
00:55:56
Speaker
um So anyway, that blog post, it was a long blog post and it went into detail on all of that. was a long blog post, like Paul Stoyan long, yes. And that was my that that was my idea, right, with Rama. Like I'd been working on it already at that point for almost 10 years.
00:56:12
Speaker
um It was this big platform full of new ideas and it it had these huge, huge benefits. um And so the idea the idea of that announcement was to like,
00:56:25
Speaker
overwhelmed with substance, right? Just provide a huge amount of evidence. Oh, by the way, we also, for about, I think was nine days, we ran a Twitter scale mass on instance um live and anyone could use it.
00:56:40
Speaker
um And what we did is we had 100 million bots posting. We used AI to generate a bunch of tweets. And so they were posting 3,500 times per second I think the average fan out we had on that social graph we generated was 400, I think. And it was a very unbalanced social graph, right? So it was very much a direct,
00:57:00
Speaker
um um it like it was legitimately running at Twitter scale with a Twitter-like unbalanced social graph. um And it was kind of funny just to watch, especially the global timeline. It was just like ah massive stream of just,
00:57:16
Speaker
just the bots talking. i also had the bots, like they would like comment with like comment and retweet each other. was kind of funny. I don't want to know what will happen on there. unless I mean, it's like vibe tweeting.
00:57:27
Speaker
i mean And honestly, that the quality the quality of that, a that to those bots talking was comparable to the quality of Twitter today. I was about to make the same statement.
00:57:40
Speaker
But, anyway so the the The point is, is that yeah we didn't pull 100x out of our ass. Like we put in, like it took us nine person months of effort to to to build Macedon from scratch. Yeah. and twitter like Like end to end and do the performance testing and, and and you know, and write that post. So it's very much a number I mean, it's it's it's just literally 100x less code than Twitter wrote to do the equipment.
00:58:07
Speaker
and And the reason it took Twitter so much code to build that product was because they are using, you know, it was built on traditional tooling um and traditional tooling wasn't able to do these things they needed to do with like,
00:58:23
Speaker
um the timelines, for example, being one example of that. So they had to build a whole bunch of customer infrastructure from scratch. And for every single time they do that, they have to build process management and replication and deployment and duability durability and monitoring. And they to all that from scratch every single time.
00:58:40
Speaker
um and And they had to do that for like, it wasn't just, they had to build multiple pieces of infrastructure from scratch. And that ends up adding up to a huge amount of code and many, many, many years of effort.
00:58:53
Speaker
ah and And actually, i actually think um like the 100X, like that's like the headline grabbing one, right? That's big number. But I also think that the comparison our Rama-based implementation to the official Mastodon implementation it's also really interesting because the Mastodon implementation is not scalable and it's written in Ruby. Our Rama one was scalable and it's written in Java. Now, Ruby is a much more concise language than Java.
00:59:25
Speaker
um And it is really unusual for, it is like unheard of for the scalable version of application to be less code than the non-scalable version.
00:59:37
Speaker
Right, right. Yeah. yeah like you Like it's always a huge multiplier because of all the additional challenges you have to face. but that And what that demonstrates is just how um how good Rama's abstractions are and how and how much we have eliminated impedance mismatches.
00:59:53
Speaker
So our code is able to be to the point um and is able to be concise because instead of having to build stuff from scratch, we're just composing simpler primitives together. Yeah. So out of curiosity there, Nathan, like if you combined the number of lines of... Well, so first of all, like really quick aside, you wrote the Mestadon clone in Java, you said.
01:00:15
Speaker
Was that just to make it more comparable with them the lines of code in in like Twitter or regular Mestadon? Or why why Java and not Clojure there? Oh, I think that was just that's just because most programmers did not program Cloderm.
01:00:31
Speaker
So we wanted to make it more relatable. Accessible, yeah. Gotcha, gotcha. OK. So then the other question there was, like if you count the number of lines of code in Rama itself,
01:00:45
Speaker
and add the lines of code of the Mastodon implementation there and compare that to Mastodon, then what do you get? like is it Is it comparable? Well, if if you're going to do that, then... know that's not fair, but I'm just curious. here if If you want to do that, then if you want to do a comparison, then for the official Mastodon implementation, you have to add up all the number lines of code for um all the lightres and Postgres and Redis and all that stuff too, right? Yeah, yeah. Oh, good point. Actually, I didn't think of that.
01:01:16
Speaker
And that that was one of like the really stupid things on the Hacker News comments for that blog post was people, like like their argument was like, no, it's not 100x because you're not counting the number of lines of code of Rama itself.
01:01:27
Speaker
Okay. but Rama is not a platform for like Rama is not specifically for building Twitter, right? It's a general platform that's would be comparable in this case to your fundamental infrastructure, like Postgres and Redis and all the other stuff that stuff is built on.
01:01:43
Speaker
Yeah. Good point. Yeah. That's yeah. That that was like, but that was like kind of infuriating just how, jesus how stupid those comments were. ah Sometimes people deliberately miss the point though, don't they?
01:01:56
Speaker
Yeah. So here's the thing. I don't read Hacker News. I'm very proud of myself for independently recreating a stupid fucking argument. so
01:02:09
Speaker
But, but yeah, and, and actually the, the number lines of code, actually, let me, uh, what's the number lines of code now? Number lines of code now is more than it was when we first announced it, obviously.
01:02:21
Speaker
The number lines of code today for Rama, we have 224,000 lines of source and 301,000 lines of test.
01:02:31
Speaker
Yeah. was actually a lot less code than, like, I think Postgres is like 6 million lines of code. Wow. Yeah, yeah, yeah.
01:02:43
Speaker
Yeah. But yeah, the it's it's it's actually kind of surprising how little code Rama is. um when you consider just like the breadth and and scope of what it can do. Cool.
01:02:55
Speaker
So Rama sounds amazing. I haven't had a, chance to try it yet. My plan was between jobs that I was going to try it out, but then apparently I got busy with other stuff. I don't even remember what it was.
01:03:10
Speaker
So I'm still waiting to get laid off again. Fingers crossed that'll happen soon. So I have some time to play with Rama, but we're all pulling for you. Yeah. Thank you. thank I'm sure my boss doesn't listen to this. So unfortunately I'll probably have to wait a little longer.
01:03:27
Speaker
um You said it took you six years to figure this out. And I know that it's Red Planet Labs, right? Is the name of your company? Yes. Not not Red Plant Labs, which is sometimes I get emails saying that.
01:03:40
Speaker
But Red Planet Labs. Planet. So... I, if I remember you all were kind of working on this heads down, don't know if you would use the word stealth, but it certainly was like, you weren't talking about it in the closure of community at the time. Like what was, um, what was the motivation to do this and, and, you know, how many people did you have at the start? And yeah, just tell us about the story of how this all came to be.
01:04:13
Speaker
so i started working on Rama in 2013. which is 12 years ago now. It was March, I think it March 15th. Yeah, it was the Ides of March. It was March 15th, 2013.
01:04:23
Speaker
So that's almost, it's March, yeah, almost exactly 12 years. well And so basically, you know, Storm was a big project at that point. I could have started a Storm company very easily. i had a ton of interest in that. You know, people were begging me to provide consulting services and all that stuff. But I ultimately didn't find that interesting to do that because it purely have been- It was your Lisp, was it?
01:04:46
Speaker
but It was your Lisp. Or Storm. Like you were talking about McCarthy wasn't interested in Lisp. You you also were just like, oh yeah, I'm not interested. Yeah, I got It's called a callback. Forget it. Okay. um But yeah, i was um
01:05:07
Speaker
I was also working on my book at that time, right? Again, i' said I'd been thinking about just like formalizing how to think about this land architecture. which is entirely based around the concept of functions, right? That's why it's called Lambda architecture.
01:05:18
Speaker
I've been thinking beyond like Storm, just like building systems like systems end to end. And I had already saw there the structure for a next generation platform for building software systems, right? Which ultimately became Rama.
01:05:31
Speaker
But at that point in 2013, I already understood that data storage should be in terms of data structures. That was just like brain dead obvious to me at that point. That's way vastly superior to to databases.
01:05:43
Speaker
um And I understood that like from Cask log that like data flow or like that style could be a really good way to express computations. um Realized it would take me so many years to figure it out from that point, from that thank point, um because it was grueling to figure it out. So, but I was determined to to to figure it out.
01:06:02
Speaker
um And I was making progress. I was making, like so I was making progress, even if it was like, Uh, not continuous progress, right. even Even if I got stuck many times for like months at a time, like eventually i would figure it out and break through it.
01:06:15
Speaker
Essentially like the way I approach programming, like any program. And this was essentially just this approach, like at the highest possible scale is, um, abstractions come from the unification of real use cases, right?
01:06:28
Speaker
I'm looking to build a next generation backend platform. I'm ah um'm ah trying to unify every use case that has ever existed. And so that's what I was doing. I was thinking of everything I had ever worked on, everything I had ever helped to work on, which is a lot of stuff at Twitter and also through my open source work, especially with Storm and trying to figure out how can all this stuff be expressed in a clean, beautiful, performant way in one simple set of abstractions that compose together. um And that was hard.
01:06:54
Speaker
um Like at first, you know, ah I understood that like it it made sense that data flow would be a big part of that. I thought data flow would be more limited, more of like a DSL.
01:07:05
Speaker
But eventually I figured out it had to be as expressive as a general purpose programming language. That's probably the first few years. That's probably 2013 and 2015 until I finally accepted that. Cause God knows I resisted that for a long time.
01:07:18
Speaker
Probably around that time is also when I, you know, rediscovered continuations and that became a big part of the implementation. um but anyway, it was grueling. And eventually 2019, I had it figured out and I had a prototype, which was not distributed. It was all just running in process, but using distributed abstractions, just in a distributed way.
01:07:38
Speaker
And so that, then I raised money based on that. So I decided, okay, now it's time to raise money and accelerate this thing. So raise a whole bunch of money from some really good investors. And then I started hiring. So 2019 is when the company really started, a bunch of people, and then it took you know, until 2023, until we we were ready to talk about it publicly when we actually had a working ah system that could actually be used for production. um And, you know, and now we've reached the point where we feel is ready for broader use.
01:08:05
Speaker
So during the the six years you were thinking about this stuff, were you also like, did you have a day job or was this literally the only thing you were doing? The only thing I was doing. Yeah. Holy shit.
01:08:16
Speaker
Yeah. So that's, different from the experience of most programmers. Yeah. ah So, but when you developed Storm, that was, um you were working yeah then, right? like in know was I was working for a startup called Backtype.
01:08:35
Speaker
I developed Storm. Storm took like eight months to develop. And then we got acquired Twitter. And then I released Storm from from Twitter. Yeah. Yeah.
01:08:46
Speaker
yeah So how how were you able to do that in very little time? like I mean, I guess it was part of your job that you were you're doing it. ah ah The scope of Storm is so much it's like you know way, way, way less than what Rama does.
01:09:02
Speaker
Yeah. Yeah. yeah so rama So let's put it this way. So rama so so let's say stormed let's say Storm took a year, right? Let's round it. And let's say Rama took 12 years, right? Except I'm a much better programmer than I was when I built Storm.
01:09:15
Speaker
So the scope of Rama is not just 12X storm, it's more like a lot more than that. yeah Yeah. Yeah. So Rama was this white whale, basically, that you were sort of, you know, working on.
01:09:30
Speaker
But I think, actually, I got question from a friend of mine who knew you were coming on the show. Yeah. And he was saying, well, you know, it's like, is it isn't it strange that like you had that opportunity to to to actually kind of be a gentleman coder for six years?
01:09:47
Speaker
um And is there something about like Silicon Valley or about the startup culture where, you know, you could essentially, know, IPO out or something or vest out where you could, you could,
01:10:00
Speaker
ah be a bit it's kind of like not what usually happens maybe it's more in europe that we don't we don't have as many people that are as that have such um remember rich when rich was looking at closure you know he was like you know got his got his uh cap out and was you know busking for money and stuff like this so you know even when even when the ideas are really good it sort feels like um you know you're putting a lot of your heart and soul into it because you know i guess At the end of the you're probably not you know a super billionaire.
01:10:31
Speaker
So you're going out money eventually. So you was you were taking quite a gamble, i think. enough money from the back-to-back acquisition that i was I had financial freedom to to do it. So I didn't have to worry about that. Right. i mean, that that that's the reason I did it because I was like, oh, I don't have to. I actually have the opportunity. yeah i have this amazing opportunity to actually pursue something and really meaningful.
01:10:52
Speaker
Right. um just I don't actually don't have to care about money at all at this point. and I mean, I would have made a lot more money then I had even just staying at Twitter, I would have made a ton of money just because I had a lot more equity to invest.
01:11:04
Speaker
um And I would have made a lot more money doing a storm company at the time. think ultimately making a lot more money from Red Plot Labs, um yeah but that's not that wasn't really what, that wasn't my motivation. No, no, no. But I mean, I get, you and obviously, like you said, that you might not have landed the white whale. And so it might not, you know, it might have all, you might have given up halfway through being frustrated.
01:11:25
Speaker
But so, you know, kudos to you for sticking with it, you know? Yeah. I mean, i I would have given up if I wasn't making progress, but I was making progress. Yeah. and I saw, like, I saw that it was, Probably about three years into it is when I was confident that I was going to succeed and in in building this thing.
01:11:41
Speaker
But in that first three years, it was I was making... ah First of all, I was making progress and also it was a lot of fun because I was discovering fundamental new things in computer science.
01:11:55
Speaker
yeah So yes that's what kept me going. So what does, um, what does that actually look like your, your hammock time? Like, you know, we, we throw this phrase around all the time, right? Hammock time. And it, it, uh,
01:12:10
Speaker
In my mind, at least, I always think of people like just kicking back and doing nothing but thinking. But, um you know, thinking can take many different shapes, whether that's like scrolling things on paper, banging stuff into a REPL.
01:12:25
Speaker
um so like, what was your process like when you were figuring all this stuff out? Well, it's a very good question you asked. I can see why you're hosting a podcast. I'll answer if I can, even though I'm just one man.
01:12:40
Speaker
and so basically what I would do is I would just sit there on my computer. i would have a text file open um and it says free form stream of consciousness into that text file. Then that text file ended up being like 30,000 lines long or something.
01:12:55
Speaker
Actually, my original original working name for Rama before I came up with the idea, like the name Rama, i was calling it supernova. ah And so but i have this file like supernova.txt and it's like incredibly long stream of consciousness.
01:13:10
Speaker
Just like kind of probably probably a lot of it's incoherent if I go back and try to look at it. But it's just essentially just like writing, taking notes. It's a lot of just like...
01:13:21
Speaker
Like spitballing, right? It's like, okay, here's this use case I want to do. Here's my ideas for abstractions. Let me try to work it out just in pseudocode. And then for those first three years, especially for the most part, I would run into a roadblock where it was just like, it doesn't express.
01:13:35
Speaker
It does not express me the kind what I've come up with so far. And so then I have to take a step back and then sometimes I'd get really stuck and then I'd have to figure out which one of my assumptions is wrong. Right. I mentioned that before with like the API for P states, how eventually I figured out, oh, it's Spectre.
01:13:52
Speaker
If it's just done in terms of ads, it solves everything. Um, and that was like, that was one of like the, uh, very memorable ones for me, just cause it felt so stupid at the time that I had already created Spectre with using it very heavily, but it took me so long to connect that to P states.
01:14:07
Speaker
But that happened so many times. Um, and, uh, you know, but enough iteration, I eventually got there. mean, everyone, everyone is different terms of how they think, but for me, it's just text files. I still do that.
01:14:20
Speaker
It's a different, I've moved on to different files. Not streaming with text anymore. um Now I'll create like a file per project and I'll stream it consciousness in there. Eventually i figured it out and then I'll write like a list of like steps.
01:14:35
Speaker
Okay, what's the steps I need to now go from this point to actually see it to completion. On the stream of consciousness stuff, I totally get how writing can help you think.
01:14:46
Speaker
um Do you go back to the stream of consciousness? and like do you Do you read what you write? Yeah, definitely. Yeah. I would go back. yeah and We're talking very abstract now, right? But yeah, just for like ideas or maybe like there was one thing. I was like, oh, yeah, I remember I had one idea there. So I'll scroll up like 2,000 lines and eventually find it.
01:15:09
Speaker
based on But it was that just how I, that's how I, i but that, that, that for me is that that's how i think the best. Yeah. Cause the other, I mean, i think there's, I mean, I'm going to switch gears a little bit towards like the, the, the horrors of AI.
01:15:26
Speaker
um And you know, we, people are going to ask this question anyway, so we might as well just ask it. It's like, okay, if you were thinking like now, Do you or would you um have used an LLM to help with that process? Or is that something which you still feel is a little bit, um let's say, orthogonal to the way that you did your research?
01:15:55
Speaker
I can't imagine an LLM would have helped with this, at least not LLMs as it is now. Because I'm doing something completely novel that's never been done before it's actually... like against like the way things are have been have been done right um so like llms are kind of the opposite of that right that they're good at like patterns or showing you stuff that's pre-existing right and they can be really good at that sure i imagine it would have been good for with or would have helped very much for designing ramo It's kind of funny for me because there's a lot of hype around AI as being innovative, but I completely agree with you that it's basically a kind of papier-mâché of what we've got now um rather than something which is going to provide a way to actually innovate on things.
01:16:44
Speaker
Yeah, I mean, i think like we don't know where AI is going to go, but I think the current state, think, is like that. But I still find chatbots extremely useful, but you have to know how you know you have to know where they're going to be useful.
01:16:57
Speaker
Yeah, yeah. Because one of the things I was i was thinking about was that if if Rama, like we were talking about this before as well, it's like if Rama is going to be a productivity tool and and LLMs are a productivity tool, then how do we compare those things? Because clearly there's no, or there's very little, ah a very small body of like knowledge about Rama in any LLM.
01:17:26
Speaker
um And maybe that will grow eventually, but but still, you know. We're going to be more into this, but I think first of all, they're not, um they're actually think they're incredibly synergistic. I think coding tools that are targeting Rama are going to be way better than coding tools targeting traditional systems because Rama simplifies development so much.
01:17:45
Speaker
And so it's going to ah enable AI to be doing much with with much less code, doing things in much bigger scope. um So we're goingnna be we're going to be pursuing that too ah to see how far we can get with ah is this is there technology. We haven't started that yet. I don't know how much exactly how we have to approach it.
01:18:04
Speaker
um Like we have to fine tune a model for it. But I do think that like theoretically um it does seem like coding tools will be really, really good on top of Rama. So Rama, where did the name come from then? You, you hinted that, or no, you didn't hint. You just fucking said it.
01:18:23
Speaker
Sorry. Am I allowed to swear on here? Where did the name Rama come from? Excellent. um Do you guys read lot of science fiction?
01:18:34
Speaker
Yeah. ah No. Well, it comes from a very famous science fiction book, Rendezvous with Rama by Arthur C. Clarke. Okay. Yeah. one of my I think it's probably my favorite science fiction book of all time.
01:18:47
Speaker
Yeah. So that's where it comes from. If you've read the book, you'll understand why it's named Rama. Okay. I will now read the book. I have read some Arthur C. Clarke, but clearly not that one.
01:18:58
Speaker
One of the greats. Yeah. Um, what's his, he had that famous quote. Um, what was that quote? There's sufficiently advanced technology is indistinguishable from magic. Yeah.
01:19:09
Speaker
Yeah. Yeah. We've hit that on this show before a few episodes back with Catherine.
Naming and Branding Challenges
01:19:14
Speaker
Yeah. So so that's what that's what Rama is then. Sufficiently advanced. Well, there's a more specific reason why it's called. If you read book the book, there's a more specific reason why it's called. okay.
01:19:24
Speaker
So actually the name the name Rama is funny because I just named it after the book. I didn't know anything else about the word Rama. I didn't know that Arthur C. Clarke got the name Rama from Indian mythology. Yeah. yeah yeah and there's like a whole it's like a huge thing and you know hinduism and all that stuff so when i found that out i was i was like oh shit i might have like really screwed myself because i don't know if this is some like evil thing but it turned all right demon that character is uh uh is is like fine uh there's nothing wrong okay i was kind scared for a moment i was like oh
01:20:01
Speaker
Because I was so happy with the name, because it's just like, it's four letters, easy to say, it's easy to pronounce. It's like the ideal name and it's unique. exactly what you want from name and it has just this really cool like meaning behind it from that book right in terms of where it comes from so i was really glad that i was able to just stick with that name nice nice glad it worked out for you yeah like like i like the name storm too but storm turned out not to be a great name because it's too common of a word right and it actually ended up being like this legal thing there was were some patent troll which got like bunch of trouble for
01:20:36
Speaker
like, ah you know, I donated Storm to Apache because I went to travel with Apache was the name because the name Storm was too common. and So, yeah.
01:20:47
Speaker
So I guess we have been talking for a while. um
Podcast Evolution and Guest Influence
01:20:52
Speaker
ah Yeah. Is there anything you kind of want to leave us with before we hit the exit door?
01:20:58
Speaker
I actually have a question for you guys. Girlfriend. you got Because you guys you guys have done, what, like 100 episodes this? Yeah. something Well, not me, but Ray. yeah but yeah So you got so i feel I feel that your listeners, you know they've been listening to you guys ask questions for so long. They they would want to know some things about you guys.
01:21:18
Speaker
You guys are kind of just a mystery to your listeners. We want to keep it parasocial. Come on. mean I'm just curious, like why like what why did you guys start doing the podcast?
01:21:30
Speaker
And has that motivation changed now you've been doing the podcast? Well, we we we we had a recent post personnel change with Josh because myself and Vijay started it And we met at a closure conference in Amsterdam that he was organizing, as it turns out.
01:21:48
Speaker
um And I don't know, I just suggested to him that we we had a nice conversation. And there wasn't really, apart from the CogniCast um thing, there wasn't really a closure podcast at that time.
01:22:04
Speaker
um And also I thought me and him were both kind of like jockey and a bit irreverent, I would say, if not downright rude. um and And that vibe is something that we've we've continued. and Obviously, Josh is is irreverent as fuck as well. So that's good.
01:22:21
Speaker
And we wanted to make something which was more, yeah, a bit more casual and a bit more irreverent than a lot of programming podcasts and certainly lot of closure.
01:22:35
Speaker
I think like the Cognacast was super nice and I think it was like, to my test, it was a bit over nice. um and It wasn't as like, it didn't actually interrogate anybody or have have a proper discussion about stuff.
01:22:49
Speaker
Um, and, and so, yeah, so it turns out that, you know, the, that was, that was enough of a motivation for us to start talking about it. But funnily enough, we didn't actually think that we, we, I didn't, the motivation was really just for me and Vijay to shoot the shit for, uh,
01:23:07
Speaker
as long as we as long as we wouldn't get bored. But um we started talking about The Repl on the first episode, I think. And Mike Fikes, who you might know from the ClojureScript community, is like a total god.
01:23:19
Speaker
And he's just such a nice guy. I've ended up working with Mike as well in in in another job. um And he's such such a lovely guy. And he he got in touch with me and said, oh, you know, if you're interested in talking about The Repl, I know a lot about this stuff and I could make mouse jump jump in and help you out.
01:23:34
Speaker
So he became the first guest and then... we
Podcasting's Growth and Community Engagement
01:23:37
Speaker
figured we might as well invite some other people because they're far more interesting than the kind of first two or three episodes that we put out. They were total garbage, you know? So, so yeah.
01:23:46
Speaker
Cool. So it's just fun and it just continues. to It's just fun. I mean, you know, and to be totally honest, we, we, um, we try to keep it relatively low effort as well.
01:23:57
Speaker
Um, which is, which was what, which is kind of what makes it sustainable. And then a friend of mine, I was doing the editing, but a friend of mine was giving me advice. And eventually I just said to him, look, Wouter, maybe it's better if you just do it because you you're giving me so much advice and I know you know how to do this shit. so And so he, you know, the kindness of his heart, he agreed to do it.
01:24:18
Speaker
um And that was nice. And honestly, it was just, a quick to be honest, it's like, it's a new medium. I've never done anything like this before myself. Neither at Vijay, neither at Wouter. And so it was just like, just something...
01:24:31
Speaker
fun and uh also i mean let's be honest i get to speak to people like you it's just incredible to me you know um i'd meet occasionally people at conferences and stuff um but never really get the chance to have in-depth conversations because you're always kind of like interrupted it's every it's always five minutes here and five minutes there and it's kind of unsatisfying So, so yeah, it's kind of like greedy, really, I guess, you know, to be unlucky that we get to invite and that you actually amazingly come on and talk to us. Yeah.
01:25:04
Speaker
Yeah. It's interesting how podcasts, just the way podcasts have exploded and they've kind of talk shows like on television at this point. Yeah, definitely. Definitely. There weren't a lot of programmers going on talk shows. Uh,
01:25:17
Speaker
The other thing I really like about podcasts, I mean, which is kind of like, it's kind of like the old web in one sense, in the sense that it hasn't really been dominated by any particular company. So like Spotify doesn't own podcasting, like Google owns search. Right, yeah, as much as they would like to.
01:25:35
Speaker
Yeah, yeah, they want to do it But there's all kinds of, you know, iHeartRadio and there's a whole, there ah this there's a podcast meta industry building up and building up, which I'm kind of like fearful of, to honest.
01:25:45
Speaker
But the fact is that you can just make these shows, put on RSS feed, and bam, you're out in the world. And we're kind of amazed that anyone listened to us. But then like after a few, after, don't know, six months or a year or something, I think because obviously the guests were so interesting, we did get quite a following. I actually don't know what the numbers are, to be honest. i never never look at that kind of stuff.
01:26:07
Speaker
But it's certainly like... or at least it was at one point like ah few thousand, which is ah was just completely amazing to me. That's like 100% of the Closure programmers in the world.
01:26:19
Speaker
Yeah, exactly. You better hope not. There's more than that. Actually, do wonder... Actually, are there numbers in that? how many Or any estimates on how many Closure Pro numbers there are? like How many are in the Slack? and There's 30,000 in the Slack.
01:26:32
Speaker
Oh, wow. yeah This is a shitload more than that, obviously, as well. yeah Although, actually, just make me think of, there's a great clip, if you look on YouTube, Grace Hopper was on the David Letterman show in the 1980s. Really? And she killed. She killed. She was amazing.
01:26:50
Speaker
So just like, one of the few instances of a programmer making it to the big time like that. so it's it's it's bad Every programmer will greatly enjoy watching her then.
01:27:02
Speaker
Right, we've got to look it up, put it on there. Yeah, definitely going to dig that one up. yeah Yeah, but funnily enough, I think Vijay gave up after 100 because he'd like made his goal. Well, 100, yeah. yeah there's Nearly 100, yeah. and ah But I spoke to Josh about it, and and it was like, yeah, it's something that he was interested in. i'm i but We wanted to give it a refresh as well and keep it going, but keep the same spirit. So, yeah, maybe as you can speak to it, Josh. What's your kind of motivation?
01:27:31
Speaker
Oh, for being on the show? Well, I mean, we were we were talking and you mentioned Vijay was going to retire, you know, hang up his Emacs claw.
01:27:42
Speaker
And um I think I said, oh, you know, if you ever do guest hosts, I could come on for one and, you know, shoot the shit with you and somebody. And somehow come on for one turned into, you know, come on for all of the ones.
01:27:59
Speaker
But, yeah. Yeah, I mean, it's very similar to what Ray said. Like, it's it's really interesting to to talk to people that otherwise, you know, you would you know you might chat on Slack with but or or see at a conference. But, you know, to get to talk to people for like an hour plus um and hear stuff, it's it's interesting.
01:28:23
Speaker
Have you guys ever tried to get Rich Hickey to come on? ah Yeah, yeah, we have, yeah. We've had Alex on um and he was really good. But i think Rich is not interested.
01:28:35
Speaker
Right. You know, we'll see. we can We can keep on asking. You know, maybe he's got more time now. Yeah, right.
01:28:42
Speaker
I think also we're a bit we're we're a bit like ah like you said at the beginning, we know we're a bit like ah we don't have to give a fuck because you know nobody is paying for us to so sponsor this stuff. so i mean Obviously, we don't ask really very hard questions. We're not that clever.
01:29:00
Speaker
so but But yeah, you know it's it's fun. i thought they were pretty tough questions.
01:29:09
Speaker
You copped very well, okay. Nice. With the onslaught. hid my fear. I hid my fear.
01:29:18
Speaker
No, thanks very much, Nathan. It was really appreciative. I'm really appreciative of your time. And yeah, it's been great to meet you. And and thanks for your questions as well. Yeah. I'll the and re in London and in May for the Reclosure Conference.
01:29:32
Speaker
so if you got Oh, wow. Okay, great. We got to go to that. Yeah, yeah. James mentioned it at the heart of closure. So yeah, it would be, that's going to be great. Okay, fantastic.
01:29:42
Speaker
yeah yeah Let's hook up. Yeah. Yeah. And maybe I'll get laid off before then. So I'll have some time to play with Rama. yeah ideal yeah yeah Yeah. Well, I think the motivation that you've given us is really strong for it. So, you know, great job on that.
01:29:58
Speaker
And yeah, definitely look forward to seeing those, the the the free version and the blog post coming out. So yeah. Yeah. Fantastic. All right. mike Thanks very much. Thanks for coming on.
01:30:11
Speaker
Thank you for listening to this episode of Def N. And the awesome vegetarian music on the track is Melon Hamburger by Pizzeri. And the show's audio is mixed by Walter Dullert.
01:30:22
Speaker
I'm pretty sure I butchered his name. um Maybe you should insert your own name here, Dullert. Walter, Walter. If you'd like to support us, please do check out our Patreon page. And you can show your appreciation to all the hard work or the lack of hard work that we're doing.
01:30:38
Speaker
And um you can also catch up with either Ray with me for some unexplainable reason. ah You want to interact with us, then do check us out on Slack, Closure in Slack or Closureverse or on Zulip or just at us at Deafen Podcast on Twitter.
01:30:57
Speaker
Enjoy your
Closing Remarks and Humor
01:30:58
Speaker
day and see you in the next episode.
01:31:33
Speaker
I don't know, Ray. But anyway, ending this tangent. Right. Okay. Into the brick wall of your ignorance and imperialist mindset. Maybe we'll cut this bit because it's absolute bullshit. And, you know, we're definitely not destroying Nathan at this point. So let's get back onto that, you know.
01:31:51
Speaker
Yeah, he's turned the tables. like He's making you sound like a red eejit. mean, this is great. Walter leaves... Goddammit, Nathan.