Programming Throwdown - Kotlin

Episode Date: March 3, 2021

We’re having a duo episode for this month! Patrick and I discuss the relevance of Kotlin, a JVM language used for web backends and android development, and why you should look into it. Also we are testing out adding transcripts to the show notes. Let us know what you think! Show notes: https://www.programmingthrowdown.com/2021/03/episode-108-kotlin.html ★ Support this podcast on Patreon ★

programming throwdown episode 108 Kotlin take it away Jason hey everybody super excited to do a duo episode. We've done many interview episodes with the two of us and one or more guests. We've had so many of those. And we have so many really exciting interviews coming in the future. But this was a time where we really wanted to do a duo episode.

And super excited to talk about Kotlin. So it's an OG style. Yeah, that's right. It's an OG episode. Yeah, hopefully we'll have more time to do these in the future. We are looking at ways that we can be more productive and get out more episodes. There's definitely, we've had a lot of really exciting requests. Actually, Kotlin is a request. So thank you so much for requesting kotlin i think it's a great suggestion we've had requests you know believe it or not we've never done ada and that really surprised me so yeah we had a request for ada come in

recently we've had a whole litany of requests and um and we do take those super seriously we love to do them and this is an opportunity to fulfill one of those. And I'm hoping we can do more of our OG shows along with our awesome interviews in the future. So I think if we were like one of those cool YouTube channels, we would claim we got an intern who did all this for us. Yeah, exactly. Yeah, we need an intern.

Try to come up with an imaginary name for them. And then, okay, anyways. Yeah, we should definitely have... a lot of interns are sven for whatever reason there's uh two of the podcasts i follow have interns named sven so that i think that's that's what the intern name has to be okay fair enough all right so if your name is sven reach us at programmingthrowdown at gmail.com so yeah i wanted to to talk a little bit in our intro topic on this thing called the gold standard. As most people know, I'm really into economics. I'm not so much into investing and those kinds of things. This isn't investment advice or anything like

that, but just the economics and just how money was invented and how people exchange things. And all of that, I think is super, super interesting. We've talked about it on past shows. And so on the perimeter of that is this idea called the gold standard, which is really interesting. It's this idea that you could, that all the money was backed by gold And you could literally take a $100 bill, go to a bank or go to a government institution, and they would give you a chunk of gold for it. And that that exchange was fixed. So in other words, the price of gold didn't change. The money is the gold. And so at any time, you could go from gold to money and back at a certain amount that was fixed. And yeah, I think that whole thing is really,

really interesting. And it really, it kind of blows your mind when you think about, you know, what would they call now fiat currency, which means that, you know, the government kind of forces everyone to use the same type of currency. And just that forcing function is what gives the currency its value. I always thought one of the interesting parts about the like, I guess, commodity backed money was and maybe it's an extreme thing is what would happen if someone would have found like in a giant deposit of gold somewhere, or, you know, let's talk about like mining an asteroid.

And all of a sudden you like 10x the amount of gold available. All of a sudden you would have, you know, now people with fiat always worry about inflation, which is very real concern. And I don't know if that gets into a little bit of a touchy topic. But I mean, I guess like when, where America now is, the USA is like, I mean, there was a lot of gold here. And so the amount of gold sort of available in the world went up dramatically.

And a lot of the motivation for coming here was people trying to find gold. I always thought it was interesting that in one way, like you point out $1 equals some amount of gold, call it one ounce, it wasn't maybe $100 was an ounce. Sure. You know, some amounts that fixed exchange rate, but in practice, like the amount of gold is always changing and the government doesn't have direct control over the amount of gold in circulation. Yeah, it's wild. I also actually, I'm really glad you brought that up. That was the first thing I thought of too.

And this is what I think. And I've talked to a bunch of people about this and heard a bunch of different opinions. But my take on it is, yeah, if an asteroid full of gold was to strike the Earth, what would happen is the price of everything else would go down, I think, because there would be a lot more gold. Oh, no, no, sorry. No, the other way around. The price of everything else would go up because there would be a lot more gold.

Gold will be less valuable. That's right. And that would make the dollar less valuable. You'd get inflation. You'd need more dollars to buy everything else. Yeah. And similarly, gold is used to make circuit boards. And so when the circuit board became a commodity, at that point, the price of everything would go down because people

needed the gold for something else that they didn't before deflation okay yes it's kind of wild to think about it's like oh this person invented the circuit board and that means like the price of milk has to go down the price of everything has to go down yeah i feel also like governments being able to change money like is in some ways like good and bad. Like if they were trustworthy, I guess it'd be really good. And the reason for saying they're bad is mostly at least from my reading is if you believe sort of like the people running government can't be at some deep level trusted. And so you don't have a trustless money system if you have fiat currency, because the government can just declare what the value of the piece of paper is at any time by printing more, or, you know, I guess taking it away. And there's always printing, I guess it can be now just like a database entry in, you know, in big banks or from the Treasury or whatever,

it doesn't have to actually be the classic, I guess, whatever the meme of the money printer going off. Like it can literally just be like a change of a value in a spreadsheet somewhere. Yeah, yeah, it's so true. Yeah, I think, yeah. So, you know, I think the gold standard has some serious issues.

And it's a lot of the things we talked about that, you know, people would find gold out West and then that would cause prices of everything, all these like nth order effects to happen and prices of everything to go out of whack. Also, the government would hedge so they wouldn't actually have enough gold for every dollar in circulation. They would actually take risks on the standard itself. And so then when there was the Great Depression, I think this is actually what killed the gold standard. And I'm not a history buff, but this is just from reading this one page, that there was basically a bank rush for people to exchange their dollars for gold.

And there just wasn't enough gold for people to do that exchange because the government wasn't really planning on that. And then that caused all sorts of other issues. Oh, man, we're going to get into fractional reserve banking and what problems there are with that. This is going to go deep. I don't think we're ready for this. Yeah, I think maybe we'll put a bookmark in it. But I just thought the idea of the gold standard was really interesting. This idea that... And actually, when we talked about this kind of economic stuff, maybe a year or so ago, I had built this little simulation. And in the simulation, I couldn't really get things to converge in a meaningful way

and um i actually went back to that simulation you know it's awesome that that we have github nowadays and i could just do that i went back to the simulation and i just fixed the price of one thing and then that made everything everything else so much more stable and it kind of makes sense like like if you think about it, fiat currency, there's really nothing preventing the government from just multiplying everything by 10 or dividing or decimating everything. And, and so in this simulation, which, you know, was, was, you know, very simple, you know, that that's basically what happened is things were just wildly out of control, but then like pegging the currency to any of the one items caused everything else to become stable. And yeah, so that was actually pretty eye opening.

And yeah, I mean, we'll have to see what happens with, you know, our episode one topic, you know, Bitcoin and all of that and where all of that goes. I know it's going to be a wild ride. Definitely no investment advice, but I'm just curious to see what's going to happen. Yeah. I mean, this conversation is something that with sort of countries the world over trying to understand how to economically stabilize their economies in the face of all the fallout from COVID has been very interesting to see that everybody's different take on whether what they're doing is a good thing, a bad thing, whether it's ruining the future, or whether the future has been saved because of these actions. It's really hard to know because it takes so long to figure

