Josh Adams is a Software Engineer at GridPoint. He joins the show to talk about his experience in Elixir. He begins by explaining the reason why prefers the Elixir language compared to the other frameworks. He also shares his journey of transitioning from Ruby to Elixir. 

Allen:

So hello and welcome to another episode of Elixir Mix. I am hosting today and today we have Adi on the panel. Hello, Adi.

 

Adi Iyengar:

Hello.

 

Allen:

and our guest Josh Adams. No, not

 

Josh:

Hello?

 

Allen:

that Josh Adams, the other Josh Adams.

 

Josh:

Yeah, not that Josh Adams.

 

Allen:

Yeah, I did. It's interesting. I didn't know we had two Josh Ams in kind of our community circles. It's quite interesting to hear about that.

 

Josh:

We're everywhere man, we're just hiding out there. There's probably three.

 

Allen:

This is not your first time getting confused with the other Josh Adams, right?

 

Josh:

Oh no, no. If

 

Allen:

Happens all the time.

 

Josh:

I'm not mistaken, he was also in the Ruby community, which is where I got my start, and it's been happening

 

Allen:

Okay.

 

Josh:

ever since I started.

 

Allen:

You think he gets the same thing? Like, oh, I thought you were the other Josh Adams.

 

Josh:

Oh, I highly doubt it. I think it's like the reaction I get is, oh, Josh Adams. And then it's like, oh, Josh Adams.

 

Allen:

Oh, Jesus.

 

Josh:

So yeah, so I hope he doesn't get the same reaction.

 

Allen:

be very, very weird. But yeah, so we were kind of chatting before the show. You're working at... Sorry, maybe I missed the company name again. What

 

Josh:

Yeah,

 

Allen:

was it

 

Josh:

it's called

 

Allen:

again?

 

Josh:

GridPoint. I work at a company called GridPoint. We build solutions for energy management, like grid energy management solutions. Very cool stuff. We're in both the hardware and the software with Elixir, via like NURBS and Phoenix. It's just a lot of fun. Started building stuff about, I just started back in October, so I'm by no means like a veteran in the space or anything like that. I'm learning along with like everybody else on the team for the most part. But yeah, real cool stuff. Real smart people, real heart problems.

 

Allen:

I mean, you kind of glossed over a lot of details. I mean, how are you actually losing an elixir for all this stuff and why elixir?

 

Josh:

Yeah, so details. So why Elixir is probably an answer that many guests have given for that particular question. It's really good with concurrency. So we are managing what we just deployed or I guess launched our first client a week ago. So cross our fingers. We're hoping that goes well in this initial phase. But we knew we needed something that could handle a lot of concurrency. requests from a lot of different sensor data coming in at like very different times from various sites and we need to be able to like take that throughput, ingest it sanely and be able to respond to it as well, because it's not just like being able to get the data, it's being able to kind of like push data back out in like a way that makes sense and have like order that makes sense to it. You don't want to see like an AC like turn on and then say, Hey, turn off right away. That kind of thing is probably going to really like. confuse and probably frustrate folks with their air conditioners, especially now that it's summertime and we're kicking off. So that's the big why of Elixir is that, you know, it handles concurrency. Basically it's like baked into when you're learning the language, you could even when you're hiring like junior folks, they're going to learn how to program in a way that's like friendly towards managing concurrent. messaging. The other big reason I kind of just mentioned is that, you know, when you're hiring folks, it's a pretty fun language to work with. I think that at least the two of you would agree with me on that one. And it's a language that I found folks even with like less experience are pretty eager to kind of like dip their toes into and learn and Interestingly, it seems to also be a language they can really kind of like, if they're, if they do have that interest, they kind of like sink their teeth into and they're able to become productive pretty quickly, um, in a way that maybe, you know, Haskell or something, there might be some sort of a learning curve there that even if you're like pretty good at it, there's probably a lot of pitfalls or, you know, probably something really cool, but it's going to take a while to get there. Whereas, you know, with it's like syntactic sugar and, and base, basis on, well, I think Jose, inspiration from Ruby, obviously it's kind of very beginner friendly. So hiring, concurrency, and the community is probably the last part there. It's very active, a lot of bright folks in the community, and a lot of active development on big projects like Phoenix may get to where it's like, you know, an exciting and I think probably well chosen tool for the job that we're trying to do.

 

Adi Iyengar:

There's literally no other language that hits that criteria. I mean, there is a web framework which allows you to quickly add a back-end UI without very little work with Phoenix, like Josh said, like productive, and do all of the embedded stuff. Maybe Python comes close, but then the concurrency and ease of scalability isn't there. Literally no other language even meets that criteria.

 

Allen:

I think it's really quite interesting. You also can do like the nerves part, right? So, I mean, not many people I know are actually using nerves. And so like, how has the experience been?

 

Josh:

All right, so here's where we're getting into my lack of being a veteran. So we actually have like split the teams off into like, as companies do into like domains of expertise. And so we've got like a team that's like responsible for the hardware side of things in the firmware and I am not on that team, but I can kind of speak towards how it's been working with them. It's nice to have kind of a single language that we're talking about. They understand what a process is, we understand what a process is, we can kind of speak the same language when we're talking to each other and kind of forming requirements. I have kind of gropped a little bit of the code on their side of things, I've peeked and perused, but, and during my time doing that, it's readable. Like I kind of understand what's going on, just a lot of the same things there, structs, maps, you know, what happened. So as far as like working with them, it's been... pretty nice. I think that at other places I've heard of, you know, kind of like working with folks that are doing a lot of like lower level languages and you got to, there's like a translation layer that you kind of have to go through to make sure that you guys are kind of speaking the speaking the same language and trying to get to your goal. And you kind of bypass that and having you know the same basis for writing firmware and soft like the web app that we're building. Yeah, so anyway, I'm more, I guess, involved in, like, we specifically, we're building a Phoenix web app that's heavily leveraging LiveView to kind of, like, take in these live events and respond to them and have, like, a live kind of, like, UI for the state of things across various sites.

 

Allen:

Yeah, I mean, how did you even get into Elixir? This is quite interesting. It seems like you and me both have a similar background. We kind of start off in Ruby and then somehow we went over to Elixir. Like

 

Josh:

Yeah,

 

Allen:

how did it kind of come out to your radar?

 

Josh:

