Joel: 0:00

Hey, Collin.

Collin: 0:01

Hey Joel, uh, how was Brighton Ruby?

Joel: 0:04

Brighton Ruby was awesome. It was so well done. Um, met a bunch of friends, including many friends of the show. Um, bunch of people I'd never met before in real life, but kind of have known online for years, so that was awesome.

Collin: 0:20

That's cool.

Joel: 0:21

yeah.

Collin: 0:23

Uh, yeah, you were saying you, you hooked up with, uh, Marco, uh, Tim Riley, some other folks.

Joel: 0:30

Yeah, uh, I think, I mean, I, it's just so many, so many people, um, I can't, I don't know how many people were there, it was hundreds. The, the place was packed.

Collin: 0:40

Oh, wow. I thought it would be small. I was imagining this being like a hundred people, maybe.

Joel: 0:45

No, it was, it was, it was many hundreds. The place was absolutely packed, I don't know how many exactly were there. Um, people travelled from all over the world, um, for this one day conference, so.

Collin: 0:58

Well, now I know it would potentially be worth me going to next year. I mean, it's worth it for us to hang out, uh, regardless, but it would definitely probably be worth it if, uh, I don't know if there's so many cool people there. I wanted, so I wanted to bring something up to you, which is, I learned this yesterday. We have a product, a food product in the United States called, uh, an English muffin, right?

Joel: 1:23

hmm. Mm hmm.

Collin: 1:25

call these in England?

Joel: 1:27

I, well, I don't know what you're referring to

Collin: 1:29

So it's, it sort of looks like a crumpet. It has nooks and crannies on the inside. Uh, it's a very fluffy kind of thing. Uh, I'm, I'm going to give you the, uh, I'm, I'm just going to tell you. It's called a, you, you call them muffins. It's what you would call a muffin. We call them an English muffin. Uh, do you know the kind of muffin which has like a stump and kind of a mushroom head and it's sort of sweet? Have you seen these?

Joel: 1:56

Uh, yeah, yeah, that's, that's what I would call a muffin.

Collin: 2:01

Oh, really? Because I was re Well, I asked ChatGPT, and this is another reason it's bullshit, because I asked it. I said, what do, um, I asked it what, uh, British people, uh, you know, do, and they're like, oh, they call it a muffin. They call those American muffins. But apparently,

Joel: 2:16

Oh,

Collin: 2:17

again, ChatGPT has let me down. Um, so that's, well,

Joel: 2:22

I think, based on your description, uh, ChatGPT is having you on. Yeah, we, we would call muffins muffins and English muffins English muffins.

Collin: 2:33

You do You call them an English muffin?

Joel: 2:34

Yeah. Yeah.

Collin: 2:37

What a

Joel: 2:37

I mean, there might be some people who would just call them a muffin, but it seems...

Collin: 2:42

I feel like that's a really good example of where ChatGPT, like, got the context clues of what I was trying to ask, and then just, like, went for it.

Joel: 2:50

Yeah, you can kind of see how it would be good at programming though, like, like it kind of understood the concept. Well, if it's, if it's an English muffin to Americans, then it must just be a muffin to,

Collin: 3:01

Yeah. And then that's an

Joel: 3:03

And, and a muffin must be an American muffin to the English. Like, it's logical. It makes sense. Just, it's not grounded in fact.

Collin: 3:11

No. Well, anyway, so, uh, that was my question that ended up, uh, being a tangent. So, the thing I've been doing this week, once again, because I'm, uh, I don't know what's wrong with me is I've been reading more 40 year old documents about Smalltalk. Um, which, you know, I don't have a lot to say about it right now. I did write another blog post called something like, uh, the Xerox Smalltalk 80 environment was really weird, was weird. Um, because I ended up figuring out how to virtualize, uh, Smalltalk 80 on my Mac, which. Uh, was really easy, actually, and there's probably things I'm missing because, like, there could have been more stuff there that I wasn't aware of, um, you know, like software and things I didn't get in my image, you know, that I was running,

Joel: 4:05

Right.

Collin: 4:06

but, uh, it is, it is interesting, because I think what I had is pretty close to, like, what Steve and the team saw when they went to Xerox PARC in, like, 1978, and so, It's interesting seeing how much of it was there based on what they saw. Like, like they had, I actually don't think they had overlapping windows in 1970. I think that came later, but you know, like they have overlapping windows, they have scroll bars, they have things like that, but other things are very weird. Like for example, um, they have, they have key commands, but they are, tend to be things like you hit control parentheses and it adds both sides of the parentheses, not like. Uh, a key command to like. Collapse this window or they don't have not things like that that I could find Um, and other things are really weird Like if you want to if you want to move a window you don't grab the little title thing and move it What you do Is you? You like right click on it and then select move and then move your mouse and click again and that's how you move windows and that's also how you change the size. So it's kind of so it's really weird. Um, it's not like an operating system. How you think of it? Like, obviously it is an operating system like it, you know, is loading on it on hardware. Uh, but the Smalltalk environment was really more like an IDE, kind of, if you know what I mean. And I think people get mixed up because they did, they, so they had a product called the Alto, which ran something like this and that was like a research machine and then they had a product that was actually that people could buy called the Star and the star was much closer to like it had icons and like it was much more like a Mac It wasn't Smalltalk. It was like a different sort of thing. And I think that people get confused They're like no like the desktop metaphor was all there It's like I think it's because they was there later on a different computer that wasn't Smalltalk but the Smalltalk environment was Very sparse. So anyway, that's what I've been doing this week. It was uh, it was so that that's cool So I'm probably gonna write more about it. But um in the meantime That's kind of where I'm at with it.

