Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 288, recorded June 14th, 2022. I'm Michael Kennedy. And I am Brian Okken. Brian, how are you doing? I'm excellent today. I hear you're a little busy. But it's just, you know, being a parent and having side jobs and stuff like that. Of course. Well, it's better than the alternative.
Definitely. I was talking to somebody this weekend about like their one job and trying to balance job and life. And I'm like, I don't even remember what that's like with just one job. I know. Or you have a job where you go to work and you do the work. And then when you go home, there's no real reason to do the job anymore. So you can just step away from it. It sounds glorious. And yet I continue to choose the opposite, which I also love.
All right. Well, speaking of stuff people might love, you want to kick us off with your first item? Yeah, we're going to talk about polar bears. No, not polar bears. A project called Polars. And actually, it's like super fun and cool. So Polars was suggested to us by actually several listeners. We got several people sent in. And I'm sorry, I don't have their names, but thank you. Always send great stuff our way. We love it.
But Polars is billed as a lightning fast data frame library for Rust and Python. And it is written in Python. No, it's written in Rust. But they have a full API is present in Python. And it's kind of neat, actually, how they've done it. So we've got up on the screen the splash screen for the Polars project. There's a user guide and API reference, of course. But one of the things I wanted to talk about is some of their why you would consider it. So Polars is lightning fast data frame library.
It uses an in-memory query engine. And it says it's embarrassingly parallel in execution. And it has cache-efficient algorithms and expressive API. And they say it makes it perfect for efficient data wrangling, data pipelines, snappy APIs, and so much more. But I just also is fun. I played with it a little bit. It's zippy and fun. They have both the ability to do lazy execution and eager execution, whichever you prefer for your use. It's multi-threaded.
It has a notion of single instruction, multiple data. I'm not exactly sure what that means, but makes it faster, apparently. And I was looking through the whole, the introductory user's guide is actually written like a very well-written book. And it looks like the whole guide, as far as I can tell, is written for the Python API. So I think that was part of the intent all along, is to write it quickly in Rust. expose it to Rust users also, but also run it with Python.
And it's just really pretty clean and super fast. One of these benchmark results performance things was, it's like Spark was taking 332 seconds and they took 43 seconds. It's 100 million rows and it's just like, let's load up a couple of pieces of data or something. Right. So there's a lot of focus on this, making sure that it's fast, especially when you don't need everything, like doing lazy evaluation or making sure you do multiprocessing.
One of the things I thought was really kind of cool about it, I was looking through the documentation, is there's a section on, that says, it was a section that was talking about parallelization. It says, do not kill the parallelization. Because with Python, we know we, there is, basically there's ways to use polars that can kill parallel processing because of the GIL.
If you're using, if you don't do it the way they've set it up, you can use it in a way that makes it a little slower, I guess, is what I'm saying. But, so there's a section on this talking about the polar expressions, polars expressions. And these are all set up so that you can pass these expressive queries into polars and have it run in the background and just make things really fast. And sort of skirt around the GIL because you're doing all the work in the Rust part of the world.
And then collecting the data later. So there's like a set up the query and then collect the query. That's kind of cool. So, anyway, I just thought this is a really, looks fun. And it's, it's just a, there's nothing to, you don't have to do, know that it's in Rust. You just say pip install polars and it works. So. Yeah, that's great. Out in the audience, Tharab asks, why Rust and not C? Maybe an example there is Pandas versus this. Also, probably the person who wrote it just really likes Rust.
And I think Rust has a little bit more thread safety than straight C does. I'm not 100% sure. But this uses threads, as you point out, whereas the other one, Pandas. And others in C don't. I also think that we're going to see a lot more of things like this. Like, because I think some of the early faster packages for Python were written in C because Rust wasn't around or it wasn't mature enough.
But I think we're going to see more people saying, well, I want it to be closer to the processor for some of this stuff. Why not Rust? Because I think Rust is a cleaner development environment than C right now. Yeah, I agree. Absolutely. It's just a more modern language, right? You know, C is keeping up. C is never going to be old, I don't think. But yeah. Yeah. Yeah, yeah. I don't mean to say that C is out, not modern in the sense that people are not using it.
But it doesn't embrace in its sort of natural form the most, you know, smart pointers and things like that. Yeah. And there's C++ maybe, but not C. There's safety features built into Rust to make sure you don't, just make it easier to not do dumb things. I guess. Let's put it that way. Indeed. All right. Well, let's jump on to my first item, which is a follow up from last week. Python developer survey 2021. Yes, you heard that right.
I know it's 2022. These are the results from the survey that was at the end of last year. So let's, I'm going to kind of skim through this and just hit on some of the main ideas here. There's a ton of information and I encourage people to go over and scroll through it. This is done in conjunction with the folks over at JetBrains, the PyCharm team and all that. So it was collected and analyzed by the JetBrains folks, but put together independently by the PSF, right?
So it's intended to not be skewed in any way towards them. All right. So first thing is if you're using Python, is it your main language or your secondary language? 84% of the people say it's their main language with 16% picking up the balance of not so much. It's been pretty stable over the last four years. What do you think of this, Brian? I think that there's a lot of people like me. I think that it started out as my secondary language and now it's my main language. Yeah. Interesting.
Yeah. And it got sucked in. Like, ah, maybe I'll use it to test my C stuff. Wait, actually, this is kind of nice. Maybe I'll do more of this. Yeah. There's always the next question or analysis is always fraught with weird overlaps. But I like the way they ask this a little bit better than a lot of times. It says Python usage with other languages. What other languages do you use Python with? Rather than maybe a more general one where they ask, well, what is the most popular language?
And you'll see weird stuff like, well, most people code in CSS. Like, I'm a full stack CSS developer. Like, no, you're not. Just everyone has to use it. Like, what is this? It's a horrible question. Right. So this is like, if you're doing Python, what other languages do you bring into the mix? And I guess maybe just hit the top five. JavaScript, because you might be doing front and back end. HTML, CSS, same reason. Bash shell, because you're doing automation build, so on. SQL. SQL.
I'm surprised there's that much direct SQL, but there it is. And then C and C++, speaking of that language. Also, to sort of address the thing that I brought up before, Rust is at 6%. Last year, it was at 5%. So it's compared to C at 30. And 29, so they both grew by 1% this year. Okay. Yeah. I think they both grew. That's interesting. Yeah, exactly.
Another thing that people might want to pay attention to is you'll see year over year stuff all over the place in these reports, because they've been doing this for a while. So like the top bar that's darker or sorry, brighter is this year, but they always also put last year. So for example, people are doing less bash. You can see like it's lower bar is higher and they're doing less PHP. Probably means they love themselves a little bit more. Don't go home crying. Okay. Let's see.
Languages for web and data science. This is kind of like if you're doing these things, what to use more. So if you're doing data science, you do more SQL is your most common thing. If you're doing web surprise, JavaScript and HTML is the most common other thing. Yeah. Let's see. What do you use Python for? Work and personal is 50%. Personal is 29 and work 20%. Kind of interesting that more people use it for side projects. If they use it for just one or the other of work or personal.
I guess people who know Python at work, they want to go home. They're like, you know what? I could automate my house with this too. Let's do that. I think that, yeah, I would take it like that. I think more people, it isn't just even automated your house. It's just playing around with it at home. Like, yeah, I heard about this, this new web framework, FastAPI. I want to try it out. Things like that. So. Yeah, absolutely. I'm going to skip down here through a bunch of stuff.
What do you use Python for the most? Web development, but that fell year over year. Data analysis stayed the same year over year. Machine learning fell year over year. And a bunch of stuff. But so sort of the growth areas year over year are education and desktop development. And then other, I think it's pretty. Also game development doubled. Doubled from one to two percent. I mean, from one to two is probably like there was, you know, that might be within the margin of error type of thing.
But still, it doubled. But I think just the other. No, other didn't grow. There's just, I think it's just more spread out. I don't know. Because there's still, I think, same number of people using Python. All right. Are you a data scientist? One third, yes. Two thirds, no. That's that fits with my mental model of the Python space. One third data science, one third web and API, and one third massively diverse other. The way I see the ecosystem. Python three versus two.
I think we're asymptotically as a limit approaching Python three only. But year over year, it goes 25% from 2017, then 16% Python two, then 10%, then six, then five. And then there's just huge code bases that are stuck on Python two. Like some of the big banks have like 5,000 Python developers working on Python two code bases that are so specialized and tweaked that they can't just swap out stuff. So, you know, that might represent 5% bank usage. I don't know. I just, I feel bad for you.
We're rooting for you. Everybody out there using Python two. Stick in there. Let's approach that limit. Yeah, yeah. Let's divide by n factorial, not n for your limit there. Let's go. Get in there. All right. Python three nine is the most common version. Three 10 being 16% and three eight being 27% versus 35. So that's, that's pretty interesting. Yeah. I feel like this is, hey, this is what comes with my Linux. This is what comes with my Docker. So I'm using that, but maybe it's more.
Yeah. It's interesting because you and I like our interesting space because we're always looking at the new stuff. So I, I'm at, I'm at three 10 and I can't wait to jump to three 11. Yeah. And actually I've switched to three 11 for some projects. So, but there's a lot of people that was like, man, Python's pretty good. And then it's been good for a while. So I don't need a lot of the new features. So. Yeah, for sure. I'm going to later talk about something that might shift that.
Yeah. To the right. I've actually been thinking like, should I maybe install three 11 beta? See how stable that is on the servers. We'll see. That might be a bad choice. Might be a good choice. That's what's okay. Uh, where do you install Python from? 38%? Just download the thing from Python.org and run with that. Yeah. The next most common option is, to install it via your OS package manager, apt, homebrew, whatever.
Yeah. And Alvaro has a great little recommendation out there for people who are stuck on Python too. There probably is a support group for Python two users. Hi, my name is Brian and I use Python too. Hi, Brian. All right. Another one I thought was pretty interesting is, the packaging stuff, the isolation stuff, um, before we get there really quick, web frameworks, FastAPI continues to grow. Yeah. Pretty strong here.
We've got Flask is now maybe within the margin error, but just edged ahead of Django, but fast API almost doubled in usage over the last year. It grew nine percentage points, but it was at 12% last year. And so now it's at 21%, which is, that's a pretty big chunk to take out of established frameworks. Yeah. Well, and it looks like the third is none. I haven't tried that yet. Yeah. It gets a lot of attribute errors, but it's, it's really efficient because it doesn't do much work.
Yeah. Yeah. People, who maybe don't know FastAPI, the name would indicate it's only for building APIs, but you can build web apps with it as well. And it's pretty good at that. Especially if you check out Michael's courses, he's got like two courses on building web apps with the fast eggs. I do. And I also have a, some, some sort of template extensions for it that make it easier. I do. All right. Data science libraries. Um, I don't know how I feel about this one. Do you use NumPy?
Well, yes, but if you use other libraries, then you also use NumPy. So yeah, it's like all of these are using NumPy. So exactly. Exactly. Yeah. Uh, a bunch of other stuff. Look at that for unit testing. Would it surprise you that pytest is winning? No. They just overtook Num this year, didn't it? Uh, yeah. So. All right. Uh, ORMs, SQLAlchemy is ahead and then there's, Django ORM. Django is tied to Django. SQLAlchemy is broad. So there's, there's that.
And then kind of the none of the ORM world is raw SQL at 16%. That's pretty interesting. Postgres is the most common database by far at 43%. Then you have SQLite, which is a little bit of a side case. You can use it directly, but it's also used for development. And then MySQL, the MongoDB, and then Redis and Microsoft SQL Server. So. Yeah. Huh. Actually SQL Server and Oracle are higher than I would have expected, even though, you know, but it's okay.
Well, I think what you're going to find is that there's like certain places, especially in the enterprise where it's like, we're a SQL Server shop or we're an Oracle shop and our DBAs manage our databases. So here you, you put in a, you file a ticket and they'll create a database for you. Yeah. Or there's a, there's already an existing database and you're connecting to it or something. Yep. Yep. Exactly. Exactly. All right. Let's keep going. Cloud platforms. AWS is at the top.
Then you've got Google cloud at 50% and then GCP, Google cloud platform, then Azure, then Heroku, DigitalOcean. Linode has made it on the list here. So, you know, a former or sometimes sponsor of the show, it's good for them. And let's see, do you run, how do you run stuff in the cloud? Let's skip over this. I think a bunch of interesting, a few more interesting things and we'll, we'll call it compared to 2020 Linux and macOS popularity decreased by 5% while windows usage has risen by 10%.
Wow. Yeah. Where the windows people now double more than double the macOS people and are almost rivaling the Linux people. That's, I think that's just, towards the growth of Python. Uh, I think, Python's just making it more into everybody's using it sort of thing. Yeah. And there's also a windows subsystem for Linux. It's been coming along pretty strong, which makes windows a more viable, more on have, have more parity with your cloud targets. Right.
Yeah. And it feels like out in the audience is because of WSL. Yeah. Maybe. Yeah. Okay. Uh, let's see a few more things. Documentation. It's cool. They're asking about like what documentation frameworks you use. This one's interesting to me. What's your main editor, VS Code or PyCharm? I asked this question a lot at the end of talk Python and it feels like VS Code, VS Code, VS Code, VS Code is what people are saying all the time, but it's 35% VS Code, 31% PyCharm and Brian right there for you.
7% Vim, but. Okay. Yeah. I just teased you. Yeah. To be fair, it's both VS Code. It's, it's, it's all three. Yeah. Or top. Yeah. Top four for me, but yeah. Yeah, exactly. Well, often you probably just use Vim bindings within the other two, right? Yep. Yeah. Let's see. I think also maybe another interesting breakdown is that if you look at the usage scenarios or the type of development done with the editors, you get different answers.
So like for data science, you've got more PyCharm and for web development, I think, hold on, I have that right. Oh, interesting. For data science, you have a lot more VS Code. For web development, you have more PyCharm and you have a lot less other in data science, AKA Jupyter. I suspect it. Yeah. Yeah. Okay. How did you learn about your editor? By far? Or first one here is from a friend. So basically friends like push editors, like drug dealers, like gotta get out.
What are you doing on that thing? Get in here. No, I think it's like, if I'm, if I'm watching somebody do something cool, I want to do it also because it looks helpful. Yeah, exactly. You sit down next to your friend and you're like, how did you do that? That's awesome. I want that feature, right? I think you're probably right. Okay. Let's just bust down a few things better. One, do you know, or what do you think about the new developer in residence role?
This is Lucas Schillinga that's going on right now. 77% are like, the what? Never heard of it. Maybe like we got, we got a little more advocacy job to do here, but he's been doing a great job really speeding things up and sort of greasing the wheels of open source contributions and whatnot. I, yeah, I'm going to take it like design because if design's done well, nobody knows it's there. And yeah, I think the same thing.
I think if he's doing his job really, really well, most people won't notice things will just work. Yep. Yeah. Quick real time follow up. Felix out in the audience says, I use PyCharm because of Michael. It should have been one of the options in the survey because of Michael. Oh, come on. That's awesome. But no, let's see. There's a bunch of questions about that. And the final thing I want to touch on is Python packaging. Let's see here.
Which tools related to Python packaging do you use directly? And we've talked about poetry. We've talked about Flit, pipenv and so on. And 81% of the people are like, I use pip for packaging. As opposed to Flit or something. And then sort of parallel to that is for virtual environment. Do you use the, you know, what do you use for virtual environments basically? Yeah. Like 42% is like, I just use the built-in one or I use the virtual ENV wrapper.
And then it's like poetry, pipenv talks and so on. There's a few. I don't know what this is. Yeah. Well, I'm glad they included that because one of the original questions didn't include like the built-in VENV. And that's, I think that's what most people use. It is. Yeah. Yeah. Absolutely. All right. Well, I think there's more in my progress bar here. This is a super detailed report. I'm linking to it in the show notes.
So just go over there and check it out if you want to see all the cool graphs and play with the interactive aspects. But thanks again to the PSF and JetBrains for putting this together. It's really good to have this insight and these projections of where things are going. Yeah. Hey. All right. I'm going to grab the next one. Ooh, we did this smoothly this time. Nice. So JIN config is just JIN actually, but the project's called JIN config. And it's kind of a neat little thing.
It's a different way to think about configuration files. So like you have, you have your PyProject or you have .toml files. You could have .any files. There's a lot of ways to have configuration files. But JIN takes the perspective of, oh, well, what if you just, what if you're not really into all of that stuff and you're a machine learning person and you just have a whole bunch of stuff to configure and you're changing stuff a lot? Maybe let's make it easier.
So I actually came across this because of Vincent Warmerdam. He's got an excellent intro to JIN on his comcode site. And the idea is you've got this, you just have for a function that you want to, in your code, you got some code and you have like part of it that you want configurable. You just slap a JIN configurable decorator onto it. And then all of the parameters to that function are now something that can show up in a config file. And it's not in any file.
I actually don't know the exact syntax, but it just kind of looks like Python. It's a, you just have names. Like in the, in this example that I'm showing, there's a, there's a file called simulate and there's actually a function called simulate and a parameter called in samples. And in your config file, you can just say simulate.insamples equals a hundred or something like that. Oh, wow. This is like, it basically sets the default parameters for all your functions you're calling.
Yeah. The ones that you want to be configurable and you just do that. Now it's still where you can still set defaults within your code and, and just like you normally would. And then, and then you can configure the ones that you want to be different than the defaults. So that's a, that's a possibility. And there's a whole bunch of, I'm going to expand this a little bit. There's a whole bunch of different things that Vincent goes through like required settings.
You can have a, you can specify like a dot. What is it? Gin dot required as a function. And it makes it so that, or as your parameter, and then it makes it so that your user has to put it in their config file. That's kind of cool. And then you can also, if you don't want somebody to configure something, you can, you can mark it as, oh, he's got blacklist the, the end samples. So if you want, like in this example, he's got a simulate function with two parameters, random funk and end samples.
You want people to configure the random funk, but you don't want them to touch the end samples. You can, you can say, don't do that. So, it's kind of neat. There's a whole bunch of cool features around it. Like, like being able to specify different functions so you can name things and, do it around like, like to say like in his example, he's got random functions.
And if you, you can specify, you know, one of the other, one of the other, like a random triangle function, you can specify a function and assign it to that. He's got, named things. Um, it's a really, it, it's a interesting way to think about configuration and the, the, the motivation section of the documentation for gin says, that often modern machine learning experiments require just configuring a whole bunch of parameters and, and then you're tweaking them and stuff.
And, and, and to have that be as easy as possible and as simple as possible, because it is, and you're going to add some and take some away and things like that because some things you want configured and then you decide not to not having to go through a config parser system, and just making it as trivial as possible to add parameters. I think it's a really cool idea. So. It is a cool idea. It reminds me of like dependency injection a little bit.
Yeah. Uh, you know, where you would like configure, say like if somebody asks for a function that implements this or that, that goes here, like this is the data access layer to use, or here's the ORM I want you to pick this time. It's not super common in Python, but it's pretty common in a lot of languages. And it feels a little bit like that. Can we configure stuff? So we have these parameters that we might use for testing or something, but it just, they get filled in automatically.
Yeah. Even FastAPI has that for example. Yeah. Yeah. Um, so cool. Somebody in the audience says it isn't, isn't Jen used with go. Um, and I'm not sure about that, but it, Jen is, is not an officially supported Google product, but it's under the Google, like a GitHub repo group. So maybe, yeah, maybe it does look very Python like though for the config files. And that's cool. Yeah. Good one. All right. Uh, let me switch back before I swap over. Okay, here we go.
Now this next one, I think universally will be well accepted. Although the comment section about it was a little bit rough and tumble. Nonetheless, I think it should be universally exciting to everyone. And this comes to us from Eduardo Orochena who sent over this article that said the, what's it called? The Python 311 performance benchmarks are looking fantastic. And oh boy, are they? So we're talking beta code six months out, right? And still, still we've got some pretty neat stuff.
So this, this links over to an article with that same title by Michael Larabel basically says, look, we took a whole bunch of different performance benchmarks for Python and ran them on Python 311 beta, which this is the thing I was hinting at. Like you might really want to consider this for if you're thinking, should we upgrade from nine to 10? Maybe you want to just go straight to 11. Right.
I mean, you know, sort of a side thought, Brian, isn't it awesome that the one that goes like crazy performance, this one goes to 11. All right. So they show all the stuff that they're testing on, like AMD Ryzen 16 core 32 with hyper threading the motherboard. I mean, like down to the motherboard and the chipset and the memory and all that. So a pretty decent stuff. And then also the build commands and all sorts of things here. So pretty repeatable, I think.
Yeah. Rather than just like, hey, I ran it and here's a graph without, without axes or something like that. So you can kind of click through here and you see some pictures and it says, all right, well, there's the Pybench, which I think is like the standard simple one. It says, look at this. The Python 311 beta is faster than 310, which by the way, was slightly slower than the previous ones. But you know, what is that? 10% or something. So already actually 16% better.
So that's already pretty awesome. But there's a whole bunch of other ones. They did one called Go. I don't know what these benchmarks are. This does, I don't think this has anything to do with the language Go, just the name of the benchmark. And then there's two to three and chaos. That one sounds like the funnest. But if you look at this Go one, this one is like almost 50% faster. 50% faster. That's insane, right?
Yeah. Wow. And you come down to the two to three is, these are all estimates, 25, 20% faster, say 40% faster with the chaos one. Come down to the float operations and Python 310 was already better than the others. But this is again, maybe 30% faster. And let's roll into the next page. You just kind of see this across the board. Better, better. Some of them are super better. Some are like a little bit better, like Pathlib's better, but not crazy. Ray tracing is like, again, 40% better here.
And you keep going. There's another one with this huge crypto IAES, some sort of encryption thing. So there's just a bunch of, a couple of these are, there's like this one at the end, you're like, oh wait, this one got way worse. Be careful because it says more is better on this composition. I guess is the results here. Like how much more computing power do you get per CPU cycle or whatever? What is that? That's a massive jump.
You saw a little bit better improvements from 3.8 to 3.9, 3.9 to 3.10. But 3.10 to 11 is like a 40%, yeah, 41% better on the beta before it's even final. Wow. That's pretty exciting, right? That's very exciting.
And actually, I think, I'm curious what some of these negative comments are, but the interesting thing is to run lots of different metrics and lots of different benchmarks and having them all be, it's faster kind of means that, I mean, I take it as, you know, your mileage may vary, but it's going to be better for whatever you're doing, probably. Yeah. Yeah. Yeah. It feels like this is a thing you could just install and things get better.
The negative comments are mostly like, well, if Python was so slow, it could be made this faster than Python is a crappy language. It's pretty much, I've summed up like 65 comments right there. By the way, so I interviewed Guido Van Rassam and Mark Shannon a little while ago about this whole project about making Python five times, not 40%, but five times faster. And the goal is to make it a little bit faster like this, each release for five releases in a row.
And because of compounding, that'll get you to like 5%. So it looks like they're delivering, which is awesome. Yeah. This is good. Yeah. Well, cool. All right. Yeah. I think that's it for all of our items. Yeah. Got any extras? Um, no, I was going to pull up the, so yeah, the, the, this one goes to 11. If people don't know that that's a spinal tap reference. Yeah, exactly. All right. I got a few extras to throw out real quick. Python three, 10, five is out with a bunch of bug fixes.
Like what happens if you create an F string that doesn't have a closing curly and just a bunch of crashes and bug fixes. So if you've been running into issues, you know, maybe there's a decent amount of stuff in the changelog here. Nice. People can check that out. Also real quick, people might, if they're on a Mac, they might check out Raycast, which is a replacement for the command space spotlight thing that has like all these developer plugins.
So you can do like interact with your GitHub repo through command space and stuff. You can create a lot of things. And there's a bunch of extensions. Uh, like, this thing's free, at least for not for team, if you're not on a team, but there's a bunch of different, things you can get that are full, like managing processes, doing searches, VS Code project management from command space and whatnot. So I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things.
I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things.
I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. I'm going to do a lot of things. which ties really well back to the PSF survey. We talked about, well, what framework do you use? What data science framework do you use? Or what web framework do you want to use?
Django or Flask or FastAPI or what? So here's one that is a pretty interesting analysis. And the title is, why wouldn't you choose Parrot for your next application? Not a framework, but literally a Parrot. And this is compared to machine learning. So it has like this breakdown of features, like a featured table. And it has a parrot, which literally just has a picture of a parrot. And this is machine learning algorithms with a neural network. And then it lists off the features.
Learns random phrases. Check, check. Doesn't understand anything about what it learns. Check, check. Occasionally speaks nonsense. Check, check. It's a cute birdie parrot. Check, fail. Why wouldn't you choose this, Brian? This is funny. I love it. Yeah, it's pretty good. Pretty good stuff. I actually reminds me of like, I have to pull up this article. So I was reading about some machine learning stuff to try to get models like even closer and closer to reality.
There's a whole bunch of tricks people do. And then, and then there's some analysis of like, sometimes it's actually not doing anything more than just a linear regression. So, yeah. Try simple for an if statement. Yeah. Yeah, yeah, yeah, yeah. For sure. They're using artificial intelligence to make the computer decide. No, it's an if statement. Like, it's just computers deciding things the old fashioned way. Yeah, yeah. Awesome. So. Well, thanks for being here. All right. Thank you.
Thanks everyone for listening.