great question. So I can't take the credit for this one. I wasn't just looking for a language to tackle, but it was actually, you've had a guest on before, his name is Eric Sullivan. And I worked with both Eric and Adi at my previous company, and KISAM was the name of the company. And we were looking for adopting a language that would help us with some of these problems. the main one being concurrency that we were running into with Ruby and threads and things like that, that one runs into. Not only that, the company that we worked at was, love the company, I can't say enough things, like good things about the leadership, everything like that. We were working in a model where we kind of promote from within and we had a lot of folks from disparate or like backgrounds that kind of got into programming from like... I was a physics major, for example. There are people with like degrees in computer science, but there are only a few of them. There are people with like art backgrounds and it was awesome. It was like this beautiful melting pot of like ideas and different ways to approach things, but we didn't have a lot of experience and concurrency in Ruby is something that I think it takes a bit of experience to know that you're doing it right. So um... Eric Sullivan and his wisdom, it was like, I guess we were taking a look at, I think, three languages, you can correct me if I'm wrong. There was Clojure, I think, Go, and Elixir. And we ended up choosing Elixir for probably a bunch of different reasons that Eric could probably explain a lot better than me because at the time I was a bit of a noob. But I think that it's... syntactic similarity to Ruby was a huge selling point. That it was written by somebody that was so active in Ruby and would be a lot easier for folks who were since we're promoting from within. If we wanted to transition Ruby developers over, the ease in getting folks up that learning curve would be just that much better. And yeah, we piloted, we developed a real small, you know, focused web app that built PDFs. And we did it really quickly. We, meaning Eric, I, and he learned along the way. Adi's computer at one point was like the workhorse. And we tested, I don't even remember. But we wanted to see kind of like the limits of how we could spawn like asynchronous, like ways to, or like processes to kind of like parse a PDF and like build something. Or not parse PDF, but like parse a CSV. middle of the PDF and Audi's computer, I just remember, it was like late at night or early in the morning or something and I just heard his fan, he had this beefy computer, he was like, he had the, at the company, I think the beefiest computer, he was notorious for like getting some radical machine and I just remember hearing the fan kind of like spin up like a jet engine and then like,

 

Adi Iyengar:

So it crashed.

 

Josh:

and then yeah, and then the screen went black and I was just like, ah. And then... We gotta make sure we don't do this to like, you know, actual servers out in the wild. But it was really cool to see that like, if you wanted to like, if you wanted to do something real asynchronous with it, it could do it. It would, you know, you're limited to your resources, but it let you kind of like do that from the get go. It was really cool. Yeah, that's how I got into Elixir. It was this like, kinda fortuitous, anybody interested in like starting up a new language and Adi and I raised our hands and Eric. allowed us to join them and yeah, the pilot was successful and adopted it more broadly and a few other projects at the company. And I kind of never looked back. I was doing a lot of management at my previous company. So not as much coding for a lot of my time there, but yeah, it was something that I really wanted to get back into and now I'm just like a developer. So I'm doing a lot less management, which is really nice. It's nice to manage, but it's also nice to kind of have your own code account.

 

Allen:

It's interesting you talk about how, I guess, the syntax is so similar to Ruby, but at the same time, it's kind of not, right?

 

Josh:

It is, but it's better. It's like Ruby, but better. I think it's like some of the same things. Like, oh, not everything has like a do and an end in Ruby.

 

Allen:

Yeah.

 

Josh:

Let's fix that. Like, you know, let's, let's kind of have that like list be, you know, there's, there's a concrete boundaries that your eye can kind of lock in on. And it just makes it a lot easier to kind of figure out what's going on.

 

Allen:

I mean, more so like the thing that stick out to me is how in Ruby everything's an object, but

 

Josh:

Yeah.

 

Allen:

in this there's no objects, right? It's totally different.

 

Josh:

See ya.

 

Allen:

That to me, I think would take a long time for anybody to really understand how things work.

 

Josh:

Yeah, the switch to the functional paradigm from like that object oriented, uh, kind of Ruby based approach was definitely one of the things that I caught myself on. I was trying to. call. I was trying to, I think when I was first walking through a book, I was trying to find functions on a struct that like I could call and it's just like, this isn't very easy. Why would they want, why would they do this? And I was like, oh, so they don't want you to do that. That's why they do it. It's a function. So everything kind of like, you know, it's F of something and you pass something into it. You get a result out and you don't have to worry about things mutating because you did that. Sometimes you do, but like you kind of know what you're going to get if you're doing stuff like that. So yeah, I think the immutability part of it, because I had gotten so used to all the annoying things that you have to do when you're writing tests with Ruby and trying to work around like state. It was kind of a breath of fresh air once that clicked and I got more used to kind of like functions as transformations that kind of like don't mutate state, you know, for the most part.

 

Allen:

Yeah, I mean, how was that for some time where you had to get used to like, okay, yeah, I'm doing transformations, but what does that mean? Oh, that means that if I didn't kind of. I always use the word catch right because it always returns a new thing that's been changed slightly right? So like

 

Josh:

Mm-hmm.

 

Allen:

if you don't assign it to a variable then you lose it right? I always have to talk to new developers and kind of tell them oh, yeah You need to make sure you actually assign that to a variable or else it's gonna be gone It takes them a long time to understand that and it's really hard to explain to somebody

 

Josh:

Yeah, definitely. It's like the blessing and the curse, right? So it's like harder to teach because I think a lot of folks do kind of come into programming from an object-growing background. At least that's my...

 

Allen:

Yeah.

 

Josh:

like experiences like you're usually taking, you're not going the other way around usually. It's like, oh yeah, I've only got functional programming experience. So like getting through that, the bad, oh, I'm gonna say bad habits, but the habits that they have when they're working in that other paradigm is definitely a little bit of a tricky thing. But once you, I think the thing that I've found that really illustrates kind of that point and helps folks learn is kind of. trying to engineer the code that you're writing around the pipeline. I thought that was one of the coolest things I still do. Just that little pipe operator kind of like tells the story of everything that you're doing to it and how it transforms the inputs as it goes through. And if you're not catching it, like, yeah, it's just going to go back into the ether somewhere. You're not really

 

Allen:

here.

 

Josh:

caring unless you're doing stuff with state in which, yeah. it won't. Then you just like make a call to the database to see how it changed things, but, or, or to whatever you're doing, that's or whatever.

 

Allen:

