Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some more things about Django I've been enjoying

jvns.ca

Post reply on HN
Print view View original

71–80 of 128 posts

Re: Some more things about Django I've been enjoying

#71

Post by miki123211 »

hecreto wrote: post #57

Not to be a downer since a lot of JEvans’ content is great. People should really give .NET a try. I don’t know if we are just old greybeard curmudgeons who look at this and go “is this a new thing? haven’t we been doing this for decades?”, but .NET out of the box with a few packages for databases, logging, etc is so pleasant you don’t even think about it. Maybe it’s just not a vocal community idk.

agreed 100%, the most under-appreciated programming ecosystem of them all.

It's also the only one that has support for making truly native apps for all four major platforms: Windows, Linux, MacOS and iOS. If you're willing to put in the work and make separate, native UIs for each, C# is the only way to go.

It's a rich enough language that it binds reasonably well to both Java (on Android) and Objective C / Swift (on iOs / MacOS), and having the core and UI layers of your app share the same language enables much higher fidelity bindings than what you can get out of E.G. UniFFI. And as a bonus, the same core is also re-usable on the server, and even in Web Assembly, if that's the way you want to go.

There used to be some issues around Storyboards and such on Apple platforms, but if you go nibless (which you should anyway in the age of AI), that's no longer a problem.

Re: Some more things about Django I've been enjoying

#72

Post by miki123211 »

echoangle wrote: post #3

