Algorithms + Data Structures = Programs - Episode 151: Is C++ Dying (Response)

Episode Date: October 13, 2023

In this episode, Conor and Bryce respond to several comments about ADSP Episode 150: Is C++ Dying? and chat about why C is the lingua franca of FFI target languages.Link to Episode 151 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)TwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachShow NotesDate Recorded: 2023-10-09Date Released: 2023-10-13ADSP Episode 150: Is C++ Dying?CppCast Episode 367 - SoagenOxide and Friends Episode 44 - Books in the box reduxOxide and Friends PodcastBryan Cantrill on TwitterAdam Levanthal on Twitter@ahl Punching Down TweetAlexander Bandukwala Why Do You Want to Save C++ TweetHylo Programming LanguageCircle C++ CompilerCarbon Programming LanguageCppFrontADSP Episode 137: Sean Parent on Val (vs Rust)!ADSP Episode 138: Sean Parent on Val! (Part 2)Ada LanguageSmalltalk LanguagePascal LanguageZig LanguageIntro 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

A lot of the conversations are about preferring other language, so it's unclear why I agree that switching languages is difficult, but it also sounds like saving C++ is near impossible. Oh, I mean, very, very simple answer about why not only I want to save C++, but everybody should want to save C++. I'm lazy. C++ has one of the largest bodies of existing written code out there. And if C++ becomes a sunset language, over time that code is going to get harder and harder to maintain, and eventually, inevitably, large amounts of, recorded on October 9th, 2023. My name is Connor, and today with my co-host Bryce, we respond to some of the comments we got on episode 150, is C++ dying?

We chat about why C is the lingua franca of FFI target languages and more. This is great because now during the podcast I can walk around and be distracted and do all sorts of other things. I mean, we'll see. We'll see. Well, this will be a good test run. I'll let the audience know

you're testing out a new mic situation yes and it's well i'm going to explain to the audience i'm just like traveling so frequently these days going back and forth between albany and new york and then like just actually traveling on the road that i am so infrequently at my desk with my actual microphone that I just went out and bought an actual decent Rode microphone that's small that I can take when I'm traveling. Because some listeners pointed out that the audio quality of the last episode was oddly worse than the audio quality of some of our road episodes where we did have a professional. Well, just to be clear, dear listeners, the reason that we had such crispy audio quality while we were on the road is because I also have a road microphone. But that is an actual high-grade interview professional thing that you have to hold with a little stick. And that's why it sounds pretty good.

So wait, are you in albany right now um yes but it's albany it's not albany albany all right i apologize to our new yorkers i was just out when we were getting off track here already folks but i was just outside albany and uh should what and you didn't tell me i didn't know you were in albany i was in the adirondacks that's where i was was, folks. And when? Literally, I got back to, we are recording this, happy Canadian Thanksgiving. I'm only qualifying that because most of you will be confused, but it is the one and only true Thanksgiving. Also, we should respect the fact that it's also Indigenous Peoples Day, probably a more

important day. But a lot that Bryce has to say, he's trying to interrupt me, of course. But I just got back on Sunday from a, what was it, four-day conference, invitation only. And it was fantastic. It's going to lead to one of our discussion topics. But I'll let you speak because I can tell you've got some questions and some thoughts. Well, first of all, Connor, this is the second time that you have been in my vicinity and not come to visit me. And that is not okay. So the next time I see you, I am going to sew an air tag probably into your clothes.

But if you're resistant, into your skin. So that I just know where you are at all times. What you really want is to put the air tag in my carry-on, which typically goes, when I travel internationally, that typically goes with me. I did not know you were in Albany, though. It's like a, you know, several-hour drive, and I was being driven by someone else, so I did not have the ability to do a little, you know, date. I would have taken the car and come and visited you. From New York, New York? No, from Albany. Yeah yeah but i didn't know this

see this is on you i did not know you were not in new york new york and that you were in albany new york so that's on you and that's not on me i'll just share my how many air tags do you think i have i don't know i guess i have zero so i'm to guess you've got like three. I have 12 air tags. Okay. Seems unnecessary. You just missed Bryce describing all his air tags. I'll be sure to speed that up because guaranteed nobody cares.

