Mastodawn

(if anyone is wondering this is what all of the "julia is learning Django" posts recently have been about, I tried to build this site in Go and failed and then tried to build it in JS and failed and Django has been great)

also the most heartwarming thing about this site is seeing how many people have just been buying literally every zine as it comes out since 2017 or 2018, it's too much

@b0rk yay! It makes me genuinely happy to hear you praise Python as such. I hadn't put 2-and-2 together when I read the email update, though :)

@SnoopJ i'm not totally sold on uv still but I feel like uv has been making a big difference to my comfort with Python recently, I've never really gotten the hang of the package management

@b0rk that common refrain 😞

Things are better than they used to be, but the experience is still so common. I'm not sold on `uv` either (especially as I live at the boundary where they are explicitly breaking compat) but I don't begrudge anyone their use of it, it *does* address some of the confusion.

@b0rk I'm curious if you have any impressions of what made Django itself more fit for purpose. My guess would be ORM-flavored things or 'sturdy infrastructure' but I always find your perspective very valuable

(perhaps I am prognosticating about a blog post 😅)

https://jvns.ca/blog/2026/01/27/some-notes-on-starting-to-use-django/

@SnoopJ i wrote about it a bit here, i think it's how "batteries included" it is and how explicit it is (which are really both Python things)

also it just feels like a stable piece of software with a lot of care put into it, like when I look stuff up about Django I find a lot of resources

Some notes on starting to use Django

Julia Evans

@b0rk ah! thanks

@SnoopJ I think the problem with Go for me in this case is that it's not a dynamic language so the kind of data transformations you want to do in this kind of site are just very painful

and the JS ecosystem just moves too fast and I think there isn't a popular framework like Django in the ecosystem anyway

@b0rk makes sense! I'm not sure I know of any such frameworks in the server-JS world. I can name `express` off the top of my head as a very common router, but that's just the problem: it's one a *piece* of a framework

("problem" in this case where a batteries-included solution is desired, that is; there are good reasons to roll your own thingy from components ofc)

@SnoopJ yeah exactly, a more minimal express-like approach is great sometimes but it's not always what I want

meejah Feb 2

@SnoopJ @b0rk what we need is just *one* more package management tool in Python, amirite??

@meejah @b0rk at least there's standards infrastructure now for the multiplicity of tools instead of "everybody's inventing their own superset"

but multiplicity does not tend to *decrease* confusion…

meejah Feb 2

@SnoopJ @b0rk Certainly the standards help.

What would help a lot more (but isn't going to happen) is to have PyPA bless / back / maintain one tool (perhaps "one in each category"?) more like "cargo" (which is great).

I swear every time I've released a thing in the last few years I have to rototill the release stuff, especially on older projects. And there always seems to be a new tool...