out. And in the meantime, you get so many other policies that impact what gets decided and what gets done now. So you're never doing this, like only change one variable at a time. It's like some very sophisticated running simulation where there are winners and losers, except that it's people's lives and welfare. Yeah, yeah, exactly. There's no counterfactuals. It's really hard to run an A B test. Maybe like at the country level you can, but even then. So onto the news to take a hard pivot. My pivot. My first news item was a little bit ago, the Raspberry Pi, I guess it's the foundation? The Raspberry Pi people released the Raspberry Pi Pico. So most Raspberry Pis before this,

which I think there's been, I think they're up to like fourth version, and then there's several variants along those. They've all been about running linux and being a full sort of almost like a computer like a mini computer right you they have video output they have sound output it's really meant to be a very sophisticated system on a board a single board computer i guess is the the term you would use yeah i mean i bought a k kvi yeah kvi. And I have my Raspberry Pi on

my desk. And I switched to it every now and then. And yeah, it's like a full desktop. Oh, KVM, KVM, KVM. Yeah, yeah, right. Yeah. So I mean, those Raspberry Pis have always been that. So to me, this is like a very surprise announcement that basically, they would be coming out with something more in the realm of what you traditionally have been talking about as an Arduino, which is a sort of microcontroller, they are putting an ARM core on their own silicon, which I guess maybe people don't know, but you hear about this ARM processor, that ARM processor. So ARM basically sells what you can think of, I guess, like as a program or an executable that runs on silicon or on an FPGA that executes computer instructions. And so you can buy that yourself, and then plug in various modules for what they call peripherals,

like doing USB, doing PCIe, doing HDMI, you can buy other pieces of things that go into your, you know, either FPGA, or if you're going to make your own chip, your own silicon, they call an ASIC. And you can buy from ARM a license for one of these cores for running instructions. And you can put it on your own chip with whatever else you want and kind of make your own thing. And that's what Raspberry Pi has done and made these. And they put a couple cool peripherals for sort of in hardware implementing finite state machines that the first people are just now getting their hands on. And I'm very interested to see what will happen. But this space is kind of converging because before you had sort of Raspberry Pi for single board computers, Arduino for sort of microcontroller

oriented things. But now there's crossover. And I even saw a news article recently, where like Arduino is going to make a board that has the Raspberry Pi Pico on it. So Oh, nice. And it get very confusing for telling people what to use. But that's pretty cool. And Raspberry Pi and Arduino both have been a huge boon to people doing embedded development, not necessarily like for work or industrial purposes, but for hobbyists, especially, because the ability, which I need a formal name for the metric, but basically the ability to type into Google a question about what you're trying to solve

and having real good answers come back has been very good with Raspberry Pi and Arduino, much better than anything ever before. So the amount of support, the adoption, the amount of users behind it. So if they can do the same thing with the Pico, it could be really transformative to the hobbyist microcontroller market.

Yeah, and the prices have been just absolutely astonishing. Like the Raspberry Pi was something like $30, maybe even $15 at one point. And the Pico is $4 for a microcontroller that has like, you know, a pretty good developer interface. Yeah, it's amazing. for for halloween we used uh an arduino to make a uh a little halloween thing that jumped out and and kind of scared people when they reached in to get candy and it was a blast i think uh it actually it really scared kids because especially at night you know because because it was made by hand which is you know plywood and some hobbywood you know no one was expecting it to move and And then when it moved, they didn't really know what was going to happen next because, you know, it obviously wasn't something you just got from home Depot.

Right. So it just moved in this really awkward way and, uh, it, it legit scared, scared people in the neighborhood. So, and, and yeah, that was only possible through a lot of Googling, uh, buying things on Amazon and setting things on fire. Oh, wait, what? Yeah, the magic smoke. So yeah, this stuff's amazing. I'm glad it's reaching more people. My news is Kubernetes dropping Docker shim.

So this is a really, really interesting story. Most people are familiar with Docker. Actually, if we haven't done it, we should probably dedicate a whole show to Docker and containers. But just a high level, Docker is a way to kind of package up, let's say, installing an OS and then running a bunch of commands on it. So let's say, imagine you install Ubuntu on a machine and then you install MongoDB and you configure it. And let's say you need to do that many, many times. You could use what's called a Docker file to describe that process. And then you can create what's called a container, which is like a virtual operating system that sits on top of something called ContainerD or ContainerDaemon. And so the idea is you can kind of take these

modules and you can run them in the cloud, on your computer, you know, on a Raspberry Pi. And it's just kind of self-contained like that. So Docker really popularized this. I mean, there was, you know, chroot before, which did a decent job of this, as long as you're staying kind of in the Unix world. But Docker kind of, you know, brought it to everybody. You can run Docker on Mac, you can run Docker on Windows, you can have a Linux, you know, OS container running on Windows, and it just works. You can actually share folders. so you can you know have shared content between your actual os and the docker os and so on and so forth but the docker business story is not as like exciting or not as not as not as nice so you know docker started

getting into this thing which they call docker swarm, which was, you know, imagine you have a database and a web, you know, backend, and you have a load balancer, and they're all meant to work together, right? The load balancer points people to one of many web backends, and the web backends points to one of many of shards of this database, right? So all of those need to communicate to each other. And if they're all kind of containers, and especially if you're running in the public cloud where the cloud is turning them on and off or migrating them, it's not obvious how you're going to make all of that communication happen. And so Docker Swarm was a way to do that. It was, it was a service registry where you would

say like, Hey, I, you know, I'm, I'm a database container and the service registry registry would say, Oh, okay. Yeah. I've seen 10 of you before you're number 11. And then the website would say, Oh, I need to connect to the database. Um, you know, Docker, uh, swarm, tell me, you know, where, where my database is and it will, it,, you know, where my database is, and it will, it had a load balancer inside of it. And it would it would take care of all that for you. Right. So, you know, the interesting thing here is this, this new thing came out called Kubernetes. And it was almost equivalent. And I mean, I'm not an expert here. So I'm sure there's features that one has the other hasn't. But but in spirit, you know, it's the same as Docker swarm.. And it just had a way, way better developer experience. And it kind of just kind of eclipsed Docker.

And this is really, you know, and so Docker shim was kind of like, you know, Kubernetes was kind of playing nice at a lot of parts of Docker. And Docker shim was a way to kind of make that all happen. And that's getting getting deprecated. So it's kind of the nail in the coffin for for Docker. Now, if you're if you're creating a Docker image, Docker container, that's actually using an open source format. So you can always use Docker to make containers and then run them on Kubernetes because it's a shared format. But, you know, Docker as, let's say, as a business, you know, really kind of got the legs pulled out from under them. And I just thought that was a little bit sad. little message of warning for, for people who, uh, who wants to start new things that you really

