Algorithms + Data Structures = Programs - Episode 148: 🇸🇮 SRT23 - Robert Leahy on C++ in FinTech

Episode Date: September 22, 2023

In this episode, Conor and Bryce record live from Venice while walking and interview Rob Leahy about C++ in FinTech.Link to Episode 148 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)TwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachAbout the Guest:Robert Leahy is a graduate of the University of Victoria where he specialized in graphics, gaming, and digital geometry processing. After spending 4.5 years in full stack web development he pivoted to financial infrastructure in early 2016 and now works on next generation market data storage and retrieval mechanisms. In 2019 he became involved in the ISO C++ committee with a particular focus on library evolution.Show NotesDate Recorded: 2023-06-21Date Released: 2023-09-22CityStrides.complrank.comMay StreetLondon Stock Exchange GroupQ and KDB+ArrayCast Episode 41: John Earnest and Versions of kADSP Episode 96: The K Programming LanguageUDPC++ std::hiveRobert Leahy on InstagramIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

We just finished walking through a beautiful piazza and there are people enjoying their final drink. I gotta say, your composure during this walk is quite impressive. This might go down as the greatest interview, maybe even podcast of all time on ADSP, the podcast, episode 148, recorded on June 21st, 2023. My name is Connor, and today with my co-host, Bryce, we record our final episode from the Slovenia 2023 road trip from the streets of Venice at night. And in this episode, we interview Robert Leahy about C++ in FinTech on the way to the Rialto Bridge. That's right, folks, we record another episode walking through the streets of Venice. This one is an absolute blast. Hello, dear listener. So, against our better judgment, we are going to attempt to record another episode

while wandering the... Oh, God, my feet are wet now. While wandering the streets of Venice. Where are we going, Bryce? We are going to the Rialto Bridge, the famous bridge in Venice. Holy shit. Oh, yeah, the water is...

The tide's come in, so the water is, the tides come in. So the water is coming up onto the road. And we, we're going to do, this is unheard of, folks. This is ground breaking. Connor, you need to not walk me into puddles. I'm wearing sandals. We've got three feet here.

We've got three feet. Okay. That's still pretty close to there. Right now Connor is holding the phone and the recorder and trying to navigate us so that he can get more nodes for his little city. Citystripes.com. Citystripes.com. And I'm holding the microphone. And as I said, Connor said at the start of this road trip, that this was something unprecedented, that a tech podcast had never had a road trip component before. I don't think that's true.

However, this is now a tech podcast that has a road trip that's going to do a guest interview while walking through Venice. And that certainly has got to be something that's not been done before. Isn't that right, Connor? Definitely not. Also, Bryce fails always at these introductions. It's the Slovenia 2023 Road Trip Podcast. Honestly, this is like the sixth last time we've recorded for the last time. We just had a wonderful dinner at, I don't actually know the name of the restaurant. A wonderful dinner. There were some interesting parts to the dinner. Oh my goodness. Are we going to, we're not going to talk about that. We are. Are we? Yes. All right. And also, listener, you're probably not going to hear from me much because, as Bryce said, we're focused. We walked to dinner tonight and we got 92 nodes on a 6K walk.

That's unheard of. The per kilometer node rate here in Venice is off the charts. And actually, if you heard last episode, I predicted that. I predicted that this would be the case. There's a pedal car in front of me. I'm very excited. So you're probably not going to hear from me much because I'm going to be navigating. You're going to be hearing from our guest, Rob, who we're going to introduce.

I assume Bryce is going to introduce at some point. And I actually don't know what we're going to talk about first. Are we talking about the dinner? Are we talking about... Hi. Let's introduce Rob. Let's introduce Rob. Hi, Rob. Would you like to introduce yourself? Hello. My name is Robert Leahy. I live in New York, and I grew up in Canada. And I'm a member of the ISO C++ Committee,

and I sit in Lug under the watchful eyes of Bryce here. Well, thank you, Rob. All right, what are we talking about today? Well, let's introduce Rob a little bit more. Yeah, like, where do you... You said you're from Canada. You said you're living in New York now. You're an ISO member.

Why did you join the c++ committee i mean going i was interested in c++ from the time that i was in university and you know you read secondhand about all the things that go on in the committee and how the language is evolving and when i got into learning about it c++ 11 was new and then 14 came out and so all that seemed very new and exciting and it was right there on the the front of my mind and then when i moved to new y York and I started working in the community and and going to CBPCon I figured this is the next thing I should do and one morning I was at the office very early as I want to do when a co-worker of mine who lives upstate came in unusually early for him and he just looked at me and said I'm not going to Belfast you should go and this was with