Joel: 6:19

I, I thought it was really interesting to see the, all the screenshots that you posted in that, in that blog. Like it's, it's kind of, it looks, it reminds me very much of very, of like old macOS. Not that I ever used that, that version of macOS, but I've seen it in like movies and things.

Collin: 6:38

I'm gonna show I'll tell you how to run it on your computer, but um, you can virtualize that too.

Joel: 6:42

Yeah. I think the first macOS I used was Tiger.

Collin: 6:46

Yeah, I used it when I was like in middle school and maybe a little bit in elementary school. I really remember it from middle school because I had typing class, um, and then, uh, yeah, and then I think I came back around Tiger. Um, I really wish, uh, I don't think my parents could have afforded this. I'm going to be honest, like we weren't rich, uh, and it would have been a lot of money. I really wish I would have. Circa 1998 99, just done like the full court press for I Want One of Those iMacs when they came out with those. I think it, I don't know if it would have changed my life, but I think it would have, uh, I don't know. I think it would have been cool, um, to have gotten in a little bit earlier than I did. Um,

Joel: 7:25

You know what would have changed your life?

Collin: 7:27

what?

Joel: 7:28

Buying like, 300 worth of shares. Right?

Collin: 7:34

Yeah, that, that, that's, that's correct. Um, Apple stock is up right now, though. I'm very happy to see it, uh, as a, as a very small shareholder. I'm always happy to see it go up, uh, especially cause I just sold a small amount of it. Um, so, oh, we paired on something this week and. It was, it's amazing. So I haven't like paired as much as you, but you talk about it all the time that you're a big fan. And now I think I understand why, because I was like, I could imagine somebody being like, it's going to be twice as fast, but it's not for us. And maybe it's because we're a dynamic duo. Uh, but it didn't feel twice as fast. It felt like six times as fast.

Joel: 8:16

Yeah.

Collin: 8:17

And like, just really, I don't know. I thought it was amazing. I'm, I think, I, I assume not everybody is, you know, I assume pairing with different people is different, but I think I am very sold on the concept right now.

Joel: 8:31

Mm hmm. Yeah, definitely. Pairing is great, but pairing is very different with different people, I would say. Um, and also like, depending on how much energy people have, and what you're trying to accomplish, and things like that, you, I don't, like, how we paired the other day, I don't think you could pair like that all day. Um, we did like, like an hour and a half to two hours, and it was like, pretty high energy, um, and I was, I was pretty exhausted by the end of it, but we got so much done, it, like, prototyping this thing.

Collin: 9:06

Yeah, it was like, it was like that much and it was high energy, but it was like a day of work actually. Like if I was just on my own, that would have been like eight hours, like for sure for me. And also I feel very, I'm going to tell you this, because you've done a lot more Ruby and also a lot, a lot more Rails than me. Um, you know, but I'm, I'm pretty good at it too, but uh, I'm no Joel Draper is what I'm saying. Um, I'm really excited when I know something about Rails that you don't know. That just, that, that makes me so, that makes me feel so good, I'm going to be honest. Because I'm like, I taught Joel something, that's great.

Joel: 9:40

I can't remember what it was you taught me,

Collin: 9:42

I think you didn't know about, about uh, DB rollback. I think

Joel: 9:45

Oh yeah, that was it! That was it, yeah. I always did, um, binstash frails db drop db create db schema load db seed, and I did all of that manually. And just kind of like, type it every time.

Collin: 10:00

yeah.

Joel: 10:01

Um...

Collin: 10:02

I, I was, I was very, I was very pleased, uh, that I, I knew one thing you

Joel: 10:06

Actually, sorry, rollback, right, so you're talking about

Collin: 10:09

Oh yeah, no, you were, you were

Joel: 10:10

done a migration, you just want to roll the one migration back,

Collin: 10:13

Yeah, you were getting the ID of a migration and then like giving it the command like down or whatever to go to that. And I was like, Oh, you can just hit rollback is what I normally do. And that'll just go down one.

Joel: 10:23

right, yeah, my process was copy the timestamp of the migration, and say, set the environmental variable version equals this timestamp, and then say bin slash rails db migrate, that's the only way I knew how to do it,

Collin: 10:36

