Django Survey 2025 - Jeff Triplett

Speaker 1: Hello, welcome to another episode of Django Chat Podcast, vodcast actually, on the Django Web Framework. I'm Will Vincent, joined by Carlton Gibson. Hey Carlton.

Speaker 2: Hello, Will.

Speaker 1: And we are very pleased to have Jeff Triplett, friend of the show, back on to talk about the Django survey. Welcome, Jeff.

Speaker 3: Thanks. Good to be back.

Speaker 2: Yes, good to have you. Good to have you.

Speaker 1: So we're going to talk about, let me pull it up here. The Django Developer Survey 2024 results. We're going to go through this, talk about what it means for the past, present, and future. Of Django. Before we get to the survey, Jeff, you just um we were both at DjangoCon US and you're former president of DEFNA that runs DjangoCon's. And I know you just had a recap. Is there anything you wanted to mention about DjangoCon US and how it went for people who couldn't attend?

Speaker 3: Yeah, it was a wonderful year, I think. Um If I was putting it over all the 11 years I've been around, I'd say it was on par with like a San Diego experience. Uh you could argue it was better because I think this is the first time uh if you're not into US like sports It was magical because you had like three or four different professional sports. It's the one week of the year where everything overlaps. So people could go watch US football, uh Monday night football even, which is really rare to have. People were going to baseball games at the Cubs. Um women's professional basketball, the last game of the season was the same week. And so there were people taking posters. There were people Chicago Bears. I think what is the women's game? The Sky maybe. Chicago Sky. Seems like that's right. There was just a lot of like interesting things going on outside of the conference too.

Speaker 3: The conference was great. If you couldn't find, you know, four or five talks that you really liked, then You need to look inside. Yeah, clearly it wasn't us. No, it was good. It was a really great venue. It was downtown Chicago, which made everything really accessible. Uh you could walk by the river. Most people don't realize Chicago has a river, wouldn't swim in it, but it was it's pretty pretty cool.

Speaker 1: No peep people just did though, right? They just for the first time in like a hundred years, they had a swim. I still wouldn't do it, but uh people did hop in and I don't think they were all you know, getting sick after.

Speaker 3: Yeah, keynotes were especially good. I think it kicked off a lot of interesting topics this year, discussions that will go on outside the conference that you will be covering for months on your show, I suspect. And also we will be back in Chicago next year, September 14th, I think through the 18th. And DEFNA right now has a call for proposals. We can probably get out. Which is going to be looking for where DjangoCon US will be in 2027 and 2028. So I think that runs through mid-January, but submit sooner than later. So it was good.

Speaker 1: Yeah, I mean the only thing missing was Carlton from my experience. But you know, in a way, maybe that freed me up because it forced me outside of my comfort zone. So I ended up spending Uh a little bit of time with you, Jeff, a bunch of time with the the with Natalia and Jacob, the fellows, and um hallway tracking. I I think the only thing I would say that is unavoidable with the space is it was on two floors. So There's a bit of up and down, but I think that also increased interactions. You'd run into people in the hallway or in the stairwell. Um, and there was that really nice big facility upstairs where you could watch games and stuff after. So um yeah I gotta I gotta hang out the facilities after a day or two.

Speaker 3: Yeah, it was a really weird layout to start with, but once you understood like elevators are hidden in places that weren't obvious. But like it kind of took like the first couple of hours that you're there. The first time you change from one room to another, people pick up on it Uh Carlton, it was like we were in a basement on the fourteenth level, and then the fifteenth level was like sunlight and very open. And you were like Middle of Chicago seeing skyscrapers and stuff. It was really surreal to like give a presentation and see like a huge building in the river beside you. So it was pretty cool.

Speaker 1: Yeah, we and we featured there were a number of good uh recaps with photos of the conference. Maybe I'll put a couple of them in. Um KD did one, I did one. I'm sorry, a bunch of people did ones that we'll link to. All right, anyways, let's talk about the survey. So let me pull up the window. So Jeff, you're you're current board member, among other things. Um what's the board perspective on on the survey? Is like how I don't know. Were there any take I let me re rephrase that? Were there any things that jumped out jumped out at you as, oh, that was a surprising result in the survey? And then we'll get into the details.

Speaker 3: Um hit me with a good one from the start.

Speaker 1: I can give one if you want.

Speaker 3: I think I've had some bias for a while about HTMX. And kind of pushing people. And so I'm in a unique position with DjangoCon US. I usually write like a blog post and say like, I would really like you to talk about these subjects. So HTMX and seeing that rise is confirms my bias to what I've been seeing as a consultant for the last four years. So I think there's also with surveys, you get people who like to fill out surveys And I think that is also a useful metric, but I view it from that lens of what do I see with clients and what do they want and what works well for them. And so seeing that crowd either catch up or kind of confirm that is really useful for me. And I think for the board too I think what I don't know if you want to talk about now or later.

Speaker 3: I think there's going to be a push to maybe get the survey out early next year. And so we're going to get data that's a little more because right now a 2024 survey when it's almost 2026.

Speaker 1: Well it was yeah, it was end of I think it was it was November to January. Um but yes, definitely you and I and uh the PyCharm team have been working on this. The plan is for sure to get out early. next year and have their results in the survey ideally by the summer. So I I think that's very doable. So yeah, it's worth yeah, worth mentioning it's all a little time lagged, the results here.

Speaker 3: Yeah, HTMX is really good, uh the C. I think there's a whole lot of like AI growth we're not gonna see here yet because of that delay

Speaker 1: Well there's still some we'll get to that. Yeah. But

Speaker 3: the uh general experience level too of developers and seeing, you know, who again who likes filling out surveys was uh

Speaker 1: was it forty forty five hundred people filled it out, so that's almost overlaps with our j with with our Django news newsletter amount. But yeah, yeah, I mean I'll just say something, Carlton, and then and then your hot take. I mean Because here goes podcast bingo. Because I work at PyCharm, I also helped out and was involved with the Python survey that uh JetBrains runs for the Python Software Foundation, the PSF. And so I took a lot of looks at that. And one of the striking things was over half of the respondents had less than two years of experience. So that one had 30,000 people respond, but it was pretty much polar opposites of responding. You know, the Python survey, if anything, I felt was a little

Speaker 1: more towards people who, you know, who hadn't coded much. Um and then this Django one, the biggest bucket by far was people with, I think, 13 plus years of experience. So there's some self-selection, but I think also it makes sense. Django is like you don't jump to Django, you go to Python first, and the Django community is I would say has beginners but a lot of experienced people like I don't know the three of us who I'm sure all filled out the survey. Go ahead, Carlton.

Speaker 2: Well, time and again you hear people, why are you using Django? It's like, well, because of the stability, because of the long-term you know, the long-term nature of my project, and that's proven dividends over the years. We chose it and we've stuck with it. And you know, th these kind of stories are the bread and butter of Django. Django. And so

Speaker 1: yeah.

Speaker 3: No one gets fired for using Django, right?

Speaker 2: Well, and