have to have something that you can kind of charge for or something that's, that's kind of unique. Otherwise, uh, yeah, it's kind of a, kind of a tale of warning to folks out there. I feel that plays in a little bit, which we don't have here, but the elastic search thing as well with AWS, where AWS was running instances of Elasticsearch. And so people weren't using Elasticsearch's hosted service anymore. And so it's forced Elasticsearch into changing their license structure.

I mean, I think these things are just really hard. Like, it's really good that people want to do open source, and open source is awesome. But yeah, it's a fine balancing game. And it's really hard to know what's going to happen over the course of years. So just actually just to put a bookmark in this, this actually won't change anything. If you're someone who uses Docker on Kubernetes, unless you use the swarm parts of

Docker, like the load balancing, some of the really advanced stuff, or you have some really advanced node configuration that's specific to Docker, you know, most people probably don't even realize this, but but they're actually building these open standard containers that that aren't even really like a Docker specific thing anymore when they're done. And so this shouldn't actually affect 90% of people out there. But I just thought it was an interesting story. My next new story continues on stuff adjacent to open source, and that is GitHub one s. So there's a couple interesting angles from this. But basically, it turns out, I guess it was Microsoft added the ability to type one s to the end of GitHub for any GitHub repository and get a version of Visual Studio Code

open in your browser in under a second where you can browse the repository as if it was checked out locally with your version, like with VS Code pointed at it. And so you can browse using VS Code browser. You can look at the code that way and the styling and all of that in your web browser. That's two uses of the word

browser. I guess that's confusing. In your web browser, you can have the file browser of VS Code and the VS Code editor look for a random GitHub repo. If you went to github.com slash jetbrains slash kotlin, because that's what we're talking

about today, and you would see normally the GitHub interface, you would see like at the top there, like GitHub, you know, file directory list. And then at the bottom, you would see like a rendering of the readme.md. Instead, if you did GitHub 1s dot com slash JetBrains slash Kotlin, you get an instance of VS Code, Microsoft's Visual Studio Code Editor, with the files on the left hand side and editing view of the readme.md on the right hand side. And so then you can just browse through it's just like a super cool use of like, the fact that Visual Studio Code is itself

JavaScript to come run in your browser. And that GitHub has the APIs that you can hook into and call this way. It also points out how horrible GitHub's file browsing was and how awesome it is to be able to do this. Like it's so much easier to browse random repos this way. Yeah, do you know if you can edit a file and create a pull request? I saw some stuff about it, but I didn't look into it because that's not sort of the normal thing I kind of do. But I did see that there were some people commenting about doing that workflow. So I think there is a workflow there, but I don't know what it is. And the other thing is, I feel I feel like it's only a matter of time. So apparently,

there's also an internal thing in GitHub that's starting to roll out called workspaces. That's for doing this kind of thing, like basically doing all your editing in the browser, in the web browser, but it's not fully rolled out yet. And then also, like, doing all your editing in the browser, in the web browser, but it's not fully rolled out yet. And then also, like, unfortunately, this doesn't work for like internal enterprise instances of GitHub. But one of the things that I found interesting is there's a disclaimer at the bottom, if you do this, go github1s.com slash some repository that says this is not an officially supported thing. But then I realized, wait a second, like, maybe it's not

from microsoft but visual studio code is a microsoft product microsoft bought github like i'm not clear uh what makes it an authorized thing unless it's not being done by microsoft so oh yeah that was my that was my impression was that someone just some did this as a hobby and oh maybe it is maybe it's not being done by microsoft then but it is kind of a cool use of the various technologies and smooshing them together in an interesting way and really does point out that like oh it is some random person and it's not microsoft okay that does explain it yeah it's still awesome super cool like why we didn't do this before why this wasn't like a thing i have no idea but like for now on like anytime you end up on a you know random public github repo like just add that one s and enjoy being able to uh

browse it much more conveniently yeah this is amazing yeah i'm gonna use this yeah definitely every day i mean this is something that we do all the time is look at open source implementations of different stuff and this And this is so cool. Cool. All right. My next show topic is algorithms for decision making, which is a free book that you can download. And a lot of people don't know a lot about decision making. decision-making. So when they think about machine learning, they think about classifying dogs and cats and the house example, like figuring out the price of a house and a lot of these supervised

learning things, which are awesome. They're definitely really powerful. But a lot of people don't have exposure to decision-making. And so they might think, well, if I use supervised learning to predict all the outcomes of a decision, and then I can just have a for loop or something and pick the best one. And the problem is that doesn't actually work because the algorithms that you're using to forecast are themselves, you know, the data that's driving those forecasts came from some other decision making system. So and so there's there's error and there's bias in those. Like, for example, you know, on YouTube, it could be that the if you search for a certain query, like you search for, let's say, funny, you know, the top 10 videos that come up, people will be more likely to click on those than the 11th video, which is, you know, you have to click on next

page to get to. And so, and so a naive system might say, well, those 10 videos are just funnier than the 11th video, right? But it's, it's not taking into account that sort of bias that was induced by the UI, right? So, and that's, you know, that's, that's, you know, kind of one example, but there's many other examples where decision making is really kind of like its own field. And I really thought this book did a good job of, you know, covering the different areas. And, you know, kind of going into detail talking a little bit about kind of theoretical, like, oh, if you have this really simple example where there's two variables and a decision, then how can you sort of completely solve that? And then getting into like the more practical

examples and all the sort of approximations and all the things that you have to do there. But yeah, I thought this was really well written and definitely check it out and let us know what you think. So I have to make a decision about whether or not to get this? Yeah, that's right. Yeah, so you should do Epsilon Greedy. You should flip a coin.

And if it's heads, you should read the entire book. And if it's tails, you should still read the entire book. Well, it has a release date of 2022. And the guy, one of the author's names is Wheeler so i like this i'm into this all right it's it's a good start i have to admit i'm a little bit biased i mean this is my area but uh um but i i thought it was a really well done book time for book of the show book of the show. Book of the show. My book of the show is Anti-Fragile. Anti-Fragile is a book, and I actually forgot the author's name.

I'll have to look that up. Nassim Tlaib. Nassim Tlaib, thank you. And Anti-Fragile is a really interesting premise. I have to admit, I didn't read the entire book. The book is actually, it's three books in one. And in the beginning, in the preamble, Nassim talks about how it's three books and the publisher wanted him to release three books and he just released one and so on and so forth. But it's a very, very,

very long book. There's a lot of really great content. But the premise, at least ostensibly, is that people think of fragile things like a glass cup. If you had a box full of glass cups, you'd write fragile on it. And you would hope that the person shipping your glass cups would take some extra care with that. And other things are robust. So if you are shipping bricks, you would just have a pallet of bricks. You wouldn't write fragile on them. But if the person operating the forklift was super rough with the bricks, they would shatter and then you would have loss. And those bricks, you'd have to just throw them away, right?