I thought it was pretty interesting. So, I mean, I do have a topic. I've been trying to get you to schedule time time to chat with me for the past few days because I've been excited. I got an exciting thing. All right. We are going to reverse roles. Although having talked to two other people in your orbit about this same problem, both of them indicated that you almost certainly are going to immediately know the answer to this coding problem. And it's going to make all of my very human, relatable, bumbling around when you quiz me. It's just going to look, I'm just going to look

very pathetic in comparison, I think. It's okay. And I'm just gonna look very pathetic in comparison i think it's okay and i'm excited and part of the reason you know i was unavailable was because i was abroad and uh you know i was near you you know technically we could have recorded if you buddy buddy buddy going from toronto to the northeast is not abroad. I understand you crossed an international border. That is not abroad. Here, let's just check. I want to check Albany, New York. Because I was actually, I was not in the popular spots of the Adirondacks.

I was sort of in the south area, which I believe is pretty close to Albany. So let's actually check. For those that know, I was in the town of Indian Lake. It's the middle of nowhere, folks. Indian Lake, we've had podcasts on a walk, podcasts in a car. Soon we're going to be having podcasts at the top of mountains. And we could have had podcasts in a park. I have had a park pod on one of my other podcasts. Anyways, we will get straight into your problem after two recaps. So first things we want to mention is, well, I got to thank you personally bryce for your hot takes on episode 150 it uh as expected is trending very well statistically we've got uh we've got i've got

a lot of i wouldn't say a lot i've gotten an above average number of people dming me one person said and i believe that was also the episode where I trash talked another podcast. Yes, yes. And they caught wind. Also, I apologize for not knowing. This is kind of on Oxide. Do I have to be a guest on another podcast now? That hasn't been set up yet.

But I have to apologize. But this is kind of on Oxide and Friends, the podcast. They don't go around at the beginning of each podcast recording and like say their names and introduce themselves which makes sense because it's like an open discussion which is why i don't really know the names of the characters but the person specifically that was talking with brian cantrell his name is adam leventhal i hope i'm pronouncing that correctly and he's at ahl on twitter for folks that want to go check him out is is he the one that i, uh, yes, yes. I'm sorry, man. I'm sorry. So, you know, we got a couple of people that I didn't add Adam or Brian in the tweet about the podcast, but then a couple of people in the comments added him. And then he ended up, uh, retweeting saying that it wasn't

very nice. I'm pretty sure he was being sarcastic because he made a joke about like, you're punching down, man. We don't even have a podcast intro jingle. So I'm pretty sure he was it was all in good fun. But we had one person DM me saying that they were pretty sure this was the end for them and they had to stop listening. Listen, folks, if you if you need to stop listening, feel free to just stop listening and not let us know. Like, we're not going to change anything because you may or may not be be upset by what we said wait wait what what was their what was their uh what was their objection would you like me i won't reveal them by name uh but i know we actually don't know is it somebody i know no no i don't think so okay but oh i'm actually going to need to go

to the adsp twitter which requires me opening up Firefox because that's the only thing I use Firefox for, for folks, is not having to switch Twitter accounts on the website. I just, I keep my Firefox logged in to the ADSP Twitter account. You know, there's like on the phone, there's a very simple...

It's easy to do it on the phone. It's almost as easy to do it on the computer. But here, this is the DM that I got from an individual that might not be listening to episode 151. And they have actually messaged me in the past. Now, if they went through the trouble to send a DM, they're still listening. They're not going to be after this one. And this person in the past, they've messaged me multiple times complaining about your interrupting either guests or me. And then I've been trying to console them being like, don't worry.

I'm trying to keep them in line. But he's entertaining. He may ruffle your feathers, but it's kind of like being a character. Whether you tune in because you don't like them or you tune in because you do like them you want to tune in i'm definitely the bad guy of this podcast anyways this is uh this individual uh who won't be named and they write wow this latest episode is so disappointing i am 17 minutes in and i think it's the last straw for me. I feel, it feels so conservative to not listen to outside opinions, discard criticism, and almost attack a stranger for their opinions. And that's all they wrote, folks.

I didn't reply, because what do you say to that? How much do you have a response, Bryce? I do think that if you listen to what I was saying, I was not rejecting outside criticism. I think I acknowledged and in fact agreed with the basic premise of what they were saying. I just disliked the way it was being expressed and felt that they were viewing C++ through a lens of like the early 2000s. Yep, fair. I mean, I think there were some spicy takes, some spicy back and forth, but honestly, I think it's all in good fun. And like I think I even said, mid-podcast, hot takes are great. You know? Nobody wants to hear a boring monotonous well, you know, it's nuanced back and forth.