10 days of notice and at the time I was the kind of person who didn't travel very well. So it was all a whirlwind, but it was worth it in the end. So what exactly do you do, like work-wise? So I work in financial technology, and that's pretty much all I've ever done in the C++ universe. Before that, I'm very ashamed to say that I wrote PHP code to put myself through university. Was that a PHP hack or a PHP piece? No, no hack at all. Just straight PHP.

I couldn't even convince the boss I had at the time to use any kind of framework. So we kind of like rolled our own and he insisted that there needed to be HTML in the mix or he couldn't understand the code. And it was very messy, but it paid the bills and I managed to graduate with no student loans. So I guess I'm obligated to thank PHP for that,

very unfortunately. PHP, check out plrank.com it's a top 10 language baby people hate on it but it's popular what can we say? I also very early in my programming career did write some PHP I was very bad at it. I'm just going to go out there and say that numbers can't necessarily speak to quality you know like I'm going to pick quality over quantity quantity um every time and now that we've had this aside about php and my emotions have gotten a bit boiled up i've forgotten what we're even talking about so okay we're talking about what you do okay so you work in financial

technology and i feel like we we don't hear a lot from i'm going to take this we don't hear a lot from people in the fintech sector because a lot of people in the fintech sector it is difficult for them to talk about uh their work uh in particular people who are like you know hft companies and stuff like that they tend to not give talk conference talks but like what what specifically what sort of software do you write and like what what are the sort of things that you deal with um in the code that you work with So when I first started working for the fintech startup I was working at, there was a lot of bread and butter feed handler code. And anyone who works in HFT and is in that universe that you just alluded to, Bryce, will understand that you're just basically trying to understand the protocol the exchange sends you

and the exchanges are bad at documentation. And then to the degree to which they're bad at documentation, they're even worse at implementing their own documentation. So there's a lot of tribal knowledge and you're writing C++ code and you're having people look over your shoulder and hand ring about performance. But that's really the entry level to the financial technology industry. And the company I worked for, we weren't doing trading. So we were trying to appeal to all the stakeholders in finance and programming, HFT, etc. And so my experience with financial technology programming has taken me on a tour

that's included things like writing feed handlers, writing drop copy on top of custom in-house fix engines, and then writing that fix engine to writing a time series database that, you know, eventually got put on ice, but occupied three years of my professional time. And, you know, I ended up getting a patent out of, so I'm okay with that. So that's, did that get replaced by a external time series DB or why did that get shelved? So my company, um, when, when, you know, I worked for a startup, not everybody may know, what is a time series database? So a time series database is a database engine whose primary method of querying and storing data is based on when it occurs in time. So the data it stores is a time series where every item is keyed by exactly one key.

In our case, it was two keys, which is one of the novel things that we added because we had a product and a time. But the primary value add is that everything is keyed on a time. And if you want all the data between two times, you can very easily get it. The database is built from the ground up to retrieve that extremely quickly. And in finance, it's very important because one of the queries that people want to perform very often in finance is to understand what happened between these two times of interest. And a time series database from the ground up is built to do exactly that. And to answer the question that Connor just asked about, you know, why this thing was wound down, really, it's because the company that I was working for that was producing this database,

that got the patent on it, that made it into an ecosystem, we got acquired. And, you know, when you get acquired, a lot of priorities get reshuffled. You're trying to integrate with a new business. And this is one of the things that got put on ice as we tried to integrate with a new company, which is still an effort that's ongoing. That's one of the reasons why a lot of my old talks and appearances are under May Street, and the new ones are under the London Stock Exchange Group. Very interesting. So, you got an idea? Oh, no, I was focusing on where we're going. I was just, I mean, we, Bryce and I,

we haven't ever talked about this on the podcast, but we do personally have an interest in time series DB. Here's actually a random question. Having worked in the financial space, are you familiar with the Q and KDB plus technologies? The answer probably is no, but maybe a small chance I might be yes. So in terms of familiarity, like personal experience with Q and KDB, and I think there's also K in the mix there. The answer to that is no personal familiarity, but we have had clients because, you know, as a startup, we try to dabble in a lot of areas. We try to get traction in a lot of areas. One of the areas we're getting traction is because one of our big focuses was on lossless packet capture and the value add on top of that. We were looking at putting stuff in KDB databases using all these languages.