That's robust, right? But he proposes anti-fragile, which actually means that, you know, for every brick you break, like, you know, another two bricks are formed or something like that, right? And so, you know, for that, you know, the metaphor doesn't extend in that direction. But think about your arm, for example, if you break your arm, you know, typically, as long as it's, you know, splinted correctly and everything, your arm bone will actually heal and develop stronger, you know, typically as long as it's, you know, splinted correctly and everything, your arm bone will actually heal and develop stronger, you know, or even, even a simpler example is if you just, if you lift weights or if you punch a punching bag or something like that, uh, you know, the, if you punch a punching bag, the calcium in your knuckles will actually become more dense. If you lift weights, you know, your muscles will become stronger, so on and so forth.

And so these are things where as they're sort of injured, they actually become better. And so he takes that concept and applies it to the financial arena and a whole bunch of other areas and applies it to running a business. You also woven into this anti-fragile book is this concept of black swans, which are kind of rare but catastrophic events. And one of his core thesis is that if you develop your business in a certain way or if you develop an economy in a certain way, you'll end up with a lot of small breaks. So a good example that he used is the restaurant industry where there's constantly mom and pop restaurants starting up and shutting down and going out of business and new ones forming. And so there's constant fragility

at an individual restaurant level, but all of that life and death allows the overall restaurant industry to be very fragile. And he goes into, you know, wine, how that is. But yeah, I think the book is really interesting. It's, as I said, a lot of content. I think even if you just read the first book, you would get a lot out of it. And it's priced as one book. So it's very reasonable. So for, I guess I've actually heard nassim talk about the anti-fragile book in person during a talk he was giving when he first released it but for the

if you really want something kind of interesting so nassim's background is um he was a derivatives or is a derivatives trader so he he works in the finance industry doing options trading and stuff i believe and yeah that's right so part of his thesis, whatever, anyway, part of what he's driving at in these books is like, how would you orient yourself if you were going to buy options or something or futures? And how would you think about black swan events or having a portfolio which is anti-fragile? But if you kind of want like a trip down, whoa, this is kind of fascinating and hilarious between two sort of high profile figures. Nassim is somewhat, I guess, Internet famous for getting into it with Nate Silver, who we've talked about before.

Oh, I didn't even know this. The guy of FiveThirtyEight. So he was the one who became famous, Nate Silver was, for predicting a lot of the congressional and presidential races. What would that have been two or three times ago. And so 538 is a number of electoral votes that we have for president. So he runs this blog 538, he's become pretty famous about this. And he writes books and stuff as well. But they both talk somewhat about, I guess, like you would say, predictions and modeling and how to talk about probabilities. And Nate Silver's book, The Signal and the Noise or Signal from the Noise.

I don't remember what it's called. Anyway, so they get into it. I think it's The Signal from the Noise. Okay. So they get into it on Twitter, specifically before the last presidential election, about what was the right way to kind of think about or to kind of decide how likely it was that President Trump would be reelected or that President Biden, I guess not spoiler alert, but or whether Biden would be elected. And so it's kind of funny, because Nassim sort of, I don't understand most

of the nuance. But his sort of take was like, oh, we should have a betting market, a predictions market, and people could place real money. And then you could be able to see the true weight of it versus that's very different than how Nate Silver does his modeling and taking a lot of survey data and compositing them into a model and trying to understand like what people's preferences are being likely outcomes. And so they get into it about whether or not which one of them has the right approach. And they seem to really not like each other is my takeaway. Wow. Yeah, I had no idea. I don't I don't follow him on on on social media. So I didn't know that that's, is he at least polite about it? Like, is this I can't, you know, it's hard sometimes on Twitter, like, to tell if people are being like pop shoddy as like an affectation or like whether they're really like frustrated. So yeah, it makes sense.

Anyways, check it out if you're into that kind of thing. Some other people I know who are more, have a background in statistics and are, I guess, style themselves as statisticians find this hilarious and they're very into it and they get into arguments about it, but it all goes over my head. Yeah. Yeah. I mean, maybe the, the following, like the second and the third book get, get really technical. I think there's something really appealing about, I think the premise and yeah, I don't know, you know, I would love to see, yeah, maybe we'll see. I'll dig up if Nate Silver has sort of real, like a counter argument to this anti-fragile sort of, you know, like ecosystem that Nassim has set up here. But yeah, I think either way,

it's really good to see sort of this point of view. I thought that was really interesting. I feel like Black Swan and anti-fragile have been like somewhat, well, I guess Nate Silver's approach to it, but leaving that aside. Anyways, Nassim has been one of those things where he came out with these ideas and then everyone latched onto them and realized they were really good abstractions. And so you hear it a lot in certain areas.

Yeah, yeah, totally. My book of the show is less educational, I guess. Very much less educational. So this is a fantasy book. This is the shadow of what was lost by James Islington. It's actually the first of three books, which are all out now. So and finishes the trilogy, I guess. So you can be content knowing that it will be finished, unlike some other authors. And this book is about a world where I guess there's like a couple different kinds of what you want to call like magic.

And one magic has been kind of deemed as forbidden and is like kind of punished. And the other magic is sort of like tolerated, but trying to be like constrained. And, you know, kind of a lot has happened in the past. And there's a little bit of time travel that takes place. And I just thought it was really well done. It's like super fun read. I was very interested to hear what happened. I thought it was really good.

And then I realized you should never read reviews about books because I went to go read the reviews about the book after I read it because I didn't want it to be spoiled. And people were hating on it. So I guess books are a little bit of preference. The people were complaining about stuff that I thought was legitimate. But it turns out mostly I feel feel it was like, kind of pedantic, like, oh, the characters didn't have strong character development throughout the book, they stayed mostly the same. And it's like, oh,

I didn't even pay attention to that. I guess I treat books when I read them a lot, like just TV shows or movies or whatever, I watch them and I enjoy them. And then I kind of move on, I don't find myself thinking deeply about fiction books. Yeah, I think that is the challenge is it just in general, people who write reviews are much more technical on really any topic. I mean, same thing with video games. I was looking up a good game for, you know, my older my son to play. And yeah, when you read the reviews, it gets super technical. And it actually wasn't that useful so anyways i really like the book i would give it a recommendation not like my oh this is the best book ever but like this is really good if you're looking for something to read has a fair amount of heft to it it's a trilogy that's done and it's a it's a good world i would i would

recommend shadow of what was lost by james islington cool so how do you read you know given that you don't have a commute at least, given that you don't have a commute, at least I'm assuming you don't have a commute. Like what is, what is the right time for you? Is it, is it when you're going to sleep or, or what do you usually read?

It's a great question. I haven't sort of like fixed my post COVID getting books. Like I used to listen to them all on, on audible plug. Um, but, but just before they even were a sponsor, like we, I just, that's how I always have done. Yeah. And so this one actually finished most of