Speaker 1: if you're on if you're on, you know, the orange site, Hacker News, no one's You know, like once or twice a year, it's like, oh, Django's still there and great, but it's not it doesn't get any of the buzz amongst, you know, college kids or whatever out there. Um I think and I yeah.

Speaker 2: Just with the survey, like with the sampling, there's always going to be a sampling. So you know when you read the Python survey results, it's okay, take that 50% and think, okay, that's that's an interesting sort of tell on how they how they the res um respondent base was skewed. Well okay it doesn't invalidate the survey at all but you need to make hold it in mind. And the same here I think we'll come on to the um you know which version are you using question And it's like well we we know that doesn't quite correspond to what the wider user base are using because we've got the PyPI download stats and You know, this is that this is a much more engaged than average responder base. Now that's okay, but we need to bear that in mind.

Speaker 1: Yeah. Well maybe let's let's finish up on HTMX and Alpine. js. So for those who don't know, Carson Gross, who's the creator of HTMX, gave the opening day keynote and Alpine JS, you know, you don't have to use you don't have to use HTMX with it, but often if you want to go to the next level to manage your state, you do. I mean, one thing I think about is that a lot of Django People are small, medium shops in a way where it's really valuable that you can single-handly do full stack. If you're at a huge company, you're sort of by definition going to be doing a single page application. And a lot of the time that's who writes the blog posts and people see online, you know, what's open AI doing. And but that's not the reality for Many developers. So I think it's also worth saying that Django

Speaker 1: skews towards I mean, even at the conference, there were people from big companies there, but there's a lot of small medium consultants. Using Django to do really high-scale websites, but with a minimal amount of developer time. So that's probably another reason why HTMX is so valuable, right? I mean, if I was a professional React developer I probably wouldn't be as excited about HTMX as I am as a Django developer who's like, oh, maybe I don't need React as much as I thought.

Speaker 2: Yeah, no, I mean I talked about this in my API maybe talk from last year. Was that Starting with HTMX and Alpine, I've been able to do things that pre that two, three years ago would I would have been like, well, I need a front-end developer as well. I need two teams. I need to build an API and I need a front-end team to build on front of that. And I I've hardly got a JSON response in the entire application. Two and a half, nearly three years in. It's like it really has changed the world. And you know, uh I made the the argument that post-zero interest rates, it you know, that gives that gives us back a nice advantage in that, you know, we can make a business case for a much tighter um approach in terms of financial outlet.

Speaker 1: Which is

Speaker 3: the trend I've seen for a while too. Sorry? Go ahead.

Speaker 1: Sorry, slight lag. I was just gonna ask if clients ask you about to use HTMX or you present it to them.

Speaker 3: Um we've got two trends. Uh one is AI changes everything. And so people do care about JSON right now. And they will, they'll continue to. The bulk of the clients I've had for the last couple of years, they wanted to get out of like maybe they're smaller or they're bigger, but they want to move faster. They don't want to like have parallel like why are you doing all the work with Rust? And then having other developers do all the work with JSON and or sorry, like a React framework or JavaScript frameworks. So for them, it was mostly like, what are our options? What is the size of this? especially if they're dealing with like yeah you know their internal tools for their companies that has a quite that has a different user experience than um here's a portal I'm going to use for managing my SaaS application And so it kind of depends on how much bells and whistles that they want.

Speaker 3: So most of the time they're just coming and saying, what can you build for us? What's the timeline going to look like? And if I give them a like, yeah, sure, it'll be two months with React. I need a month or I need two weeks to do all the JSON APIs, I'm going to hand it to you, and then your team's going to run for a month to do React and then bring it back to me. Or I can say, why don't I just do this with HTMX and we just do this as a and Carlton's Neapolitan is a great tool to use for these crude apps. I can get it done two weeks. Which one would you take? Because it's significantly cheaper too. So most clients get it and they seek that out. And it just depends on team size too. You know, bigger teams may have a whole fleet of React apps or React developers. We have one now that's doing that, hundreds of models.

Speaker 3: And you know, we'll develop APIs for them and let them slice that data up the way they want it.

Speaker 1: Well, number two on our list, may we and uh with apologies to Carlton, we're not turning into an AI podcast. But it was clear even a year ago, AI usage is growing. I believe the stats here, let me pull it up. Where are we with our stats? AI usage. Oops, I should have had this ready.

Speaker 3: Yeah, and for people who didn't see the last uh little bit, HTMX was on kind of a nice growth curve, maybe plateauing a little bit, and React's kind of dropping amongst

Speaker 1: Yep, for sure. Um apologies. Here we go. So Uh this this was the section, so on AI, and it led with which of the following tools have you ever used? Um You know, again, a year ago almost 69% said ChatGPT, 34% copilot, 15% Claude, 9% JetBrains AI assistant, uh, and then cursor. I would have to assume that all these numbers are going to go up and I would suspect Claude in particular is going to go up. Um I don't know, Jeff, what do you make of this? I mean actually, can we mention you're you're you're an AI influencer now? You get flown out to the West Coast to

Speaker 3: sign into the U. I don't know what the hell that means. Yeah, I don't even know what the hell that means. Um Uh yes. Uh AI is we you could we could do a whole show on AI, so I'll try to keep it brief.

Speaker 1: Yes.

Speaker 3: AI is not going away. People have feelings, which I respect, about the bubble. We could get into that in a lot of detail in a different show. I think it's AI is very good at writing Django code and if you vibe code because of the way Python code's been consumed, Django code, the documentation for Django. lends itself to be something that if you whether you like vibe coding or not, AI is very good at vibe coding Django apps. I think Django is very important to these companies as well. I 've seen a couple of awards and I forget the names of them where there's coding competitions and they're saying, we won a gold medal for our testing. And if you look at what they're testing and what they're doing, 42% of the test results are coming from Django code and fixing Django bugs and problems with Django.

Speaker 3: And so even if these companies aren't like building applications with Django, They sure as well are like

Speaker 1: Django in contribution.

Speaker 3: Yeah. And I want to get there. That's part of what we're doing with the fundraising work group and the DSF now. But Django is heavily influencing AI, even if they're not building it with Django. They're testing it and they're bragging about getting, you know, patting themselves on the back for these coding competitions that they're winning. Saying how successful these are. So when you see that Anthropic or OpenAI says, we are doing very well, we are 82% with these programming, you know, that this level, 42% of that is how well it's it's dealing with bugs and what it's fixing the problems it's solving with Django. And so I think it's very significant to us. And you know, try vibe coding sometime with a Django application. It is really good at it. Switch to another framework like FastAPI and it's okay at it. But there's just 20-some years of knowledge of Django and documentation and blog posts

Speaker 3: that's, you know, compiled in.

Speaker 1: Carlton.

Speaker 2: Well, I don't have too much to say. Yeah, everyone's using it. Um it you know seems handy. I you know I don't have too much to add.