Yeah, so this is a, yeah, it's a little bit more convenient. Um, but. Yeah, uh, so, so I, I'm really sold on pairing. I think it's, at least pairing with you. Uh, you know, I don't know about other people, but, um, Uh, so, so very sold on the concept. Uh, it's, it's too bad you're in, like, a very different time zone than me. Uh, cause it really limits the amount of time I could get you to do it. But, um, yeah, I don't, I don't know. That's all I really had to say about it. Uh, I saw you made a tooth this week about, uh, about literal though, about how it, uh, You've now, like, installed it in a real app, and it's, like, working, and, um, I don't know, do you want to talk about that?

Joel: 11:16

yeah, sure. So, um, kind of like building literal and testing it as we go. Um, but there's, there are a few features in literal now that are pretty stable. Um, partly because they, there are some tests in, in the literal code base. And partly because they're very well tested in the application. I'm kind of building it around. Um. Um, yeah, so the, the features that I'm using mainly are like literal struct, literal data and literal attributes. Um, so quick recap on those, basically, uh, literal provides, um, this kind of like class level macro. Uh, attribute macro, it's called, um, and you can say like, this is the attribute that this class has, this is its name, this is its type, um, and you can, you can then say like, it's, it's either a special like keyword argument, um, splat or positional argument splat or a block, um, and then you can specify like, do I want a reader, Yeah. And like, do I want my reader to be public, private, protected? Um, same with a writer. Uh, you can also give it a default, um, and you can give it a coercion block. So basically saying, um, I could say the type of this attribute must be a string, but then I could say do value and then value dot two S. So I'm basically saying whatever value comes in, convert it to a string. And then try to set it, um, so as long as it returns with a string from that, from 2s, then it's going to end up, uh, having the right type.

Collin: 13:02

That's pretty cool.

Joel: 13:04

Yeah, so, so this, this is available on all of these, uh, things that literal attributes is the mixin that allows you to kind of add this to an existing class and then, um, literal strut, uh, it's just like a strut, literal data is essentially a strut but it's frozen, um, so you can't mutate it once you've set it, um, yeah, so, um, there's now I think 650 ish, uh, attributes Using this in production and, um, it seems to be working really well. So quite happy with that.

Collin: 13:40

That's amazing. Yeah, no, it's really cool that, like, you have two different things now that are actually being used, you know, uh, like, seriously.

Joel: 13:49

Right. Yeah. Um, it's, I mean, it, it's the, the whole concept of literal, like, basically the idea is that if you have an error in your code, you could wait, like, you could try to avoid that error for as long as possible, um, and kind of let it propagate down through your code. Um, and eventually you get this error, maybe like 10 files away from where it originated from and you have to, and you've got this like really weird error message that you have to try to understand. Um, or you could try to make things raise really early, but with the most helpful error message they can raise. Basically, as early as possible. Um, and I think that is the better way to go. So, the idea of literal is, as soon as an object receives the wrong type of thing, it raises and it says, Hey, you tried to set this thing, um, to this, and it was meant to be one of these. Essentially, um, and the idea is that you run this at least in your tests, uh, and so just exercising the code means that you've got a lot more kind of coverage, um, a lot, a lot more, um, chance that any kind of like. Mistake is going to be caught and it doesn't catch everything, but it does, you know, it does really help you catch a lot of, a lot of things, especially, um, the dreaded, like nil doesn't respond to X kind of, um, error message that you often end up with, like, rather than that message, you would probably have, Hey, we expected this thing to be integer and it was nil, um, exactly here where it was called. So.

Collin: 15:43

Yeah, and I, I hope that the errors are that succinct, something I tooted about was thinking about this week was that, um, this one framework I was using, I don't, you know, libraries, you know, I don't want to name names. Right? But the error message was like, I really need it to be like, I expected this to be an array of this type and you passed me an array of this type or whatever it is, right? Like just to like, say that. But instead the error is like some shit happened basically and then it just prints the entire like array or whatever to my console I'm like this isn't helpful at all I know something like I really just need to know like what type I was expecting and what type I passed in and Then like I could fix this in two seconds, but you didn't say that so, um, I don't know That's just something I I would I would like in a you know in a library like that.

Joel: 16:36

Yeah, the third thing that you can say, um, actually, and, and literal doesn't do this yet, but it's going to do it very, very soon, um, is not just like what type was expected and what type was passed in, but what attribute was it expected on, because sometimes that's not very, really very clear.

Collin: 16:53

Oh Yeah, no,

Joel: 16:54

so it's like, hey, the, the attribute username was expected to be a string and it was a nil,

Collin: 17:01

Yeah, that's exactly what I

Joel: 17:02

you've got exactly those three things. Um, So, yeah, that,

Collin: 17:06

is I pass you an array and you just print out the whole thing. Cause like, I can't do anything with that. But if you said this array was an array of strings and I was expecting an array of integers, that's, that's very actionable for me.

Joel: 17:19