like before COVID, but we've not had a lot of, uh, what could the show is since then. So, um, now I find myself actually struggling. Like it's, I don't think I read as much as I want to, uh, in part because I don't have the commute. And so I haven't found a good replacement strategy yet. Yeah, I'm in the same boat. What I've started doing is trying to read at night, but I just fall asleep. And so I found the sleep timer in Audible to be really useful. But even then, it's like at most, that makes it so I don't end up at the end of the book when I wake up, but I still have to figure out, okay, how much of that 30 minutes did I actually listen to? Yeah. Yeah. Um, I think actually, well, yeah, I think paper books might be better now that I spend much

more time at my house, but I just got now the habit of buying paper books because I would never read them. So I don't know, maybe I need to try buying some book and paperback or hardback and trying it. Yeah, it's a really good, really good point. I, yeah, I have found the the audible, like or the audio book at night thing to work relatively well. Or maybe kind of early in the morning type thing. But But yeah, I definitely you know, I think once things kind of open back up, then you know, it'll definitely be the book, the audio book reading will pick back up. So, I mean, if you still have a time or are interested in hearing it. Yeah. With that, with that glowing endorsement. Audible is a, is a sponsor of the show and you can go to audibletrial.com slash programming throwdown and you can get a trial thing get a book check it out see if

it works for you i mean there are still plenty of times to do it if you if you have a yard and do yard work if you like folding laundry um walking the dog going for your you know jog i need to be doing that um those kinds of things i mean i think those are great times to uh listen to books on audio and actually encourage yourself to maybe do it a little longer than you might otherwise, because you get really into a good book. Yeah, yeah, totally. Actually, you know, before winter, when I was mowing the lawn, that actually was probably, you know, during the pandemic, that was the majority of my audible time, I would say would be, would be doing yard work. And then ask, why are you out there mowing every other day? Yeah, yeah, exactly. I'm like, shh, don't tell the family.

Grass grows really fast. Yeah. Yeah. Also, you can support us on Patreon, patreon.com slash programming throwdown. We definitely appreciate everyone's support. We're going to look into getting a Sven intern to join and we're hoping we can use the funds that y'all have contributed to ultimately

produce more content. I think we've used it in the past to advertise the show, and that's been really successful. And we've been able to teach this whole area and describe what it's like to work in tech to so many more people. And now we're going to pivot a little bit away from ads and the direct outreach and more towards producing more content and in a way that's productive and efficient for us. So we really appreciate all of your support. Yes. Thank you to all of our patrons. Yeah. And with that, it is tool of the show. My this show is sentry sentry is a it's it's a bunch of tools but you could access it from their website i think it's sentry.com but it is

a way to collect errors and crashes and um i recently integrated um eternal terminal in with integrated Eternal Terminal with Sentry and found it to be really, really useful. So a quick recap, Eternal Terminal, it's this SSH-like program. And it's been getting really, really popular, which is super, super fun. But it also means that there's all sorts of esoteric errors. And there's all sorts of other crashes I don't even know about that are happening. And so I wanted to find a way to collect crashes and these other things. And I tried a bunch of different alternatives. At a low level, there are some pretty standard things. There's like Breakpad and Crashpad. And on Mac, there's Crash Reporter, right? But I really wanted something that was higher level where I wasn't going to have to write so many bits and pieces.

And after trying a few things, Sentry was by far the best. The way it works is, you know, in this case, it's a native C++ app. So I was using the Sentry native library. But you link this Sentry native library into your code. They have a relatively simple API. In my case, when Eternal Terminal starts, it looks for a config file. If it doesn't see it, it creates it and it puts a little UUID in there, a unique identifier.

And then it'll use that identifier to dedupe. So if you crash, you know, a hundred times, it won't generate, you know, a hundred different reports on the backend. And then there was, you know, just some hooks into like the signaling system for Unix and Windows and all of that. So when there's any type of crash or anything, it just ships the log off. But yeah, it works great. So there's a Sentry dashboard and I can see in the past 24 hours, all the crash messages, and then I can go back in the code and try and decipher what

happened and it gives stack traces and everything. So yeah, I thought it was a pretty cool system and I recommend it. I haven't actually paid for anything yet, but this is in master, internal terminal master. I haven't done it in a release yet. And even on master, I'm hitting the 5,000 event limit. So I'll probably switch to the paid version before I actually cut a new release. And I've been happy enough with it that it's already provided really good value for me. Nice. It looks like it's sentry.io. Oh yeah, cool. Thanks for the correction.

And Sentry like monitoring, not Sentry like 100 years. Oh, yeah, yeah, Sentry. But yeah, check it out in the show notes. We'll put a link to it that's accurate and everything. It's really cool. And also, I think they do like browser and stuff. I mean, I wasn't building a website,

so I don't know for sure. But yeah, I mean, they also support a ton of other languages. So if you're doing Python or Node.js or whatever, they have bindings for all of that. My tool of the show is, for once, not a game, an actual tool that is Ninja, which is ninja-build.org. Ninja is, I guess you would is just like a replacement for make. Yeah. So if you are building C++ or C projects, you're very familiar with make, make itself invokes the compiler, but it is itself monitors dependencies and determines what and when things need to be rebuilt. But make makes is quite legacy at this this point i guess you would say like it's been

around for a long time still works and a lot of people you know kind of are very into it but it's not always in my opinion the fastest or the best yep at figuring out when and what needs to be rebuilt so it often over builds things or is slow to figure it out especially on bigger projects which i happen to be be working on present. And so Ninja was suggested and I tried it and it handles things like understanding you have multi-cores. And so doing in Make, it would be the dash J option for running multiple jobs in parallel.

It's really quick at figuring out the dependency graph and what needs to be built. So if you're building everything, I don't think you would see much difference between Make and Ninja to be honest, but maybe. But if you're doing partial builds, ninjas definitely noticeably faster and pretty easy and best of all I don't actually never written a ninja config file what happens is since I use cmake on on my project we normally would use cmake which outputs make files for you so that's kind of

confusing to me anyways but you have a cmake. CMake makes the Make files and then Make invokes the compiler and the linker. So in this case, you tell CMake you want Ninja files and then you run the Ninja command and Ninja invokes the compiler and the linker for you. And it has very, like, it's not much time to transition over. I've not needed to fidget with it, so I can't say much about the configurability of it. But I found it to be like pretty efficient. And everybody that on our team who has tried it has ended up pretty much just switching to it. And it's pretty no

nonsense and has a pretty nice output. So it looks it looks good. And it runs on in parallel by default. And it's really easy to build only specific binaries if your project builds multiple binaries. So if you've not tried it out before, and especially if you're using CMake, it's really easy to build only specific binaries if your project builds multiple binaries. So if you've not tried it out before, and especially if you're using CMake, it's as easy as just passing, I believe it's the dash, no, I don't know. Dash G. Is it dash G?

Dash G Ninja with a capital N. And so if you're using CMake, definitely try having an output Ninja and check it out. Yeah, Ninja is amazing. I highly, highly recommend everyone switch to Ninja. Yeah. You know, the interesting thing about make is if you do make dash J, but you don't provide a number, it just blows up your computer basically. Like, yeah. So make dash J with no number sets it to infinity. No. Yeah. So, so if you have to build, let's say 300 files, it will spin up 300 processes right then and there