And I never got direct exposure to that except to have people vent at me that it was not a great technology in their opinion. And now I can't vouch for the veracity of their opinion or whether it's grounded in truth. But that was the hearsay that I got. And I've heard pushback against that when I've gone over drinks with people and gossip with them. And as I said, I have no personal way of corroborating that. But that's the hearsay, at least within the company that I work for. Are you able to state, this is spicy stuff, because my other podcast, Arraycast, is representing that community. Not Q specifically, but we do have a Q representative. Are you able to say, not by name, the people, obviously, because we never want to call out people,

but are folks from a certain company or a certain sub-industry of fintech that have said that? Or is it just sort of a smorgasbord? I mean, we want the spicy. We love spicy content. of fintech that have said that or is it just sort of a smorgasbord smorgasbord i mean i just it's uh we want the spicy we love spicy content hot takes are what drive ratings so i think the people who have said this to me in the past were people who are who are coming at that platform from an outside engineering perspective like they kind of came in with engineering first principles in mind and they didn't have a lot of the context around the development and emergence of KDB and its associated languages loaded into their brain. And so maybe some of those design decisions made sense to the stakeholders in the area, but for someone looking in, it just looked

like a mess. And so I ended up with basically a stream of complaints about it washing over me. And that formed my opinion of it in a way that, as I admitted before, isn't informed by my own firsthand experience, but just sort of by hearsay, which as I admitted before, isn't informed by my own first-hand experience, but just sort of by hearsay, which, as I said before, can be very lossy. But that's my impression, is my impression is people came in with expectations they had from other areas of software engineering. They came into this very specific space where I think there's only one contender. They were immersing themselves in a lot of tribal knowledge they didn't quite understand, and they had nothing but complaints about it.

And I think a lot of that, combined with the novelty of our use case, led to us designing our own time series database, because I think we did look at KDB, and it was decided that it wasn't fit for the purpose that we had particularly. Yeah, so it's something to be implicit in this conversation that Rob and I have been having back and forth. But for folks that haven't picked up on it, KDB Plus is a time series database

that is, to a certain extent, quite popular across certain firms in the financial space, which is why I asked about it. Anyways, very interesting. We were going to have to have more guests with time series DB experience to get... To get to the bottom of this.

Yeah, because the language, the executable, was sold for $100 million, and it is, by the people that hold it in high regards, it is highly regarded. But that's the thing. I think there are mixed opinions. You should explain that it is associated with a particular array programming language. Yeah, so when Rob mentioned that Q was sort of in the mix, so go check out, I will link it in the show notes,

an episode from ArrayCast where we talk about the history of K. And actually, we did a little history of K. We did it because it was really fascinating. Yeah. So the short version, though, is that there's been K0, 1, 2, 3, 4, 5, 6, 7, and 9 is the latest, which is Shaq DDB. But K4 was spun into a company called KX and was sold for $100 million. But one of the caveats was that K is an ASCII language. It only uses ASCII symbols. And the people that were buying the executable first derivatives, which is a company based in Ireland, did not want to use an ASCII-based language that is just kind of line noise, according to them.

So they asked for a wordified version. And Q is that wordified version. They basically, instead of, you know, writing a slash for a reduction, which is what that is in the K language. Did you really mean ASCII symbols? Yeah. Every function is a single ASCII character in the K language. But in Q...

A single ASCII character. Yes. So like But in Q... A single ASCII character. Yes. So like exclamation mark, plus, slash, minus, etc. And, you know, comma. Everything maps to a function. And in Q, instead of using a single ASCII character, they added a word for every ASCII character. So now instead of being able to say plus slash with two ASCII characters,

you would say, I'm actually not sure if they added plus as a keyword for the plus symbol, because I think plus is pretty well known by everyone, but you would say plus over. Technically, I think it's parentheses plus, parentheses over. But anyways, the diesel is on the ladder. And they also added shortcut conveniences, so you would never actually spell parentheses plus parentheses over. You would spell some. And anyways, point is, keywords were added to K. That became Q.

That's what they sold. Why am I so out of breath? So Connor is a little bit out of breath because we just walked up a bridge to cross the Grand Canal of Venice because we are now headed towards the other bridge. Wait, how do you know that's the Grand Canal of Venice, because we are now headed towards the other bridge. Wait, how do you know that's the Grand Canal? Because that's what Rob told me earlier. So, okay, back to a different topic from earlier.