Yeah, so that, that one's quite tricky to do, but, um, let me just go back for a sec. So what literal does right now is it will say, hey, we expected, um, nil to be an integer or something like that. Um, what it's going to do very soon is we expected this attribute nil to be an integer. Um, and what it's going to do eventually. Is say, is be able to give even better errors when you've got something like, um, a union, or an array, or, um, or, actually not, not really a union, it's not really relevant to that, but, but for example, an array or a hash type, um, so with an array or a hash type, you can sometimes have quite large, um, like quite large lists of things, um,

Collin: 18:08

performance issue is what you're thinking?

Joel: 18:10

no, no, no, so what I'm thinking is like, let's say you have an array, And it has, like, a hundred items in it. And ninety five of them are strings. And five of them are integers. And the error message just says, Hey, expected this huge array to be, um, an array of strings. But it wasn't. Right? That's not that helpful compared with if it said, Hey, we expected this item in this array to be a string. But it was an integer.

Collin: 18:42

Yeah, the item it index, whatever was not the thing or something like that. Yeah. I mean, I would even just be okay of like giving it, if you imagine in languages that have like, um, you know, where you can declare like generics and stuff where you could be like, this was supposed to be strings and it was string comma. Integer even that even that would be good because I would just like know that something's up there but Yeah, just printing out like the whole thing like you say cuz they can be big so if it has a hundred items in it Like I don't know like I can't do anything with that

Joel: 19:15

Yeah, I'm kind of still working on, on quite the right wording, but what I'm thinking is with, with array, for example, is to say expected this thing and then use square brackets to, and then indicate the index. So like, um, list, square bracket, like five. To be an integer, um, as part of an array of integers, but instead it was a string. Like so that your, your error message actually just gives you all the information. I know it's the fifth item in this array. The type that it was checking was array integer. The specific detail was that this one item was a string when it should have been an integer, and then you get kind of everything. So I'm, I'm, I'm working on that. It's, it's a bit tricky because, um, basically. In order to support all of the existing objects as types, the interface that, that, um, literal uses is it just calls the triple equals method on the type and passes it a value, and if that comes back true, then it is of that type, if it comes back false, um, or false y. Um, then it's not of that type. Um, and obviously that's just binary true or false. It can't go into, like, dig into the detail. Like, it's not recursive. It can't say, okay, now I've checked that it's an array. I want to check each item individually, and then be able to raise a specific error message for each item. Um, so I'm gonna basically add... An additional interface that some types can implement, um, which will be kind of, it will have to, it will have to have the same functionality as the triple equals method, instead of, I guess, basically, once that triple equals method fails, you can then do another check against this possibly slower, uh, method that's kind of going to break it down and give you a better error message, if

Collin: 21:02

Yeah, that no that all that absolutely makes sense That sounds great. No, I'm really excited Cuz yeah, there are a lot of things that it That sort of thing can help, uh, and error messages specifically, though, for me are the thing where when this goes wrong, because I couldn't make it happy in some ways, I'm like, I just don't want this anymore because I can't figure it out, um, and this presumably would have, maybe, I don't know, I, I think it just makes me frustrated at that point.

Joel: 21:33

right. Yeah, it's going back to, um, kind of more generally what like using literal now, um, on. Uh, you know, hundreds of different classes, the thing that I'm noticing is where I've tried to use type checking libraries before, things like Sorbet, um, even RBS can be quite, quite tricky and it doesn't, like, I know it doesn't have a proper, um, like static type checker yet, um, like steep is looking very promising and that's coming, coming soon. Um, but there's still a lot of like Ruby syntax that steep doesn't really understand and that can get you kind of blocked on things. And also there's a lot of Ruby that just can't be statically type checked. Um, so you end up taking a lot of shortcuts anyway. But going back to my, my point, um, A lot of these things often feel like it's a lot of a burden to have to like add types to your code base. Um, and the thing I've noticed about literal is it's actually removing burden because. It's replacing your initializer and it's replacing your writer and your reader code. Um, you don't have to call like add a reader, add a writer. Um, and, and you also don't have to ever look for like, Oh, do I have a reader for this attribute? Do I have a writer for this attribute? Separate from the initializer where the attribute is set. And so everything about each attribute for your class is basically really consistently stored at the same place at the top of the file. If, if anything, it helps you just, helps you remove code and have less boilerplate because you don't need to do anything in your initializer, like it's, everything you could want to do is all done for you, or otherwise there's like an after, after initialization callback that you can use if you need to do some extra setup. Um, but yeah, like, so, it's, it's very much like, it gives you a lot of extra safety. It doesn't do it by adding burden. In fact, I think, I think from my experience, it seems to be taking a lot of that burden away. Um, so I'm really, I'm really excited about that. Um, but I've been working on a new feature, uh, kind of hacky on that. Um, the last couple of days, and, and that is basically, I'm trying to make it so that you can use literal to, to basically improve instance variables, so, the problem with instance variables, a lot of people have written about this, um, and, and some people would say that you shouldn't really reference instance variables directly, you should always use instance variables. Um, I think like readers instead is the problem is if you make a typo in when you reference an instance variable, it's going to be totally fine. It doesn't care. It's just going to return nil. Um, and so there's a, like. There's a whole ton of bugs that you can easily introduce just by using instance variables and, like, referencing instance variables rather than referencing methods, because if you call a method that doesn't exist, then instead of there being, um, like, nothing, it's gonna, it's gonna raise and say, like, that method doesn't exist. Um. The problem with calling methods is I feel like reader methods should really be kind of like an external interface or, um, or if you need them, some calculation or some data, not like reaching for the data itself. Um, and it just feels a lot purer to me to use instance variables internally within a class. But aside from that. If you have a class like, um, like a flex component where it's got a lot of methods on it already, like if you think about it, um, in the, in, in the HTML elements, there are things like title, um, and title is a very, very common attribute, but title is also an HTML element. So if you have a method title, That's meant to be referencing an attribute title, rather than creating a title tag. Um, then you could, like, you have another risk, which is, if I typo the definition of this or something, then I could end up calling a method that does exist, but it doesn't do what I expected it to do, because I'm meant to be referencing an attribute. Does that make sense?

