Transcript: Django and Rust Tooling - Lily Foote
This episode is sponsored by Hacksoft, your Django development partner beyond code.
More on their services later in the show.
Hi, welcome to another episode of Django Chat, a podcast on the Django web framework.
I'm Carlton Gibson joined as ever by Will Vincent.
Hello, Will.
Hi, Carlton.
Hello, Will.
And today we've got with us Lily Foot who comes through joining us again.
Hello, Lily.
How are you doing?
Hello again.
Hello.
Thanks for coming on.
It's been a while.
So the big news was that you were elected to the steering council.
Yes, congratulations.
Along with you, Carlton.
Well, yes, but you know, so we're we get to see far too much of each other now, right?
All right.
Well, so let's let's assume people don't know anything about that.
Like what is that what does that do?
And what do you all do now that you're on it?
Is it one is it I don't even know actually.
Is it once a month?
How often do you do meets or is it all email list?
We've been doing weekly recently.
Um as we got started, we were thinking we should just have a lot of meetings so that we can start working out where we're at.
Uh we've just um started to maybe drop down to four uh every two weeks.
Um, but um yeah, there's a lot to do and a lot to get started with.
So what have we been doing every week?
That's true.
Um yeah, we've been um discussing um various things.
Uh there were a few quick wins we got out of the way first, like uh confirming uh Marius, um, who was a previous fellow as a merger.
Or releaser.
Is that it?
Was it a merger?
Was it a merger?
Was it a releaser?
Oh, I don't know.
I don't even know anymore.
Whichever it was, we he can now do that.
Yes.
Um and
sorry, just for context, because once he lost his fellowship, he couldn't do that.
Yeah, so the the under the Deb Ten rules, the um it used to be the case that everybody who was on the old Django core team could hit the merge button on Django Django, and it was like, well, hang on, that's uh A, the old core team, you know, people who hadn't been active for 10 years were just you know still had commit rights to Django, and so hang on, that's not kind of how it was.
And so um Dept 10 defined both um a merger and a releaser role, and I think there's three or four mergers, the fellows, and then a couple of other people, and then there's meant as I think there's three releases or maybe even four releases.
Um, so there's the fellows who do it mostly, but then Marish, who's they're able to do one if you know you know, one was on hold and the other was ill, and Marish could step in and get the release out the door.
And that was something that came up just as the previous steering council was resigning, so um it's not had anything happen with it until we got going.
Got it.
And I'll just uh shout out to James Bennett because I was on the board when he was doing a ton of work to kind of make all this happen.
So um I believe he spearheaded a lot of depth 10.
Yes, a lot of invisible,
a lot of invisible work he spent on that.
That I saw a little bit of it on the board, but you know, I just just to say like these things, you know, come at a cost, even though they're largely invisible to the community.
So it's good to highlight them.
Um yeah, I mean, and part of the issue, not not the issue, part of the reality is that Django's a big ship and it takes an awful lot of effort to turn because and rightly so, it's got 20 million downloads a month, right?
It's uh it's a there's a lot of vested interests in you know various different points and lots of competing desires and wants.
And okay, that's normal.
It takes an awful lot of effort to get Django to move, and Deptem was crucial in in doing that and setting us up for the for the next thing.
What else have we been up to, Lily?
Um well, several has got uh elected on various things, so we've started discussing some of those.
I know Carlton's big on uh improving the third-party package ecosystem and making that more uh understandable and so on.
Myself, I'm I was looking to make contributor experience better, and we've been having a lot of discussions about why is that not great at the moment, what are various things we could try and do to change that, but there's a lot of stakeholders and it's a very thorny problem.
Um, I mean, looking over at the Linux kernel, they're dealing with similar problems of um there's the Rustin Linux project who are wanting to make big changes, and then there's the maintainers who are wanting to make sure that they're not left supporting stuff without um enough time and energy and so on.
It's and we're facing similar problems.
It's it's it's a tail of old as old as time, I think.
Tale as old as time, as well.
Um so can are there any sort of headline sort of things that you that stand out to you?
So you know it's been a couple of months, we've been meeting every week, we've got we've talked with the fellows, we talked with you know all numbers of people.
What what sort of things step stand out to you as like, okay, you know, this is doable, this isn't, this this will take longer, this is quicker.
Yeah.
Um I'm not sure there's any really, really quick wins um with the contributor experience thing.
Uh one thing that I think we've agreed will be helpful is to try and uh uh uh get new feature ideas and discussion uh away from the attention of the fellows because it's a lot of uh energy that it takes from them.
And try and uh replace that with a process that is more community driven and um once we've got uh as a community decided that actually yes, we do want to pursue this idea, then it can get uh put into track and uh uh worked on um and get the uh review and so on from the fellows.
How exactly we manage that is still being discussed.
We've long used the forum as a hey, um you've got a new feature idea, you should discuss it here first.
Um one of the problems we have with that is that uh discussions tend to fade away and no one realizes that they're actually ready to make an action on.
Um sometimes there's disagreement and it filters out with no one agreeing, or sometimes people are like, yeah, that seems a good idea, but no one takes the uh next step of moving it on, as it were.
Um so we're thinking about ways we can maybe uh formalize uh which ideas are worth thinking about more and having a way of tracking them better.
We don't need to turn this into a steering council meeting, but it's helpful helpful helpful for the rest of us to have a sense of what all is happening.
I think I think this I so I mean the the the the conclusion to draw at least from outside is that that there's lots of activity and there's lots of stuff going on.
It's even even if not instant, um at least visible.
But we we've we have got a project, a GitHub project board that people can go and have a look at and and all the rest.
We should link that in the show notes, but that just sort of shows what we're thinking about now actively and what we know exists for you know later on when we've got a bit more capacity.
What's what what is that under?
Is that under the Django GitHub?
It's under the Django org, and then I think it's a mystery.
GitHub projects are an utter mystery.
All right, I'll
I'll believe it, I'll find it and put it in there.
Yeah, no, but I believe it's a project, an organizational level project called Steering Council something.
And then there's also another repo with our meeting notes where we're putting on every week.
There's you can go and see the meeting notes and what's been discussed and all the rest.
It's GitHub slash Django slash steering council, and then if you click the projects tab, you'll find it.
Okay.
Uh I, we, me and Jeff should link to that in the newsletter as well, I think.
Um so
one thing we wanted to do was be more visible, right?
We wanted to show that.
So, you know, if we're going in the newsletter would be amazing.
Well, I mean, you know, yeah.
Now that I know about it, I'll put it we'll put it in there.
But you know, I remember, you know, being being on the board, the secretary would take all these notes, and we had all these extra work to have some things were private and some things were public, but it was just, you know, in this dark, dusty corner of the Django project site.
So it's sort of anyway, so it's doing the work and then it's like telling people about the work.
Um speaking of which we should I should we make sure that we on the newsletter we're linking to the board notes because we were for a while.
But as well, we could put those in the show notes because they the board notes now go up on a you know, it's a whole Django app in the in the Django Project.com website with a model and a list view and all sorts.
Yeah.
Jeff and I need, you know, because we we have the Django updates, which various people um do, which is great because it means it's in there every time and it's a quick way to see, oh yeah, there's double-digit, you know, things you know, added um every week.
So as much as it I think we talk about, you know, being stuck and slow, like there are all these all these things happening.
So just on that little side thing, Lily, I just wonder do you have any thoughts on how we might or are we communicating well enough?
Do we need to improve?
Do we have any ideas maybe the answer no I don't have any ideas but like
can I recommend the blog the blog was good.
You guys did a quick blog post.
Like that's super easy sorry to jump in that's super easy for like the newsletter to link to for people to post on social to me that seems like the easiest way to like link to stuff for example
I think I am worried that we're even with the communication we are doing we're it's probably not enough probably not visible enough we do have uh our steering council uh minutes posted on the forum I think but I
I think until we start announcing that we're doing something rather than just discussing what we might do it's difficult to be more um open about what we're doing.
I mean talking about another uh podcast like we were just now is one way but um yeah I there's a lot we're talking about and not loads of it I think is filtering out at the moment but hopefully that will change
yeah there are no quick fixes I guess is a thing so talking of talking of quick fixes this wasn't a quick fix at all
you were
involved in uh this year's Google Summer of Code project
oh yes
uh so
tell us all about this because it's headline feature of Django 5.2 coming up yeah
um well uh so composite primary keys uh the oldest at the time open ticket in Django um I'd started to look at it a bit myself but uh life circumstances and so on meant I wasn't making loads of progress and then uh Ben comes along says he wants to do it for Google Summer of Code no one else has been proposing this but
he has a proposal it seems good uh so we say yeah let's give it a go and he's just absolutely blasted through it
and it's a success right it's in
yeah yeah I mean there's still more to do there's um foreign key support and generic foreign key support specifically but an awful lot of the work has been done and it's as far as I can tell really solid.
Well that that's a big thing I was just talking to someone the other day who was who didn't know that was coming who was having to do that their own you know their own cobble the other way for performance reasons so they were super excited
I think it's also there's a pull request which may or may not have emerged out how tracked it closely but that uses composite prime keys somewhere in the Django website.
Ooh fancy is will that be to do with track in some I think so
dog food it
yeah I was definitely talking to Baptiste at the last Django con about track because he you know busy maintaining that and he was like well I would rewrite it as a Django app but composite primary keys it's like well now you've got no excuse Baptiste.
Yeah I don't 100% remember which area it was but they had something that was basically a composite primary key and they the PR was to make it actually a composite primary key.
My um I don't you'll tell me this if this my sort of understanding is that it's going to be most useful for people integrating Django with a legacy database in the first pass right so you've got an existing schema that uses composite primary keys and then you'll be able to attach a Django model to it much more easily.
Yeah I think that's a very solid use case for it.
There's also potential use cases in multi-tenancy I think the motivating use case for Ben who's working on it.
But yeah there's various use cases for it and um especially once forum key supports in it should be very solid.
Yeah and it's gonna be another one of those exciting periods where the patterns the usage patterns emerge merge over the next couple of releases right yeah and how was mentoring like you just sat back and had the
odd review um yeah we had I think we had weekly meetings and I reviewed the code as it came in and there wasn't much more to it than that he had a very clear idea of what he was trying to do so it was just about o
kay uh helping him understand the code base and um making suggestions on how to do things a bit more Django y but it was actually quite hard and soft.
Okay super
and now you have to remind us I know you've you've with Django not you've been a navigator and then I believe you
I was a navigator on the pilot session of DjangoNot Space and then life and Google summer of code got in the way and I haven't done it again.
I would like to but time constraints.
Yeah yeah yeah well but just the fact that it's you know it's Django Nots who are often doing the update the Django the updates on Django itself and the whole as I think we we probably discussed a year ago the whole point is it shouldn't be the same people dipped into every time it's like you know when you have the bandwidth contribute and um so it's great that there's an organization and structure around it to facilitate that.
So it's not the case that
yeah I think it's one of the biggest wins of the past few years more than any of the technical contributions even though composite prime keys is amazing I think Jen Knot Space is even better still.
I would agree was so there's a couple things we want to talk about but I feel like coming from these highs of uh steering council Google Summary code um so you're willing to share with us that at the moment you're in between jobs because you were made redundant of all people are you willing to expand upon that because uh so many people have trouble getting a job or keeping a job and then for someone like you to lose their job is um
I think it's helpful for people to hear about that because it seems quite shocking but it happens.
Yeah so um I started uh at um uh back in November and I was getting settled in working on understanding the code base uh doing a bit of support for other people in the team that sort of thing and at the uh and then in January as I was expecting to pass probation which my manager had told me he was ex
pecting me to do um it I discovered that the company had uh overhired and were having to do a uh redundancy round and I believe a lot of my team went with that as well as just me but yeah job hunting again is not the not the most fun experience.
Well but it it's you know companies there's a lot of cost to companies doing that right obviously they're not trying to but just just from a for them to hire a team and let go of a team clearly they didn't want that no obviously you didn't want that but um it happens so well and and then um so where are you at now right?
Because I know when we spoke to you last you you worked on um colo
for quite a while
and you're doing a lot of rust are you how much what would you say the split is between Rust versus Python Django these days for you or in terms of your um you know dive in right now
well given I'm unemployed it's all side projects at the moment.
Yeah so um
well do you do you have a preference I guess I would say right because you know we often we often lose people to Rust and they don't come back.
I mean at the moment I'm trying to do both it's um rust is exciting I love a lot of the power it gives me and the performance but I also really love Django for its flexibility and um just ability to get something working that is very easy to get to production quality is battle tested and stuff like that.
Well let me let me ask you because so I'm a little late to the party but I've and I'll probably attach it to this I hopefully I have a tutorial finally on UV and Django.
So UV is written in Rust it's the package manager it's taking over the world you must have some thoughts on on that and how they did that right because they sort of they did it from scratch as opposed to cobbling together other existing pieces the way most of the other tools out there had had done.
Yeah it's
it wants to be it wants to be the cargo for Python right
so yes, exactly double s right yeah yeah, cargo the Rust, the Rust
package manager.
It's very impressive.
Uh there was a keynote at a Rust conference uh by uh uh the founder of Astral
Charlie Charlie Marsh.
Yes, that's the name.
Um about uh a lot of the stuff that they were doing with UV and from a Rust perspective, and that's a great watch.
I highly recommend it.
Um I've not actually used UV much myself.
Uh um but uh yeah, it seems really solid and it's taking over a lot of the Python mind share at the moment.
I should go watch that one because I was just thinking.
I'll link to it.
He gave he's given a number of talks, and he's quite good at it.
There was one too, I think it was a Jane Street, which is like a quantitative trader.
So it was a little more hand wavy, but he was and this was I think four months ago, but he was saying how you know it launched in February, and so four months ago is what, like November, it was already 10% of all PyPI downloads were using UV.
And, you know, it is it almost seems too good to be true, right?
That it on the one hand has like a single you know lock file for everything, it also can do your Python, and it's not and it's fast, but it's so fast that you can do things like move things out of CI into pre-commit like so fast that it can change the way we work.
So that in some ways is the most interesting thing to me because that was one example, but I'm sure there's others.
If you just don't even have to think about any of this stuff, you know, that sounds great.
And I so that's kind of what I'm super excited about.
And yeah, um
I think as long as you are uh willing to learn the new workflows, it's probably a really solid um choice these days.
Um my problem is that I have my own uh workflows that I really like, and I haven't just felt like investing the time to adapt to UV.
Well, sure, right.
And I think it you know, to the you mentioned the sort of battle testedness of Django, you know, it's I believe it's VC funded, they still aren't at a 1.0 commercial release.
Um everything looks positive so far, but that is an additional risk, right?
That who knows at some point they're gonna have to do something, right?
They have rough, they have UV.
Yes, monetizing in the DevTools space is tricky.
I mean Docker managed it, I guess, right?
So I'm sure that's an obvious uh well, you know, it's yeah, it's also interesting, you know, Docker is in on Teams, right?
You if you all just use UV and it's all in a Toml file, like does that remove the need for Docker in some situations?
Like I'm I'm still a little bit ignorant on it, but it seems like it would in some cases.
Maybe I tend to avoid Docker unless I have to use it for work reasons anyway.
So like Docker for local development is just like sticking needles in your eyes for no reason.
Like, yeah, Carlton's Carlton's Carlton's, yeah.
I I've I I hop on the.
If UV can bootstrap my local environment, then you know that's an interesting proposition.
Well, and the the whole Python thing, like the the PyEnv, um, you know, you don't need py env if you can just put it in UV.
Uh like that's
such a huge thing for just for beginners, right?
Because gosh, like it's a minefield.
I mean, and I'll uh shout out to my employer PyCharm has UV support now, um, which is cool.
Now there's a question of levels of support, so we're you know gonna have even more integration.
But um yeah, it's pretty it's pretty wild that something that's a dev tool that's foundational can be so popular so fast.
Because this is not a space, like there's a whole there's an XKCD on it that I saw uh Charlie put in one of his talks.
Like, this doesn't usually happen around standards, right?
So I think there's been a lot of frustration with the legacy tools in this space, which is one reason it's achieved such good adoption.
They've got a lot of the UX right with it, as far as I can tell, especially with the performance.
But as well, the single tool, right?
It's the single tool that hand that does it, that does it right.
It got for me, it show it go shows how you know a decent amount of money goes an awful long way, right?
So they've managed to fund it fund a team and actually put them on it full time, and all of a sudden all these problems that were insoluble for a decade or more uh are resolved in the space of a year.
Money is the fixer for all people.
Well, it's the and it's the combination of the Rust bit, but then just even if they just rewrote it all in Python from scratch with the money, there would be some improvements, you know, not maybe not as much, but there would still be no one, yeah, no one had the desire or the time to to do all that.
That's kind of why I'm curious.
I want to watch that Rust talk because I've read a little bit about it, but I want to understand a little bit more what actually they all did from scratch.
Yeah, I think there's a lot of clever people who've worked on it, and therefore a lot of clever ideas in how to really optimize things.
And Carlton, so are you you're a UVer or whatever the phrase is?
No, I'm not a UV.
You know me.
I uh like it.
Well, that's why you you sounded you sounded like you were unnoticed with it.
No, I'm interested.
I'm looking, I'm looking at it, I'm investigating it.
I've I'm not using it in battle.
Like I I mate, it takes an awful long time to get me to change tooling.
Like an awful long time.
Well, all of us again.
This speaks to I mean, I haven't done anything real with it other than toy projects because it's kind of like, well, if I'm not facing speed problems and my team isn't crazy frustrated, like why would I be
that it doesn't all of the problems it solves, I think brilliant.
None of them are problems that I have.
Um, and so I'm in I'm happy to watch it.
I'm I I'm probably in the position where if somebody said, Should I use UV, I'd be like, probably.
But doesn't I the fact that I'm not using it doesn't mean you shouldn't.
Um, I'm old man herding goats on the mountain, that's me.
And you don't need to copy what I'm doing at all.
I'm slightly skeptical about the VC funding position, I have to admit.
Um, I'm slightly more concerned about that than other people.
You know, other people are happy to say, oh, well, let's not worry about it, but money's all good.
But if money is all good, that's super.
I'm personally interested in making sure that that what I know what the state of play and the community tools are, so that you know, if it all does go horribly wrong, I don't feel like, oh god, and we're now trapped in a you know VC hellhole.
Now that's just you know, that's very unlikely to ever come to pass, and it's you know, the the Astral team are all great and they have no intentions to all that, but you know, just as a matter of you know diversity within the community, I'm happy to hang out with my trusty tooling for a little while longer.
I I feel very similar to Carlton on this, except I wrote my own tooling.
Right, yeah.
Well you wouldn't
for a long time
I wouldn't, but recently I I have, yeah.
Well, I'd I'm pr quite sure I'll be doing a PyCon US demo of UV with PyCharm, amongst other demos.
So I'm uh as much as I would love to hang out in a cave and herd goats, I'm uh forced to.
I think I absolutely have no problem with other people doing it, but I've been using the same solution, I've been using Blood Chain Wrapper for 15 years plus, and I have no intention of changing any sort of.
But I think it's it's it's this interesting to me, some of these tools or things like this barbell shape, where on the one hand, like power users or speed matters, boom, like yeah, they'll flip over.
And then and then the beginner thing, right?
And this is the like the three of us are a little removed from being pure beginners, but God, like, you know, you tell someone, oh yeah, just install Python.
Okay, like
yeah, exactly.
Exactly.
Right?
Like there's so many tools, so many ways to mess it up.
And then if you can so I'm in some ways, I'm almost most you know, just from the teaching angle, I'm most excited by that because I have seen how ridiculous that is.
And um
Yeah, I think that's for me, that's the most exciting thing as well.
I think that the an an easy, reliable, it works.
Here's how you bootstrap your Python environment, which isn't gonna confuse beginners.
I think that for me is the is the the speed is a bit like speed schmeat, you know, like
and it's the same thing that everyone else is on, everyone's on exactly the same one, you know.
That's yeah, yeah.
I mean, uh and even I think this is a little bit maybe hidden to some to some of us, but like just installing Python has really improved in the last five years.
I mean, python.org installer is great, Microsoft with the Windows support.
I mean, you know, even five years ago, it was like I had, you know, every time I got a new computer, I was like, oh, hmm, this is gonna blow some time.
And now it's I don't want to say trivial, but if you know the steps, it's not so bad.
So I have I have robbed one bit from UV is that I've started using the standalone builds on servers because I was using PyEnv, and it just I feel no need to compile Python.
I would really, really love if python.org would ship pre-compiled.
Um the
Python standalone stuff is amazing.
Um uh that was actually created before uh Astral, and Astral have adopted it since um
using it.
Uh release the maintenance burden from
but um I'm not actually using Gamlet at UV to fetch the standalone builds as a sort of you know nominal flag in the ground for no reason, totally pointless.
Well if I can swear
you can go on.
The templates, Django Rusty templates, right?
Yeah, all your side projects built in Rust.
We're rewriting Django in Rust.
Yeah, tell us about that.
Um but I mean after I left Kolo, I was uh looking for some way to continue using Rust and templating is one of the more performance sensitive areas of Django, I think.
Yeah, but absolutely from a CPU side of things rather than an IOT.
So I thought
But also just to give context there, any re sorry to butt in, but any request, any request, it's gonna go, what's where's your time going?
We went database templates, like one and two.
So anyway, carry on, carry on.
Yeah, so I was thinking, well, I I love Django, I'm really enjoying Rust.
What's the best way to put those together?
And templates was the answer I came up with.
So since autumn last year, I've been trying to uh build a parallel implementation of Django's templating language using Rust.
Um and I'm aiming for 100% compatibility of rendering, so it can really just drop into an existing Django code base and get all the potential benefits of having been rewritten in Rust.
Um I'm not at a stage to do any benchmarking, so I don't know if I've succeeded yet on the performance side of things, but once once it's complete for a given version of Django, I can then start looking into benchmarking and performance improvements and all that sort of stuff.
Okay, so that sounds really, really, really exciting.
Can I ask you a question?
If I've got a custom template
tag, yes,
how would that work?
Because that would be written in Python.
Yes.
I haven't got to it.
It's it's been on my radar as the thing that I am going to need to solve at some point, but I haven't got round to it yet.
Okay, okay, fair enough.
It's good to strike that away, though, isn't it?
I have some ideas, but I haven't looked deeply and really grappled with that one yet.
I'm just trying to get the core stuff working.
Uh, the other thing I'm uh really trying to do with it is give better error messages than Django gives.
Ah well, yes.
If you get an error in Django templates, you get this horrible traceback of uh Django templates internals, and it's not really very easy to understand what's gone wrong often.
Now we could fix that though, couldn't we?
Isn't there a way of marking frames as to be excluded from tracebacks somehow?
Possibly.
I was reading a a rich that I was reading the rich docs yesterday because I was doing it, and they they've got a traceback thing where you can say skip these frames, skip that frames, and I was like, ah, we could do with that in Django because who wants 30 frames of template internals?
Like what's what's the uh instrumented render 48 times as you go down the node list?
Yeah, I definitely encourage any um anyone looking for a fun issue to try and tackle that.
We should create a ticket in tracks so that someone could do that.
Because I think that that'd be a useful thing to have, and it's probably not too difficult, maybe.
I love it, I love it, I love it.
Can I ask your take on um because I love the Django template language, and I I one thing I love in particular is just not defining a particular um variable, deliberately not defining a particular variable, and then so having the whole block just vanish away because you know the if defaults to empty and it it it knows what to do and it doesn't raise an error.
But lots of people don't like that.
They're like, no, no, no, I I really want I really want this to be much more strict with me.
Do you think
there's any way we can sort of be have a template say, look, this is what I'm after, and you could lint it maybe that the the context you passed actually did have the variables that the template was looking for or something.
I don't know.
What's your thought in that space?
I think there's some room for exploration there.
Um it would be nice if Django could um be more strict for the people who want it to be more strict.
The trouble with I is I don't think it can be a global setting, like most of Django's template settings are, because existing stuff like the admin and third-party stuff might very much rely on that feature.
So I think what would be necessary is a way to limit it to templates that have been written by the developers of the project.
And then they can opt into being strict on their own templates but fall back to not strict when interacting with these upstream templates.
The idea, an idea comes half comes to mind.
This is just me making stuff up as we go along now, but uh idea half comes to mind of like having a template tag that sort of defines what the expected context is and then takes the context and sort of links whether those are true or not.
But uh we'll have to we'll have to brainstorm this at Django coin or yeah.
There's yeah, there's a lot of I think there's a lot of stuff in templating that actually could be uh explored and improved, and it hasn't really had loads of attention for a while with um the popularity of APIs over templating.
Yeah.
But I think especially with HTMX, templating is coming back into vogue in Django, so yeah, I think it's happened.
But so have you seen all these exciting component libraries of Django components, Django Bird, DJ Angles, like these various slippers?
I've I've seen some of that from a distance.
I've not dug deep.
You haven't got one which you're waving the flag for you.
No, I mean um well, I haven't really worked on a Django project for a while.
Um, because with Colo, I was writing tooling for programmers, not writing a website really.
Um so I'm really kind of rusty on some of this stuff.
But also you're more of a back-end, you're more of a ORM expert, right?
I mean Yeah.
Uh anything back-end has always drawn my interest.
Frontend has always been complicated and scary.
Well, can I ask what uh do you feel the pull at all to, you know, given your skills, uh are you still happy in web land, or do you feel that the data science pull at all?
Um I don't know about data science, but uh
Well, I guess everything else, right?
That's the problem with data science, is it encompasses just like everything else with programming languages that isn't web.
Certainly DevTools is interesting to me.
Um Rust is known primarily as a systems language, so getting into doing more systems type stuff could be really interesting.
I know that the embedded world is really cool, but I've done basically nothing to know how to work with that.
But there's a lot of areas of programming that I would actually quite like to uh explore more.
But it there's only so much time you have, and it's a question of how much do you lean into your existing uh skill set and how much do you try and do something new.
And yeah, I'm really trying to find that balance, both in my open source life, like building Django Rusty templates, and my work life, whatever turns out to be next for me.
Well, uh one more question, and then I'll add a questions for both of you, actually.
So in the Rust world, which I know Carlton, you've spent some time there as well.
So so taking cargo, taking package manager, and then applying it to Python, are there any other obvious things that Rust does that Python with a bit of money and brains could or should adopt?
Do you think
I haven't thought of anything obvious yet?
Carlton, any ideas while I come to the store.
The thing I'd like to see more.
I was going to ask you a little bit about this, was is that if we could improve the story around the um the Rust to Python integration.
So there's maturian, it makes it very easy to package up, but it's still a bit scary.
You know, if I'm just if I'm quote unquote just a Python developer, and then I see this.
Oh, I could go and build something, this Pi PyO3 thing.
What's going on?
Ah it's still, you know, you've still got to dedicate two, three days to sit down and plow through it and oh yeah, and now I've got my hello world from Rust.
Yeah.
That was
quite a lot of gone.
Yeah.
I think I think the Python Rust interoperability story is actually really solid.
Um it is, but still
it's I mean, if you compare it to what you had to do to get an extension module before Rust came along.
No, no, no.
C C plus Python,
it's all
way more painful, at least my impression from the outside, than I ever found the experience with Rust.
I think I think the Maturin uh developer and team have done an amazing job of just taking advantage of the Python packaging backend evolution over the past uh years that and built something really solid.
And and PyO3 is a really solid piece of um technology too.
I've actually joined the maintenance team of that.
So have you?
There you are.
There you are, folks.
If you're looking for a Django RM expert who also does Rust is on the maintenance team of the Rust Python integration framework.
I think you need to think you need to think bigger.
You need to go raise some VC funds and do something.
I mean, right.
I mean, you have the background, right?
You have the perfect background of Python, Rust, DevTools.
I don't know what specifically that thing is, but you know, that's all you need to do is say, yeah, I can do it, and you know, Astral's doing it, so you know, there's VCs are trying to spend the money that they have.
Anyways.
I wonder if there's one thing we could pick up from the Rust ecosystem, which is additions.
So particularly in Django, we've um have very strong backwards compatibility constraints correctly.
So because we've got those 20 million downloads a month that we have to keep thinking about.
But additions in Rust allow you know you to step forward and say, no, we're gonna drop compatibility here and we're gonna step forward, and now you have to be using this addition if you want to be using this.
Um well, it's a bit more nuanced than that with Rust.
Um, because they have extremely strong backwards compatibility.
Um I think you can use a new edition in your own code, but depend on code that's written in an older edition.
And they've defined these editions in such a way that uh the compatibility between those is still there.
That's all forward compatible.
Yeah, so you can opt into uh the better behaviour, but in a way that still integrates well with what's gone before, which does mean that you can't uh make some backwards incompatible changes that you would like to.
Because you can't keep that cross-edition compatibility.
But I would like a uh I think Django uh has some rough edges and bad defaults and stuff like that that there's a uh quite a bit of uh resistance to uh changing and improving.
I would like us to find a better way to handle that.
And something like additions.
Like something.
I mean, maybe, I mean, what's the difference between an addition and an LTS?
Maybe maybe we could do something where we um where we improve defaults every LTS cycle or something.
Okay, well I would
have to see how that rolls out.
One thing I wanted to ask you is about we've talked about UV and we've talked about Rust, and one thing that Rust does very well is CLIs.
And uh you know, we've talked about the dev the DX, the developer experience of UV and how they've nailed it.
And there's some you know wouldn't it be nice if we could you know improve the DX of Django somehow?
Yeah, well, there are some really nice um libraries for um command line stuff in Python as well.
Uh I really like click.
Um I've there's a uh terminal user interface, is it textual in Python?
I can never remember what it's like.
Yeah, textual.
Yeah.
Um I suspect there's a third-party library out there somewhere that integrates those with Django's management commands.
Oh, there is one.
If there isn't, there
should be.
Yeah, no, there is one as well.
And there was a release of there's typer as well, which sits around click and gives makes it type hinted.
Yeah.
And there was a release of Django typer as well, quite recently.
Yeah, so yeah, I think it might be nice to start depending on click in Django so that we don't have to deal with argpass, because arg pass is kind of crufty.
It's it's not tight enough for you, you know.
You like it.
It's I mean it works, but it's verbose and it's I I think it's been demonstrated that the third-party ecosystem has done better, and it would be nice if Django opted into that, I think.
I've got one sort of half idea is that we should build all these things just as around Django and rather than necessarily trying to force the Play-Doh into the shape it doesn't want to go in.
Sure.
Um then the problem becomes discoverability rather than backwards compatibility trade-offs.
Yeah, yeah.
Anyway, we'll start.
Well, we're we've covered a bit of time.
Is there any are there any things that you wanted to mention or we should have asked you about while you have a microphone, literally and figuratively?
Nope, nothing's coming out to mind.
Okay.
So I've got to ask, you're on the steering council, you've got all the power, you've got a magic wand to wave.
What's the thing you're gonna fix, in Jang?
It can be community, it doesn't have to be primework.
Yes.
I mean, I ran for election on this, it's got to be trying to make the contributor experience work better for everyone involved than it has been before.
Okay.
Fair enough.
Well, we've had yeah, we've we've we've covered all the things.
So this episode will come out in three weeks.
So if your LinkedIn profile says you're still looking for work, people should reach out to you.
Um, but again, I think it's it's just
and I've just got to say one more time, really cool contributors to the ORM, Rust being on the Pi 03 maintenance team, you know.
There isn't much more you could ask for if you're looking for someone, you know, with some jobs.
Yeah, but I I appreciate you being willing to talk about it publicly because this is a thing that happens, and it's not just newcomers who have this issue.
And um so thank you for agreeing to that.
Hey.
My pleasure.
So we're gonna have links to a whole lot of stuff, including um Lily's packages, and check them all out.
And we are DjangoChat.com.
We'll see everyone next episode.
Bye bye.
Bye bye.
This episode was sponsored by Hacksoft, your Django development partner beyond code.
Learn more about their services in the link in the description.