All right, back to talking to Rob. What is a feed handler? I mean, before we end the discussion about KDB, I was reloading the context. This was from several years ago into my mind, and one of the things that Bear's pointing out is the use case that we had that we were trying to fit KDB into was very particular. We were trying to, like, shove a lot of market data into it and then process a lot of market data out. And I think that a lot of the K queries were too pre-canned and involved a lot of caching things in memory, if I remember correctly, whereas we were looking for a more stream-based approach. And that may have been where some of the friction came from. Again, I'm not 100% certain of all the details because I didn't do that exploration.

I just know we did not find it fit for purpose, which is something that a lot of people I've gossiped with in the financial technology industry have found very interesting indeed because a lot of them are very interested in KDB and use it as their one and only tool for a lot of these jobs. Sorry, Bryce, back to you. What was your question? We're going to have to have FinTech Watch now. We're going to have to bring people, because we don't, I mean, it's hard to get people from hedge funds

and HFT firms on, but clearly Rob's chatting with us because he doesn't work for a proprietary trading desk and doesn't have to worry about getting his hand slapped. There's probably more of these folks out there that we could be talking to. So, FinTech Watch, ADSP listeners, you heard it here first. We're going to get more

folks like Rob on, or maybe Rob is just going to be the only guy we talk to in the FinTech space, and we're going to have him back as a regular podcast guest. What is a feed handler? So the way that a lot of financial exchanges work, and when I say a lot of financial exchanges, one of the things that's coming out of the expansion of my company is the fact that a lot of this knowledge that I have is very strongly America-centric and perhaps Europe-centric. So the markets in America and Europe function by broadcasting UDP multicast data to recipients who receive it,

and a feed handler would be something that takes that data off the wire, parses it, and makes sense of it in some way, like provides you some kind of structured data you can interact with in C++ or your language of choice that allows you to actually make sense of the data as something other than zeros and ones. The degree to which you... It's always UDP? Right.

And so that's what I was alluding to when I said that a lot of this knowledge that I have from working for this startup is centered around America and Europe. In America and Europe, primarily, the data is transmitted via UDP. Throughout the rest of the world, for example, Asia and the Middle East, it's a mix, right? A lot of the exchanges do transmit the data via UDP, but others choose to do so via TCP Unicast, which calls into question a lot of the software patterns that we use for handling this market data because they still have market data in the sense that we think of market data, right? A stream of updates from the market, status updates, trades, orders, levels, etc. But they don't disseminate

that information over a multicast channel. Instead, you have to connect up, authenticate, subscribe to the data you're interested in, which may be some or all of it, and then receive it on a unicast channel, which is something that I think that a lot of firms that operate primarily in America and Europe aren't quite used to. And we're going through a little bit of a technical cultural shock in that area. Interesting. So you alluded to this a little bit earlier, that all these various different feeds, that they have different formats and protocols, and it sort of sounded a little bit like it may have been like the Wild West.

To what degree are there standards or specifications for all this financial data? And is there an industry consortium or something that writes out that specification? Or is it just like a certain company says this is what they're going to do? How does that work? I mean, since I've been developing this proprietary time series database that's recently been put on ice, I've been taken a little bit out of that world. So I was much more in that world approximately three years or so ago when I had my hands dirty in the feed handler world. But that was also before the startup I worked for kind of took off and then got acquired by a large multinational and we got exposure to this range of markets. What I would say is that to the degree to which there's standardization,

there kind of isn't standardization. Like a of exchanges and by a lot i don't mean necessarily even a double digit percentage but a lot of them will like take nasdaq's technical specification and use some version of them but they may be mutually unintelligible they may use nasdaq's framing protocol but then the payload may be different for example like um mold and its equivalent which i can't uh call to memory right now walking around the streets of venice are fairly common we should say that it is almost 11 p.m. local time Venice, the dark streets of Venice, and we're recording this podcast live. We're walking to the Rialto Bridge. I'm so disappointed we didn't interview Christian and Damien like this. This is groundbreaking stuff, folks. I'm