and try and build everything at once. So I guess if you have a small project, that's fine. But if you have a big project, yeah, that seems bad. Yeah, I mean, you know, even Eternal Turtle is not even that big. And actually, the thing that got me to switch to Ninja was that I did make-j. I was in a hurry, and I meant to do make-j 4. And I forgot I didn't get the 4 in a hurry and I meant to do make dash J four. And I just, I forgot,

I didn't get the four in time and I had to restart my computer. And I was just like, this is so, this is so dumb. There's one thing actually, um, is that the reason why I hadn't been using ninjas is having to pass the dash G to see make all the time. But I found there is a C make config you can set somewhere in your home directory and if you do

that it will always run ninja by default i guess i always tailor my build anyways i always have other flags to pass in like dash d flags for defining like how i want the build to configure so passing one more uh makes sense because i just go into my history and edit my last run so yeah but yeah that's good to know i didn't know you could put in defaults into the cmake cool yeah totally yeah ninja is great everyone should should definitely jump on that if you're using make where everyone is a small subset of people that are building cnc plus plus and listening to the show and have a cmake front end i would say that's maybe 8 000 people or something i don't know maybe 10 000 we need. We need a poll. All right. Yeah. Yeah. If you're using

CMake, let us know. Actually, if you switched to Ninja and like it, definitely let us know. Cool. On to Kotlin. So. Oh, yeah, go ahead. So the first time I heard about Kotlin was in the context of people saying you could now develop Android apps. And I hadn't heard much about it before. But I was interested to learn that I assumed it was made by, you know, I guess it would have been Sun slash Cisco as an extension of Java, because it got picked up by Google for doing Android stuff. But I was surprised to learn that Kotlin actually came out of the JetBrains team, which are the people who make IntelliJ, CLion, and a number of... Is it Py... One of the Python tools. Which Python tool is it? I was going to say PyCharm, but I don't think that's correct.

No. Yeah. I know what you're talking about, though. Is it MyPy? Oh, man. No. Anyway, so they make a lot of... Yeah, it is PyCharm. They make PyCharm. Cool. Oh, they do. Okay. Yeah. And so they make a lot of tools yeah it is pycharm they make pycharm cool oh they do okay yeah and so they make a lot of tools that a lot of people have heard of um so if you're not just using i mean i guess if you're a power user and using emacs or or vi you know more power to you if you're using an ide it's likely you've run across uh one of the jet brains and if you haven't i encourage you to try out they're not um there's often free versions, but they're not always free. But if you work for a company, most of the time, most people's company

will pay for using the tools. And I would say JetBrains tooling is really good. And they were the ones who actually started Kotlin and then open sourced it. Yeah, I was really shocked to learn that almost half the people using Kotlin are not writing Android apps. They're doing a lot of web backend.

And yeah, that was super, super surprising to me. Yeah, I mean, I'll have to really dive into that. I mean, actually, I could see the rationale because if you already have a web frontend in Java, that's definitely the easiest migration to make or a web backend rather. But yeah, so yeah, I think another thing that made Kotlin really, really popular

was this whole drama around Java, the Java APIs. So this, and actually, Patrick, I don't know, you might know a lot more about this than I do, but ostensibly there was this issue where I think like Oracle kind of owned Java, but you can't really own a programming language. You can only own, I guess, certain APIs. And there's this whole back and forth

between Oracle and Google, who are the people who make Android. And I just feel like Kotlin was probably part of that whole, I mean, Kotlin is definitely, I think, better for Android development. But I think part of it too, is sort of strategic. Yeah, I mean, that whole thing is still I think still in in the court. But I feel like I don't want to address it without prepping myself, even though I feel like I know what the situation is, because it becomes pretty, pretty subtle. Yeah, that makes sense. Yeah. But you know, I think that that, you know, Colin has a lot of

really nice features. So, you know, for one thing, if you're building a front end, and this is, you know, my personal take, if you're building a front end, that tends to be the place where you really need type inference. Because you're dealing with a lot of callbacks. And so things can get, like type inference, lambda functions, these things become most important, at least for me in the front end. And like, like, for example, like eternal terminal doesn't really need, you know, async or anything like that, because it just does one thing, right. But but on the front end, you have all these different buttons and switches, and everything kind of needs to be asynchronous. And so and so that's where, you know, these kind of language properties really shine. And Colin's very good at that. You know, being a JVM language, it's fully compatible with, you know, Clojure, Script,

which we've talked about on past shows, and obviously Java and Scala and all those other languages, which is really nice. But another really cool feature about Kotlin is it also interops with Objective-C and Swift. So it's entirely possible for you to have like a Android app in Kotlin

and then let's say you feel compelled to write the iOS version of the same app, you could at least move a lot of the business logic over and then you would write using the interop, you would write the front endop you would write you know the the the front end um in swift let's say but but all of your business logic that sits on the on the phone could could be shared uh between android and ios which is really appealing actually reading through kotlin and having done some swift i found like it actually feels almost like they are targeting

the same trade-offs. So if they feel very similar to me, obviously Swift wasn't meant to be like a JVM based language, even though I believe that now Kotlin also can be a front-end to LLVM. And so you can build it without the JVM. But Swift and Kotlin, the syntax itself is different, like the operators you use and the words. But the way, like how constant versus non-constant variables are done, how that stuff is strongly typed, but if the type can be easily inferred, you don't have to write it. These kinds of things feel very similar between the two to me. Yeah, that makes

sense. I mean, one thing that Kotlin, that I wanted to call out about Kotlin is they borrowed the data class idea from Python, which I really like. There was a period of time where I would basically use protobuf on everything that I built, even if I didn't need it. And the reason is because the code that protobuf generated was so convenient. Like I could take any C++ class, I could turn it into a string, I could turn it back into a class, I could compare things.

I didn't have to write any of the comparators, right? And at least the way I think when I program is I have some classes that are just holding data. And then I have other classes that are procedures and processes. And so I'll typically have a widget class that has a whole bunch of different properties. And then I'll have a widget runner class that uh you know is empty in terms of storage but just has a lot of logic and and then the widget class like you have to end up implementing the hash function the comparator function all these things right so um you know with python and i don't know who who kind of came up with this first so i could the arrow of causality could go in the other direction.

But with Python, you have this awesome import called data class. And you can annotate a class as a data class. And you could choose for it to be frozen or not frozen. And so then what happens is if I have a data class, let's say, called point, which has an X and a Y for the coordinates, I can create this sort of point class, I could print it, and it'll just print X colon Y colon automatically without me having to write that I could serialize a bunch of points to disk and then get them back. It's just a really nice kind of setup. And if I choose to make a frozen data class, then I can't actually change, let's say, the x coordinate.