> Some light load testing (with (ab -n 1000 -c 1) shows that right now we can serve about 2-3 requests per second (on a ~$10/month VM). > After turning on template caching, it seems like the site can now pretty easily handle 12 requests per second or so without using all of the CPU. I have not carefully benchmarked the before and after but it seems like it’s made a pretty big difference. That seems crazy low, I think…

If Django could run reasonable numbers of requests on early-200s0 servers... what has gone wrong since?

I imagine even a $10 VPS should be a much more powerful machine than a high-end server from 2005 or so.

Re: Some more things about Django I've been enjoying

#73

Post by 7bit »

BrenBarn wrote: post #69
7bit wrote: post #29

Earlier quoted context omitted.

How would you model string comparisons with LIKE?

For those you would have a method on the field object (e.g., `Table.field.like("whatever")`).

Yeah, but that's different from the operator. It's a different way of thinking about it. Maybe that's the reason they used dou le underscores for everything, to keep it consistent.

Re: Some more things about Django I've been enjoying

#74

Post by mmclar »

echoangle wrote: post #23
7bit wrote: post #21

Earlier quoted context omitted.

There may be many reason other than rejecting that suggestion leading to what it is know. Your statement somehow suggests that it was deliberately decided against what you propose. I don't think we know that. I can't quite picture how operator overloading would look like, could you give an example?

> I can't quite picture how operator overloading would look like, could you give an example? Instead of this: self.filter(end__gt=self._midnight(today)) You could write a "Field" class that implements __getattr__ and __gt__ so you could do self.filter(Field.end > self._midnight(today)) The "Field.end > self._midnight(today)" would evaluate to an object that would just store "my field name is end and my value needs to…

SQLalchemy does that. One advantage of the Django syntax is that it can be (pretty much) directly dropped into a query string on any admin page or DRF query and filter the results. E.g. the admin page for all the events after noon today:

  admin/event/?end__gt=2026-07-26T12:00:00
Being able to do ad-hoc queries using the same paradigm your app queries are written in, and then pass urls around with those queries included (e.g., quick one-off reports or answers to client questions) is so helpful.

Re: Some more things about Django I've been enjoying

#75

Post by selfmodruntime »

loevborg wrote: post #52
CraigJPerry wrote: post #18

There are so many footguns[1] in async python but it really has stolen the zeitgeist of modern python web. Synchronous django has a lot to commend it. If you deploy it reasonably well (workers, behind a caching reverse proxy etc) it's easy to operate in production even under duress. It's not going to be the right stack for long lived websocket connections or whatever but for a CRUD-ish or enterprise app, often very p…

Please go on. I also feel like asyncio is a big hack. Even just accidentally blocking the event loop is way too easy. And I couldn't believe it when I read that you need to store a reference to a task in a set to keep it from accidentally getting canceled. How did this become the main stack of AI backends? It's like node but slower AND much easier to mess up because of synchronous IO.

Well references in python are mutable by default, so you essentially combine an asynchronous model with mutable shared state. Combine that model with unknown caller exceptions in any subfunction and you're in for a world of hurt.

Re: Some more things about Django I've been enjoying

#76

Post by selfmodruntime »

echoangle wrote: post #3

> Some light load testing (with (ab -n 1000 -c 1) shows that right now we can serve about 2-3 requests per second (on a ~$10/month VM). > After turning on template caching, it seems like the site can now pretty easily handle 12 requests per second or so without using all of the CPU. I have not carefully benchmarked the before and after but it seems like it’s made a pretty big difference. That seems crazy low, I think…

Wow. With a web service in Go or any similar language that would measure in the thousands, at least.

Re: Some more things about Django I've been enjoying

#77

Post by acdha »

selfmodruntime wrote: post #76
echoangle wrote: post #3

> Some light load testing (with (ab -n 1000 -c 1) shows that right now we can serve about 2-3 requests per second (on a ~$10/month VM). > After turning on template caching, it seems like the site can now pretty easily handle 12 requests per second or so without using all of the CPU. I have not carefully benchmarked the before and after but it seems like it’s made a pretty big difference. That seems crazy low, I think…

Wow. With a web service in Go or any similar language that would measure in the thousands, at least .

Using Django back in the 2000s it was easy to get in the hundreds of requests per second unless you were doing truly pathological things in templates or gnarly database queries, and we have far more cores now. Usually something that low either meant things like not caching database connections or complex logic in templates.

Re: Some more things about Django I've been enjoying

#78

Post by marcosdumay »

CraigJPerry wrote: post #18

There are so many footguns[1] in async python but it really has stolen the zeitgeist of modern python web. Synchronous django has a lot to commend it. If you deploy it reasonably well (workers, behind a caching reverse proxy etc) it's easy to operate in production even under duress. It's not going to be the right stack for long lived websocket connections or whatever but for a CRUD-ish or enterprise app, often very p…

Yep, if you are going to make asynchronous programming, you need either a small, plain, and obvious layer that calls insulated synchronous code or some stack with high quality assurances.

Re: Some more things about Django I've been enjoying

#79

Post by acdha »

seanwilson wrote: post #35

For Django's default template language, does it still have these limitations? 1. Brackets aren't allowed to help with boolean expressions like {% if a and (b or c) %} 2. You can't do basic arithmetic like {{ x * 2 }}, but you're allowed to do {{ x | add:"2" }}. There's hacks to multiply using {% widthratio a 1 b %} or division with {% widthratio a b 1 %} though ( https://stackoverflow.com/questions/18350630/multiplic…

> It's like hiding the kitchen knives because they might be misused.

I used to agree with this more strongly but over time decided the Django model was actually more effective as your cue to ask whether you should have been writing a Python function instead and calling it (which has been super easy since something like 1.4 or so IIRC).

Unless you have a small, very diligent development team it always seemed to end up with people coming up with thickets of template logic which were harder to understand and test but because they’d grown so complex people would act like it’d be an excessive amount of work to switch. I had a few projects where I delivered order of magnitude performance improvements while replacing hundreds of lines of ugly code, especially since using Python directly made things like caching and more complex formatting much easier.

Re: Some more things about Django I've been enjoying

#80

Post by marcosdumay »

jonatron wrote: post #7
shakna wrote: post #5

Earlier quoted context omitted.

Those numbers sound... Single-threaded. Like they're using the development runserver instead of uwsgi or gunicorn.

A $10/month VM might only have a single thread anyway. Some providers like lightsail are really slow too.

The $5/month VM I rent has 2 CPUs. And you want to overcommit because of IO blocking.

Anyway, more than a decade ago my django servers could handle close to 10 requests per second on each thread.

Post reply on HN