Collin: 25:47

Yes, that does make sense, and yeah, I can see both sides of that, um, with the instance variables versus, uh, using, you know, setters and getters or whatever, uh, attribute, you know, whatever. Um,

Joel: 26:01

Yeah.

Collin: 26:01

in, back in my Objective C days, the... Kind of the rule that, like, the community, I feel like, settled on, was that, yes, you always, so, other than in the initializer, basically, you always access through the property, uh, but also Objective C is a different language than Ruby, um, notably, so, uh, I don't know if that's a rule that carries over.

Joel: 26:28

yeah, so I've, I've read people advocating for using readers all the time. Um, I, I think that's what you mean by property,

Collin: 26:36

Oh, sorry. Yeah, I meant

Joel: 26:38

C, yeah. So, and, and, and one of the arguments is that it helps you avoid refactoring. Like, if you could change the implementation of that reader, To be a calculation, or something like that, rather than a property reader, without having to change any of the call sites. Um, and, get that, but, to me, it doesn't make any sense. If, like, within a single class, I can change, I can, I can find all instances of, of an instance variable very, very quickly just by like selecting one and pressing command D a bunch of times, right? And then I can just change them all at once. Like that, that argument to me is, is, is pretty weak. Like it's not difficult to do a find and replace. Um. Yeah, the, the argument that, you know, if you call the wrong one, it's just gonna like silently fail and you won't know about it until something goes really bad. That's really strong. So what I've been working on for the last couple of days is basically, um, seeing if I can have a kind of pre processor that will kind of parse your Ruby code, look for any instance variables that aren't guarded by, for example, an if condition that says If defined. Instance variable, then reference the instance variable or maybe raise unless defined or return unless defined or something like that. If it can find the instance variables that are referenced, but not guarded and update the Ruby code before it's, before it goes to Ruby to be interpreted to, um, instead say, you know, raise an error if this instance variable isn't defined, otherwise return the instance variable. Then you get, I think, a lot more safety. If you typo an instance variable, then it's just going to blow up straight away, as soon as you try to run your tests. Um. Whereas if you get the right one, then that defined conditional is going to be false. It's not going to raise. And so it's going to move on and let you reference the instance variable. So this is like, I don't know if this is going to work. Um, but the idea is that to somehow hook into either like the require process or, um, Or like there are some hooks that you can do to like, after a file has been required and then you could perhaps like patch it. So using eval, you could patch, like override the methods to, to redefine them to new ones. Um, but yeah, this is kind of what I've been working on the last few days. Um, like basically using syntax tree to do the parsing and like of the file. Um, um. Yeah, trying to figure out the right hook, uh, to be able to do this. And there's actually, there's a gem that's pretty similar, um, that, um, Cameron's been working on, and, uh, I think, yeah, I don't know. I think, I'm, I'm just excited for the possibility of, of, of, like, there being these kinds of, like, layers of pre processing that you can put in. Um, but yeah, I don't know.

Collin: 29:52

No, that's cool. That, that, that makes sense. That, yeah, I mean, it seems like kind of an obvious feature to add too. Um, so it makes sense to

Joel: 30:00

Yeah. I, I think there's probably been a lot of discussion about whether the Ruby implementation should change and I don't think we're likely to ever see a change. If we did see a change, it would

Collin: 30:11

would break a lot of things, most likely.

Joel: 30:13

yeah,

Collin: 30:13

They're not big. Ruby's not big on breaking things.

Joel: 30:16

it would probably come with a magic comment. So you'd, you'd have a magic comment at the top of the file, and then within just that file, maybe instance variables had to be defined before they could be read. But, um, yeah, Ruby's not big on making that kind of change, and I think... I think it's probably not necessary, like, I think, you know, it's amazing what you can do with, um, just like hooks and monkey patching and

Collin: 30:41

Yeah, like Ruby code, you know, that's like. That's the coolest thing about Ruby is that it has this very minimal syntax that lets you do things that feel like language features, but they are not. And they, uh, you know, I mean, that's, to me, that's the best thing about Ruby.