So I can't do my point dot x plus plus. That's illegal, right? But because it's frozen and you have to make a new point anytime you change something, it's immutable. Then there's other sort of optimizations they can do that are really attractive, right? Like you could put it into a, you could use it as a key in a dictionary, for example. And Kotlin takes this data class idea and brings it over, which I think makes development a lot easier. That's pretty cool. I did not know about this data class in Python. So that's a valuable tip right there. They do have something similar in Java, they have a couple different ones. I know one of them is called like Lombok, which is like it integrates with your sort of ID and build system. And you produce it's kind of like what you're saying, I guess, like simplified class descriptions, they get transpiled into like

all the boiler boilerplate code. So like standard Java, you're not supposed to like directly access the variables, you're supposed to have getters and setters for everything like that's kind of accepted. And writing those out is super tedious. And like you said, the hashes and the to string. So instead, they allow you to write like a very simple description and say that you want all those things to be generated, and then it'll just auto generate it for you nice so is there like in c++ is there an equivalent for this what is that called it's that no but kind of yes um it's oh i think it's hang on i want to check i think it's is there marshmallow there's a way to do it with macros yeah i think there's marsh marshmallow is a thing that also exists in python but but i think marshmallow originated from c++ and that might be one way

to do it so i think the way if you're going to do something like this in c++ but i it's generally fun it's called x macro i was thinking x args and i knew x args was wrong x macro um but all it is is uh sort of including but you can kind of do the same thing but it's all with pre-processor macros which if you've used c or c plus plus before i mean using a lot of macros can get you into trouble uh to make sure it's pretty hard to read so i definitely wouldn't recommend doing it but that's the main way i've seen it be done at like a code level. Obviously, like you're, you're saying Jason, like a lot of people use sort of protobuf or something similar to that, like another IDL kind of like description of data description language,

which is an external tool. And it doesn't really integrate at a code level the same way. Yeah, that makes sense. Yeah. I mean, I think protobuf would be the way to go. I think, as you said, you know, it's so frustrating when you, you know, like control click on a class member variable and it takes you to like a pound define that, you know, is unrolling 20 different ways and you have to go and chase it down.

Cool, so yeah, I think, you know, just some, you know, since Kotlin, you know, Kotlin, wait, Kotlin is used for Android development and mobile development. It's good to talk a little bit about developing for mobile. Actually, have you ever, I've built some apps in the past, none of them were super popular, but, you know, definitely not an app building expert. But a few things that I kind of learned along the way, the biggest one was not to block the main thread. So it's very tempting to write in this procedural way. It's like, okay, I click the button. Now I have a whole bunch of logic to do. I want to go to a database. And when I get the results from the database, I want to show it on the screen. But that ends up creating this really bad experience. And you've probably seen this.

I think iOS actually won't let you do this. So it's like it won't like the language, like Objective-C will somehow just not let you do it. But on Android, you can see this where even if you have a really high end phone, if the app is not written in a good way, like it could kind of stutter or the app can freeze while it's doing some logic. That's true, not even just on mobile. I mean, that's true even on the desktop. In general, you don't want to do that. Yep.

Yeah, totally. And so Kotlin makes this easy by introducing coroutines. So typically, before Kotlin, if you're doing this in java for example um you'd have to have a bunch of threads right and you'd have to have a thread pool and you'd have to say well you know the person clicked on the button so um you know go to my thread pool and and and spin up this this thread that you know does some sort of logic. And it ends up being a lot of boilerplate. With coroutines, coroutines are at a high level.

You could think of it as kind of like a thread pool, but it's built into the language at a pretty fundamental level. So it's kind of like a first-class citizen. And so instead of you maintaining your own thread pool, you could just say, hey, you know, do this thing asynchronously. And and the language itself handles, you're doing tutorials seems like something that I kind of almost envy, like, coming from a background of developing, like mostly command line utilities and stuff, seeing something like Android Studio and its support for Kotlin and having the backend and like out of the box doing just amazing, like auto completions and suggestions and the usefulness is something that

Kotlin comes with and being actually, I believe it's kind of like the recommended way now to build Android apps, like they don't even like you just go to their web page, and you know, kind of follow the default, like make your first Android app, it will have you develop it in Kotlin with Android Studio. Yeah, totally. You know, a IDEs have these RAD tools, rapid application development. And basically what that is, it's a fancy way of saying it's like a little editor where you can kind of drag and drop buttons and drop down lists and combo boxes and all these things. And you can actually get a lot done in the editor. And then typically the editor has this like two-way is bi-directional mapping to either the source code or some kind of XML or JSON file.

And so, for example, if you're doing Qt on desktop, you can use Qt creator and it will create this.ui file. And that.ui file kind of explains the layout of your application. And then you just have to sort of plug into all the buttons. And so you don't have to encode, write, draw a button and put it over here. You don't have to do that by hand. You could just use the editor. And so for mobile, this is really, really important because, you know, a lot of what you're going to be doing on mobile is on the design side.

And so, you know, having a RAD tool like that is extremely useful and makes you much, much more productive. And also, you know, it'll kind of force you to separate the, you know, layout and the visual, you know, design from the business logic. It'll kind of force you to separate the you know layout and the and the visual you know design from the the business logic it'll kind of force you to do that which is a really good you know healthy practice to have i mean the other thing that the the tooling like that i guess is like now well i guess used to be the big thing like on ios you had very few form factors and on android you had tons but not everyone just seems like they've given up and gone to what is it called like adaptive UI or whatever, like UI, basically, like flowing and changing based on like, you know, kind of smoothly across a range of

resolutions and sizes. And I feel like doing that stuff by hand becomes like, very difficult. And having the these tools, although some people kind of want that pixel perfect layout and sometimes it's still supported but using these tools in general especially for new people and making sure it's going to work across the right range of assumptions these tools are vital to be able to help you do that yep yep yeah totally i think um you some more mobile development stuff is kind of interesting is is um you have to deal with signing your app. So a lot of these apps, when someone goes to get your app from either the app store or maybe they download it from a website, they download the APK file, they want to make of that. They'll integrate with ProGuard. ProGuard is this tool which kind of prevents people from decompiling your app and then kind of taking away your source code and all of that,

extracting the source code out of it. And so there's a whole bunch that goes into deploying an app that you really don't think about when you're building something, let's say, when you're building something, let's say, when you're building a website or something. And so the IDE does a really good job of handling a lot of that versus the web where on the web, you have to go get Webpack and run it and figure out how that works and everything. And there are frameworks like Next.js, which we talked about, you know, with Guillermo Rauch on a past episode, which will, you know, do a lot of that for you. But here, I think a lot of that, the IDE just makes that even more easier where you can just kind of click a button and all these things happen in the background.

Kind of off of the developing for mobile, but one of the things that came up recently at work that that i saw you know sort of kotlin kotlin has a way of dealing with was talking about optionals and i was talking before about similarity to to swift but in in kotlin like by default your variables can't be set to null and if you want them to be set to null then you need to declare them as nullable which is analogous to the optional. It's a kind of different way of saying it. And if you have a type which you're dealing with a variable which is nullable,