It's good to have hot takes. We did also, I wasn't going to mention this, but we did get a comment from this one was a comment, so it wasn't a DM, so I can mention their name. Hopefully I'm going to pronounce this correctly, but if not, I apologize. Alexander Banduquala.

And they wrote, would love an episode. We don't, it's not going to be this one, although we might get some brief comments if they're, you know, constrained to less than 60 seconds from Bryce, about why you want to save C++. A lot of the conversations are about preferring other language. So it's unclear why I agree that switching languages is difficult, but it also sounds like saving C++ is near impossible. Oh, I mean, very, very simple answer about why not only I want to save C++, but everybody should want to save C++. I'm lazy. And I hope everybody else is lazy too. C++ has one of the largest bodies of existing written code out there. And if C++ has one of the largest bodies of existing written code out there. And if C++ becomes a sunset language, over time that code is going to get harder and harder to maintain.

And eventually, inevitably, large amounts of that code will have to be rewritten entirely in a different language. And there's just no world in which that migration does not come with a grave cost. And I don't want to pay that cost. I would like the world to be able to continue using C++ code for the next 50, 60 years and have it be a healthy part of the ecosystem. I'm not saying that every new project should be written in C++. I think there are some that should be. But I don't want the existing body of code to have to be rewritten or replaced because that, uh, if we do that only because if we have to do that solely because the C plus plus language,

um, has become stagnant, uh, that would be a huge waste. Um, and I, you know, you get,

you, you, you, a lot of people get excited about like rewriting a project from scratch, like starting over. Oh, we can do everything right this time. Oh, I don't want to do that. That just sounds like a lot of work. And I would much rather work smart than hard.

And I think it's really good to be lazy in this field and to not reinvent the wheel. So, you know, that's why I think we should want to save C++. Because like it's here today, we have a ton of code written in it. And that code is important. Yeah. And your answer kind of highlights why three of the four main successor initiatives, although I guess you might not consider Circle a successor initiative, but it's always listed in the list. Three of them are trying to maintain a very good story for backwards compatibility.

CPP front, basically you can just, you know, CPP2 just, or CPP front compiles to C++, everything works. Carbon has like a first class story for trying to interop and they're trying to build tools for where it won't work. And Circle is just a advanced C++ state-of-the-art compiler. I think Val, which also we got another comment. Ooh, let's bring up my LinkedIn because I'll mention them by name as well,

except I need to switch back to Chrome now. So I don't need to sign in. I got a comment that was, you mentioned Val, and it's no longer called Val. We need to start calling it by its real name. This was Chris Van Rens, I believe. Yes. And the new name for it is Hilo. So we're going to trip up and call it Val. And I thought about going back and renaming our episodes, because while we were talking with Sean Perrin when we were in Folkestone in the UK for CPP on C, it was still named Val. But then by the time I think some of those episodes came out or right after it got renamed to Hilo, we're leaving it as Val back there. But going forward, we will try to call it Hilo. But Hilo is really of the four of those initiatives, Circle, CPP Front,

and Carbon. Hilo is the only one that isn't trying to prioritize backwards compatible. And I still think they are trying to have some kind of story, like they'll have a, you know, maybe a from C++ to Hilo, you know, documentation, but the other three are all, all have really good stories. And a part of, and honestly, I'm not, I'm not sure if that's – part of me thinks that's a great idea to not focus on the backwards compatibility. The reason being it's real hard to be compatible with C++. Part of me thinks if you don't focus on it from the start of the language, it'll never happen. But if you do focus on it from the start of the language, then'll never happen um but like if you do focus on it from the start of the language then it it may consume your entire effort um and uh there's a relevant story that i

that i tell ramona all the time um uh and i'm gonna tell it but I think Connor's going to speed it up. Well, we have to decide, uh, are we going to try is, is, do you want your algorithm question to be a separate episode or are we going to try and squeeze it into the end of this discussion? I don't know. I'm going to let you make that decision. How long do you think it's going to take? 10 minutes? 15? 30? Oh. 15, 30 minutes. You know what?

We're going to skip the Bryce story. Okay, we'll skip the Bryce story. I can be irresponsible. But actually, what we're just talking about here brings up an interesting question which I've never, I think, thought about deeply before, but I think is something that both of us know to be true,