Speaker 1: I mean one thing I would uh the only other thing I would add on this is again working uh what what we s it seems that even as there's new models coming out all the time, so Uh Sonnet 4. 5 came out. I'm sure there'll be uh you know other ones. The trend seems to be slowing. They seem to be they're really good, but they seem to be, you know, not these huge emergent leaps that we had. And more and more tools, IDEs, so PyCharm, but all the other IDEs, are giving users the option to select whatever model you want for chat or for agentic use. And that's pretty interesting in terms of Maybe it's gonna be a little more commoditized or maybe the pendulum swings towards users deciding, but I think most users are not You know, you Jeff, or even me, or even Carlton a little bit, like they just want something that works.

Speaker 1: And so the current encyclopedia of choices and changes is completely overwhelming. And I suspect we will get to a place where their sort of defaults or can do things like scan your code base and say, hey, you want or you want to use a local model? Like we we think that this local model, given your laptop, is a good choice. You know, because right now it is kind of crazy. It's like it it's like the everything store of models, and most people can't make heads or tails of it other than most of them are pretty good.

Speaker 3: Yeah, and I think like if you look at how accelerated it's been, um, I know there's this, I'm not sure what your expectation level is, but like we've had two major anthropic model releases in the last like 60 days. And each one has raised that bar by like two to three percent. And so if you look at how much we're gaining year over year, it's quite a bit. But now that we're getting like within 80 some percent, meaning most problems you throw at it, it can just solve and do. Um it's kind of hard to gauge. But we've also had like OpenAI has released a couple of big models in the last 60 days. Some of the like Deep Seek 2. 1 or 3. 1, I think it's 2. 1. I've been playing with it through the cloud.

Speaker 1: The 600 million parameter one. Yeah.

Speaker 3: It's it's amazing. And so some of these models, it's it's really getting to a good point. And so if you're just trying it out now, I think it's interesting. What the survey misses though is a lot of the CLI tools, which I think is where AI is really good. I don't have a lot like using copilot and cursor and an IDE. Um I I it this doesn't do it for me, but when you get to the CLI based apps, I feel like those are really good and and more effective And we won't make this an AI podcast and move on.

Speaker 1: I'll just say the promise of, you know, for example, PyCharm has Juni is that we can use analysis of the project that we have through the IDE to be more efficient with the tokens. And so you can have equal, if not better, performance and lower cost. I think that's that's what all the IDE companies are going towards. That's what we're going towards. So there's something to that because Claude Code, you know, and stuff uh and copilot, they're happy to just infinite tokens, infinite cost, and not worry about worry about all that. But uh people who use these heavily, you can easily spend $100, $200. you know, a day if you're slamming a big code base. So I think that will decline. But anyways, I'm curious what the survey will say next year on this, for sure. So we touched upon Django developers being more experienced.

Speaker 1: Number four on our list and Carlton, you're on the steering council, uh type ins. So there was again survey respondents, but it wasn't even close in terms of response for type ins. I know this is something the steering council has been talking about what what is there to update on on that?

Speaker 2: Well um so again it's the you know the group the cohort is like um a more engaged leading edge cohort so uh an an innovators um leading edge type early adopter type so okay we need to um you know take that with a grain of salt but Yes, there's lots of people using type hits, there's lots of people s wanting to see type hints in play. The question is how? Um And so uh y you know, it's something we're gonna talk about or will have talked about by the time this came out of Django in the Med. Um I'm gonna get Simon Charette in the room who's got ideas about the ORM and You know, very I've got ideas about um types type um type safe serialization. Um I don't know who else is gonna be there There are there must be approaches that we can take.

Speaker 2: But Django being Django, we're not just gonna be able to, you know, whiz through, rewrite the ORM in some totally, you know, type-safe way. It's It is dynamic Python at its best. And you know, as it says in the MyPy doc somewhere, there are patterns, there are dynamic patterns in Python that are simply not expressible with Python's type system. And so y Django fits right into that description and or or Django as historically written. And the ORM's the key bit, right? Is you know, if you if you're in your view, how are you gonna How are you going to get type safe things out of it? That's the that's the big challenge. And if we can, if we can add a type safe layer on top of the of the ORM, then

Speaker 2: that would feed into the to the um the model objects you that you're consuming not model objects but that that query layer objects that you're consuming in your views being type type safe and then well your views could start being type safe you're like okay we could have you know The query parameters come in that those those given gnome types. We could have or any of these things we could start to introduce. But there's some hard questions to be answered first. And then with Django, it's it's a question of how do we get those into the codebase because we've got the stability guarantees, we've got the API stabilities, we've got the long-term support policies. It's we can't just rip it up and start again. Um so don't know. But I think it's an exciting time and I think

Speaker 2: Typing in Python has come on a long time away from five or six years ago when the steering council then last looked at it. Um it's a lot better. And a lot of the rough edges have disappeared. And so I think I'm optimistic that we can make progress.

Speaker 1: And there's new types. I mean, just this year, right, Astral put out Thai. Um, Jeff, you would know there's another another one came out. Did Facebook put one out as well, I believe, or Meta put out one. So it's

Speaker 3: a no

Speaker 2: time.

Speaker 1: I mean the one thing I would say is I'd I'd and I don't think this is the direction people are saying is I just wouldn't want it to be required because one of the powers of Python is that you know you can ramp on, but we're not if we turn it into Java and C, it's kind of not what Python is to me. So

Speaker 2: the uh the original peps here about typing, they said that um uh pyth types will never become even by convention um required, right? And it's that that bit of the original pets of kind of not well, they kind of are required. They you know it it has become conventionally the case that you do need type Pints. But dynamic Python is still a valuable thing. That there are some core cases where you want to know Um I mean I don't know take the take the data types coming out of um a form. So you go cleaned data and you get an untyped, totally untyped dictionary there. And you get no help from your IDE and you get nothing. Whereas even if you've got a typed diction dipped out of the clean data so that the type checker could go, you know what, I was expecting a name field, not a noom field.

Speaker 2: Oh, because I mistyped it.

Speaker 1: Well, but this is the concerns of an experienced developer and an and a beginner, right? But

Speaker 2: yes, but if if Django just gave you a typed stick, typed stick instead of an untyped dick. out from say your form as one example. Then as a beginner you would just get that type thing but and I you know VS code everybody might be using. Well it it will tell you by default hang on there's a an a key error here because we're we're expecting you to use name not num oh yes it's a typo and that can't be picked up Without typing place.

Speaker 1: Well Jeff, you would say just Pydantic, right? You're big on Pydentic.

Speaker 3: I I like it. I think it is the next Django level uh framework for Python. Um and if you look at Pydantic AI, it's good for AI. I think data classes, I think there's a lot of built-ins that are fine. There's probably three or four libraries out there competing specs, but Pythonic is the one that I like. I feel like it's optimized. It's just a nice developer experience. As far as typing goes, if you look at kind of this next generation of tools that are using typing by default, they look very different than what we do with Django. Now this isn't like RAR dinosaur Django 's old, but look at like the Python typing library. It really changes and typing is I don't like the name of it, but basically it's a way that you can use type hints on your your Python application so that you can expose options and arguments to the command line.