looking at the audio quality. This is coming through crystal clear. The listener is going to get to hear this conversation. We're walking, we're talking. This is a high quality. I'm thinking to myself, I can't believe this, the quality of this interview. I'm, I'm, I'm, I'm, well, we're almost hit some people, but that's okay. They walked around us. Oh, look, a squirrel. I'm just, I'm just, I can't, I can't believe it, Rob. This is fantastic. Keep going. And, and, you know, Connor and I are can't, I can't believe it, Rob. This is fantastic. Keep going. And, and, you know, Connor and I are both Canadian, at least, you know, culturally. And so I only regret that you can't hear him say sorry and me say, uh, more often as we almost run into people with a wire and a microphone, we just finished walking through a beautiful Piazza and there are people enjoying their, their final drink. So it's not really the kind of environment in which you

focus the most on the technical aspects of what you're talking about. You're crushing it, though. You're crushing it, Rob. People are going to be falling off their seats. They're not going to believe that this was, I mean, I think they'll hear some Italian voices passing us every once in a while. And that's the only thing that'll keep people believing that we're actually recording this podcast live, walking, talking.

It's a new format. We're changing the game, Bryce. We're changing the game here on ADSP the podcast live from the dark streets of Italy at 11 p.m. at night. Look at that. You know what? You heard those voices in the background. Those were some tourists slash Italians enjoying. Also, at some point, we're getting gelato.

I have the perfect beef to pick with Rob. And earlier, Connor and I talked about how this podcast, which is called the Algorithms plus Data Structures equals Programs podcast, the name of the book. We talked about how we don't really talk about data structures that much in this podcast because Connor and I are kind of anti-data structure people. We're just very pro-algorithm. We're very pro-algorithm. Sure. But there is a particular data structure that has truly confounded me. And it is the proposed Stood Hive. And I think Rob would be a great person here to ask about Hive because when we recently, and I should explain, Stood Hive is the thing that's been proposed for the standards

committee. And then I'm going to let Rob explain what it is. But it's a thing that I have been unable to understand its purpose, and I think Rob was initially felt that way, but then over the course of last week at the Varna Committee meeting, he learned some new things that now make him think that it's a useful thing that we should have. So maybe you can explain what hive is and why you think we need it. So yeah, as Bryce said, I went into the discussions we had about Hive at Varna last week, and I was a Hive skeptic. I understood that it's a data structure, and all data structures have some degree of value, but I couldn't see it in my own work. And after we'd concluded the discussions about Hive, I was gossiping with two people on the committee about the possible use cases. And I actually convinced

myself that I want something that approaches that data structure because the things that Hive offers are things that I actually use fairly regularly because the properties of Hive that are the most interesting to me are that it has constant time erasure, reference stability, and also allows you to iterate the elements in any order. It doesn't make any guarantees about the order of the elements. And it occurred to me that every single time that I write any kind of network server, I need exactly this data structure. I have connections that come in. I want some state about that connection. And I want to be able to use that state from an asynchronous operation that can depend on the stability of that reference in memory.

But I also want the ability to iterate all of the connections, and I want the ability to erase any of them because they can end at any time without incurring any kind of cost, without any kind of linear complexity, without any allocations or deallocations, and most importantly, without invalidating other references. And this is exactly what Hive gives me. And right now, I use stood list for that. But the problem with stood list is that whenever a connection ends or begins, you have to allocate or deallocate. Now in the grand scheme of things with a TCP server, that doesn't really matter, but we can do better. And I think that's what Hive offers us or at the very least me. Interesting. Well, you know, that is actually a use case that

maybe changes my, maybe changes my mind a little bit. I'll have to give that a little bit more thought. But that is certainly the sort of use case that I'm not surprised doesn't come up in the sort of work that Connor and I do. Because we are often thinking about sort of pure compute and not things like interactions with network protocols or anything having to do with the OS. And while we do do concurrent programming, we're typically doing parallel programming where we're just coordinating compute work and not where we're, you know, dealing with like asynchronous network programming is very different than the sort of concurrent programming that we do. Yeah, go ahead.

Yeah, and I guess that points something interesting about like kind of the thread that's been woven through this conversation, starting with, you know, the proprietary time series database I worked on, to time series databases, to KDB, and then on to this, is that what I've been immersed in in the last three years, and what the startup that I worked for was concerned with, was giving people really great access to the world's market data. So we had this idea that we needed to give people access to the data, but that access to the data wasn't at the kind of sub microsecond latency that people really associate with HFT, because this was more about doing research or doing something like analytics after a trade or a day or something like that has completed.

