*intro music* ANNA: How’s it going? It’s been a while, y’all. AMOS: Uhh, yeah, I actually recorded like a little thing last week to tell everyone that we’d be at Gig City. And when I went to edit it, I didn’t notice when I recorded it - there were like - I was in a hotel room and you could hear people like, talking in the hallway and a tractor trailer went by and you could hear their air brakes going blooooooooo and I was like ‘well, we’re just gonna skip it’. I didn’t send out a message, but I’ll send one out today telling people not to expect one. But then we recorded, so. ANNA: That’s totally reasonable. Keathly, are you muted? AMOS: Yeah, this is fantastic. CHRIS: I was muted. I don’t know how I got muted. No, summer is super tough, ‘cause you have to - everyone is like going on vacation and stuff and it’s just hard to coordinate… AMOS: You were both traveling for work, right? ANNA: Mm-hm. We had our company summit in Santa Monica last week. AMOS: Oh, that sounds like a terrible place. ANNA: Oh, yeah. It was fun. AMOS: I was in Peoria, Illinois. ANNA: Oh, how was that? ANNA: It was okay. I just lived in a hotel room for four days and didn’t really leave. ANNA: Oh… AMOS: I was trying to get some work done. My daughter had camp, and since she had a broken arm and it’s like six hours from our house, I didn’t want to drive home and then end up having to drive back up there for something. Which ended up being good because she got poison ivy on her hand on her arm that’s broken ANNA: Oh, gosh. CHRIS: Oh, no! AMOS: She’s a trooper, though. She - they said she didn’t really complain or anything. But I went and brought some medicine out to her so she could have something hopefully to help the itching. ANNA: Ohh… that’s the worst. Keathley, were you travelling too? CHRIS: Yeah, I was in San Francisco, just for work stuff? ANNA: How’s the new gig going? Is it good? AMOS: I think people are making noise at his house, so he’s staying muted. I’m not used to waiting for Chris to talk. ANNA: I know, really. It’s weird. This is like a new world that we’re in… The look on his face is really good. CHRIS: We may have to cut all this out. I mean, you guys might have to record this without me. It’s real bad here. AMOS: Oh, yeah. I can hear it. ANNA: Whatever. It’s fine. AMOS: Just keep yourself muted until you want to talk. ANNA: So how’s the gig at BR going, speaking of wanting to talk? It’s good? He’s just gonna give us thumbs up and thumbs down this whole time. CHRIS: No, it’s really good. There’s just a ton of moving parts, and - *whirring noises* AMOS: That is fantastic. You - wrap your whole microphone and you in a blanket. ANNA: Yeah, and sit in a closet or something. AMOS: Go out on the deck. We’ll listen to birds in the background… So, what are you guys - look, there, I went back to it. You had me saying ‘y’all’, and then I missed you guys… CHRIS: We took one week off, and that’s all it took. AMOS: And I’m gone. I’m worthless ANNA: That’s not true. AMOS: So, uh, what do you all have going on in the Elixir world? ANNA: We had an Elixir Bridge going on a couple weeks ago and that was really good. I’m actually giving a workshop at Right Speak Code, which is a conference that’s happening at the beginning of August in New York that I’m really excited about. So that’s been fun. And then working on my talk for Elixir conf for building up this exchange. That’s been fun. What do y’all have going on? AMOS: Um. I’ve been chasing crashes due to memory - running out of memory. I’ve been working on embedded devices so I don’t have as much memory. Um. And we were sending out tons of messages as there are events that come into our system and I was just caching them in memory in bulk and then sending them out to however many connections you have. So, in the messages that go out to the connections, it all gets copied, and then caching them in bulk, and I was caching every ten minutes - not like a number of them. ‘Cause that’s the spec I have is to send them out every ten minutes. So just gathering all that up and then keeping them in memory, and I wasn’t even thinking about every message you send getting a whole copy of that. So it gets pretty expensive. So I spun off a little process that instead of caching I send off to that process, ‘hey here’s the current end of the events that I’m supposed to be sending’. And then it batches like 3000 messages at a time and actually waits for all the connections to say that they’ve received before it does the last batch of messages so we’re not loading up lots of memory. So that’s been pretty fun. I kinda wish we were on the newest version of Elixir so I could use Continue, ‘cause I think that would be pretty sweet. ‘Cause this process only sends messages to itself. So… It would be nice to be able to use continue. ANNA: Are you working on anything interesting that you can talk about, Chris? CHRIS: Um… No. ANNA: Not that you can talk about? CHRIS: Yeah… I can’t talk about it yet. I’m actually probably completely allowed to talk about it, but I’m not sure if I’m allowed to talk about it yet. I just need to find the rules and then I’ll actually be able to share some of the stuff we’re working on. It’s very very interesting. I can say as much as we’re doing a lot of distributed things and that’s pretty fun. Because that’s deep in the things that I care about and I’ve been learning about. So hopefully there will be some interesting things to report. I’ve had some interesting discussions with the people who are working on Firenest - off and on discussions - and hopefully there will be some interesting things that come with that. My hope is that when we get done with all this, is that some of this stuff will go back to the community that everyone can utilize and take advantage of. The only other thing that I’ve been working on is the stuff we talked about last time we had a call and trying to give up more stuff, and I think that’s working out pretty well. ANNA: Oh yeah? CHRIS: Well, I’m emotionally ready to do that, I would say. AMOS: So you haven’t done it yet? CHRIS: Yeah, I haven’t done that part of it yet. I’ve just been trying to think about if there’s like. Work I wanna do to get to that point where I can say ‘oh this is the community’s now’ or I can say ‘somebody else is the owner of this now and they need to take it over or whatever’. So I’m not exactly sure how to proceed with that, but I think I’m sort of emotionally ready to step away from a lot of the projects that have been causing me a lot of anxiety. Friend of the Show, Fred, reached out to me about it after he heard that last episode and provided a lot of really good feedback and helped me kinda get my head on straight about a lot of things, so… That was really good. And, yeah, I think I’m emotionally ready to move on from some of those projects and say ‘here, community. This is yours now. You figure out what to do with it, if you want it or if you don’t and that’s totally fine’. ANNA: Is there anything in particular that he said that you found super valuable? CHRIS: You know, the thing that resonated with me the most - and this is very telling about my deeply fragile ego about all of this stuff - which is, he was like ‘the only way that this really goes wrong for you is if you like - giving it up doesn’t go wrong for you. Everyone knows that you helped build it and come up with these ideas and whatever. The only way that things really go wrong is if you hold onto stuff long past the point of being willing to invest time in it, because that’s when it atrophies, and that’s when people do get mad at you and say you just let it die, whereas if you give it up to the community, then it lives on forever, or at least as long as the community wants it to live on for and everyone is better for it. So the only way that you sort of ruin your reputation is if you hold onto it for long past the point of you actually wanting to work on it.’ And, you know, he was just sort of like ‘you know, people are always going to be asking you for feedback or stuff like that. They’re always going to have issues. And the fact is is libraries that people use are the ones that have issues, so that’s a good thing. But at the same time, this is free. This is your time and your labor and you should spend it on things that you care about and not the things that you feel obligated to care about because the transaction is such that - no one is paying you for your time. They’re just asking you to work for free’. AMOS: Sounds like great advice from our Canadian friend. ANNA: Yeah, that sounds like really good advice. CHRIS: Yeah, it was some real real talk, so that was good to hear. AMOS: I’m gonna send you a song from another Canadian friend, Niel Young, that says “It’s better to burn out than to fade away”. It sounds like it resonates very well with what Fred was saying. CHRIS: So, yeah. I think that’s actually going really well. I feel a lot better knowing - even doing the mental leap of sort of knowing that I’m going to remove myself from these projects once I get them to a reasonable state. It puts a sort of finish line, where I feel that’s actually achievable now, and I can work towards that. It fills me with a lot of positivity and confidence and it’s like ‘oh, I can actually achieve. If I just do all this stuff, then I can move on from that and that’s fine’. That feels surmountable. AMOS: How about you, Anna. What have you got going on. You did Elixir Bridge a couple years ago, but what else do you have going on? ANNA: Yeah, I’m working on that workshop for the conference in New York and then I’ve really just been working on this exchange idea. CHRIS: So, explain to everybody what it is you’re doing, ‘cause they may not be aware. They may not have read the speaker announcements yet. ANNA: Um, yeah. I’ve been speaking a lot about crypto and Elixir and I’m interested in that world. So if anyone is familiar with bitracks or any of the exchanges out there where you can buy and sell crypto and modeling a version of that in Elixir. It’s been fun so far. AMOS: Are you going to step out there and disrupt the crypto world with your new exchange? ANNA: No, no. I just thought it would be interesting given the nature of the problem and how these exchanges work to see what it would be like to write it in Elixir since I haven’t come across one. There might be - I think there are a couple of crypto currencies that are writing one right now in Elixir, but I don’t know if they’re public yet. I just thought it would be an interesting thing to try. AMOS: So what have you run into so far that’s been maybe the most challenging in doing this? ANNA: Um… That’s a good question. I mean, so far it’s really just been getting deep into the weeds of how these exchanges work and the challenges of how transactions actually get written to the block chain and how you actually have to manage those things, which is not so much Elixir as it is just, the crypto world. There’s a lot of complexity and a lot of latency and I don’t know if bitcoin actually has the time it takes for someone to write the transaction to the blockchain and having to hold crypto in like hot and cold storage - I’m talking about a lot of things that aren’t really relevant to Elixir. So I haven’t really dug into a lot of the complex - there hasn’t been a lot of complexity yet on the Elixir front. Mostly it’s just been like figuring out how to model what is actually happening on some of these exchanges. AMOS: *whispers* It’s so quiet. CHRIS: Sorry, I have to stay muted. There’s very loud hammering that takes place. AMOS: Well, and I think we’ve all been pretty busy. So… I’m getting ready to move. So I’ve been emptying out my house and painting it and everything - getting it ready to sell. And looking for a house about four and a half hours away. One thing I did, Elixir-related, is I reached out to the local Elixir group where I’m moving - I’m moving up near Kansas City. ANNA: Oh, when is that happening? AMOS: Before August, probably. Trying to get there before my kids start school. We already signed them up for school, so now we have to get on it. But the Kansas City Elixir group has been pretty awesome. I got on - they have their own Slack channel and I got on there and I’ve been telling them what I’ve been doing and I’m going to go up there to a meeting here on the 12th and visit them up there. And like, I was looking at a house in a neighborhood and I just messaged them and said ‘hey, what do you think of this neighborhood since I have a very cursory knowledge of this neighborhood?’ And they gave me feedback - lots of feedback. That was pretty awesome. And - the community is very inviting and I appreciate that. And I saw a few people that used to run Ruby Midwest and I went to that a few times, so it’s kinda neat to see old names too that I haven’t talked to in a long time. CHRIS: And I work with one of those people. AMOS: Yeah, I know. We made fun of you. CHRIS: That feels accurate. AMOS: That was actually - the most welcoming part of the community was making fun of Chris. CHRIS: ‘Oh, yeah. That Chris guy. Total scumbag. I have to work with him.’ ANNA: No, that can’t be true. CHRIS: Eh… Well… Ya know. ANNA: I’m excited about Gig City and being able to record live. I know it’s not for a while, but I saw you tweeting a little bit about that. AMOS: Yeah, yeah. Um. James mentioned recording live as part of the event, and I got a little excited. It’s always fun to do live events and get people talking. Maybe we can talk some of the speakers into being on the show. I mean, other than the two of you. But yeah - I’m pretty excited to get down there. I’m looking forward to seeing John Hughes talk. Since I realized I was going down there, it’s - it’s the most exciting part to me. I think I’ve seen almost everybody else there in person at one point or another but not John Hughes. And I’ve been actually reading a lot of the papers that John Huges talks about in why functional programming matters, and that’s been pretty interesting. And his talk that he’s giving on that. Multiple times - it’s a pretty good talk to be looking at. I’ve been digging a lot into more hard functional, trying to see how that'll affect how I write my Elixir because it is a functional language, but there are some ways that it’s very different from ML or Haskell or anything like that. Not that I’ve done a lot with those professionally, but just learning about them is helping me isolate where change is happening and think more about data transformations down a pipeline and then reacting to the data transformation at the very end with the actual outward world changes of state. CHRIS: This is actually something that I’d been wanting to talk to y’all about. I think we hinted at it a couple episodes ago… I don't remember when. There’s a lot of people - like, you know, Joe Armstrong is famous for saying that Erlang is the only object-oriented language out there, is the only one to get it right or whatever, based on Alan K’s original vision and that kind of stuff, and um. I wanted to present a question to y’all which is, what does functional programming mean to y’all? Because I tend to think that functional programming as it’s described today is much more about it’s characteristics than it is about any sort of real definition. That there are just things about a language that trigger functional programming to people whether or not it’s historically accurate. And at the same time, I wanted to see what y’all’s thoughts were on the idea that Erlang is an object oriented language and kind of by inheritance, Elixir is also, to some degree, an object oriented language. And I wanted to get y’all’s thoughts on that. ‘Cause I have a very strong opinion, so I’ve already biased everybody, so I wanted to see what y’all though. ANNA: I’m actually curious, Chris - or, Amos, if you wanna respond, but I’m curious - given that you’ve been doing a lot of thinking - what it means to you? How would you define functional programming? AMOS: So I - talking to other people, I run into two common definitions. One is if you can create higher order functions. Like - if functions are first class citizens that can be passed around, that’s functional programming. I look at it more as immutable data and functions - given the same inputs, you’ll always get the same outputs. And I think of that as functional programming. Although if you don’t add in things like being able to get input from a user, where the same input is not going to give you the same output. If I ask a user for a number, they put in one. The next time I call that, they’ll put in ten. That's not a function according to the mathematical definition. So in order to get interesting things, you still need those side effects, but I think it’s focusing more on trying to keep that side effect stuff out is the functional programming I’m looking at. CHRIS: Yeah, I think people sort of define this stuff as a - well, functional programming puts emphasis on data transformation or you have functions that you can pass around as data and execute functions elsewhere and apply functions against data or whatever it is. But I think there’s a whole set of things that come along or like characteristics that come along with that in a modern context that aren’t historically accurate or don’t really describe functional programming in a real way. The things I’m thinking about are like immutable data. So, we sort of take it for granted that we have immutable data structures and other functional languages have immutable data structures - you know, Closure has immutable data structures and Haskell has immutable data structures. But we take it for granted now and we have these data structures and a lot of people conflate functional programming with immutability. When that’s actually a relatively new concept, all things being equal. That’s not a historical precedent, necessarily. People build languages with certain characteristics and things are immutable because they have to be. So, for instance, Erlang uses immutable data because it solves a whole host of concurrency problems. It’s a means to an end. Closure basically follows the same thing. It uses immutable data because it solves immediately a whole host of concurrency problems and the rest of it is making it easy to do data transformations with immutable data structures. And I think that’s what Closure really brought to the table was - you had immutable data by default and you had very specific ways that you could manipulate it and extend it that worked for all immutable data structures. Um. And so it puts that emphasis back on the data transformation as the focus. So I think we tend to describe these paradigms by their features and I wonder how useful that is. And by the same token, the reason people had this opinion that Erlang is this object oriented language is because messages. And for some reason we just associate messages with object oriented languages just because of smalltalk and that kind of stuff. So, people talk about Erlang being an object oriented language or being the most object oriented language, and I’m not sure that’s a good thing. Because the things that I learn from OO, I now sort of actively fight against doing because I don’t feel like they’re sustainable for building systems long term. I’ve seen systems that attempt to model object oriented code by having a process per entity kind of thing and every time I’ve seen people do that in Erlang and Elixir and… They always regret that design decision once they get deeper into it. They become like ‘oh, this did not give me what I wanted’, it becomes very limiting, you start to find bottlenecks in that system, you find inconsistencies in your state because you have your state spread all over the place, so I’m curious to see what y’all think about this idea of Erlang as an object oriented language, ‘cause I can see why people say that, but I don’t think that’s a thing we should lean into at all. Does that make sense? AMOS: Yeah. I - so, when I’m working Elixir, I do feel like it’s fairly obtutorian, but I look at the objects as different things where before everything in my system was a little object, now, the call microservices, the processes, are objects but they’re not individual pieces. Like, I don’t have a user process. But there are some aspects of a process as a whole being treated like an object. Because it has state. A process is gonna have state. Its had to do interesting things without having state. So it’s just abstracted to a different level. And I think at that high level, some of those OO techniques are still applicable, but inside, they’re not. So - I don’t know. I would go back to - there’s one guy who was all over the Ruby community, did a lot of javascript, burn all software… ANNA: Gary Burnheart? AMOS: Yeah, Gary Burnheart. That’s it. Thank you. So, Gary talked about an imperative shell with a functional core, and I think each process is kind of like that. And that imperative shell is your object, for lack of a better term. And some of your OO techniques still apply at that level. But internally, traditional functional programming techniques and styles tend to work better. CHRIS: I think that’s a reasonable way to look at it. My opinion is that at the end of the day, you want to be a lot closer to the way that Sosha tends to lay out his code. Especially if you read some of his blogposts about when you should spawn processes and stuff like that. I think generally you want to end up a lot closer to that. Which is - you end up modeling the entire behaviour as just data, and not as a series of processes that all are kind of creating data and manipulating each other, because that’s a recipe for madness. You’re still back in that same problem you had where you have states strewn across your application and now you have to figure out ways of managing them. You’re often going to be much better served - I think the example he uses is a deck of cards. If you’re playing with a deck of cards, you just model it all - the deck, the cards, the individual player’s hands - model it all as just data. Put it all as a stateless fashion, and then put it inside of a single process and let that one process manage that entire set of state, and I think you’re going to be much better served doing that than trying to spawn individual processes that were to manage the deck and the hands - you know, for each individual thing. You’re going to end up in a bad situation that way. AMOS: So, I try to decide on processes based on lines of failure and supervision instead of data lines, byt sometimes the data can get so complicated that at some point it might be better to spin something off that has less responsibility to handle and I often find out that that naturally falls out along the line of failure even if I might not have noticed it at first. Or recovery. I guess it’s not really a failure line but a recovery line. Because it might be easier to recover this small amount of data because you know how to recover that but maybe the wider system you don’t. ANNA: I think that makes a lot of sense. CHRIS: It’s funny how much that starts to permeate your thinking. I know for me it’s become, concurrency while having multiple actors is a great way to gain like. Parallelism and speed and performance and all that stuff, but it’s interesting how much my thinking has been skewed - I use concurrency as a means to an end where the end is ‘I want fault tolerance’. So I wanna separate these things so that if this fails, this one doesn’t. And you can achieve that by using concurrency. It’s just funny to me how much that’s changed my opinion of all of it. How much that’s changed the way I think about state, how I structure state. How I structure process structures. It took a long time for me to realize that the end goal of all this is basically just fault tolerance. At least for me. You get all of these benefits that sort of fall out of that. ANNA: In the applications that you’re seeing, Chris, is it partially that people are just still - especially with Elixir, it’s been around a little while but a lot of people are still new and are still trying to wrap their heads around these paradigms, so you see some patterns that are maybe inherent from their background before, so maybe the knowledge is just evolving. So it’s not that people are inherently trying to develop systems that way. CHRIS: Oh, yeah. I don’t think it’s - I think people are just taking the skills that they have from their old jobs or whatever, and they’re just applying them again in this new thing. And getting some amount of results out of that. My concern - not even concern. My feeling is that encouraging people to think about it in that way just sort of propogates the problem, or like. It spreads the problem as opposed to stopping the problem before it even happens. So by telling everybody oh, it’s like this great object oriented language or it has all these characteristics of an object oriented language, we’re encouraging people to apply those patterns, whereas I think if we didn’t - I mean, I don’t know. If we didn’t do that, maybe Elixir wouldn’t get adopted and it wouldn’t matter at all, but I do see people applying that stuff, right, wrong, or indifferent, and you just have to do it a lot until you’re just like ‘oh, I didn’t really like it that way. I’ll have to think of a different way of architecting later on’. AMOS: Yeah, definitely. I think that that - I think it’s okay - you have to use the knowledge that you have in order to grow and learn new things. You can’t just dump it all out and come back. And I believe that there are things that apply to both functional and OO. And using it and playing is a big part of people learning and people coming together. So I - maybe we just - maybe over time, we’ll learn to merge these things, ‘cause I think there’s a happy medium between like Chris, you saying ‘let’s stop all this object oriented stuff’ and ‘let’s do all object oriented stuff’. There’s got to be something in between there that might be better than what either side is seeing. CHRIS: So my question is, too, is are there things that you have found a lot of use using or you’ve had a lot of use using that you’re pulling from past experiences? Is there stuff that I’m missing? AMOS: Oh man… ANNA: Yeah, I don’t… hm… AMOS: That’s a tough on-the-spot question there. ANNA: Yeah… AMOS: I mean, I’m sure that there is. I just don’t know where that is. ANNA: Yeah, I mean, similarly, I’m sure that there are. But then that’s separate from just in general good software engineering principles that you think about when you’re writing code? AMOS: How about single responsibility principle? ANNA: That’s the first thing that came to mind. AMOS: Yeah. It came out of OO, and I think it applies to all programming… ANNA: That’s what I was thinking when I was talking about things that apply to all languages versus just object oriented. That’s kind what I was thinking about. AMOS: Yeah, yeah. But, I mean, it came from the object oriented world. At least that phrasing of it. And that applies to your processes, to your data structures, to your functions, to your modules… ANNA: And I guess that was kinda my question between that being inherently object oriented when we talk about being inherently object oriented, ‘cause a lot of it is really just good - some of that is just really good general practices. AMOS: And I’m not - I’m more saying these are things that I learned in the object oriented language world - my baggage that I’m bringing with me. These are good tools to be used. Chris, are we right, wrong, or indifferent? ANNA: Chris looks… I can’t tell. I can’t tell by his facial expression. CHRIS: There’s a lot of drilling happening right now. ANNA: I also like to subscribe to the strong opinions loosely held. Like, having an idea of what you’ve worked on and an idea of what’s worked and having those tools - it’s always valuable to keep in mind, rather than saying ‘this is terrible or this is terrible’. I think, Chris, even what you’re saying - you still have all these ideas in mind. You’re just saying what makes the most sense in the paradigm that you’re working in. AMOS: Maybe we’ll get some listeners that will tweet at us to see where it applies and where it doesn’t. CHRIS: Oh, I’m sure we’ll get that. ‘ Cause now we’re entering the realm of the software craftsman. I think if you’re used to a certain way of thinking, then that is naturally - all these new ideas are giong to naturally make you feel uncomfortable. Which isn’t a bad thing - that’s how you grow as an individual, so I think - this is what leads people to avoid these ideas, ‘cause they think ‘this isn’t the way we’ve done it in some other paradigm’. I think we cleave to closely to the way that we’ve always done it because of familiarity and comfort. AMOS: It is easy to go back to that comfort level, but I also don’t want to jump too far from it. Although I do say things like ‘spend a week writing code as if case statements don’t exist’ just to make yourself uncomfortable, take your thoughts apart, see how it changes your thinking. And sometimes I get a lot of flack for that. People are like ‘well case statements are great’. Well… Yeah… CHRIS: What is your problem with case statements? You don’t like case statements. Of all the things to not like… AMOS: I don’t think case statements are bad. I just see them very overused and case statements inside of case statements. And if you tell somebody that they can’t use them - adding restrictions to yourself can sometimes be freeing in making your mind think of solutions that might be better. And it’s just a very common problem that I see - is gigantic case statements and nested case statements. And it’s - hey, take a step back and think differently. I’m not saying just jump straight to pattern matching function heads or anything like that, but just forcing yourself into a paradigm can actually be freeing in your creativeness. ANNA: I would agree with that. AMOS: It’s like - here, we’ll go back to OO. How about Sandy Mets’s rules? They’re not really OO. But where she says ‘dont have more than four lines in a function’. Well, that’s great. Let’s try that for a while. Just to see how it works. Not to say that it’s the ultimate or it’s the best or that’s how it should always be done. But just put some constraints on yourself whenever you start to see problems. When was the last time you wanted to test a function that had three clauses and a case statement and a case statement conned underneath. Good thing we have string data otherwise you’d never be able to test it. ANNA: I think, to be discussed further. We probably have given people - I’m sure people have opinions about the things we just said. Any final thoughts? AMOS: Don’t use case statements for a week. ANNA: Haha… Keathley? There’s no way you don’t have final thoughts. CHRIS: No, I really don’t. There’s no way we can publish this. This is terrible. AMOS: We’re totally publishing this. CHRIS: I’m like. Not thinking at all today. ANNA: I think that’s the general consensus of the group today. CHRIS: Ahh… like, I can’t get it together. AMOS: You have construction going on at your house. I have it going on at mine, plus I’m trying to find a house… CHRIS: And I have to pack. We’re leaving here in like. An hour. And so I have to pack still. ANNA: Alright, well, have a good - where are you going? CHRIS: Oh, we’re going to Georgia. Somewhere in Georgia. I don’t even know. AMOS: Sounds like how I vacation. I just let my wife plan. ANNA: Well have fun!! AMOS: So you’re going to Georgia, and Anna, what are you doing this week? ANNA: I’m actually here. I’ve been travelling a lot lately, so it’ll be nice to not travel. AMOS: Ah, well, Chris is travelling, you’re staying at home, and who knows what’s going on at my house ‘cause selling a house - you never know. ANNA: Right? Well, have a good rest of your week, y’all. And we’ll catch up in a week. AMOS: You too, thank you! CHRIS: Yep, later, y’all.