Speaker 3: So you can write really good command line apps with it. So if you want a Boolean, you don't have to figure out arg parse. You can just say, I want a verbose colon bool and give it a default. And it will know when you run your application-help. it will show you that you know you can do that dash revose and this is true. You can use type hints with it in a way that feels very natural. You get all the benefits and you don't have to write code. It makes you look at Python and go, Why hasn't it always been like this? And so I kind of see the future and I see like we're in a good place if we can start there. Now trying to slap that on Django that's been around for 20 years, this is the raw dinosaur part, that's tough. And I agree with all the reasons. Carlton Hassan, um whether this becomes a new layer, or maybe somebody like there's the nano Django

Speaker 3: project, which is trying to make a you know, like a more lightweight version of Django or Flask experience for Django. Maybe somebody comes up with something that utilizes types by default. We've seen this a little bit with Django Ninja in APIs, but I don't think they quite go into it enough. I see a world where somebody writes this and the pattern becomes more obvious. And then it's not like, oh crap, I gotta support this for my IDE so I get good completions. Which is great. And it becomes more like I get all these great benefits because a query set can turn into JSON or it can turn into Toml, and you get these side benefits for free because it's what typing lends you. So I like the developer experience, I guess, is my too long didn't read it.

Speaker 1: Fair enough.

Speaker 2: Yeah. Anyway, I agree with all of that. I think there's a lot going. There's a lot of possibilities here. And I think just from a as a from a sort of steering council hat-on perspective, it's it's it's come a long way in the last five or six years. And I think it's time to seriously have the discussion again about, okay. What does typing in Django look like or what could it look like?

Speaker 1: So continuing onward Databases. So I think no surprise Postgres and built in ones are way in the lead. It's interesting that Oracle's growing. It's small, but it's still growing. Um, I anecdotally I don't that doesn't match with my experience, but you know, I have blinders on. I'm I just haven't heard anything about growth around Django and Oracle, but I guess it speaks to continuing to support Oracle as an official backend. I don't know if either of you have theories on on the bundle there.

Speaker 3: I think this is our bubble. You know, I think that you've got real-world users who use this, who don't take surveys, and we don't hear from as much. And so I think the growth was what, from three percent to seven?

Speaker 1: So it's seven percent now. Yeah, went from two percent in twenty twenty-one and twenty twenty-two and then up to six percent last year, seven percent this year. So that's you know, it's It's 76% for Postgres, 42 SQL Lite, 27% MySQL, MariaDB is nine, and then Oracle, and then Mongo. So it's, you know, 7% is For real. Yeah, no, definitely it's I mean definitely my bubble. Um

Speaker 3: and I'm not sure what other frameworks support Oracle, but if you look at the PyPI stats on it. Uh made up number. I feel like it was almost as many people use the Oracle driver as Django. I'm probably off by maybe half. Maybe it's half as many people. It's a large number of people who use the driver. Um I wish from a steering council or just I I wish there was a better way to defer what that means. I don't know if that's like if Django could support some level of saying like it I'm not suggesting like we remove these database drivers. I wish there was a way to be able to measure that. PyPI seems to be one of the more accurate ways we have to measure that. Because there you there's a there's ways that we can say like take CI stats out of it and let's just get real usage stats or what we as close to real as we can get So like if anybody comes up with a clever way to be able to measure

Speaker 3: how many people actually have the Oracle driver installed with Django, same thing with MySQL, MariaDB, all of these would be just super useful, even from like a board level. So we kinda know, you know, because I would love to fundraise off of this this information.

Speaker 2: um just in the news the last week or so for being now the you know world's most valuable company or something or they've tribled their value or I can't remember exactly what it was or They've got

Speaker 1: the CEO is was the richest because they're going to be doing allegedly all the open AI data centers. Yeah.

Speaker 2: Right. Okay. So there was that was why the where they go on the new. But the thing is, Oracle is a big company. It's used by in a lot of a lot of um co um enterprises they're using it and um i think it does Django well to have um Oracle support as you know as first class. I would love to, you know, if we could somehow make it happen, I would love to see us have um Microsoft Server um and the server um support as well, or a dual server, SQL server that you like to call it. I'd love to have that. um as built into Django because I think it's a gateway for Django into these environments where there is a lot of money available. And then there's a second question about how we get some of that money. But I think it's important for Django and I think it's good and I would be personally I would be sad to see it taken out.

Speaker 2: I think that would be a um I think from an open source and from a you know volunteer-only basis, and there's all sorts of arguments as well. We might get rid of Oracle support. I think that would be an error for us. I think you know, long term it's been a good thing for the framework. And um We should find a way to keep it.

Speaker 3: I think a challenge we have to uh speaking with my board hat on is Our fundraising is something that we we've added a third fellow this year, and Django was unsupportable, it was untenable to continue with two fellows or one and a half fellows. So we've had to raise that. There's been some criticism about the way that our fundraising page is laid out because it doesn't really emphasize that you're supporting the fellows. And so in the next couple of weeks there should be some changes to that to help support companies because we say we want like Oracle and these companies to support us, we don't make an easy business case for them because we send them something and it says donation. And donation is going to help go to sprints and do things. And so I think we have to build a better business case for them. And that doesn't mean we won't still do these things.

Speaker 3: We'll support these things. But you know, like a sponsored fellow is just an easy win. I would love to see a sponsored fellow. That doesn't mean somebody works for these companies. It just means we give them a way to actually pay something to get a business case off of it. Like if it takes nine months to review pull requests, I suspect we could figure out a way to make it not take nine months. to review a pull request of a company's sponsoring. Doesn't mean they get any features that they want, but this this is the kind of things we're working on from a board level because we want to be more realistic about how we get our funding. And you know, thankfully the community has been beyond receptive and supported us for this long. But I think we can also make a better business case that we can get a better level of more sustainable level of funding. And I just think that's good for all of us. It's good for everybody.

Speaker 3: Good for the community.

Speaker 1: Can I just say I think we're all wearing DjangoCon shirts. Carlton, you have an older one. Jeff

Speaker 2: Barham, 23.

Speaker 1: Jeff and I

Speaker 2: got 24.

Speaker 1: 25. Oh

Speaker 2: sorry, 25. So this must be 24.

Speaker 1: Yeah, you have 24. Yeah, yeah. I was gonna just wear it, but it's fall here and it's getting chilly, so I put this on.

Speaker 3: Got the Durham bowl on, so that was a good one.

Speaker 1: Yeah, sorry. Um Okay, well said. Third party packages. So again speaks to the who responded? Django Rest framework was The big one by far, but it was sort of the usual suspects.

Speaker 2: Just go j sorry to jump in there, but it is the big one. Like so um Jeff was talking about um PyPI down uh download statistics. Django is in um sorry, Rest framework is installed in over half of all Django projects. So it's like you know more than fifty percent of Django projects are using DRF. Yeah,

Speaker 1: so