It's funny that you mentioned the word state, right? I don't think I've ever used that word so much until I went into Elixir, because then you start talking about state all the time, as opposed to before you're talking about objects, right?

 

Josh:

Hmm. Yeah. Um, they, they are, I feel like they're two, two sides of the same coin to me a little bit. Like the object, it's just like where the state lives in, well, maybe it's not just an elixir thing. I'm not like, ah, I don't have like an encyclopedia of languages to pull from with experience. But like, um, from my, from the experience that I do have, it seems like the state in, in elixir, um, maybe this is a- Inheritor functional programming in general is like it's bound. It's like contextually like, yeah, the database store state. And you're not operating like in a database and querying the database. It's like, you're, you're just, you're just working with functions. And that's kind of the beauty. You don't have objects that, that like, you're, you're updating the state on. You can, but you'd have to like, bind those to variables to like, do that and rebind them and, uh, you're not, you don't have to worry about like. Yeah, it's like the state of the structures is like inherent to them. It's not like something that like you have to worry about coming back to because you're reassigning it. Yeah, that kind of maybe it was a long winded and maybe it didn't make sense of trying to figure out what to come with that.

 

Adi Iyengar:

I think it made sense. I think how I look at it for these modern functional languages is that state is anything that's outside of a procedure or a method or a function. And in functional programming, at least in a write function, you don't assume something is living out of the function. Elixir, I mean, obviously, has processes and agents and all that stuff. But yeah, all the variables that you send in, there is a Haskell word, like referential transparency, where you know everything within the function. is within the function, right?

 

Josh:

Mm-hmm.

 

Adi Iyengar:

That's how it looks at it. But I think you're saying that state, or object is where the state lives is, yeah, right, for all object-oriented languages. So that's, yeah. At least all

 

Josh:

Mm-hmm.

 

Adi Iyengar:

of the ones I know.

 

Josh:

All 300. I was the one to see.

 

Allen:

Yeah, I mean, the other thing I'm kind of picking into my mind about when you're kind of learning new languages. Yeah, okay, syntax is a huge one. But once you have a paradigm shift like this from object oriented over to functional, I mean, that's one. But the other thing too, that I think makes things even more confusing is OTP. That's another huge thing that nobody else has in this whole supervision tree. I don't know, is there another language that has something like that? I guess maybe you do that at like a

 

Adi Iyengar:

I mean,

 

Allen:

DevOps kind of way, right, got

 

Adi Iyengar:

right,

 

Allen:

my database

 

Adi Iyengar:

right.

 

Allen:

up, got this one up.

 

Adi Iyengar:

It's being part of application layer. I guess Go has something like that. But yeah, nothing like the supervision tree exists in other languages. Yeah.

 

Allen:

I mean,

 

Josh:

Yeah.

 

Allen:

how is that? Because that's like, what? What is a Gen server? I mean, obviously, it makes sense not to break it down. But if you just look at the word at first, what the heck is that?

 

Josh:

Yeah, that one took me a bit to kind of like reason with the generic server. I feel like it's because I didn't realize that Jen stood for generic for a little while and I was just like, it's generating a server. Like, what is this doing? Um, it's like a service. Uh, I don't know what it kind of is, but like, yeah, it is a little, a little funky. Um, but at the same time, it's like one of those things that because it's extracted into. It's its own like behavior. It's, you don't, I don't know. It's, it's that way of like managing state where this thing is like, yeah, it's a server that manages like state in some way or does something and you don't have to worry about structs doing that, which I think are like having value objects be kind of value objects is incredibly nice.

 

Allen:

Is it value objects? Is that the right word to use?

 

Josh:

Yeah, I use that word. I think I've definitely heard that. Again, I'm not a computer scientist or anything like that, but I think that a value object from... I can't even tell you where I read it. But it's like an object or a structure that you can pass from one thing to another. Instead of having a function that takes in an X and a Y to compute the area for a rectangle, you can pass in... an object that has the X and the Y on it. So you're, you know, or a struct in Elixir Land. So that you're passing around a single entity and it's a way to kind of reduce the like, arity of functions. It's got other benefits too,

 

Allen:

Oh.

 

Josh:

and then you know that what you're wrapping, like you have a struct, all the benefits of a struct, you kind of like getting a name to the like, values that you're wrapping and co-locating

 

Allen:

Mm-hmm.

 

Josh:

them. So yeah. I don't know, Adi. Is a value algebra or something? Did I just make that up?

 

Adi Iyengar:

Use that term, so I don't know. I actually don't know what it means. I think I've only heard a few people use it, you being one of them.

 

Josh:

So, all right, cool.

 

Adi Iyengar:

That makes sense, though, what you're saying. I guess encapsulating a bunch of values into a struct or a bigger structure for it. That also gives that type advantage to type inference.

 

Josh:

Mm-hmm.

 

Allen:

Oh yeah, I've been kind of, I don't know how you say this. Yeah, I've been reviewing some code from somebody who came from a big Java background and I did teach them that, hey, you know, maybe you should think about this as like a series of steps and use a pipeline kind of feature. And I think that clicked for them.

 

Josh:

Mm-hmm.

 

Allen:

But the question is sometimes it's like, you don't really know how to name that thing. That's a collection of all your data. And so I don't know why, but it really made me angry when he started like appending the word struct at the end of every struct,

 

Josh:

Hehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehe hehehe hehehe

 

Allen:

which is just weird for me. I mean, how do you like so you call that a value object? That's just you said as the term, right? So, you know, what? How do you actually come up with names for something like that? Do you guys have any ideas about what's like a good way to come up with a name for something like that?

 

Josh:

Ah, Adi probably has a better answer to this. I feel like naming is, I forget

 

Allen:

So

 

Josh:

who

 

Allen:

hard.

 

Josh:

said this, but it's like the hardest things in theater science are like

 

Allen:

Yeah.

 

Josh:

naming things and validating caches. And I don't know if that's the most true, but naming is something that, especially for somebody like me, I get like bogged in the details, naming is like. But it's also fun because when you land on the right name, everything just makes so much more sense. Nothing is more frustrating than seeing thing A and thing B in a test. You're like, well, what are you testing? Thing A is like, what is thing A? There are ways to do it, don't get me wrong, where you're kind of like sequencing names. But yeah, the name, my strategy for naming these trucks is just to be as... like close to what that struct is in its domain as possible. So like if I'm throwing a change set into something, it's like a change set. If I'm throwing like a generic structure, then it may be struct. But that's like very rare. Usually, yeah, if I'm like building up a pipeline, then I'll just name that like, you know, here's what I'm passing in as like the argument to the function. I don't know. How about you, Abby?

 