What we were really concerned with is very high bandwidth. And so anything that we could do that would level out our performance characteristics was worth it. And so implementing something like Hive to be able to accept incoming connections from our clients and service their queries more quickly and more efficiently would be worth it. It might not lower the absolute latency and the absolute worst case that we experience, but in that case, that wasn't what we were really concerned about. This was more of a big data application. And in my company, we've been seeing the application of a lot of big data techniques to financial market data in a way that belies people's expectations for finance,

which is primarily associated with HFT. I got to say your composure during this walk is quite impressive. This might go down as the greatest interview, maybe even podcast of all time on EDSP. Folks, I'm wearing my garment. I'm collecting the nodes. We're walking at a 950 per kilometer pace.

That's like, that's fast folks. And not only are we walking at that pace we're going up bridges we're going down bridges we're walking across rivers and i'm navigating but like we're twisting and turning there's people by us on fact that probably i've seen a couple looks from the locals here maybe tourists being like what is going on here these guys pointing a microphone at each other's mouths this is this is this is history being made right now with Rob Leahy. You are too much, Connor.

I'm going to have to cut you off. Okay, cut me off. But let me tell you, folks, this is a big deal. This is history. This podcast is history being made. Rob, I've got to tell you, he's been like this all week. No, not like this. This is history.

I mean, we actually made history a few times. That's true. That's true. But this is real. I mean, this is the new greatest way to record podcasts. Walking, talking. Look at this. We got people. They've had too much to drink.

We love it. I think, buddy, you may have had too much to drink. Listen, I had a couple glasses of wine, and we love that for us. And honestly, I'm also navigating like a champ. We're 30 seconds away from the Rialto Bridge. Have we ever been like, oh, I took a wrong turn? Absolutely not.

My navigation skills are unparalleled. Look at that. Here it is, folks. Here's the bridge. Well, does he want to be on the pod? We should get a local. He wanted to be on. We should interview that drunk girl.

Well, switching topics, because we like to get a little bit of soft topic of background on all of our guests. Rob, so maybe you could tell us a little bit about one of your favorite hobbies, weightlifting. I mean, weightlifting is by far, I would imagine, my favorite hobby, but I don't know that there's much to tell about it. It just consists of doing the heaviest weight you can in the snatch and the clean and jerk, which belies most people's expectations because they hear weightlifting and they just think of lifting weights which is not the case and the other way to disambiguate the sport is to say olympic weightlifting but the fact of the matter is is that i spend altogether too much time on c++ to ever consider going to the olympics so i can't call it that how long

how long have you been lifting weights i I mean, lifting weights, going on eight years, weightlifting, something like seven years. I did weight, you know, just lifting weights as a bodybuilder with a buddy of mine. And then I decided to structure my training more and be a powerlifter. And then I herniated three discs in my back and decided I wanted to really be a weightlifter. You're pushed away, but guess what? We're getting our selfie too, folks. We are. Spin around. Get in there, Rob.

This is going down as the best podcast of all time, folks. We're at the top of the Rialto Bridge. How does it feel? It feels wonderful. It is absolutely beautiful here. I have been loving walking through the streets of Venice. It's a pity that tomorrow morning at 8.35 a.m. I have to fly to London and go home

for an entirety of three days before I come back to London for CPPNC, which both of these two gentlemen have tried to convince me is perhaps not the wisest thing, but it's... Not good for the trees. All right, all right, all right, all right. But that's the plan.

I think we should probably sign off here. Wait, we're not going to sign off yet. Let's ask a couple more. While we're at the top of the Rialto Bridge, we got two Canadians here. Yours truly. Was born and raised Prince George, BC. Studied in Vancouver. Live in Toronto now. We're here with Rob. Give us a little bit, raised Prince George, BC, studied in Vancouver, live in Toronto now.

We're here with Rob. Give us a little bit of your Canadian background, Rob. So my Canadian background doesn't consist of more than one city. I was born, raised, went to all the schools possible in Victoria. And listeners who may be in Victoria may be skeptical and think that I just went to elementary school, middle school, high school, and the University of Victoria. But that is not the case. I went to elementary school, middle school, high school, the University of Victoria, and then Camosun College, and then back to the University of Victoria before I graduated and then left Canada and Victoria on Christmas Day 2016. So you must have really loved—I mean, I've been to Victoria, it's lovely, but you must have really loved Victoria.