Joel: 31:03

right, yeah, I mean, like, even things like Zitework, um, which is, you know, really popular autoloader for Ruby. Um, that is still doing a ton of monkey patching and stuff that you might turn your, uh, eyebrows up at or whatever. Like it's, it's, it's really, um, yeah, it's, I mean, but like it's stable. It's really stable because it's well tested and everyone uses it and, um, Ruby is kind of designed to be used like that. So I don't know. I, I feel like. This is, um, an interesting kind of way to experiment with like, what if we could enable language features that don't exist, but we want to use them because, um, you know, they fit better with the way that the way that we code or whatever. Um, and I don't know, it's kind of, it's kind of fun.

Collin: 31:55

Yeah, I'll just make a hot take that I'll probably recant when you tell me it's stupid in two seconds. But I guess if you hate all of those kinds of things, you should probably just code in Python or something. Like. You know, there are languages which don't have as many of those features, and Ruby is really built, like, it is really built to support them in a way that, like, other languages are not.

Joel: 32:19

It, it is, but it's also built to be very customizable. Like I couldn't do half the stuff that I do in Ruby. In a different language and like make the code be the way that I want the code to be I just I don't feel that I could do that. I think crystal is probably the closest to that but but like Even like you don't have anything like the the flexibility in crystal that you have in ruby,

Collin: 32:45

No, I mean, you can't, right? Because it's a, uh, it's a compiled language, it's very different. Um, yeah, I don't know, Ruby's a

Joel: 32:51

I don't know. I I love it. I think it's I I like how flexible it is and how kind of dangerous and sharp

Collin: 32:59

Yeah, that's the fun of it, is that,

Joel: 33:01

fun of it

Collin: 33:02

everything can blow up at any moment, you know, you're riding on a razor's edge, I think it's amazing. I like things like that. It's great. Um, Did you see this? Okay, I don't know if, I was debating bringing this up, but like, did you see this bullshit from, uh, the, the DHH So, okay, this Rails Foundation thing was, we don't, I don't want to spend like 20 minutes on this, but like, this Rails Foundation thing was formed last November. And they're like, we're formed, we have a million dollars. As far as I can... Have they done anything other than RailsWorld? Is that... It's the only thing they've, like, done, right?

Joel: 33:39

I think Rail's World is the only thing that they've put that they've shown that they've put on so far.

Collin: 33:43

Right. So they announced, they announced this conference. And some people, I feel like, were... Sort of... Like... Well, skeptical in the way that they're like... Did RailsConf say they wouldn't like you to speak so you made your own RailsConf? Which probably isn't entirely fair because, you know, maybe, maybe, you know, Europe deserves their own version of this or whatever that isn't, uh, I mean, there probably is RailsConf something or other. I know there's one in Australia, but you know what I mean. Um, and they were like, no, it's offensive. You would say such a thing, you know, all that kind of stuff. Uh, And then he wrote this friggin blog post and he's like, personally, it's gratifying to see that we've been able to leave the old squabbles behind route around the nonsense, which is a link to him talking about when,

Joel: 34:36

hmm. The the tantrum. Mm

Collin: 34:37

yeah, the tantrum when, uh, Ruby central or whatever is like, eh, we don't know if it's elite, you know, we don't know if we, maybe you shouldn't speak this year, um, and get back to joyful collaborations on this fantastic framework. But like, number one is calling it nonsense, and doing all of that, right? Um, is that routing, like, is that leaving old squabbles behind? Or is that just like, making your own conference? Uh, that is, now there are two things. And like, I'm not against two things, like, more Ruby conferences is great. But like, the fact that he then said this about it, I don't know. Isn't that, what do you think?

Joel: 35:17

Yeah, this is, this is a tough situation and, um, it's difficult to talk about, but I think it's important to talk about it. Um, I, I don't know if I have the timeline entirely right, um, but I know that there was a lot of stuff, uh, going on around the time that, like, before, before RailsConf, before this letter was written to, uh, to David,

Collin: 35:41

Yes.

Joel: 35:42

and... Actually, we should talk about the letter. I don't, I don't think the letter was great. Um, the, the one that he quoted in the, in the, um, his original tantrum. I don't think that was great. I think it could have been probably handled a bit better. Um, but like they made a decision that like, due to some of the things that DHH had been doing, saying, um, the way that he had treated people in the, in the Ruby community, that they didn't want him to keynote. I think that's, does that sound fair? I'm

Collin: 36:14

Yeah, I mean, it was that, it was the stuff at base camp was very controversial. It was, you know, I think it was around the time he started appearing on Fox Business and stuff. Like, there was a lot going on, you

Joel: 36:27

right. I don't know if it was after or before they started writing about, um,

Collin: 36:32

like DEI and stuff.

Joel: 36:34

yeah, like the waning days of DEI and, or like about how Andrew Tate's not that bad

Collin: 36:40