which is C, C++ is a really poor interface language. And by that, I mean it is a poor language to be used as a medium for other languages to interoperate with. Now, C, on the other hand, is freaking great. C

is the de facto ABI language. If you want to have two different languages or libraries or things interact, language. Like if you want to write a library, if you want to have two different, you know, languages or libraries or things interact, you define a C API reasons for this. One, the nature of C means that you have less stuff boil up into the API that has a platform-specific ABI nature to it. And I guess also less of the type system is exposed. What else is it that makes C a better interface language

than C++? What do you think? I mean, I think we know this to be true, right? Yes. I mean, it is the lingua franca of FFI and like almost any language that builds an FFI, it's to target C. I don't actually know.

And if you look at like ways of like interfacing between like C++ and Python, like they're, at least the last time I did anything in that space, they're all horrific. And I'm just going to assume that they're, you know, if they're at least last time i did anything in that space they're all horrific and i'm just going to assume that they're you know if they're better today they might be a little bit better but they're still probably pretty horrific yeah and i'm not a i'm sure there's you know 10 of our listeners are better people to ask for the answer but like in my mental model c is a much simpler

language that doesn't necessarily simplicity is what. That doesn't necessarily... Simplicity is one. Yeah, it doesn't necessarily mean it's a better language, but it is much simpler. Like there's no facilities for, you know, generics or an equivalent of templates. And also the evolution of C, although it is ongoing and they are adding things and there is a C committee that is active,

I think they are much, much more conservative in the language changes that they make. And that leads to a much more stable target for an FFI in terms of like, if it's something is getting updated, you know, every three years with a bunch of new language changes in terms of like lambdas and stuff like that, then you, you're going to have people saying, oh, you know, I want to be able to target this library that uses X, but I can't do that now because the FFI capabilities of the language that I'm using doesn't support the new C11 standard or something like that.

Whether or not that's actually the right answer, I don't actually know, but in my head, that's what it is. My gut reaction was simplicity too but i i suspect that there's something deeper there because there are other languages that are simple right um i mean perhaps perhaps part of it is c's dominance in systems programming for so long that um because it was a simple language and because it was the language that platform APIs tend to be written in terms of pretty much every language had to interface with it. And so it just sort of became the de facto standard. And maybe simplicity isn't really why it won as the lingua franca, as you said.

But maybe it was just early market dominance. Certainly, I think if we talk about why C++ is not a good interface language, the answer is lack of simplicity. C++ has a fairly complex type system and template system. And that type system gets exposed directly in the spelling of symbols, in functions and in types that other languages would have to interface with yeah and like to interface to a c++ object you have to you know you have to deal with polymorphism um with c++ way of doing polymorphism to to interface with uh c++ uh functions um uh or rather to interface with what we in the c++ world would see as a function,

which may include multiple different overloads of the same name. You know, if you're in a language that doesn't have a notion of overloading, each one of those may be a different function. And if you're in a language that does have some notion of overloading, then you still, like, your notion of overloading may be different than C++'s notion of overloading. And so it's, like, if you look at it as a simpler question, it's like, what is a function?

In C is a very simple, straightforward answer. C++, I would argue, does not have a simple, straightforward answer to that. Because what we as C++ programmers think of as a function might actually be really a function template or an overloaded function that boils down to multiple different actual function entry points in the binary ABI representation that other languages would have to interface with.

So certainly lack of simplicity is why c++ is not the lingua franca um but is simplicity really the key thing that makes c the lingua franca perhaps it's the nature of the c type system where you have these sort of fuzzy sized types um maybe it's um i think i think what you said earlier is a huge component of it, though. Like C has a 50 year head start. And maybe a language like Zig is actually a better language to target as an FFI target. But Zig is created in the last 10 years. And there's not like, I don't know what the number of libraries that are designed in C or system libraries that were designed either because they were designed decades ago, or they were recently designed, but they wanted to be good targets for FFI. So it's just like, because it's what is it like the rich gets richer, like they had a 50 year head start. And there are probably languages out there or languages that could be designed that would be better targets, but they don't have a 50 year head start. And they don't have the ecosystem of languages? The answer here really may be not to compare C to contemporary languages, but really to ask ourselves, if we turn the clock back, we go back to the 70s,