You didn't want to go somewhere else for college? I don't know that going somewhere else for college is something a lot of people in Canada really do, unless they go to McGill or Waterloo, and that wasn't really something that I was interested in. And the University of Victoria has a really great software engineering program particularly, so I got to stay there, save some money, get a great education, and most importantly of all, perhaps, get my iron ring. So it has an actual software engineering program, not just a computer science program. So are you like an actual engineer in the eyes of Canada?

Depending on what you mean by Canada, then yes. I mean, in Canada, being an engineer can mean one of a variety of things. It can mean that you graduated from an accredited engineering school and got your iron ring, which I did. Or it can mean that you went through the rigors of finding a professional engineer to study under for three years to become a professional engineer, which I did not do because I left for the United States two and a half weeks after I finished my last course. Let's see the ring. I want to see what this ring looks like. All right. It is, in fact, an iron ring.

I don't have any way to verify its authenticity. I've got a sister with a partner that both have these rings. It's official. I can verify it as a sibling of an engineer. Do you have any other Canadian questions for Rob? Not any Canadian questions. We'll wrap potentially the greatest podcast, technical technology podcast.

But listen, listen, this was honestly, can you believe it? We just walked 2.1 kilometers at a 10-minute pace. Is that good? And it's very good. It's very good if you're just walking. Most people walk slower than that. We did it.

We recorded a golden content podcast with Rob. So the last thing I have to ask is, Rob, if people want to follow you online, I'm not sure if you're writing papers, but I know you're giving talks at CppCon. You said that you're planning on, I think, proposing three talks for CppCon 2023. You've given six before, if my math checks out. So where can people follow you if they want to go watch your talks, find out more about you've given six before if my math checks out so where can people follow you if they want to go watch your talks find out more about you follow you on the socials i mean on youtube for my talks would be the the best one i i nominally have a

twitter but i haven't posted on there for four or five years and i don't plan on starting which a lot of people in tech would say is unfortunate other than that i i have an instagram and it's just all of the four names that my parents gave me concatenated together. But the only thing that I post on there is me lifting weights and eating food, and so that doesn't really seem like it's very technical in nature. No, no, no. Go ahead and list out the handles. Some of our listeners may be interested. Vittorio might be interested because Vittorio lifts weights.

We have some other. We've got some people in the C++ community that like to lift. That are into fitness, let's say. I guess if you're into fitness and also into eating, then you can follow me on Instagram at Robert Allen. That's Allen with two A's and two L's. Hennigan Leahy. That's my Instagram handle. And Connor is laughing because that's so comically long.

And believe me, I've heard that before from people who try to tag me in stories. They complain bitterly that my Instagram handle is altogether too long. I mean, if they're using some app that doesn't auto-complete that, that's disappointing. You should get three letters into that, and if you follow Rob, that should auto-complete.

I mean, what if you follow other Robs, though? There's no other Robs. I do have an Uncle Rob, but he's not on Instagram, so... I can think of, like, three other C++ Robs. I mean i mean this is my favorite one but i can't think of like three other ones well you know too many people anyways thank you rob this was groundbreaking historical stuff the listeners you're gonna get you're gonna be getting hit up on instagram for sure by the fans of bryce the listeners of the pod and I think that this is the last time we will record for the 2023 Slovenia road trip. What a way to end the Slovenia 2023 road trip.

I mean, there's no way we don't do this again in the future at the Nigeria road trip or future road trips without getting this walk and talk pod. I mean, honestly, it's a wrap, folks. Thanks for tuning in. Thanks, Rob, for being a guest. Thanks to him for knocking that bottle. That wasn't any of us.

We're static right now. All right. We're going to go to sleep now. I think I've got to pick Connor to bed. He's not going to go to sleep. We're five kilometers from home. Bryce is going to water taxi home. I'm going to go get some more nodes, and then we'll call it a night.

Okay. All right. All right. Okay. Well, thanks for having me on and on topic for where we are. I will just say, Buona Notte.

Buona Notte. Buona Notte. All right. Be sure to check the show notes either in your podcast app or at ADSPthepodcast.com for links to any of the things we mentioned in today's episode,

as well as a GitHub discussion where you can leave questions, comments, or thoughts. Thanks for listening. We hope you enjoyed and have a great day. Low quality, high quantity. That is the tagline of our podcast. It's not the tagline.

Our tagline is chaos with sprinkles of information.