you're basically Kotlin forces you to handle it. So you either have to say, I'm choosing to ignore it, which is bad, don't do that. Or you have to say basically what the behavior should be normally and what the behavior should be normally and what the behavior should be, if it's currently null. And Swift has something similar for optionals, which is, you know, if the optional is not there, it's missing, then that's a specifically handled case

versus if it's there, and it's set to some value. And I feel we were talking about this, you know, coming up at work and talking about how like, this flow being preferable to kind of previously, people might have done something similar with like, kind of throwing exceptions in Java, right, you might throw an exception that, oh, I couldn't, I couldn't parse this into tokens, the string couldn't be parsed into tokens, throw an exception. And that for control flow was considered acceptable. But now you might, I guess more the style or the current more preferred way would be maybe you return a whatever container of tokens, but that container is wrapped in an optional or in this case, sort of nullable. And then if you know that the person is forced to handle the case where the thing itself is missing, not just like, so you can get no tokens, you can get some set of tokens, or you can get this state where it says basically, like, I failed to do I failed to fulfill what you asked me to do.

And then people can take applicable handling, and it's expressed in the type directly, because it's wrapped around with this either nullable or wrapped as an optional. And we were just talking about how like that's become more popular i think it comes out of kind of like the functional programming world um this is super super common but it's it's gained a lot of traction to the point where i feel like it's almost become like the recommend recommended way and i and seeing kotlin here is uh you know i guess like a decade old but you know, I guess, like a tech aid all but you know, more recently developed language has a direct support for this flow. And I feel like that's just a really good thing. Like, I kind of wish I had that in C++, like a way to force me to handle this this way for things which could be null and the language sort of supported it sort of nicely and directly because I feel it's a good design and direction personally often. Yeah, yeah, totally makes sense.

Yeah, I was noticing this as I was going through and integrating the internal terminal with Sentry. One of the things that I noticed was that if I caught an error, but it was actually like a fatal error, I just caught it somewhere else and then ended up rethrowing it or it caused problems downstream those were actually the hardest to learn anything from like it was the hardest to really instrument because because you know it's like you don't really know what went wrong like the easiest things instrument instrument are the ones where you just die instantly like you say like this

something really bad happened i'm out and here's the stack trace like those are the best but you know not not every error kind of fits into that category as you said like there might be this time where you're tokenizing something and if if the tokens aren't correct you just want to return null and there's a way to handle it that isn't so dramatic right and and a lot of those you know I used to just throw and then catch somewhere else. And that became really difficult to diagnose because it's very hard to actually know where it's going to get caught. But if you instead go this route of returning null, then you might have to handle it in more places. But the trade-off is you end up with a clean flow.

And when, let's say if one of those places just can't deal with that null and it has to crash the whole app, like that's actually where the problem is, not those other places that just handled the null just fine, right? So yeah, actually you mentioned this in an earlier episode, Patrick,

about how there's a certain style i don't know if you follow it or if you're at a place that followed it where they they just don't throw anything they just don't throw exceptions yeah this is fine being in c plus that's sort of the recommended way i i was pointing out someone brought this up literally a few days ago and i was saying you know as far as know, I haven't seen a lot of sort of high level C++ people, professionals sort of recommend use of throwing and catching in C++. It's just generally either inefficient or just hasn't been rolled out. Like it's just not an accepted way of doing things. So yeah, we actually don't allow throwing in our code. Yeah, I think it's a way to

go. I mean, in hindsight, you know, and the nice thing there too is, you know, occasionally the language will throw an exception, you know, like you do A equals zero, B equals C divided by A, boom, exception, right? And if you don't catch those, the default behavior, you can catch the signal, you can intercept that signal, and then you will get a stack trace and a whole bunch of really useful information. So not catching the exception can result in some really detailed information that could be actually a lot more useful than catching the exception and then exiting. And then now you end up with not the right information, it becomes very hard to fix.

Yeah, I think I'm not doing active Java development anymore, but it feels like in Java, it used to be more common to have, I guess they call it checked exceptions, where if your function knew it would throw an exception, people would need to handle it and potentially pass it up. I feel now the style is more to do a runtime exception where you extend, you inherit from runtime exception, and then people aren't forced to catch it. um like you're saying if your os signals that's a runtime exception like

it's not a compiled time you you don't you never know what could cause your os to throw an exception because you could just be kill dash nine from something else right so you never know what all actually i don't know if that makes anyways separate topic you never know what all actually, I don't know if that makes anyways, separate topic, you never know what a signal not an exception, but I think you're you have the right spirit. Yeah, so so you never know what could just like flake out runtime. Similarly, if you get into some state that you know, is not handleable, you can sort of throw an exception if people know better than you when you wrote the code and say, Oh, actually, like I know what causes this and I want to handle it, They can still catch it. But otherwise, like Jason is saying,

it passes all the way up and contains the stack information. Yeah. So let me think. Other stuff. I mean, we've covered most of it. In 2018, Kotlin was the fastest growing language. So I think it shows that there was a clear demand for something else for Android.

So before 2018, so I think before 2017, there was almost no Kotlin on Android. I don't know if it wasn't supported or just it hadn't been popularized. And so in the past, I think, well, in the two or three years between 2017 and around 2019, 2020, Kotlin went from 100% backend to 50-50 backend mobile as a language. So that's huge, huge growth. And as I said, I think that's because Java is a pretty difficult language to be building a frontend. And Kotlin kind of addressed a lot of those really deep concerns. And so if you are looking to do Android development, definitely, definitely, even if you're experienced in Java, take the time to learn Kotlin. I think it would be really useful.

It feels good to be back on a normal non-interview. I like the interviews, but I like this too. Yeah, this is great. Yeah, I know a lot of people have emailed us, you know, asking. I mean, a lot of people love the episodes too. I mean, it's pretty much a toss up, but, you know, as the show's grown, we do have a lot of folks emailing us asking for, you know, more of the natural episodes.

And specifically, you know, they have a lot of languages they want us to cover that we haven't got to yet. I just want the sweet, sweet tool of the shows. Yeah, the tools of the show are awesome. Actually, I was going to use VC package. I found out we made that a tool of the show way back in April. And now VC package is really taking off, which is amazing. So I think we definitely called that one early. But yeah, so it's really great to be back and uh you know we're gonna find out a way to uh to do these these type of shows more often thank everyone again for their

thank you all for your support um check us out on discord there's actually a really several really good threads going on discord you know there there was the questions chat room, which we used to answer Q&A last month. And, you know, that is just, you know, continuing. There's discussions offshooting from that. And then the on topic, which is the main room, has a lot of good content. So check us out on Discord. You know, if you have questions for us and you add us, we try our best to answer just about anything. And also talk to the other folks on Discord.

There's a lot of really, really talented people on there. Music by Eric Barndollar. music by eric barn dollar programming throwdown is distributed under a creative commons attribution share alike 2.0 license you're free to share copy distribute transmit the work to remix adapt the work but you must provide an attribution to patrick and i and share alike in kind