Speaker 3: at DjangoCon I pointed this out too and And so people listening understand it. A majority of people install Django through Django Rust framework than they do just doing a pip install Django or UV install Django. When I see clients, most of them have Django Rest framework in the requirements file. They do not have Django in their requirements file. And it blows my mind when I see that.

Speaker 1: Yeah. Yeah. So I just want to plug, there's a really great ecosystem page that the board and others put up. Um we'll put a link to it that links Resources, you know, awesome Django repo that Jeff, you and I do, Django packages, which you do, Jeff. Jazz band, Django Commons, Django Girls. Um, I love that we have this page and I would love to see it a little more prominent. And there is some work on the forum, some some efforts around maybe doing something on the homepage, but you know If I had a magic wand, I would want this page to be on the homepage in some capacity or just like it's such a good page. And I I know how much work went into curating this and I agree with all of it. I think if people

Speaker 1: Saw this as one of the first couple things they see as part of Django, it would help Django a lot. Can

Speaker 3: you show that on the vlog thing we're doing?

Speaker 1: I probably can.

Speaker 2: I'll just do my little rant while you're looking for it. But like I I you know, I honestly believe that we can't um scale Django's Corbit like what Django Django itself, you know, when you pip install Django, what you get we can't scale that too much. We can't we can add small features and we can we should probably take some features out to create a bit more breathing space. But um We don't need to. The ecosystem is big and large and it's there. But when you turn up at the Django site, you just you've got no idea that any of it exists. And so the goal was to try and give an in-road. And this is just the first version. It's not as glamorous as it could be on everything, but this was our st the steering councils take of light, you know, these are the some of the some of the highlights and lots of links to other resources so that you can find more. But the goal was that somebody could go through this and discover kind of the richness of the Django

Speaker 2: ecosystem. And I think if we can promote that as a community, this idea that, you know, somehow we're lagging or that we're st we're static or that we're, you know , with whatever whatever negative vibes go might go around at times because Django is old, those could kind of disappear because actually the ecosystem is really vibrant. You know, th th there's always new packages coming up and you got you you folks do a good job of promoting them in the newsletter and whatnot. But if you're a newcomer to Django, how do you even find the newsletter? Well, the ecosystem page does at least mention it, right

Speaker 1: For sure. So

Speaker 3: you're doing some work to get this bubbled up in search, because that's the other problem, is like there has to be some visibility. And people don't care who are outside of our circles. If they go to the website and they see search and they click on something, they just want to find that data. They don't care that Oh, this is buried three levels deep. And so I really appreciate that Tim's doing this to try to bubble it up. Same thing happens with Rust. You can do Rust with Django, but you wouldn't know it from searching our documentation. And so I know part of that effort is to link to a couple of blog posts that show how to do rest with Django. And if you look at like Django's overall stats, which isn't captured here. Uh you know, Python has grown a ton. You know, Python is now the most popular programming language on the planet. And it's grown at least 26% over last year. So it's significantly larger than everything else.

Speaker 3: Django's overall download stats have plateaued. And FastAPI a year ago was smaller than Django. And now it's 10 times larger than Django. Now I don't think that we have to grow 10% or 10 times. But I feel like we're missing out a little bit. And I think because of like that information that we already it already exists, we know about it. We need to do a better job of telling people and showing in the search or maybe If somebody's listening and wanted to do a really good rest how-to, there's a how-to section in the docs. We show people how to do CSV files and generate it and consume it, I think maybe. Uh but we don't tell people how to do REST. That how to would be a very, very important page to help people make a decision because they're going to Fast API and then they hit us up at conferences and say, How do I use the Django ORM with Fast

Speaker 3: API? Which is absurd. Absolutely absurd to my core that that is a thing. I

Speaker 1: hear that all there. Yeah.

Speaker 3: Yeah, we can totally get there. And I bet you in a year, Django would grow a lot. We don't have to focus on growth. I just don't want us to stay at a point when Python is going, all these other web frameworks are going. And Django is is actually better at doing a lot of the applications that people are trying to build with it.

Speaker 2: We're all vested in the Django ecosystem, but it I think you know we could make the case quite um well that for a lot of use cases Django is a better choice is than you know other thing other things. Why well RM admin good for building the other things around your website that other than just the rest of the endpoints. But Being able to build REST endpoints and consume APIs and all those other things, those are core use cases for the web. Django needs to have a good case for supporting. It's a batteries including

Speaker 3: I want to quote that very large font so big that it doesn't fit into the screen. And so that's yep.

Speaker 1: All right, let's get through the last last couple here. So Latest version of Django. So people said they were on overwhelmingly on the latest version of Django, which um That's nice to see. You know, we J Django fellows and the community put a lot of effort into the long-term uh releases, guaranteeing around three years. So those are the 0. 2, so 5. 2 and then 6. 0, 6162 will also have long-term support. I feel like that's if I had to pick one area of the survey, I was like, oh, I don't know if you know, 70 -80% around the latest version, that would be the one that jumps out at me.

Speaker 2: For me, that's the tell that the the aren't the the the responder base is the very most vested in the in the community. We know from again from the Pi uh PI downloads that at any given time, depending on where we are in the in the in the release cycle, between 50 and 70% of people of downloads are for a supported version of Django. And that drops. That will drop now because we've just released um or six point six point oh is in pre-release now. When six point oh goes final and we finally drop support for four Django 4. 2, suddenly we'll drop Down, and it's only then that people start upgrading and they get to 5. 2, and then they hang, and we just about get onto that by the time the next uh LTS goes that goes out of date and they drop off again and it goes down and back up again.

Speaker 2: No way. Or 82, 80, however many percent on the on the latest version.

Speaker 1: Yeah, so

Speaker 2: ID user base.

Speaker 1: And oh Jeff, there's a quote from you here. But yeah, it's so it's 75% said they're on the latest stable release. 21% on the LTS and 3% on the other. So yeah.

Speaker 2: Next just for next year, this how often do you upgrade um Django projects? I'd like to um ask two questions there. One is like, do you upgrade to you know to the latest major release or do you hang around on the LTS? That's kind of that's one question. And then the second is each month when the point when the little point releases come out, do you upgrade those? Like all the time or every few months or when there's a security release or you know to get an idea of how quickly people are jumping on the point releases as well. That would be a nice differentiation there.

Speaker 3: I bet this is mostly tooling led too, where people adjin go to a project and they're just not upper bound pinning anymore because I don't think they get bit as much as they used to. Like they get warnings. And so I suspect that's part of it because when, you know, after 6. 0 is out, 6. 1 's gonna have a few warnings, but like with the LTS cycle in general, we're letting people know ahead of time. I just think the barrier there isn't as high as it used to be, and people are probably lazy, uh like myself. And they use CI and CI catches so much of this. So that would be my theory.