no, he's that bad. I'm gonna, I'm gonna tell you. Controversial take, that bad. Uh, yeah. I, I don't, I, I don't know. I think a lot of that stuff came after. Here's, here's the timeline I remember. Uh, the stuff with the Basecamp stuff went down. Um, which was very big controversy. And then, the RailsConf thing happened, when he had this tantrum and wrote this blog post. And then, Basically, once, uh, what am I going to say? Once and I feel like a lot of the community was like, Jesus, this guy, right? Um, he just went full heel turn. He just started being like, screw it, if everybody thinks that I'm this conservative asshole anyway, like, I guess I am, you know? Uh, and I mean, he already was, but you know what I mean, right? That, that is sort of how I remember the timeline.

Joel: 37:34

right. And he was like, blocking people left, right, and center on social media. And just like, yeah, really, I mean, I, I've lost track of all the, the, the blog posts that I've read that have just really kind of almost made me sick

Collin: 37:51

Yeah.

Joel: 37:52

with just like. How, how gross they are. Um, I, I particularly think that the, the post he wrote about Andrew Tate, uh, and, and quoting and comparing him, uh, to like really, really sexist, like disgusting rap lyrics. Um, and being like, yeah, but this is fine. So Andrew Tate is fine or whatever he said, you know, don't look, look up the article, like see for yourself. Um,

Collin: 38:21

it won't be linked in the, in the show notes if anybody wants to find it.

Joel: 38:25

But like, it just, I mean, in this, in the Ruby community, I think there's already, like, a huge diversity problem, and having a leader that is kind of like writing toxic, like, things about women is pretty gross, um, and I think that, I don't know, I'm, I'm just, I'm pretty, pretty amazed that No one, like, none of the companies that are backing the foundation have really, like, caught onto this or, like, called it out and said it's not okay. The foundation is supposedly, um, meant to be kind of growing and expanding the, the, the Rails community, but, um, but, like, it's got, like, anti women. Rhetoric like published on a blog that he's used to share rails news by the the head of the foundation and The head of rails

Collin: 39:26

Is he

Joel: 39:26

and and yet

Collin: 39:27

officially the head of the foundation? Is that, is that accurate?

Joel: 39:30

I think he's he's Gonna chair the board

Collin: 39:34

Okay.

Joel: 39:35

But there's a there's a board and the way I understand it is there that there's gonna be or there already is I don't know If it's been completely set up, but, um, from, from each of the founding companies, an employee or, or some employees are going to be, uh, on this board and he's going to check the board.

Collin: 39:54

don't, I don't know how I feel about that. Um, if that's accurate. But, uh, So. I have always thought it's weird that he personally owns the trademark to Ruby on Rails. And when I say this, other people don't seem to like, have thought about this as much as me, but I, I thought, so when I heard there's going to be a Rails Foundation, I'm like, I guess it'll be like a non profit and maybe he'll transfer the trademark, but they didn't do that. So I'm like, I don't know. It seems, it seems very strange to me. I'm not saying like there shouldn't be a conference in Europe. I think that's, That's great. It's the context around this seems very, uh, not good to me.

Joel: 40:34

I think what it was for me from my perspective is there was, there's been a bit of a vacuum of like, Like, I've been wishing that there would be some kind of Rails foundation that could kind of secure the future of Rails and mean that it's not dependent upon this one person.

Collin: 40:57

Yeah, like, you don't think of, like, yeah, because it kind of feels like Rails even today is, is bigger than David, but it is also, he has retained a lot of control. And, like, I would think of somebody like Matz. His also has a lot of control. But you don't think that like, when you think of Matz, you don't associate it with like, Matz like owns Ruby or whatever. You know what I mean?

Joel: 41:21

Right, yeah, you,

Collin: 41:21

that. Like I don't think he personally owns the trademark to Ruby. Maybe he does, but I don't think he does. Or like the guy who made

Joel: 41:27

of the Ruby, the, the Ruby, like, you don't think of Ruby as being culty. Or, um. Or like toxic,

Collin: 41:38

Yeah.

Joel: 41:39

you know,

Collin: 41:40

Yeah.

Joel: 41:41

of the rails community really are like, like the, the, there is a, there's a huge DHH cult. Um, and, and like people, like when you try to contribute to rails, it can be really toxic the way that people talk to you. Um, like you contribute. Like an opinion on something about a framework that you really care about. And people are like blocking you on Twitter because, because you shared an opinion that monkey patching, like with a method that's used particularly in a certain way, like, might not be a great idea. And there are other other options that should be considered. Like it's just, it's just really toxic. Um, and it feels really culty and that that really concerns me.

Collin: 42:29

Yeah, not great. I mean, the thing I always think is what you said, which is like, Matt's is nice. So we're nice. DHH is dot, dot, dot. So we are ellipses dot, dot, dot. Um, yeah, I don't know if I have a lot more to say about that, but like, yeah, it's the whole thing feels very weird. And I think most Ruby people I've met personally have been just like the kind, very lovely, but, uh, I, yeah, I don't know.