what really made C successful compared to its contemporary languages? And specifically, what made it successful as the systems programming language. And this is not a question that is an unknown question. It's been talked about, perhaps even talked about to death in other podcasts, other literature, other mediums. I mean, but wait, though, what were the other systems languages at the time? I don't know. I personally, I have no idea.

I don't know i personally i have no idea i don't know either i mean i the only one i can think of is ada and i actually don't know what year that was created and i can i can rattle you off a bunch of other popular languages from the 70s and 80s like small talk and pascal and etc but like none of those were systems languages ada and small talk um or sorry yeah adam and small talk um i think let's talk about those briefly um because i think they have some similarities there ada and small talk um in comparison to c okay i mean like they're very dissimilar languages though correct i don't know yeah but. Yeah, but in terms of level of complexity. Okay. They both have an object model. I know Ada does now. Did it back in the day?

I know very little about Ada other than it's one of the very few languages that has fixed point and bounded integer types as a part of their type system. I mean, Smalltop certainly was an object-oriented language from the start, right? Yes. I mean, it is. Okay. I'm fairly certain, just based on the first sentence of the Ada wiki, that it's also an object-oriented programming language from the start. Okay.

Is Pascal an object-oriented programming language from the start. Okay. Is Pascal an object-oriented language? I don't know much about Pascal, other than it was one of Wirth's languages. Because isn't there object Pascal, which was a later derivative of it, specifically for object-oriented programming? Maybe. I know that Pascal led to Delphi or Delphi.

Right. So I would say that the reason that Ada and Smalltalk probably didn't succeed as Lengua Franca. Wait, wait, wait. I got to clear this up. Is the same reason that C++ fails in comparison to C, which is that they're substantially more complex languages. And in particular, they're languages with object model um and figuring out how to uh interface to objects is harder than figuring

out how to interface to simple structs and functions there's a there's a couple uh listeners that are like screaming in their heads right now because you've misunderstood what i what i said i i was rattling off a couple popular languages that would never have been the lingua franca ffi target because they're not systems like uh small talk is like a totally gc'd not the most performant message passing system that uh lives in like a workspace similar to apl that like you don't have like written text you have like workspaces that you load and so and like you can only develop in small talk in like a specific ide that's built for the language like it it would be impossible you know and i get that and i was confused where you were listening at but ada is different so yeah ada is that's but

that was the only so i said the the only systems language that i know that might be a contender uh would be ada but like all the other languages i know wouldn't be contenders because i i don't think like a gc you know i think i think I think Pascal's actually, I think the question is really why did, because Pascal is the contemporary of C, right? I think the question is like why C, not Pascal? I mean, Pascal wasn't very popular. Like Pascal. Yeah, but why not? I mean, I'm not an expert in Pascal.

We'd have to have someone on. But like the high level things that I know about Pascal or that is that it was taught a lot in schools. There were a bunch of people that really liked it. But at the end of day, from like a programming language theory point of view, like they introduced a lot of interesting concepts that then other languages adopted.

But like it had these fatal flaws that made it very difficult to like build large scale programs and like really be productive in. What those are, I do not know. If you are a Pascal person, feel free to leave a comment on Twitter or a comment on our GitHub discussion in the podcast notes. But I just know that like Pascal was an interesting language. It had a certain in its heyday, a modicum of success. But no one was really surprised at the end of the day when it didn't like when it didn't like thrive. I think I could be wrong.

I'm sort of, like I said, high level from what I know. Pascal is a language I know very little about compared to small talk. Wow. I'm like at risk of offending some more of the listener. We've got to have some old person on here to teach us some things about, about the history of sea.

Sure. I mean, we got to have a lot of folks on. I mean, we got a couple of comments that said you have to get Brian Cantrell on as like fast as possible. So I don't think Brian listens to this, but we will reach out to Brian. I mean, we've, I think we have a list of folks that we I mean, we still have a long list of folks from when we talked to this, but we will reach out to Brian. I mean, we've, I think we have a list of folks that we, uh, I mean, we still have a long list of folks from when we talked to, um, Jane, which was the start and then very quick end of our, us becoming a rust podcast. Um, but we were supposed to have a bunch of folks on Esteban who worked a lot on the error messages.