Speaker 2: So I mean for as when I was a fellow, it was a big thing that we always thought about was um, you know, maintaining this stability policy and not Introducing break and change and making the upgrades easy because when I started as a fellow, the narrative was, oh god, it's a pain to update Django and I'm still on 1. 3, ho ho ho ho chuckle because you know and it was like a kind of badge of honor as the who was on the most outdated version. And five years later, by the time I stopped being a fellow, it was like, no, no, no, everybody should be on a supported version. And the kind of the the the um the mindset had shifted. Um And I think that's a good thing. And I think that makes it easier to bring the community with us.

Speaker 3: I think Python's been really helpful too, because I think they're stable releases and less change from year to year. My only critique of them is I really wish we would get out of, I know, so Python was three point something knowing that Pi was going to happen at some point. And so the 314 release is why they've doubled down for years and said there would never be, they would never jump to four, never jump to something else. There was a CalDAB spec for a while, and that proposal gets thrown around every once in a while. It's called a PEP. And there's a pep where they've tried to decide like, should we rename Python to be like Python 25? Because that's when Python 25 will be. The answer to that is no. They're not going to for the foreseeable future. But I would love to see if this trend continues, it would be really amazing to say what version of Django are you running and say, I'm running Django 26 or Django 27.

Speaker 3: And that name, that value has meaning and a release date would be amazing to get to that.

Speaker 1: Well, we talked about that in the latest episode a little bit. So yes. You're speaking to Carlton's language.

Speaker 2: I'd call it like something like that. I don't I haven't I haven't seen yet the the kind of the the the one that gets it, but I I I see Um every time we get to a 6. 0, I see people commenting on you know the the various comment places, oh but this isn't a major release, it's just the same as the last one. There's no difference between you know, 6. 0 versus it could have been 5. 3 just as meaningfully. And then it doesn't, I can't remember without looking. When was 2. 2 released? Any idea? No idea. I'd have to go and search through the archive. How out of date exactly am I when I when I see that project? I don't know. I can't.

Speaker 1: Yeah, tied to tied to the actual year sounds sounds nice. Maybe maybe we go to an annual release cycle then instead of eight months, though. I don't know.

Speaker 3: That would be I think that's the point that would be yeah more contentious. But I would love to see it because I think LTS, as stable as Django is, we can start to make that like here's the cycle we support two or three years. And it's just always rolling. But that that's a again, that's the thing. No, I'd love it if

Speaker 1: I'd love it if you just, yeah, exactly. If you know Django 22 is like, oh yeah, Django 2022. So if

Speaker 2: if anyone out there has got like the the the clear idea of the hip, do suggest it because I don't I don't think there's too much resistance to a possible change, but no one's yet suggested like the, you know. Oh yes, that makes total sense.

Speaker 1: Okay, testing. Let's uh so pie test reigns supreme at 39%, followed by unit test at 33% Then PyTest Django, which is a package to do it. 30% coverage, 21%. And then um Django Test Plus at 12%. That's that's a Revsys package. Now, Jeff, you're the you're the PyTest person in this conversation. I Don't use it much, if at all. Carlton, I believe you're also PyTest Lite and you're or maybe

Speaker 2: Yeah, I'm coming round to it because of playwright, to be honest. But um I still write um I still write kind of unit chess style things. Even if I'm using the the the PyTest runner, I'll still do my arrange. Act, assert, kind of formula within the test because I've worked on big projects and what happens For me, is the fixtures just go missing in action. I'm like, we're spending ages trying to track down the fixtures. So I like to keep the scope of the fixtures very close to where they're being used. So I still write tests in that style, even if I'm using PyTest. But yeah. I see that's very popular. Can't quite work out how Python itself could adopt it or how Django could adopt it because we've got a custom test runner and the move to PyTest would be a big

Speaker 2: a big project.

Speaker 3: Yeah, if if you only use PyTest to run Django tests, uh even if you're not fully embracing it, I think it's a better developer experience. I can't speak for how you test code with the Django, Django's itself. And the other trend that I see, I think I've mentioned on your show before, is that people who swear by uh class-based views seem to really like PyTest like myself. And then people who like function-based tests really like class-based unit unit test style tests. Yeah, Django Test Plus is just Django Test Plus is just a wrapper. It's just convenient features. It works with unit test. It works with uh Py test. Uh it works with both. Um I like PyTest a lot. I think well I think what Carlton tried to say too is uh

Speaker 3: PyTest fixtures are like a friend of me of mine. I hate them. I hated them for a long time, but I love them and I use them a lot. trying to figure out where you can expose fixtures so that they make sense to people because it just looks like here's this argument passed to a function. What the hell is this? Where does it come from? And that's something that just has a a weird UX. Once you embrace it and you use it, whether you define your fixtures inside the same test file, if you've got a config file you put them in that's next to your tests, you just have to kind of know where to look. Django does this in a few ways too with things like signals and how do I know what a models file is? Like where does this if you're starting from scratch in Python trying to figure out like Django does some things that aren't obvious either. And so I just kind of like embrace that by learning Django. So PyTests, I'm like, eh, where the hell are the fixtures

Speaker 3: at? Cool. You can declare and you can put them where you want them to be, is kind of what it boils down to. But they're so powerful.

Speaker 2: That's just code hygiene the same as always. If you put your code in silly places, you're gonna have a trouble finding it later, right?

Speaker 3: Exactly. I just find that I can write better tests with less code using PyTest and fixtures. And I like that function-based style personally. You can tab it over and put a class in front of it if you want to. You don't really need to with it is where I'm at.

Speaker 2: So here's here's a question. And I think it it's um it it's about Python and PyTest. But I think it reflects on Django and the ecosystem and the third-party package story versus in-core the discussion that we're always having in Django. If you do look at the Python survey, who's using PyTest? Well, it's It's like almost everybody and all the major packages use PyTest and all the um kind of headline Python developers that I follow and I you know really respect their judgment are like PyTest is the bee's knees But PyTest isn't part of the Python standard library. And it's like Python's number one testing framework or recommended test framework really isn't part, doesn't come bundled with the language. Well every other language out where the test framework comes bundled with the language. Why not Python? And so you ask that question. The answer is, well, we can develop it more quickly, and it's, you know, it's easy to iterate.

Speaker 2: And the trouble with the standard library is everything gets stuck and there's yearly releases, and that's the only update cadence. And everyone's happy with that story in the Python land. But then we come back to Django. It's like, oh no, everything's got to be in cool. Hang on. Which is it?

Speaker 3: I think it's the fundamentals of what Python is. And it's good that Python has some opinions about how to test. And I suspect someday PyTest would maybe come into or some some pieces of it are going to go into the language. Because that's gonna make it easier and faster for it to support. Um if what you're alluding to is like a rest story, um I think that 's What do you you know when when you think of using a web framework, if you polled, and maybe that needs to be the question, like what should a web framework be? Um half half of people are gonna say it's REST. Half are gonna say it should be able to do HTML templates. People, there's you know, there's probably people who've used DRF for ten years that don't even know why Django has a template engine. And I think they would be wrong. I don't want to see Django turn into Flask where it doesn't have any opinions