Joel: 42:58

Yeah, what I'm trying to say is, we were really hoping that there would be a foundation, right? And that it would secure the future of Rails, and kind of like... Make rails better, but that foundation needs to have control and it needs to have like a representative board, a board that's representative of the community, not just of a handful of, um, of like big corporations with deep pockets. And also, um, it needs to have control of the trademark so that it's, it's not like always. Um, under, under complete, like, control of this one person. Um, and I think that, that would have, that would have been, that would have done a lot to, I think, um, improve the community. But what we got instead was... What, what it seems like is DHH was, was pissed that he didn't get invited to Keynote RailsConf and had this plan to put it on, put on his own conference and he's tricked all these companies into spending a million dollars on putting on a special conference for him so that he can be the big star of the show and he's, and, and we were saying like, feels like this is what he's trying to do and people were saying, No, don't be silly. He's not, he's not trying to do that. Like

Collin: 44:16

what about him makes you think he wouldn't do? That would

Joel: 44:20

Right, but he's basically admitted to it's linked to the post

Collin: 44:24

Which,

Joel: 44:24

and and it's really concerning.

Collin: 44:26

I would think if you're trying to leave squabbles behind and get back to joyful collaboration, why would you link that? Why would you do that? Um, other than, I mean, he, okay. He seems like a rich white dude who has not been, who has been rich for a really long time and has not been confronted with a lot of these things in a very long time and not been told no a lot. And, uh, you know, I think that, I think, I think it does things to your brain after a while, you

Joel: 44:55

Mm hmm,

Collin: 44:56

Um. I mean, I don't know. I like, you know, maybe if I was rich, I'd be, I'd still just be the best, but, um, as I am now, but, uh, you know, I, I don't know. I feel like having that be your experience of the world has to do something, uh, to the way you see the world. Uh, maybe not everybody, but it sure seems like a lot of people, right? Um,

Joel: 45:16

I do think I do think it's got worse since he realized that you can treat your employees like crap To the extent that like 40% of them or more I think leave your company and you can still make loads of money and you can still easily hire people because like You're rich. What,

Collin: 45:39

I like to think Elon Musk is what, uh, is what DHH has shown by the ghost of Christmas yet to come or whatever. But um, maybe, I don't think he's, I actually don't think he's that bad, but he's pretty bad. Um, yeah,

Joel: 45:54

what, what Elon Musk and, and DHH and even Donald Trump have in common is, is traits of narcissism, I think.

Collin: 46:03

yeah,

Joel: 46:03

apparent traits of narcissism in what they write and put and communicate to the world.

Collin: 46:07

It's It seems strange to me, not even in like terms of giving money to the Rails Foundation, that none of these like big multi billion dollar corporations see the fact that this thing is so, uh, they don't seem to see it as a risk, that it's so tied to one pretty mercurial seeming dude. You know what I mean? Like maybe they think it just isn't a problem, but like, I don't know. That seems like if I was making a business calculation, that would be a thing that would make me maybe not be as excited about rails, you know?

Joel: 46:45

Mhm. Mhm.

Collin: 46:47

but I don't know. This is why I'm not the CEO of a company. Um,

Joel: 46:52

Yeah. Before we conclude on this, I mean, we should, I'd like to say that, you know, the, the, the rails core team members and contributors, um, and, uh, the, the foundation's new director, Amanda, like they have nothing to do with this. They, they're not responsible. They're not involved. Um, it's, it's They, and, and we shouldn't involve them at all. Um, but, but I think that,

Collin: 47:21

She seemed very nice.

Joel: 47:23

yeah, Amanda sings amazing, but we should definitely be holding the board of this foundation to account. Um, and the, the members of the foundation, KPA, Doximity, fleet, uh, GitHub, Intercom, Procore, Shopify, and 37 Signals as well as like app signal, uh, and Cedar Code and Planet Argon like. They are foundation members and they are, I think they hold responsibility for, for what the foundation does. And they have basically just, they're, they're backing and supporting this attitude and saying, this is okay. You, you don't have to be welcoming. You can use the same blog to share rails news. And also, like, say disgusting things about women, and we're going to be okay with it, we're going to give you a million dollars that you can use to put on a conference because you got cancelled, like, so you can put on your own conference, and it's going to be great, like, it's really disgusting, and um, I, I, I think that, that they should really reconsider what they're doing.

Collin: 48:32

Yeah, I agree. I feel like being on the core team is a tough situation probably for some people. Um, But I don't, yeah.

Joel: 48:42

Yeah, I realize, um, I'm gonna really struggle to, uh, to get my next Ruby on Rails job now,

Collin: 48:48

Um, I hope not. Uh, any, well, let's cut it there then. Uh, Thank you for listening. Uh, we, we appreciate it. You can follow the show on Mastodon also, if you want. Uh, we post there sometimes or retweet things. Um, and, uh, if you like the show, please tell your friends, tell whoever, uh, when you go to Railsworld, you know, tell people there, um, and we will, uh, we will talk to you next week.