Adi Iyengar:

I think usually the module, the struct is based off of a good variable name. But I mean, again, come with a good name for the module is also a challenge, right? Josh is my naming guy, so. Actually, I did want to bring up this thing before I forget, since you're talking about the whole pipeline thing. And I mentioned a couple of times. Have you guys, like, with this whole CRC thing that Bruce Tate talks about, construct, reduce, compose, I think, or

 

Allen:

Mm-hmm.

 

Adi Iyengar:

something like that? Oh, convert. reduce, convert. This is a really awesome blog post. I think it's called Learning Elixir. It's all reduce. And I have seen it didn't really have an impact on me, to be honest. And really, it didn't really help me understand anything better. But I've seen it have firsthand impact on so many junior engineers. It doesn't pipeline and make sense to them. And they read that. People I mentor, I tell them about that. And they're like, oh, that makes so much more sense. I don't see why, because it doesn't make sense. It didn't really help my understanding much, but I did want to bring it up, because a lot of beginners listen to this podcast. Check out Learning Elixir. It's all reduced, or something like that. This is a blog post that Bruce Tate wrote.

 

Allen:

Yeah,

 

Adi Iyengar:

Not sure

 

Allen:

I

 

Adi Iyengar:

if

 

Allen:

do

 

Adi Iyengar:

you guys

 

Allen:

remember

 

Adi Iyengar:

have heard

 

Allen:

that.

 

Adi Iyengar:

of that.

 

Allen:

I remember that term, but now, are those all the right words in the name? It's something like that. I don't remember

 

Adi Iyengar:

I think

 

Allen:

exactly

 

Adi Iyengar:

it's construct,

 

Allen:

the right name.

 

Adi Iyengar:

reduce, either compose or convert. This is the last one. But the whole idea is in Elixir, everything can be built with that kind of methodology, where you create a struct first and pass it along for reduction to a bunch of processes and convert it to the final return value that a function. of needs it feels I don't know if it's do you guys it feels obvious to it felt very obvious to me but to like a beginner elixir it felt you know life-changing

 

Josh:

Yeah, I think it's like one of those things where because you're, when I did start building pipelines, like I think one of the holy grails of this is like plug. Uh, and like that kind of like really clicked for me. It's just like, Oh, I'm sending this like structure down. It's got fields and I'm just like modifying this lately. And if it's like in a pipeline, the first argument in that next function is just the thing that I'm spitting out from the line before it. And so I'm like sequentially kind of like modifying or not this plug as I go down. Um, there is plug con, uh, and it was just like, that helped it really click for me. It is like, you're like taking a bunch of operations and you're, you're reducing, uh, to a single result, uh, based off of like a bunch of inputs. So that's, I will have to read that blog post and I haven't, I haven't. So that sounds pretty cool.

 

Allen:

So I have a question for you. Do you prefer to do a reduce within a reduce or a map within a map and then pull out nil values?

 

Josh:

I am a big fan of reduce. I maybe use it too much or more than I should. I just, all right, it's probably not great, but I kind of put together a live view function recently that we had to get something done. It had to be demoable. And the way that we had to, it was for something we didn't. think we were going to have to build. Like, I'll put it that way. So

 

Allen:

Mm-hmm.

 

Josh:

it was like one of those last minutes, like, oh, we need this. Oh, okay. So I kind of came up with this thing that's probably not the most maintainable, but it shouldn't be there for very long. So, you know, it shouldn't be there for very long. Throwing airfoots in. So I basically took in a socket, you know, structure. And the way that I add errors to it is I have a function that's like a generic, you know, add error to socket function. And it just like updates and assigns value that has errors on it. And I reduce over the socket in a bunch of different places. And the way that I make it same to read is if I've got like a nested reduction, like a reduced within a reduce, I tend to find it much more readable to kind of like throw that into its own function that then spits out the result of the reduction in a way that's sane. So I've got in this live view, which I'm not advocating it for as being the right way to do things at all, but I do have a function that has four or five levels of reducing nestedness. And that's, you know. It's actually pretty easy to read because of the way that it's written, but I don't know if it's the right way to do things. It works. When I do need to match on nils or something, if I'm going through... I do like to leverage the pattern matching and the function, like an anonymous function. So like if you're coming through and you want to do something one way, if like a value is nil, you just handle that in its own pattern match on the nil case and

 

Allen:

Mm-hmm.

 

Josh:

you still have the function. You don't need to kind of pull the nils out. I think it's more performant too, going that way, because you're kind of hitting it at the time that you're running into that. But I guess that doesn't really pose too much of an issue unless you're dealing with real big collections.

 

Allen:

Yeah,

 

Adi Iyengar:

Yeah, I go

 

Allen:

sorry,

 

Adi Iyengar:

down.

 

Allen:

the reason I brought this up is because I'm having this kind of big discussion with a team. And they seem to love doing like, mapping and then mapping inside of there. And both and ends up having to like have like a multi dimensional list. So then they have to flatten and then they still have to pull out meals. And I'm like, Oh my God, this is so hard to understand. And with the reduce, it's pretty easy, right? So instead of putting a nil, like they deliberately put nil values in there and strip the nil values out later on. So it's like, instead of just putting a nil value in there to strip out, like why not just. reduce it and then just return your accumulated value. Doesn't really make sense. But yeah, it's been interesting. That's why I wanted to ask the question. And I think that most elixir developers are probably going my route, or the route that I think you and I both think about, which is like, why not just reduce it? Especially performance definitely comes to mind. I'm sorry, Adi, you were about to say something.

 

Adi Iyengar:

I mean, I was saying, I think to me, I mean, I think it doesn't really matter. I think as long as if they write the nested map, like what Josh was saying, like if it's readable, if the map function is put in a function with a good name, which makes it obvious what that function is doing for every variable in the list. And yeah, sure, performance, but I mean, by the time we play with big enough connections in Elixir with enum. And if it's big enough, the performance is an issue. Memory will probably be an issue before that. So I feel it's more, I definitely lean more towards readability. How they go through the pipeline, it's very subjective, how people

 

Allen:

Mm-hmm.

 

Adi Iyengar:

think. It really depends on that. And that's the flaw of the declarative world we're in, like the declarative language. Like the. something like raster, see there's less ways of doing things that seem right. But in Elixir, you can make a really terrible enum, especially enum operation, because there's so many functions in enum. It's crazy, right? You can lose all collection of those functions and not even have a performance impact and make different things look correct.

 

Josh:

Hmm.

 

Allen:

I mean, the other thing I've been trying to instill into them is like, they love to do a lot of like the plus between lists, like a lot. So instead of building, like what they actually were doing is somehow they were actually building up a list backwards and then they but then they thought, okay, I can actually fix this by doing plus plus, instead of just doing the reverse.

 

Josh:

Hmm.

 

Allen:

So it's been fun to kind of see new people come to the language and see, you know, how they write code, what's their thought process. And also, I don't know about for you guys, but for me, I can see usually where this person came from, what language was before. So a lot of the guys are JavaScript developers, so I can definitely see what I would see in JavaScript. I remember looking at Python code from another project and I was like, this looks like Java. And I asked my manager at the time who was a big Java family. Did you write this? Yeah, I did. I'm like, Oh, because Python is supposed to have like snake case and you wrote this in a camel case.

 

Adi Iyengar:

Okay,

 

Allen:

Yeah, that's

 

Adi Iyengar:

yeah,

 

Allen:

stupid rule. Yeah.

 

Adi Iyengar:

that's part of best practices. That's already established in the community. That's not subjective.

 

Allen:

Yeah. So it's just interesting to kind of see. And also sometimes like when people make mistakes that I wouldn't make, it's just, I usually ask them like, why, like what was the thought process? Cause I would love to hear, you know, like those ideas about like, where was your mind going when you thought about like this? Why did you write the code like that? And usually here's some pretty interesting answers and it helps you kind of understand how can I explain concepts to people like, oh, okay That's what your thought was. Okay. Well, you need to think like this because blah Although I understand why you think like that today. I asked somebody something like that and I was like, why did you write code like that? And like I don't know. I was just trying stuff and I'm like, oh, I don't know how to be there with that one But this is just interesting to hear this kind of replies back

 

Josh:

Mm. Yeah, I think I've done, I recently trained actually the company, Gridpoint is very passionate about getting Elixir into like everybody's kind of purview. And so we actually have trained our QA engineers to write fairly basic Elixir. And so I kind of like trained, I kind of like spearheaded that training. And it was really interesting to see folks with like very little. programming experience kind of like hop into Elixir as like some of them their first real like language I just needed to teach them how to write Wallaby tests like really simple Wallaby tests and so going from like zero like literally never taken computer science or anything like that like any courses or read about it so like getting them to write Wallaby was very interesting there are a lot of things that you know I take for granted or I think it's just like kind of obvious And it's totally not. And it's totally reasonable for folks to think some way. If they just experience things in the way that they have. And there's a lot of, even though they didn't have an object-oriented background, I find that a lot of people think in the way of ownership. Things have attributes that are tied to them. So I'm trying to say this thing dot. First name is here, but it's not working. You're just like, oh no, you gotta grab the first name from it or something. Yeah, it's really interesting to see how different people approach problems in ways that aren't wrong. It's just they have to kind of shift the way they're kind of viewing it, the perspective.

 

Allen:

Me you didn't pull an audience say all this is your first programming language. Let's build Phoenix. That's usually his style for teaching people programming.

 

Josh:

Hmm. Yeah, not quite. I didn't want to spook him too much. Ha ha ha.

 

Allen:

How does this method work for you? Does it work out?

 

Adi Iyengar:

Hey, my wife is a tech lead within two years, so... Sang. In that case.

 

Allen:

Interesting is that how long it took you to rebuild Phoenix or what I'm just curious. There's a lot of stuff involved in Phoenix, right? And obviously I'm just joking with you, Adi. I just thought that's a very like demanding thing to bring to a beginner. Alright, let's build this really great framework right now from scratch. You ready? Here we go.

 

Josh:

It is kind of like a different way though. I think Adi too, from what I know of him, sorry Adi, I think it might've been rough to do, Adi really enjoys teaching and really enjoys intuitively understanding things from my experience. It's not just like understanding it. It's like building up an intuition for that thing. And I, and he, I think are pretty big fans of like Feynman, like he's a Richard Feynman, he's like a physicist. And one of his, like really. Big ideas that he preached was like, you can't explain it to somebody that doesn't understand it. You really don't really understand it yourself. And so taking something as complex and specific as like building a web framework and trying to teach that to somebody with less experience probably was as much like, you know, here, let's get you better at this language as it was at here, let me get better at this language, Ferati, and probably a lot of fun for him and difficult in like trying to convey. You know, web servers, like you said, are really complex. Feeling that in a scratch, really complex. So yeah, it's probably much of a, you know, scrap scratching both backs there.

 

Allen:

You're saying you're both fans of Richard Feynman is that Sarah heard

 

Josh:

Yes,

 

Allen:

You

 

Josh:

very

 

Allen:

know,

 

Josh:

much

 

Allen:

I love

 

Josh:

so.

 

Allen:

Richard Feynman, but I think more so think about his weird Experiences where things just kind of happened to work out Do you know the story about where he just kind of wanted to sound smart and pointed out a map and said this doesn't look Good, but he actually had no idea what he was talking about and actually point to something that was correct He didn't hear this one

 

Josh:

Mm.

 

Adi Iyengar:

I don't know, but I wouldn't be surprised.

 

Allen:

Yeah, I don't know. I read one of his books and I was like, and he was talking about all his life stuff, especially when he picked up women, he had a very weird style that seemed to work out for him.

 

Josh:

Thank you.

 

Allen:

Yeah, he's just a weird guy. But it's interesting. Like, again, he like one of the things was to give him this map of like a government facility like they wanted to build and asked him to check it out and if there was anything, something wrong that he saw and he had no idea what he was reading and he just randomly pointed something and said, I think you should check this out. This doesn't look right. Cause he wanted to sound smart and actually he picked out something correct. That was wrong. So it's got a really interesting background. If, if, if you guys at home never heard of this guy, it's definitely check him out. It's, I don't know what to say about him. That's what I know about the guy.

 

Adi Iyengar:

Is it Shirley or joking? Mr. Feynman, I don't want that. It's like

 

Allen:

Yeah, yeah, that's

 

Adi Iyengar:

a

 