Speaker 3: because it's so hard to debug and it's so much harder to like write tests and try to figure that out. So I like your question. I think it's, you know, PyTest has moved at an accelerated rate. But I think we have to figure out like what are we as a web framework and what what batteries do we need? I don't think the answer is remove all batteries. I think it's remove the batteries people don't use, but we should be open to adding batteries that people need. What could be contentious here is go look at the Laravel community. They've added if you go to Laravel repo on GitHub, you can see that there's a slash MPC MCP, sorry, slash MCP. uh which is the you know restful way AI agents can wrap REST API calls. And so they are already supporting that now. They also have Breeze, which Breeze

Speaker 3: is their way to call Layer of L code, interact with the Layer Vel application using MC. And so I look at this and I go, in five years would Django support this at the project level, the repo level on GitHub? And that I struggle with that because I think we should. I think we should allow those experiments to go. I do like the path that you're talking about where third-party packages have to prove themselves. I just feel like the industry is moving at a different rate than what we are used to. And that means we're going to miss a little bit And I do think that it's fine to take some bets. I wouldn't mind seeing like uh it's been a while, like Adrian had data browse or data view or something a long time ago. And that was kind of like let's let's add this level of viewing the Django database and getting data.

Speaker 3: It's almost like Neapolitan, but I think it was more data CSV related kind of store.

Speaker 2: Simon's got a package SQL dashboard or something. Django SQL dashboard or Django SQL Explorer, which is very much like this. You can just sort of dig around from the admin

Speaker 3: And I and I think data browse was bundled in like Adrian when the last I I'm making up history here. I remember Adrian said, here's this package, I'm gonna add the Django, it's really useful. And it didn't work out. And he removed it. And I think that's fine to have these tests that we run. It could be that maybe it's Django dash experimental or just slash experimental becomes that, but I would love to see us try to swing and you know Try for a home run, try something that's new. Because I think these things are very relevant to the industry. Stuff like MCP. Some people listen to this podcast are gonna say, that's a bubble. We shouldn't support that. Um I'm just looking at this is stuff that other frameworks are doing I don't see where this would ever fit into how Jade Ghost Cadence currently works, but I think we should allow the space for people to make experiments

Speaker 3: and Sometimes it works, sometimes it doesn't work. Uh, if you look at like South, and you know, Andrew Godwin worked on this for a long time, that was a really rough path to get into Django, and at the end of the day, it worked out beautifully. But I I I hope that it doesn't take somebody 10 years to get something like MCP or get something that you know is valuable to the community and other frameworks already adopting. I don't think we have to look and do everything other frameworks do, but I would like to see us be more like aware of what is working in Laravel, what is working in Rails, what's working in FastAPI, and have those conversations.

Speaker 2: Yeah, no, I mean I my my agreement there is with you is all about the experimentation and all about the m enabling the experimentation. My my kind of take on that is that we enable that through promoting um external packages rather than trying to bundle everything in core. I think the the the answer I get from the the Python devs about why PyTest won't be merged into the standard library is because it shouldn't be there. In fact You've got your core thing, which goes slowly, and then you've got your your things around it, which go at a much faster pace. And I think we as a community can go at a much faster pace if we promote What's out, you know, the the the third party story, the the external package story, even if some of those are under the Django umbrella, whatever that means, you know, for officially promoted.

Speaker 2: Yep.

Speaker 3: I think that's also code for the Python process to get changes in is more than what they want to do. And I totally respect that. They should be able to run the project as they want. I suspect there's a time when development slows down and it's pretty stable. And it is stable, but I suspect it gets to the point where it's less effort and easier to maintain if it goes into Python. And maybe it never does, but that's my guess. Okay.

Speaker 1: So last one is looking ahead, you know, what should we what what should we what should Django include in the survey next year And I'll just give a shout out. If you're watching this on YouTube, you can put this in the comments. That will we'll see it and also it'll help boost the vodcast. But I would say uh UV obviously should be in there and it will be in there asking around packaging. Um AI, thinking about how we ask how people are actually using AI. And I do think there's too many questions. So I'd like to see fewer questions. I know that's I think it's a general consensus tr consensus around trying to make it not take so long. But As I've you know mentioned to the um the PyCharm team who also works on the Python survey, like this survey is really important to Django.

Speaker 1: This is the only real way other than vibes and hallway track and maybe Django in the Med that we have a sense of what the community is doing. So I do I'm proud to see what the surveys become. I guess is what I would say.

Speaker 2: No, it's super. And again, you know, I've said this about the Python study, but congratulations to the um jet brains for the effort that goes into it because they don't have to stamp up every year. It's a lot of work.

Speaker 1: It's a lot of work that they do.

Speaker 2: I think we have to, you know, acknowledge that.

Speaker 1: Yeah, and honestly, one of the big reasons I joined JetBrains is because I was on the board when the survey started and worked with them on this and also the promotion. And um yeah, they're good citizens with that. Jeff, anything I didn't mention that you'd really like to see next year on here

Speaker 3: Um you and I have spent months looking at data and like thinking about it. Um I'm inclined to wonder if we could just put up like a GitHub repo or something and get feedback on the actual question. and just see if it would be useful. Like maybe let the community kind of help with it. Also, like, I I wouldn't mind some more like long-firm questions just to let people like, what are we missing? And you know, maybe get some that are less like. Check the box because it's so hard with overlap of like what's your favorite third party package, what's your favorite testing? And there tends to be this overlap between the two, and we're only capturing what we know. And so I don't know how to fix that other than like Let's get more people telling us like these are tools we also use that should be in the survey and maybe get them to bad format for that, but at least it's a it's an easier loop than just a big Google Doc

Speaker 3: we share.

Speaker 1: Yeah, the data team at JetBrains, they're able to parse out and analyze long form for you know thousands of respondents. So that's a good point. We should do that. We're coming to the sh end of the show, our new thing, projects and books. I can start projects. I'm going to plug environs, which I think Jeff, you also like. This is a way to do environment variables in Django. I think Django dash environ is probably the most popular one. There's a couple other ones. I personally like Environs because it's relatively lightweight. You can, in brackets when you install it, uh put Django in there, and then it gives you Django database URL, a couple other things. Um I just like it. I have nothing against Django Environ I'd use either, but personally I like environs

Speaker 1: and I've messaged a couple times with the maintainer who's been doing it for a long, long time. I don't know if everyone's using I know everyone's not using environs, so I'll just give it a plug. I think it's very solid.

Speaker 2: Okay.

Speaker 1: Either of you.

Speaker 2: I'll go because I'm the on the notes on second. Um so I'm gonna plug um Atwin Desktop. So um it it it's this new app that was just announced today and I've downloaded.

Speaker 1: Can we spell that a A-T-U-I-N?

Speaker 2: A T-U-I-N. Um a few years ago this tool called Atwing came out and it's a a fancy shell history. Now you you'd both you'd both know me. You know I don't adopt new tools. You know, I'll try everything out, but I don't adopt basically anything unless I'm not sure.

Speaker 3: I I think you're AI in fact. This can't be the real Carlton. Because