We were supposed to have JT on to talk about, you know, the working on the community aspect of Rust and why it became super successful. Anyways, lots of folks. And we will also have someone who is a C expert and a C... I was thinking about this. Is veteran a word that you should not be using? Because I referred to... In a couple talks, I said that I referred to APL people that I chatted with as these APL veterans. And in hindsight, I was like, I probably should have just said experts. But I'm not sure. Is it on a list of words or is it okay to say veteran? It's not on the list of words that I worked on the Insights in Christian Terminology list. However, there are words in that list that are words that are recommended avoiding

because they were military jargon or they had a military connotation. I generally think that it's best to avoid words that have any sort of military or war connotation if you can. I know that there are some people that are bothered by it. The nice thing about the word veteran is I actually think it encapsulates a certain amount of respect because you're trying to say not only are you an expert, but you're an expert that has been doing this for a long time. So it's both like experience and expertise. And I don't know, like expert covers

60% of that. I don't think anyone is going to be like, oh, you're just calling me an expert. I would prefer you point out that I've been doing this for decades. But anyways, yeah, probably best to... I would avoid the term veteran because it does have a military connotation. However, I did take two years of college Latin and I learned very little, but very, very little. I took Latin in college because I figured it's a dead language. They can't make you speak it. Like they would make you write it, but I was like, they can't make me speak it. And I'm terrible at pronouncing things.

I was wrong. They made me try to pronounce Latin. uh latin um i'm pretty certain that veteran comes from the latin uh the turn is the turner is something like that which is uh which means like old um uh like experienced and does not have a specific military connotation i think the origin of the word doesn't have that but since then you know culturally we we you say veteran um uh you assume that people mean uh people hear a military connotation to it so that's why we should avoid i mean i now and right after i said you know it doesn't capture the experience part um only the expert part by saying expert i, you know what I could just say? Experienced experts. That works just fine. So anyways, we got to wrap up our last, stay tuned, our few episodes.

There is one more thing. So we only are at point one of two points that we needed to bring up before we were to get to Bryce's algorithm. But we're at the halfway point. And we need to record two more episodes tonight because Bryce is excited about something, but I'm also excited about something. Anyways, the other thing I want to mention before we get to episode 152 is that we had someone reach out on GitHub, if I can bring up that issue. And because we're short on time, I am not going to read the whole thing. But basically, it was a response to episode 149 where we were talking about my City Strides root generation algorithm. And the GitHub user's name is CarString.

Let's see, if I click on this, it does have the name. The name is Chris Wesseling and they are in Amsterdam. I think actually Chris might follow me on Strava. I could be wrong about that. But I think these are the same person even though I have not made that connection. And he points out a bunch of stuff about graph theory and some optimizations.

And I've also had a couple different comments from a couple different people that I know that all had some great suggestions, some about pruning, some about annealing, some about ASTAR algorithms. We will revisit the CityStride graph algorithm in the future. But the thing that I wanted to bring up is that I don't think I articulated well some of the specifics of the challenge

that I was solving, which led people to be kind of confused. And one of the things that I should have mentioned is when you brought up weights, I should have said that I don solving, which led people to be kind of confused. And one of the things that I should have mentioned is when you brought up weights, I should have said that, like, I don't want weights. Because weights, not only do they not help, they hurt. Because a street in this graph, one edge does not represent one street. Streets are represented by multiple edges.

So you can have... it's are all edges equidistant no they all have different lengths then you want weights no let me finish my point so all i care about in my well i care about multiple things but the goal is to complete streets completing a partial street is worth nothing I do not want weights and some algorithm that rewards me for completing segments of a street or parts of a street. And also, too, you might be thinking, well, if you're completing part of a street, that's still getting you towards completing that street in the future. And the answer to that is not optimally necessarily. There are some streets... Go ahead. What do you want to say? But if it gives you a routing where... I'm gonna cut all this out probably the point is I uh this problem has been not as well articulated

anyways we'll revisit the problem I will articulate it better the point is this problem has been not as well articulated. Anyways, we'll revisit the problem. I will articulate it better. The point is weighted edges, not a great idea. Be sure to check these show notes either in your podcast app or at ADSPthepodcast.com for links to anything we mentioned in today's episode, as well as a link to a GitHub discussion where you can leave comments, thoughts, and questions.

Thanks for listening. We hope you enjoyed and have a great day. Low quality, high quantity. That is the tagline of our podcast. That's not the tagline. Our tagline is chaos with sprinkles of information.