 Here we are for the final closing keynote. Yeah, let me just quickly introduce Francisco to start with. I think most of you met Francisco on the day one. But if you've not, Francisco is the founder and CTO for airline solution. I've known him for a few years. He's been an awesome supporter of this conference and in general function programming. And of course, all the awesome work he's doing, he and his team is doing on the beam. So it's an honor to have him back and continue to support this conference. So thank you, Francisco, for being with us on a Saturday afternoon from London. Thank you. We actually have people from three different continents now on this particular thing. And then we have Bruce. If you can just unmute yourself for a second, Bruce, and say hello, hello to people who can see you. Hi, everybody from Florida. So we'll talk a little bit more about that in a second. Yeah. And so Bruce, at least I've known him again for a few years, been a very big inspiration and big influencer in the programming world. I first read his bitter Java book long, long back and being a fan of him since finally someone spoke the truth. Kind of a thing. And of course, his seven languages in seven weeks that was amazing as well. And I don't know how many of you were there in the 2019 conference. Bruce did a fantastic keynote at the 2019. It was titled Joy. You know, basically it was everything to do with Bruce's experience of how he kind of got back into experiencing the real passion of programming and maintaining that passion. A lot of wisdom in that talk. So if you've missed that, I'll put that on the chat here for folks who want to view it later. But you know, I'm so glad that Bruce you're back with us this year. And so without much delay, I think I want to hand it over to both of you to take us through this exciting topic. Well, thank you so much for having us. You know, thank you for putting us such a great conference and really rallying the functional programming communities in Asia. So Bruce and I last November, I think it was both keynotes that tell it to Brazil. I think one of the things, you know, with the pandemic is that you're once we might be apart, these virtual conferences actually have actually brought us together. And throughout this conference, Bruce had the opening keynote at the conference, and throughout the conference, there was a theme emerging. Other speakers, you know, me included, started referencing Bruce's talk. We were referencing his talk out of admiration for what he was doing out of concern, but also because it was full of parallels and anecdotes, which we ended up using in our respective talks. You know, myself, you know, late that night before having to present mine rewriting my talk to fit in items from Bruce's talk. So when the opportunity showed up, we decided to join forces. And so, you know, despite the pandemic actually easing up, it had to be a virtual conference. We couldn't have done it otherwise. For reasons, you know, we will now explain. So, Bruce, when we last spoke, I was actually in London, but I'm now back in Rome, and I was a bit concerned when we were kind of sinking preparing this keynote because you had a really, really bad connection. That got me worried. The problem seems to be gone now. Where are you? So I'm in the Palm Coast and so the bad connection was Marina Wi-Fi, and I'm actually on a boat. So we took some pictures this morning. Let's see. So this is our boat called currently and we're kind of jammed between these two pilings. And so yesterday we got in and we tried to back the boat in so that we could get off easily, and the wind was so bad that we had to pull straight in. And then we kind of turned around and it's a beautiful little marina with just lots of, the water is glassy smooth this morning. There's a lot of beautiful boats and it's a lovely temperature outside. There are birds tweeting and, you know, fish playing, and we've even had some dolphins pretty close to here. And so we're there because we are taking a trip. I live in Chattanooga, Tennessee. And these pictures are taken way over here in New Smyrna. Actually, we're just north of that now in Palm Coast. We thought that we'd be in New Smyrna for the talk, but we've moved up that green line north just a little bit because we are taking this cruise called the Great Loop. And I don't know if you know it, but more people have climbed Mount Everest every year than have completed the Great Loop. It's an audacious undertaking, but it's fairly low risk like nobody's ever died. And, you know, there's been a few people embarrassed, but, you know, nobody has ever gotten in over their heads because for most of this trip we're within sight of land. So great. So, I mean, that's fairly close to Cape Canaveral as I can get it. It's a beautiful coastline. I've taken a similar route, but by car, not by boat. I think my favorite town, by the way, on route just to take notes, I hope you'll be able to visit the St. Augustine. We spoke at Alexier Days there, but what is the Great Loop? You know, can you tell us a bit more about it? Yeah. So starting with our journey, I walked downstairs one day and the non-adventure person in our marriage is Maggie. It was 2020, and we were feeling what everybody else was feeling at the time. We were, you know, I had come through some medical issues. There was the pandemic. There were professional issues. Maggie had many of the same, and we felt like we were drowning. So she read this book called From What Is to What If, and I had seen this trip in the past called The Great Loop, which is a nautical trip that we'll talk more about in a second. But Maggie started to wonder, what would quarantine look like if you were able to control the circumstance? From what is to what if, she started imagining and she started reading this book unbeknownst to me, right? So I walked downstairs and I said, hey, Maggie, what's she reading? And she flashes this book, The Great Loop Experience, and I don't think I said anything for a full minute. I think that my mouth just hung open because this is un-Maggie-like to really start to plan something this adventurous and this audacious. When we've got jobs, we've got kids, when we've got a house. And so we started planning this and, you know, we started thinking about four years out and then two years out. And then some of our best friends said, if you're really serious about this, you should drop everything and go. You should drop everything and go. You should dream. You should get out here. And so this is what The Great Loop looks like. If you see Tennessee, so that's maybe right about in the middle. We are in the lower right corner, that's the southeast corner of Tennessee near that angled line in Chattanooga. And we're on the Tennessee River. So if you follow that line that looks like a V down to the southwest and then across, that's going to put you here where the loop starts. And then you take the longest man-made canal in the United States called the Tentum Waterway and some Alabama Rivers to get down to the Gulf of Mexico. And then you sail across to what's called the Big Bend of Florida and then you do what's called the crossing because the blue line on top there gets too shallow for most boats. And it's a little bit too treacherous to do alone. So most people take a long trip across the only time that we're out of sight offshore. It's 70 miles offshore, but we do what's called the crossing. And we come into a town called Tarpon Springs. We actually went a little bit down to Clearwater. And then you go down around the tip of Florida and the Keys in Miami. You come up the coast all the way through Georgia, South Carolina, North Carolina. Near, near Norfolk, Virginia, you go up near Washington DC into the Chesapeake Bay. You come out and then around New Jersey to New York. And then up into Canada into the Canadian Great Lakes through this beautiful waterway called the Trent Severn Waterway. And then you come out at Chicago after going through Lake Michigan. Then you go down the Illinois, Ohio and Mississippi Rivers. And then we turn back to the Tennessee and we're home. And so Maggie and I said, we're going to take the dog. We're going to do the trip. We're going to buy a boat. And so we were imagining what if our circumstances were different, what boat would we like to live on? And we said, we kind of like a tiny house on water. And that's effectively what we got to do the Great Loop. We got this little boat that we're calling currently, right? Because currently is kind of now what's happening in our lives right now. And this is what the boat looks like now. Though when we saw it the first time, it was on land and it was, you know, the paint is shiny and everything, but it wasn't in the best of shape, but we loved her immediately anyway. I mean, it was love at first sight. We knew that we were going to put in an offer. We came in planning to haggle and we said, no, we're going to pay you the full price. And so we got this boat, we whipped it into shape and to whip it into shape we had to ship this across land. And so this big fort lift came and made noises with our boat that no boat should ever have to suffer. And I was sad and currently was sad. And then they dropped the boat onto the trailer and the trailer and the boat together made these loud, angry noises. And I was terrified and Maggie was terrified. I think I cried. And so eventually the boat showed up unscathed in Chattanooga, Tennessee. And they took this big lift. They put it in the water. And then we drove the boat home. Sounds amazing. Is it as easy as you originally thought? Yeah. So you asked that question already knowing the answer, maybe to embarrass your friend. That's famous words, yes. So yeah, there's this little cove. So when they put this thing in the water, there's a little dock behind you. And what you can see is that this is a cove surrounded on all sides. And there's this little dock. So if you're looking at this picture or if you're not a coal off the starboard side, if you're looking at this picture, it's off to your left. There's a dock and you see that little dock with a pole on it. Well, so we were pointing right at right back at land and we had to make this fairly technical maneuver on this boat that we'd never driven before. In fact, we'd only driven these tiny little pontoon boats, which is like a floating couch on water. And so we pulled out from the dock. This is the first five minutes, not even on our trip yet, getting ready for the trip. Our first five minutes, we pulled out from the dock and I immediately noticed that the throttle and the rudder were much more touchy than I imagined. That I couldn't really tell where my rudder was facing until I was going fast in some direction. And my my really kind of, I don't know. I don't know the best way to say it. Excitable wife. So she started talking calmly and I knew that that's what I was in trouble and she said, Hey, Bruce, you're going to hit the dock, you're going to hit the dock, you're going to hit the dock. And indeed, the dock was attracted to my boat and my boat was attracted to the dock and they got together and they kissed lightly. And, and we left a little lipstick and the dock left a little lipstick and everything was okay. And then we started pulling away from the dock, picking up speed and out of control. And Maggie said, You're going to hit the boat. You're going to hit the yacht. You're going to hit the expensive yacht. You're going to hit the $5 million yacht. And finally, just inches from control, you know, right after my wife says, If you don't turn to the right, you're going to take out the $5 million yacht. I finally remembered to turn into the obstacle, goose the throttle a little bit to kick the back end around and then nudge it into forward and we were off. So no, nothing about this trip has been easy. But, you know, why are we talking about the loop? You know, I kind of, I see a metaphor coming here, Bruce. Yes, yes. So I believe that loops are in the heart of programming. And loops are also in the heart of human experience. Indeed, when we want to eat somewhere, we typically go back to somewhere we've gone before. When we're learning something new, we go back to it and practice it again and again, programmers and people understand loops. It's a great metaphor. In fact, my first program that I've ever wrote was a loop. This is a basic program. 10 print Bruce go to go to 10 right and then I would add spaces to it to make it slant off to one direction and then the other as as I ran it. And I even turned this little program into a game where instead of Bruce I was writing these angle brackets that looked like UFOs. And then I moved them back and forth and and. Yeah, so so my first program was all over this. I mean, this is a functional programming after all you're not one on sailing, or basic, even though yeah that was probably my first program as well which I wrote in my computer be 20 but, you know, going back to the loop I mean you starting chatting finish and chat and you get. And, you know, who knows you maybe you've enjoyed it so much that you'll want to start all over again, and then you're selling the loop again and again. It's, it sounds like a tail recursive function to me, you know, basically, a function, you know which can call itself, you know, without adding a frame on the call stack. So, you know, still recursive functions, which allows to create loops which can run forever without stack overflows. We go in and we pair them up with another category of functional programming you know that of immutability, you know where process or function for that matter is the only construct allowed to change its state. So, together with processes, immutability and tail recursive functions, we get the building blocks which we use in both our mathematics here. And we use these building blocks to actually break down our problem into many smaller manageable problems. And this manager problem is what we call an OTP loop where we abstract away from tail recursive functions, we break up the loop into many smaller handles so we've already taken a problem and broken it up into many smaller processes. And break it up into many smaller handlers, solving an inbound event at a time. So, I think it's very similar to what you're doing with your trippers. Yeah, that's exactly right. I mean, this is, this is really something that somebody else has designed. And, and we're not thinking about that giant loop where we're taking this loop of breaking it into many small side trips that you could think of as each one is a transformation. Right. So, yeah, I like, I like that metaphor. Yeah, so, you know, an OTP loop will take an external event. So, in our world, in the early legacy world, it's a message. It will have a loop state, which is basically Brooks and Maggie and their moods on the boat. And it passes it on to a custom handler, which deals with it. You know, I will be referencing, you know, generic servers moving forward, but you know, this concept will apply to all OTP behaviors, be it a finance state machine, a bad handlers, tax agents, you know, or even supervisors. They all build on the same concept of a generic server. It's the pattern you're behind all patterns. Yeah, so exactly. And you could think of you could think of the loop in this in this form where we've got these we've got the old state and that's that's how we were before we go to this new place we accumulate these new memories and then we are somebody different. And, you know, a gen server will go in and wait in a receive evaluate loop when it receives a message that extracts from the mailbox inbox handler and passes on, you know, to the current gen server state and message. And usually, you know, going to create a custom handler for every request type, and you forward it to the gen server as an OTP message. The handler deals with the message returns a new state. The handler is the only place where the gen server state is changed, you're triggered by the messages it receives. And, you know, of course, along the side, you know, the state change, the handle executes all of the necessary computations needed to deal with that message. And these computations might result in side effects, such as sending messages to other behaviors or Bruce, you know, joining us for this conference or sending signals, updating things to a database so as, you know, as he's working along the updates things to groxio, or just plain IO, you know, send out radio messages. You know, the goal, as we know in virtual program is to try to limit side effects and retain as many of the state changes as possible within the process you're basically trying to isolate as much as possible. We promised, you know, alongside the basic, this is the only other code snippet we'll show you, you know, this is a keynote after all. And Bruce put together this example, but when I saw it, it immediately reminded me of Tim Bray at Oscar, I think the year was 2008. He went in, it was the open source conference, and he showed very similar code, which was in Erlang, but code which did very, very similar thing. And I was so blown away by what he said, I had to write it down. He said, you know, after you open the top of your head, reached in and turned your brain inside out, this just looking like a natural way to count integers. And Erlang does require some fairly serious mental readjustment. But if somebody came to me and wanted to make a lot of money to build a large scale message handling system that really had to be up all of the time but never afford to go down for years at a time, I would unhesitantly use Erlang to build it in. Now, this mental readjustment is all about thinking functionally. It is all about abstractions. And in fact, it's about a more natural way of doing things than what you might be used to. And it's a way of doing things taken for functional programming and the functional program paradigms. You know, the hard thing here is not, you know, as Tim described, you know, taking your brain turning inside out. The hard thing here is unlearning what the other programming paradigms have taught you. The hard part is not embracing the Erlang in a way of doing things. And, you know, that comes naturally. I mean, Bruce, how does all of this look like to you? Yeah, I think I think you've got it exactly right. I think that the point is that this is a transformation interface, right? So we have the we have the count. And all the user needs to provide is this function this count plus one, right? So, and on the river we see something that looks very much like that. We don't we don't have to build all the infrastructure of the river. It's already there. What what the infrastructure needs to be added to make a river a river that's deep navigable is a transformation interface. So I know that that sounded confusing. Let's let's make it a little bit more concrete, right? So think to a movie called the Jungle Cruise, where you have this iconic scene of this boat going over a waterfall, right? And the problem is that the level of the river on the upstream side does not match the interface of the river on the downstream side. The levels are different. So if I try to sail a river like this, proud currently comes up to the upstream side, comes to the tip of the waterfall, flows over the waterfall, and then bad things happen. So instead, what we do is we use an interface. And in this case, the interface is a transformation. And the hardware that we're going to use the trend to do the transformation is a lock. So we take currently no sinking here. Load currently conveniently to a full chamber full of water with doors on the top and doors on the bottom. And then we close the doors and then we drain the water out of this isolated chamber. And then currently can sail off into the sunset. And this is what it looks like in practice. So this is a lock that we're pulling into this boat in front of you is a toe called the bear cat. And we're not going to be the only two boats in the lock. In fact, this is the second time that we've gone through a lock with our boat. And we were terrified, because we'd only ever gone through, only ever gone through this lock at once. It's pulled in, tied up to this ballard and this ballard is another interface, right? It's rather than tying up to the side of the lock, which would be bad, right? It would keep you in the same place, which you don't want, right? It would keep you in the same place on the wall and then you drain the water out and you have a boat hanging on the wall. But instead, you have this interface that neatly slides up and down and floats on the top of the water but stays in a track. And this does keep the boats in place. And then other boats come in and tie off and there's still other boats on the left hand side in this picture. And then after you drain all the water out, all the boats sail out and move on down the river after we've used our transformation interface. This sounds great. It's fascinating, but let's get real here. It's not all about sailing. We all have day jobs. How do you get your day job done on the boat, Bruce? Yeah, so effectively we look for times to sneak in work between all the other things that are happening. And so effectively we're looking for three or four hours that we could really hit hard. And in fact, Maggie is across from me working diligently on editing some cross go videos right now as we speak. And so there are other tasks to do that kind of mix around, but effectively when I'm creating content, I'm using, I'm taking this content, it builds these big videos, and so I need to have access to good internet most of the time. So I create this content. And then I upload it to the internet through this system. So the antenna is called a pointing antenna, which is seven individual antennas under the triangular cover on the upper left. And those connect four of those connects to two different cellular providers, two of those connect to a Wi-Fi gateway and one is a GPS signal so that we could tell where we are. And that connects to this system called a pep wave. And the pep wave, if you see on the bottom left, there are two cellular SIM cards. And so that we could use two cellular providers and stitch together the best possible signal between the two. Now, most of the time this works like now we have brilliant internet and we're in this small town called Palm Shores Palm Coast. But sometimes, probably three times so far, we haven't had any internet at all. No internet, just alligators. Well, so what that does is it makes you eventually consistent, which I guess is not an issue at all for you. You do not need asset properties, you do not need transactions, you do not need strong consistency for what you're doing. And that the same applies to a lot of the systems I design. Eventual consistency is enough for your use case and you need to build your software around it. I mean, what I take is important for you is that you are continuously able to develop new material for Groxio, which you then upload, but if there's a delay in uploading it, users won't probably notice, they won't notice this latency and that they will get the new content once you're out of the alligator swamp. Is that right? Yeah, yeah. And you can see that in some of the other things that we do on board, so we'll get to the power in a second. But we're going to have to be maintaining our engines, right? And in this case, there are 10 different pumps on board and those pumps move fluid from one place to another. This particular system moves fluid out of this shower bilge and into what's called the sump of the boat. And so I had to, there was a float switch that was broken here. In this case, there's my engine and as you can see, there's a little bit of redundancy baked in here. Yep, I see two oil filters and that's so true. Yeah, yeah, two fuel filters. Yeah, you had two SIM cards. You need to have absolutely everything to avoid single points of failure. I mean, you need a Bruce and you need a Maggie as well. Yeah, that's right. That's right. The two oil filters give us redundancy. But I actually just saw one belt in the engine. What if the belt breaks? Is that not a single point of failure? You know, do you have sales as well? Do you have orgs? You and Maggie can take and use? Yeah, yeah, we do have some systems that I'd like to talk about. So we don't have perfect redundancy in the sense that you're used to thinking about it in the Erlang sense. But there are other systems that we do that do give us some redundancies, but none of it's perfect. For example, here I am replacing the batteries on the boat. There's six different batteries, but they all go bad at the same time, right? And so in order to combat that, there are different power systems on the boat. If we're at the shore, we could wire to shore power. We have a generator on board. We have a solar panel on board. But still, if you are starting the boat, the batteries have to work. At least one of the batteries has to work and it has to be one that I can connect to the engine. So that's not perfect. So you did say earlier, you will be sailing your past woman of favorite cities, New York City. And I think when you're there, you have to pay a visit to the AT&T long lines building. It's just south of the Bowery. And it's my favorite example, which always reminds me that single points of failure are not just in the software. You need redundant power supplies. And the long lines building was used to house telephony switches, less so these days because they don't take up that much space, but telephony switches may never fail. You have to be able to make calls, even in case of a power outage. And the long lines building has a fuel tank in the basement, large enough to store enough gas to power up generators and keep the phone switches running for two weeks in case there's a blackout in Lower Manhattan. And you've said it, you've got multiple batteries, you've got solar panels, you have wind turbines as well on the boat. Yeah, yeah. So, but what we have isn't, isn't perfect, right? It's, so we don't have a, we can lose all of our batteries at once. And though we have different power systems, we can get failure. So, yes. I mean, I see there's only one boat. And, you know, failure happens when you least expect it, you know, what if an iceberg makes it all the way down to the Florida coast. And, you know, what happens then? Well, then we're looking at bigger problems. But yeah, yeah, your point is taken. So we have these things called not, not icebergs, but crab pots, right. And so a crab pot is an industrial lobster trap. And if you hit one, it wraps around your propeller. And sometimes the lines are strong enough to pull that propeller axle right out of your boat and sink you. So we have systems for thinking about how to make things a little bit more redundant. So one of the ways is that when we are not confident about something, then we're always running with a buddy boat. So you saw this picture of us coming out of the locks. Well, that's that ship right there is a is a tug. I think it's an American tug or Nordic tug. And, you know, we ran down to Chattanooga with with that buddy boat. And there's also this crossing, and that's a little bit more extreme because at that point we're out of sight of land so we need to think about more about that system so I want to talk a little bit about that. This is where we're trying to cut across cut across the big band of Florida, and you might think that it would be better to follow the shoreline closely but it turns out that that those waters are treacherous because they're shallow. And because the sand moves around so we get what we call shoaling. So it's relatively easy to run a ground. And if you run a ground and the tide goes out then you're landing on the side. Then, then you're letting water into places that it's not supposed to go you're letting fuel and oil out of places that it's not supposed to go and it can be a bad situation. Instead of following the land we go out to sea for the only night on the loop. And so we've thought a lot about this particular day because it's different than the other days in the loop. So here's where we're looking for here's a little video that shows us looking for what's called red to which is a red buoy with a number two on it. You can see the Maggie's driving here I'm helping to navigate. She's picking it up, and you can see the navigation charts, you can see that long line at the bottom and that line is kind of pointing to the crossing. And there's red to. And then on the other side, there's a red for at tarpon springs and we're going into the channel there so we're driving across. We brought a friend with us for a little bit more scalability right and so what are we trying to scale. Well the hours we can sleep. So with Sam aboard, we can sleep for two hours on for every hour that we drive. And then so eventually so we start this relatively late into the day because we want to go overnight. So eventually the sunsets. There's a there's a picture of the mass in the middle of the night. This is what our running lights look like which they're read so they provide they preserve our eyesight. And you typically have them on like in this lock on the Tennessee River but we typically have them on when we haven't had enough coffee right. And so here's a picture of the iPhone saying that we are in the middle of the Florida coast, and eventually we're going to get to the other side, but we have to be careful so the redundancy that we have is that little red boat that's on top. It's pretty small it's only 12 feet long. And in this case, it takes 700 pounds which is just about enough for the three passengers and the dog. Obviously we'd have to take the seats out but we have a little bit of a motor that can that can get us that can get us to a point where we can radio for help. So did the three of you do the crossing alone is it safe you know I was following your Twitter and I was very concerned. Right right so we did cross alone in this case and we have systems for dealing with that too so the first one is that we file a float plan. And this is something that we can use to, you know, to notify the Coast Guard that we're leaving somewhere, and we tell people that we trust that we are we are leaving and if they don't hear back from us to notify the Coast Guard. And this is what a float plan looks like we talk about our boat we talk about the equipment that we have on board. We talk about the passengers on board. Those who are the captains, what level of experience they have, and then along the way we collect information about the trip. So, there's a there's a person that that we knew about that wound up doing the crossing. And they had this brand new boat with all these new electronics and they turned everything on full blast just because they could. They cooked their alternator, which meant that one by one, these systems started to go dark. And one of the things that went dark was the navigation system that told them where they were and the radar for seeing other boats in the middle of the night with the sharks and the alligators. They're away from land, and they called the Coast Guard because they had a battery backup and they said, we're a vessel in distress, and the Coast Guard said, where are you. And the boat said, I'm in the Gulf of Mexico. I don't know where. And that's not enough information, right? This this one worked out okay. But what we do is every, every hour we write down our position and the time and and the distance from from shore. So, so that the Coast Guard can can find us if we have problems. So yeah, I mean, you basically what we call an append only log. That's great person. Yeah. And that's where it comes useful for troubleshooting. I mean, all of this sounds kind of like the air handling we're used to in the airline ecosystem. We go in and we try to isolate failures in layers, a bit like the layers in an onion. If you cannot solve an issue in a particular layer, you escalate to the next layer. So, you know, you first try to fix the problems on the boat. If that doesn't work, you jump into the rubber dinghy. If, if the rubber dinghy is not enough, you try to go over to your body boat. And if the dishes there, you put on a life vest and call the Coast Guard. Is that right? That's right. I'm getting it. Yes. It's great to see how you're using your earning experience, you know, in, in the loop here. Now, just like, you know, we have generic server loops with custom handlers supervisors will do exactly the same. You know, they have handlers which are there to deal with failure. So you've got your supervisor. It runs in a receive evaluate loop. It's only task is to go in and monitor other gen servers. So other, or well, or any other OTP of process behaviors. And it can send a message to the gen server, instructing it to terminate, or it can also receive an IC signal for the gen server, allowing it to react upon the termination. And, you know, the supervisor, you know, when it receives exit signals, it handles it in a special handler whose, and what this handle does is goes in and restarts the server. So everything which was functioning in the server is safe. And it allows the server you to continue executing from, you know, even right before the failure. I guess it's a bit like your insurance company of being very quick in, you know, in paying out if you do crash the boat and supplying you with a brand new boat, so you can actually go in and complete your trip. But I trust you that there are also limits in your insurance as to how many times, you know, it will give you a new boat and restart it. I'm wondering, I don't know if you've seen it, but I'm wearing my keep calm and let it crash t-shirt today. Have you printed your keep calm and let it sink one? Not yet, but we have to have a keep calm and let it sink shirts. Yeah, let's start a thing here at Elixir at FunctionalConf India. Now, you know, I love to cook. You've been to my house many times. We've had, we've shared many good wines and many good meals. Do you need a cooking board? I mean, I'd love to sail and be part of the loop, maybe flip a few burgers and make a few plates of pasta. Yeah, come on, come on, we'll take you. So our, our family, well, sort of, so we can, yeah, we've got room for six, so we, we, we don't grow beyond that, you know, and, you know, it has to be the right six and you guys definitely qualify. But, but yeah, so six during a daytime run, but overnight. No, we can't do that. So you'll need a second boat. And you'll need the second boat, not only for full tolerance, you know, but also for scalability purposes, you could be maybe, you know, we'll leave the kids with you and Maggie and Allison and I can go into the other boat. Or, you know, I'm sensing another problem here, what we want to invite Leslie Lampert along, you will need at least three boats if he needs to join. How do we solve that? Yeah, so there's a there's a number of systems for solving that and most of them involve either getting a larger boat which comes with its own tradeouts right or providing vertically. Yeah, yeah, or, or multiple boats and and we see many families doing the loop together. And that's that's all always possible. So those are our two scaling models. I mean, usually at scaling horizontally with multiple boats, you know, tends to be the cheapest. Yeah, cheapest. Yeah, so this is an amazing adventure. And the programmers get it right. So we start somewhere. Each iteration is a stop on the trip. And it transforms us sometimes in ways that we expect, sometimes in very unexpected ways. Sometimes we're in isolation and sometimes concurrently. So we watch and we wait until we're back in the same place. Home again, and transformed in exactly the right way. Thanks for leading us through this. Thank you. Awesome. All right, I think there's lots of comments and I think we should turn over and take some questions now. Again, an inspiring story Bruce here. You probably are now going to be inspiring a whole generation of programmers going on their own version of adventure, whatever that is. So yeah, that's, yeah, that's what it's all about right it's it's maybe so for us it's a loop we had a we had a house close to a river I grew up in a river town. I hope this does inspire other people to reimagine the circumstance so Maggie had the was sad, because we were in quarantine, and we were letting life happen to us, and she reimagine what happens if we reshape our quarantine. That started this this whole adventure. And we've just kind of cracked the surface so I hope that you'll take the chance to reimagine your circumstance. I mean, we've come out of your two very hard years, but I think a lot of what we need to think about is what are the positives which have come out of these two years. And, you know, as I said earlier, I myself have just moved to Rome, to Italy, and it's the pandemic, which has enabled remote working and enabled us to do it and make our customers realize that we can help them as well remotely as as we did on site and virtual conferences you said today you had people from three different continents coming in and listening in. You know, that would have been really, really hard before the pandemic. So, I think, you know, let's embrace the positives, which have come out of it and let's keep on building on them. Absolutely. I think one of the most inspiring thing I heard during the pandemic was, you know, someone drawing a metaphor of what we are going through is kind of birthing. And on the other side is something much more beautiful, waiting for us. And so if you keep that perspective, it can actually really help you focus on the positives and being opportunistic of what you could do, given the circumstances, and Bruce is like a living legend for that, showing leading the way, and I'm sure that would be, you know, something all of us draw inspiration for. So again, thanks both of you for doing this, Francisco and Bruce, thank you very much. If there are questions, folks, if you can leave that in the Q&A section, we will unmute you so that you would be able to ask your question directly, and maybe we'll take 10 minutes for questions. I'm sure people have someone earlier commented that I have hundreds of questions. So we won't be able to take 100, but a few for sure. So we've got Brian. Hi, Brian. Great to see you, you know, and he's got a question. Brian, can you unmute yourself and ask it in person? Brian, if you can just lift your hand, raise your hand, I will unmute you. There we go. Yeah, Brian, if you unmute yourself, you should be able to speak now. Okay. So none of my questions are technically related, actually kind of is. So I guess the first question, I'll limit, I won't do hundreds of questions, I'll limit to maybe three. So as a voter myself, I'm curious to know Bruce's perspective on this, is how does he feel about the state of the art of vote instruments and the technology available to put on to votes. So I assume that you're talking a little bit about AIS. Well, that was the question I put in there. That was going to get to I'm more interested in just the general instrumentation I assume you have Raymarine or one of the other brands on board. Yeah, so, so what we do. So I believe that that what's happening in boat in boat electronics is the same thing that's happening in car electronics that that you have a you have a new car and it works great. And then two years down the line. It doesn't work so great anymore because there's, you know, eight more study the art systems that have been delivered or all the maps that you've bought have been updated and they're not. They're not current anymore. So what we tend to do is we use the big electronics package right there. Can you see that. So that's that's that's old. That's old Garmin system. And then on the top of that, if you if you see there's like an iPad with, you know, all the fingerprints all over it. And yeah, we use that for with with Navianics and I think that that's a pretty common way for people. I think that's my point is that everyone ends up using their iPad or iPhone because instruments suck. Yes, yes, yes. It feels like you're taking a step back 10 years like on my on my boat I press and they all try to be modern by the sense of giving you these like nice flashy you eyes, but they never bothered to upgrade the actual hardware inside to support that. So when you when you press on a screen, like you'll notice sometimes a two second lag when it's page paginating over and this whole industry is like right for massive disruption. I agree. It's it is so underwhelming and it is so overpriced like the the instruments that Bruce has on board. If you were to get a equivalent like in terms of hardware horsepower and then functionality in a non boat setting you're probably talking about maybe hundreds of dollars but that equipment right there is thousands if not tens of thousands of dollars. It is a complete joke and I $12,000. Yeah, exactly $12,000 for upgrade. Brian, isn't it just the same in the automotive industry though it's exactly the same. Exactly. I'm looking for a new car right now. I'm actually looking for a car which will allow me to display my iPhone screen on the display in the car because yeah by the time you you get your car the software on it is already outdated. It's well so there are there are limitations that have to occur in voting at least so that the the equipment has to be hardened for waterproofing to a certain extent it has to be hardened for UV exposure to a certain extent it has to be hardened for just humidity exposure to a certain extent and what this does to the casing is that you really lack airflow. So, you can't have CPUs that are going to be overtaxed to the point where they're going to require cooling like direct cooling in any way. And so this, in part, I don't want to discount the greediness of these companies because that's a huge component of it as well. But in part I can't speak for automotive but at least I'm voting. I don't know why the hard the the electronics feel so stunted in their like in their progress, but there's, there's just so much to be like Bruce I'm sure that you're you've at this point now have become aware of your fuel consumption because that is like the the you get out there like you start living the life, but then you realize like wow I'm just burning through diesel like so much of it. And in the tools don't really exist to help you optimize your court they do on like large container vessels, but not in the recreational areas. And so one thing that I've always wanted to do and I'm really happy to see that you know this is the foundation of allowing for this in Erlang elixir starting to happen, but a lot of the effort around nx are tools and I'm hoping to repurpose at some point in order to enable me to build out better functionality for voting. And a lot of this is predicated that voting at its base just becomes like a series of vectors and vectors translate very very well over to others. And so a lot of that work imagine if on your chart right you say I want to go from from where I currently am to this destination. And the charts are where the depth so you know if you have a system that's smart enough it should be able to give you navigable course, but if it also optimized for your fuel consumption, like these are things that should be part of it shouldn't take you 1020 years 10,000 hours offshore in order to accumulate that knowledge, because there's so many recreational watercraft owners that are never going to get to that point. And they're just wasting so much fuel when it comes to like just going out for the day. Not to say that we all need to just like go on that optimized path because sometimes it's more funded me and around, but the same time like, like, based upon everything else you said Bruce I have to assume that you're very diligent about your fuel consumption and ensuring that you're being as efficient in that regard as possible. But it is a that's a whole like profession into itself and learning how to optimize for because you have to start looking at current you have to start looking at when so if you're dealing with headwind at a certain time of day, do you then decide to delay your your current leg by 12 hours or go over. Yeah, so what we did is headwind. So we took a different approach. We took so rather than so most this the standard loop boat is about 38 feet and has about a 12 foot beam or 14 foot beam. And that's that's because people want to take their their American living rooms onto the water. And that's not what we decided to do what we did was was we we we decided to squeeze the boat, make it skinnier. We decided to to make the boat lighter. And we didn't compromise on features and that put us in a boat called a range of tug. So we don't really worry too much about burn, we worry about our burn instantaneously right and we could see our instant consumption. And that's and then basically so we track that and then we track like a couple of times a week or or or monthly or something like that we look at our overall diesel consumption and decide how that compares against our budget do we need to drive it up or down between those things but but what Brian is saying is is exactly right. It's that we have this this idea that that there's there's tide so water coming in water going out. There's there's the shape of your whole and then the power and the efficiency of the engine and then to a lesser extent when and all these things coming to do come into play when when you're processing efficiency and we could be a lot better at that with the horsepower that we're throwing at the electronics, then we are and is right for disruption, I'd like to move on to the next question if there is one, or Brian if you have one. I have one boost. Okay, okay, I've got a question for you was come what's next up for grog show what is it you know you said Maggie was working on some, you know, was adding some some videos once you're giving your talk. What's yeah what's next. So right now we are working through through life books so we we are last full module was index which is machine learning which is exactly what what Brian was talking about that the idea that you could have a generic program and you could train it to solve specific problems and the program the input for the program is a tensor, which is just a bunch of that's it's a multi dimensional array. I mean, that's really what I love about. I'm sorry if I'm interrupting you, but it's what I love about the way the interest is heading towards you know because, as I said in my opening chemo code beam. You know we have, you know, take the work which is happening with nx action on top of that embedded in nerves. What you're doing is you're actually moving to compute to the data. So you'll start running your your machine learning algorithms in the boat itself localizing them. Yeah, you add faster hardware you add your access to better GPUs multiple GPUs, alongside the work which has been done with the JIT compiler. I think it's really opening up for a lot of opportunities. Yeah. Yeah, but as so one of the things that happened is, is that the way that we consume data science and models like, like, for example, you know, a like like the fuel consumption model that that Brian might produce the way that we consume that is not the way that you consume a particular chunk of data or a particular program. It's more we'd we'd like to see like a top to bottom narrative of the experiments that we're running. And so to do that there's a there's a program or I guess a little bit of a framework called lifebook which is, which is an interactive mixture of code code output and pros. There's a tooling that's around that an elixirs version also adds a distributed element of that to make it interactive. So, Groxio is talking about live book, and really we're focusing on scenarios and tools to make that happen the scenarios that we're doing right now. I did some collaboration with with my co author for building a binary clock with elixir and nerves. And that's Frank Hundlith the creator of the nerve framework so I talk a little bit about our collaboration and how that works. And that's the video that Maggie is working on right now. Okay, so I can take in our share. There is a question which if you could raise your hand and I will have the answer it. I was curious about fault tolerance in the context of like maritime communication for example where either in normal situations your bit rates might be slow, but many times. The boat might have to be completely in radio silence or let's say a submarine is down like for a month or so or something like that right. So, like a lang beam style system would probably be fault tolerant for maybe minutes or maybe an hour or hour scale outage but like how does it behave in case of like so much asynchronicity or disruption in communication like what are the difficulties of that system. We've been building systems like that for decades, as you've just described. I mean, network outages are rare today, but you know they can last days network outages can last weeks. And despite these network outages happening you still need to be able to function. So, you know this is something you need to build into your business logic from day one so you cannot go in and design a system. And then, you know, halfway through the designing you'll go in and add a feature okay but the system also needs to work offline needs to continue functional flying it's something you need to need to start doing in from day one. And just to give you an example, I mean we had one switch where, you know, partial failure meant that you couldn't do any long distance calls, but all your local calls were still being served, and then they kept on being served. But long distance calls couldn't be happening, you know couldn't happen because someone had cut the cable. So, it just very much depends on, on, you know, the type of problem you're trying to solve. And, you know, you added in a follow up question that, you know, telephony case by contrast would be fairly soft real time where you're down can be a few minutes maybe. But again, that's not necessarily the case. It just sometimes that you do develop systems, which could be down for, you know, for a few minutes after which you get into trouble so you know that could be a bank system for example, where there's only so much money you might want to allow people to take out of the bank accounts year before they start hitting your overdrafts. Right. Like the cash machine system is basically like that. I guess every cash machine has some sort of a rate limit of money on it, because if it loses connectivity with the bank, it should still be able to dispense some cash but not. It was correct. It was. And things like that, right. Cash systems are not synchronous and like popular beliefs they're asynchronous. And, you know, and they lead to eventual consistency. And they've actually done it where you they've gone into two separate cash machine and extracted money at exactly the same time. And, you know, with not enough money on the account, the account went overdrawn that that is how the systems are built. It's all about trade offs. It's all about trade offs between consistency availability and reliability. And, you know, depending on where you want to be in that quadrant. You need to base your design decisions and your trade offs on that. Yeah. Even if you go into elixir and the Phoenix framework that the channel presence is, is built with exactly these trade offs in mind is that that they're independent consistent independent systems, and they're each locally consistent and they're eventually consistent with the whole system. It doesn't matter how long you're offline. I mean, I'll just, I'll just quote Joe Armstrong here. You know, airline, you know, you fire off a message, but you've got no guarantees that the receiver will receive that message. So you basically you send them pray. And you pray that then user receives that message but you don't know if it does, you know, on a virtual within a virtual machine. Yes. Yeah, it will receive it. But if you're in a distributed systems, you don't know if it will receive it. And that this lack of reception is what you need to deal with in the program itself. So that's where you live in that full tolerance. Yeah, I'm also curious like, like the pathological cases, the to like or whatever the network is in communication for a long time. And then there's suddenly a lot of stuff to send across. And then there's like this crazy amounts of chatter, which sort of saturates the network potentially or like those, like, I suppose those are pathological cases where you need to reconcile the state of to it, like heavily diverse. Correct. It completely depends on the format. It completely depends on your use case. And you need to design around your use case, you need to sign your system around your use case. It's not something you can bolt on as an afterthought. So if there are requirements that your system has to be offline for weeks, then you need to test it. And you'll make sure that these vast amounts of data can be transferred when the systems comes up again and have possibly have some form of throttling. You know, I know a lot of these, a lot of distributed value stores have exactly that. Yeah, and help them cope with, you know, the surges and data. And yeah, and we've had, you know, many, many interesting experiences addressing your systems where, where, you know, these use cases had to be thought of and just happened afterwards. Right, right. And I can, I can provide two examples. So I mean, you've already talked about one, like a nuclear submarine that has that has its own, its own consistency demands that we'd all prefer not to be thinking about exactly right now. But, but there's another one called Nebo. And Nebo is a system where we have this little chunk of hardware that's that's in a closet. And it has been up for for all every day except three. And every day that it went offline, because we didn't have that particular device didn't have connectivity. We got a flood of messages say, Where are you? Did you sink? And so, yeah, as a consumer, I know exactly what you're talking about. But there are our systems that aren't designed to be robust and reliable and this time and Brian's right. Maritime systems are ripe to be disrupted. We have, we have the technology to solve problems that we're not solving right now. All right. Thanks. Yeah, I think we are running out of time, but I just had one last question and maybe we could wrap up so it's Bruce and Francisco, both to both of you. You know, in your loop metaphor, you, you touched upon a lot of similarity between functional programming and what Bruce is trying to do with his trip. There were two things that came to my mind as it was going through. One was the debugging aspect that typically, you know, one needs to worry about in programming and the second is testing. Right. So are there parallels that you could highlight that that touches upon these two aspects of programming. Yeah, the big one is that I have to have a regular conversation with my engine. I should do it every morning. It's probably every two or three mornings with me. But, but essentially there's a regular maintenance program and part of the maintenance program like every 200 hours, I have to check something called the raw water impeller, which means I have to finagle my way into this engine hatch and do what we call boat yoga to kind of reach six different screws pull those off and check that all of it that this rubber star has all of its tines on it and that it's it's still supple. And if it's not, then I can't cool my engine and it's going to fail. Right. So that's a an example of a test that I need to run on a periodic basis. I need to check my coolant and my in my oil level every morning because those are systems that can make me fail today. So we do that and you know also there's a there's a little checklist we're kind of looking around the engine for leaks because if you keep an engine room pretty, pretty clean problems, the engine will tell on itself right. See, see individual problems. So this is not a perfect example of a of a software test because the software tests, typically I will run after I make a change. This is a test that I have to make on a regular basis. This is more like monitoring of sorts right. So spot on. So, exactly. And when I started programming. We had the buggers where you were able to go in and trace your code sequentially. And it was, it was when I started my career at Ericsson, when I first came in contact with concurrent racing. And the process manager, which was part of OTPR one, it was the tool I was working on when I was on the OTPR one team, which allowed us to start tracing concurrently. And all you need to look at what's happening now, you know, I mean, look at open telemetry look at what's happening in the distributed tracing space. That's all coming in now and now and we have tools to help us do that exactly that making you making distributed tracing accessible, you know, to the masses. And it all feeds into into. So the process manager has, you know, now you turn into the application monitor app on. It's turned into a month basically large scale monitoring tool where, you know, it goes beyond your current racing. You know, you're able to monitor memory, CPU usage, core usage and so on. So it's, you know, as, you know, as our systems get more and more complex and more and more distributed. The tools, you know, the tool chain, which is, you know, the tool chain is evolving around it and it's catering for these needs. Absolutely cool. I think that's, that's a good thing. So I know we've overshot and I don't want to keep both of you over a weekend hanging in as well. So thanks a lot for doing this and inspiring us to kind of chase whatever dreams or experiments we want to run so thank you both of you. Hope you reach back safely Bruce. We hope that you enjoy the trip but your back safe home. How long is it left for you to finish the trip another three months, if I'm not wrong. So we're going all the way to October. So we've been, we've been gone for for two and a half months and it's a 10 month trip. Okay. Give or take. Thanks everyone. See you on the boat Bruce. Take care everybody. Thanks everyone be signing off. This is this is the end of the functional con. Thank you everyone for joining. Thanks for making this conference a great experience for everyone. We'll have the next edition as Francis was saying we will hopefully do that in person next time and hope to see all of you. Please do, you know, help with the conference itself, you know, in terms of speakers in terms of volunteers in terms of program committee. So as soon as the next conference planning starts we will let you know and look forward to working with all of you. Again want to thank all the volunteers, specific shout out to Natasha and John who have, you know, worked a lot to get this together. Vikram JD other folks on the tech team who helped build this platform and all the volunteers who've, you know, help moderate the sessions and keep everything going seamlessly. So thanks everyone again for making this possible. And most importantly, all the attendees from all different countries who some of you who have stayed the whole night up to be part of this conference greatly appreciate that. Hope you don't have to do this next time because we all can be in the same time zone the next time. So with that, signing off. Thanks again for a wonderful conference.