Allen:

the one.

 

Adi Iyengar:

okay. Okay. Oh, yeah

 

Josh:

I have that book

 

Allen:

Those are

 

Josh:

and

 

Allen:

real

 

Josh:

I just

 

Allen:

stories

 

Josh:

haven't

 

Allen:

from

 

Josh:

read

 

Allen:

his,

 

Josh:

it yet.

 

Allen:

right? I think he wrote that book, right?

 

Adi Iyengar:

I think it's edited, but it's a

 

Allen:

Or about

 

Adi Iyengar:

collection

 

Allen:

him.

 

Adi Iyengar:

of random memories, basically, at least what I haven't read it, but it's on my list. Interesting. Well,

 

Allen:

definitely

 

Adi Iyengar:

the

 

Allen:

rated.

 

Adi Iyengar:

book I would recommend, it's our pick time, where there's a fine one lectures on physics. But that's what Josh was talking about, making something intuitive. It's so big. One of the things that stands

 

Josh:

Thanks for

 

Adi Iyengar:

out

 

Josh:

watching!

 

Adi Iyengar:

is he would derive some of these physics equations without using. very minimal math, like one of the equations he derived was second law of thermodynamics. And I was kind of mind blown, just how you can use intuition to come up with relations in mathematics, like proportions in mathematics, and come up with most of the equation. And that really is a great example, because I think that's the goal when I learn and when I try to teach. And yes, obviously, you're

 

Josh:

Cool.

 

Adi Iyengar:

right. It could be overwhelming. The people I kind of like taught this to, in front of whom I've built Rails or Phoenix, like small versions of those, I think it was obviously outgauge if they're ready for it. Most of the times I was leading on a maybe, but I kind of gave them the benefit of that. And it ends up working out, because once you build that intuition of something, it automatically feels a confidence, motivation to do more. And oftentimes, they end up... getting better than I was at that stage because, you know, they kind of have a lot more confidence than I have.

 

Josh:

Mm-hmm.

 

Allen:

I just kind of kind of want to go one. I want to go back over what you're talking about. I think I do something similar to you except for I don't build Phoenix, I just kind of deconstruct part of it. Because I think it's good to kind of show like because people are like, Oh, where did this thing come from? And how come you know? A big thing I like to show is if you go to that web, the underscore web dot ex file that gets created and where you do with the use stuff. I think that's huge to show to people because then it takes away some of the magic. that people usually see. Like, how come when I do a controller this works, this is like, well, look, it's actually importing this and also using this thing and all this kind of stuff. So it's really helpful to kind of help people to understand that actually this is just a lexar code. It's not like something crazy. It's just a lexar code. Right.

 

Josh:

Mm-hmm.

 

Adi Iyengar:

Agree. I think it's just layers of it, right? I think what's so great about Elixir, again, is that in Phoenix, layers of that mystic magic is not as deep as rails. Rails take a lot more digging than just looking at an underscore web file to figure out what's really happening thanks to so many more options Ruby provides in terms of meta programming than Elixir.

 

Josh:

Yeah, I do not miss the, what was it, the phrase, automagical. I don't miss those moments where you're just like, how is this working? Oh, I guess I have to crock the real source for a couple hours to figure out why.

 

Allen:

all built-in method missing.

 

Josh:

Uh, I almost forgot about that. I...

 

Allen:

Yeah, but I mean, sometimes I do miss that magicness. You know, I do miss the things you could just add functions and life would be interesting. But yeah, there was, I don't think I was ever really bit too many times by like random stuff happening because I didn't have really too many complicated apps, but I do miss a lot of kind of the convenience functions and things you would get in Rails and Ruby. So that's definitely something I miss. Like the inflections and things like that you could have. Those are really nice.

 

Josh:

Hmm. Yeah. Go ahead, I...

 

Adi Iyengar:

I was going to say, Alan, you could always unimport kernel in your Mexican fig and import a kernel and define handle, what's handle? Undefined function, right? That's like Elixir's method missing.

 

Allen:

Yeah.

 

Adi Iyengar:

There you go. It's Ruby.

 

Allen:

Yeah, maybe there's, I mean, because you can't doesn't mean you should, right?

 

Josh:

Yeah, I'm gonna

 

Adi Iyengar:

Right.

 

Josh:

have nightmares. I'm gonna have nightmares that folks heard that sentence. You know? It's okay.

 

Adi Iyengar:

We can cut that out, we will refrain from saying stuff like that but yeah.

 

Josh:

Yeah. Somebody really could like absolutely demolish the dev environment. So now how'd that happen? Now they're redefining kernel. Great.

 

Allen:

Yeah. But kind of coming back around, right? I mean, I'm kind of curious with your training, how long does it take for somebody to kind of go from zero to pretty, I wouldn't want to use the word confident, but pretty, what is the word for that? Capable, I guess you could say, with Elixir in some of your training when you're kind of passing on to new colleagues?

 

Josh:

Yeah. So I think everything, like, if I, if I'm, if I'm learning something as I age is that everybody is there in person and everybody, there's just such an individualized, like, everybody's like a product of like where they're coming from. And that is different for everybody. So I don't think that there is an answer for that. That's just like, oh yeah, it's like a month. Um, I can say that there's some intersection of interest. um, like time, like availability and their like life to engage with the material. Um, and, uh, you know, if it's, if we're talking about like, we have a static like zero that they're starting from, I think those are the two important things. It's just like their, their passion or like their, their willingness to kind of like dig into this themselves and figure it out. Um, And, uh, you know, I don't think I play a huge part of that if I'm teaching folks. So that's like, if I, if I get somebody, um, that's super passionate about it, it's, it tends to be a lot easier to kind of get them up to speed. Uh, what I will say is if you do get that kind of, um, intersection of passion and availability, like of time to learn, uh, to dedicate to learning, at least, um, it can be, I mean, getting folks up to speed with writing Wallaby tests from like literally never having written a line of elixir took. Uh, a couple months, um, uh, pretty, pretty like rapid. I, like, I kind of pivoted mostly into that, um, teaching. So it was a pretty intensive, um, you know, starting from what is Elixir. We kind of followed, um, exorcism for a lot of it. And I'm very grateful that resource exists. Uh, it's huge. Um, because. you know, I can try to explain something and I might say it in a way that clicks, but again, everybody is there in person and it might not have clicked, so having like a variety of ways to see the same information I think is super important. And Exorcism kind of like gives that, I think, and the material there is just written really well and the whole idea of it like being something that you're writing tests or you're getting the tests passed I think is like a huge thing. It was, that was pretty easy for the QA folks that I was training to get on board with because their whole, you know, like goal is to make sure that things are passing tests in one way or another. Um, but I think. for folks that aren't like as into TDD, it's pretty great to see that being kind of front and center. Yeah, I'd say like a couple months for folks with zero experience that are passionate about it, perhaps longer for folks that have less time in their life to dedicate to learning or perhaps like, you know, less interested in learning. For good reasons. Yeah, kids, whatever. Yeah.

 