Speaker 2: yeah, no, yeah, so this this is my um this is my avatar that I've put on for the show today. But I tried Atwin, I try everything, but I adopt very few things onto my final workflow. And Atuin is the shell history that I I gave it a a uh go and I'm like, oh yes, this is this is just great. And I have it set up so that in my projects up arrow is um like a project local history search and then command control R is like global history search and it's just phenomenal

Speaker 1: You haven't told me about this before, Carl. How has this not come up?

Speaker 2: Well, I just hadn't quite got round to I have been, you know, fam um standing it a little bit on um Mastodon, but um Anyway, they've released this desktop tool, which and the the plug is runbooks. run. So it's a little and I've downloaded it, it looks good. Um and I'm only plugging it because I I'm so impressed with their existing project. And it looks a bit like say a Jupyter notebook, but it's specifically tasked to shell integration, it's got SSH integration, it got Kubernetes monitoring sort of going on it. And it's for kind of like run books, for kind of ops, ops , um, ops notes, but instead of having them in a note file and copying them across to your shell, you just click run and it's there and so it's up to date and it's documented it's coders configuration and coders documentation and it looks sweet so I'm plugging it for that both that

Speaker 2: to in the the shell client the shell history client is wonderful give it a try But also Atmin desktop's their new thing. And it's all open source and I think it's built with Rust and Tao Tori, which is like the electron thing. So anyway, anyway, that one.

Speaker 1: Here it is. Shells all the way down. They get points for marketing for that phrase. All right, Jeff.

Speaker 3: Nice. Oh yeah, you had me at Rust on that one. Andrew Miller's Django prod server is I I'd love this is one of those spaces where people are trying to make the deployment and um the whole production story better This to me is very night and day eye-opening because it allows you to add this third-party package. You can add it to Django. It gives you a dev server and it gives you a prod server. I feel like we set people up and say it's really easy to develop something with Django. Go read this documentation on deployment, which is awful. And it's not that the Django docs are awful, it's that Python's deployment story is awful. And I love seeing this because you can install it. You can choose Gunacorn or choose whatever you want to, and it mostly just works by default.

Speaker 3: And it gives you the right level of switches that you can dial in and tune That way you can get a, you know, people are going to have opinions about what should live in their configs, rightfully so. But this is a much easier story for somebody who's new. It also creates a dev server, which does what you think. I believe this also like I think prod server also like um turns off debug and I think there's a couple switches it flips for you as well. Um I would love, love, love to see this grow into something Because it creates like third-party hooks too, so you can plug in Guncorn, you can plug in other, you can plug in tasks even. So Django Q2 works in task libraries. And it's creating like an architecture which I would love to see inside of Django because it's not pulling all these third-party libraries in.

Speaker 3: It's just creating like a framework and hooks. so that you can add an easier story for putting your Django application in production.

Speaker 2: And this is very much like the Django way, right? Is is you create a an interface. An API that people can implement and then you know we might, you know, Django would normally provide a default implementation, but if you want a different implementation, you just swap it in. So database backends, cache backends, email backends. Storage pluggable. Yeah, yeah, yeah. It's all pluggable. Same thing, same idea here. And I think that would be a lovely addition. So I'm excited to see how it evolves over the next cycle.

Speaker 1: All right, last bit, books. I'll be quick. So I'm actually why machines learn. I haven't finished it, but I'm working on it. It's Doesn't shy away from the math behind uh LLMs and AI in history, but really well written, really nice balance of again, it it goes into the math. It doesn't shy away from it, but it's Mainly text. So continuing my thread of trying to wrap my head around AI this year. But I think one of the things it mentions right off the bat is Yeah, there's math and there's linear algebra and matrixes and a little bit of calculus and stuff and probability, but it's not it's not overwhelming math. Like he gives the analogy early on of um Oh, what's his name? Ilya, um, one of the founders at OpenAI who, as an undergraduate at the University of Toronto, was studying math and physics and went to Jeffrey Hinton and said, hey,

Speaker 1: like what's up with neural nets and was given a bunch of papers and then came back and said, Well this math is so simple. Like how could how could there be something deep in here? And that's Kind of one of the points is that the underlying you know that why he and um Sutzkever, I think Ilya Sutzkever, was like, oh, maybe this is the path is because the math, you know, it's not math for math's sake. The underlying math is like You know, there's some stuff there, but it's not you know, it's not string theory or anything like that. So anyways, I'm enjoying it. I've I've sat on it for a little while, but I'm finally dipping into it and Maybe I'll have more to say. But I mean right like the fifth page, it's showing some like matrix multiplication. So it's very much a it's not like a pop culture popular physics book with no equations. It's like it's got equations in it

Speaker 1: But it doesn't have homework. So I'm enjoying it.

Speaker 2: Okay, I'll go. I'm gonna continue my vein of um tech books. Efficient command line, uh efficient Linux at the command line by Daniel Barrett. This is um like a basically it's a bash book. It's how to you know use your shell, but it's it's great. So there's there's the old ones, there's things like you know the the the real staple holes like learning bash and classic Shell scripting and the bash cookbook from whenever. And they're all wonderful. But this is it's got some good moves in it. There's a good chapter on um like a letter.

Speaker 1: It's not a thousand pages either.

Speaker 2: I I learned lots of things about um manipulating history, about launching subprocesses, about sub argument substitution. It's a great read. refine your your shell skills. I I really recommend it. Efficient Linux at the command line. Okay.

Speaker 1: Jeff, do you have one? I

Speaker 3: didn't bring the physical book, but all of Jesse Sima 's books, uh pronouns they them, are amazing books. If you don't mind showing that on the

Speaker 1: Yeah, yeah, let me pull it up.

Speaker 3: I'm challenging you on this like vlog world we're in now.

Speaker 1: Yeah.

Speaker 3: Their books are amazing. My kids' favorites. There's a lot of unicorns. There is a

Speaker 1: Netflix series, right?

Speaker 3: Yes, of the Netflix fame. And this is a partner to uh John Botifado, who is the vice chair, going to be chair of PyCon US for the next couple years, also Pygotham, a lot of people know them from. Uh if you go back to the book page, top link.

Speaker 1: Do you have a specific recommendation? This one?

Speaker 3: They're all good. The narwhal one's good. You got a little uh unicorn pony that thinks it's a narwhal, lives under the sea with its family. Like what's not to love about that? Um I just see lots of Django Pony love when I see the books. Um they're really good from like an adult perspective. Some of them are really get you thinking because they're just they're presented very well. Brilliant illustrator, really good stories. Love seeing them have like a YouTube. series that I think season three is out soon and just a small part of the Python community I love seeing like this whole thing is great. So Snow Kids a new book just came out a couple weeks ago.

Speaker 1: I like that.

Speaker 2: Good, good, good.

Speaker 1: All right. Well, thanks everyone for listening. Jeff, thank you for coming on. It's always a pleasure to do this. And uh we'll see everyone next time.

Speaker 2: See you next time.

Speaker 1: All right, bye-bye