Allen:

Yeah. Yeah, and this is also including all the OTP stuff or what? I mean, I guess in the language itself is not that big, I would say.

 

Josh:

Yeah, no, I didn't go into really OTP at all. I mean, I kind of described like what, you know, Hey, there's this thing called OTP, don't, don't go to that exercise. I gave them like a, yeah, you know, extra credit if you want to like learn about that, but we're just going to get up to, uh, structs like enum, like basically enum, um, and, and structs and figuring out like how that works before you get there, you gotta know like, you know, the kernel operators and. Like the plus, like what does a plus sign do? String, you know, these kinds of things. And very basic. So I think another thing that you had asked in your initial question was like capable, and I would say that has its own parameters that you have to take into account, like capable of what? Capable of like writing a gen server. That's probably going to take a decent bit longer because there's a lot of foundation

 

Allen:

Mm-hmm.

 

Josh:

that you kind of have to build there in order, at least if you want folks to build something correctly. bit more of like an advanced part of that curriculum.

 

Allen:

Have you ever gone over the difference between the double and triple equals in elixir?

 

Josh:

I actually did, yeah. I think one of the first things that I was doing was, I wanted to give them, the player on open up IEX and kind of go through and see what these operators do. So like one plus one is two, one equals one, those kinds of things. But then I gave them a struct and. You know, say equals equals. Oh yeah, sure. That, that, if they have the same attributes, like that's, that's great. Then you do like equals equals. And if they have like a different, you know, some, something about it differs, but you can't see it kind of off the top. Just looks the same. That really kind of blows minds sometimes. That is fun. But it's like a, you know, strict equality. They, they, you know, that was something that didn't seem like, I remember when I learned the analog in Ruby, it was like, oh, that's a little weird. They seem to pick it up, maybe they're smarter than I am, pretty quickly.

 

Allen:

I've actually never used triple equals. I saw it in code, I thought it was a mistake. You guys

 

Josh:

Yeah.

 

Allen:

ever use it in your actual code before or no?

 

Josh:

I don't think that I have, but I think I could see its utility, like

 

Allen:

Mm-hmm.

 

Josh:

in very specific situations, but yeah, I don't know.

 

Adi Iyengar:

I used to have a very small project where it was a production app, but I needed to validate something as an integer, not a float one.

 

Allen:

Thank you.

 

Adi Iyengar:

And I didn't want to import ecto or do any weird type steps. I think that was only because it also validates type. So yeah.

 

Allen:

Okay, that's interesting. I guess I could see for that case, but even so, for most things, you just want to say, well, is one equal to 1.0, right?

 

Josh:

Yeah,

 

Allen:

But now

 

Josh:

I think that's

 

Allen:

I remember

 

Josh:

the vast

 

Allen:

floats

 

Josh:

majority.

 

Allen:

are goofy, so is that actually even true? I don't know.

 

Josh:

Uh, uh, I think we've been doing a lot of stuff with like decimals, floats, and it's shirts at my current company. And I never thought about using triple equals. I still think I'd go with just kind of like conversions or pattern matching on types, um, in the functions clause. But, uh, that is a cool thing to think about. I was trying to like reach for a case where I'd use it, but yeah, of course I had one obviously.

 

Allen:

And this kind of goes back to what I was saying before. The reason I think I saw Tripp equals because it was a JavaScript developer who wrote that code and they were just checking to see if two UUIDs are the same.

 

Josh:

Mm.

 

Allen:

So I guess better safe than sorry than really you're making sure that that's really equal to each other.

 

Josh:

I'm trying to think of when that would not work with double A-Los. Was it just a string? Ha!

 

Allen:

I mean, they basically are kind of like two strings to a certain extent. Unless you go into the database, I believe.

 

Josh:

Yeah. Like if they were wrapping, I didn't know if they were like wrapping it in their own struts or something, probably a good idea. Or if they were like,

 

Allen:

No,

 

Josh:

actually,

 

Allen:

it was

 

Josh:

yeah.

 

Allen:

dot notation, double equals or triple equals sorry.

 

Josh:

I gotta be honest, I don't see the advantage of it. Not saying that there isn't one, but I think that is one extra character stroke. So one step closer to your carpal tunnel in my book.

 

Allen:

Yeah, again, like never over read this one. It's really just what I what I was saying to you is just like, okay, I'm from JavaScript, I need to do a quality check. I should always use triple equals. That's

 

Josh:

Did

 

Allen:

where

 

Josh:

they

 

Allen:

I think

 

Josh:

have a

 

Allen:

it

 

Josh:

lot

 

Allen:

came

 

Josh:

of

 

Allen:

from.

 

Josh:

variable bindings like this in their code too? That'd be

 

Allen:

No, that's a good point. I'm glad that didn't happen. But like

 

Josh:

pretty

 

Allen:

I said,

 

Josh:

rough.

 

Allen:

lots of maps within maps within maps with a flatten and then removing nails.

 

Josh:

Yeah.

 

Allen:

Yeah, so, okay. Cool, I mean.

 

Adi Iyengar:

I know one thing, in Ruby, triple equals doesn't work perfectly. I know in Elixir, if you do one triple equals 1.0, it returns false, and it returns true in Ruby. And I never really got deeper into it, deep enough to retain the reason. But I just know that it was weird. I just want to share that here. I think JavaScript. has a pretty solid triple equals. And it looks like it has a pretty good triple equals, too. But I know Ruby Python has something weird stuff, too, where they use the object ID and stuff. So.

 

Josh:

Oh, it's like a memory thing? Hmm.

 

Adi Iyengar:

Yeah, I think it's the stack thing. Yeah.

 

Josh:

It's even stronger, yeah, even stronger equality.

 

Adi Iyengar:

Well,

 

Josh:

Maybe.

 

Adi Iyengar:

I think you can... Yeah, I don't know. I don't know. Maybe.

 

Josh:

Yeah, I'm out of my depth here.

 

Allen:

Yeah. Well, I think we're kind of approaching the end of our time though. I mean, did I miss anything else? So this is the coolness of the real Josh Adams that we've got to meet today.

 

Josh:

I don't know about that, but yeah, I'm sure other Josh would be cool too to talk to.

 

Adi Iyengar:

The coolness of this Josh Adams cannot be captured in just an hour long podcast episode. The coolness of this Josh Adams is next to next to next level. By the way, just for listeners, Josh was one of my mentors who really helped me learn how to really code, how to have proper etiquettes and get etiquette, get tickets. And yeah, how to come up with great names, how to communicate. That's a huge thing as an engineer. And I think an engineer is not a senior, in my opinion, if they can't communicate their side in an empathetic way. And Josh was the first person to teach me all that. So yeah, shout out from me. to Josh I tried not talking too much because I'm obviously super biased and I would just like keep talking positive

 

Josh:

Thanks for watching!

 

Adi Iyengar:

about Josh for two hours. So that's why I've kept myself a little bit quiet today.

 

Josh:

Yeah,

 

Allen:

So

 

Josh:

that's

 

Allen:

maybe

 

Josh:

that.

 

Allen:

you should turn it around and say negative things about him, right? We can't fluff him up too high, because when people meet him, you know, they're going to be expecting the best. Not to say he's not, but now we've got to have something bad about him.

 

Josh:

Oh man, yeah. My eyes are, for folks that are just listening to this like I usually do, my eyes are rolling really hard in the back of my head while Audie was giving me that. I have learned equally as much if not more from Audie. So yeah, you learn something from everybody.

 

Adi Iyengar:

That's true.

 

Allen:

Cool. Yeah, I just don't want to, I mean, I know we can go on and on for forever, but I don't want to make the editor of this episode hate their job. So if there's nothing else kind of poking me, we can transition over to PIX. Cool.

 

Josh:

Sounds great.

 

Allen:

Let's head over to PIX. So shall we have a guest go first? Or is it host go first? I forget.

 

Adi Iyengar:

It's usually panelists go first, yeah.

 

Allen:

Okay, Adi.

 

Adi Iyengar:

I guess I can go. So I have actually, since we have a physicist on today and I've been reading a lot of physics, this one's like a more philosophical physics book that I just finished. It's by Sabine Hausenfelder. She's a pretty prominent YouTuber now. It's called Existential Physics. It really makes you think through what is even possible to discover and what's not. And she's not religious, but I really, I think, and neither am I, but I think she does a pretty good job of making a case for some kind of an intelligent design to the physics that we know. Anyway, I think it's a pretty unbiased book that really makes you think. very, very deeply about physics, if you're into physics, cosmology, if you're really into cosmology and philosophy, if you're into that too, it's an amazing book. Yeah, I literally, Friday night, I was like not able to sleep because it just, I was in a deep thought after reading this book. It's an amazing book. And my regular, well, elixir pick, we're gonna have a Bruce Tate soon, but I figured I'd pick one of his, grogzio courses, the OTP one, a few of my mentees finished the OTP grogzio course recently and they just they loved it. They did like talking about it so highly and one of them told me why don't you recommend this to me earlier and I was like okay well I'm not gonna not gonna do that mistake again and just like let you know everyone who listens to the podcast know that grogzio has amazing courses, specifically the OTP one I've heard is We're really awesome. I think it's like 70 bucks or something. So if anyone wants to learn OTP and learn from one of the best in the industry, check out Groxio's OTP course.

 

Allen:

Okay, now does it transition over to me or does it go to the guest yet? Now, it goes back to me, right?

 

Adi Iyengar:

I think it's Guest, Sasha likes to be the

 

Allen:

The last

 

Adi Iyengar:

finale.

 

Allen:

one, right?

 

Adi Iyengar:

Yep, yep.

 

Allen:

Oh, okay, I'll be the Sasha then. Go ahead, Josh.

 

Josh:

Okay. Yeah, okay. So, books. I actually haven't been reading a lot of books recently. I will say that I do have the Feynman Lecturers. I read them really briefly after I graduated. They're great. It's probably not something that everybody's going to pick up. If you, because we kind of briefly talked about, or I'll dotty touch on philosophy, I will say I'm like super into philosophy too. on the genealogy of morality by Nietzsche is like a must read. I've read it a bunch of times and I still don't understand everything. I love reading books that I can't understand after a hundred times. So that's a big one. And yeah, elixir wise, I mean, there's this book that's come out recently called build your own. web framework in Elixir. That's pretty awesome. I kind of just started it again after not reading it for a while, but I'm getting through it. It's pretty cool. I would definitely take a look at that. Unbiased, it's a really good book. I wrote it, but you know, even if you didn't, it's a great book. And then I already mentioned... I think Exorcism, if you're just getting into things, I think is a pretty great resource. It's free, it's easy to kind of get hooked into. It's got a nice badge system for folks that like gamifying their life. It's great. And outside of all of that, you know, Zelda, Tears of the Kingdom came out recently. I know video games are sometimes discussed here. Big fan, love that game, incredible. And yeah, maybe a little bit different. Going outside is a recommendation. It's nice outside. And then in the Northeast, kind of taking walks if you can. If you can, if you're able. Kind of helps me be more effective when I'm not out on a walk. So I would recommend taking walks. That's it.

 

Allen:

Okay. And then for me, I'm gonna make mine quite quick. Really, it's basically that book that we kind of mentioned before. Was it... I'm sure that you're joking, Mr. Feynman. I think that's what it's called. Fantastic book. It will definitely... I don't know, I laughed quite a few times when I was reading it. He's a very... definitely a very interesting guy. So if you don't know who Richard Feynman is, and you look over a book that's kind of interesting, definitely check out that book. You will probably... Want to start Googling this guy and learning more about him based on just that book alone. So, all right. And then with that, it's great to have you on Josh. Hopefully they have you back again on the future. And see you guys next time. Is it how

 

Josh:

It was

 

Allen:

does

 

Josh:

a pleasure.

 

Allen:

how does Sasha say it? Bye,

 

Adi Iyengar:

Bye!

 

Allen:

isn't it? Bye.

 

Josh:

Thanks. Bye.