OT Question : When choosing a stack for creating sites, would you choose Django over ASP.NET Core or PHP? If so, why?
You only know python.
I am good with Python and C#
Django 3.1
21–30 of 209 posts
Re: Django 3.1
#22Cool, they've implemented async views. ASGI has kinda passed me by. For some small project's I use Gunicorn. What's the setup for ASGI that's popular?
You can use Uvicorn to run ASGI apps. You can also use it together with Gunicorn https://www.uvicorn.org/#running-with-gunicorn.
Re: Django 3.1
#23Slightly OT: How does HN feel about the recent craze to make web python asynchronous? To me, the performance gains are dubious in many cases and the complexity overhead of handling cooperative multitasking just seems like a step back for a language like python.
Long term Python user: if I want to do something asynchronously I reach for Go or Elixir (unless it's just way more practical to do it right there in Python). Adding function colors [1] might have been a practical decision, but was IMHO a mistake.
Why do I have to decide if my function is synchronous or not when I write it? I don't want to do that, I want to write only one function that can be called synchronously or asynchronously. In Go or Elixir, the decision is made by the caller, not by the API designer.
Which leads me to a parallel universe: Go-like asynchronicity should have been introduced with Python 3, when backward compatibility was explicitely broken. The gain of switching to Python 3 would then also have been a much easier sell than "just" fixing strings.
Of course, there are probably a thousand things that I'm overlooking, but this is my feeling...
[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
Re: Django 3.1
#24Slightly OT: How does HN feel about the recent craze to make web python asynchronous? To me, the performance gains are dubious in many cases and the complexity overhead of handling cooperative multitasking just seems like a step back for a language like python.
Well, if you have external API calls in your Django app and you are running sync (which I would absolutely advice, with running async it is really easy to get an unpredictable performance which is sometimes hard to track down) having the ability to run some views async is really crucial. Otherwise your application might me humming along smoothly at some point and coming to a sudden complete standstill or performance…
> plummets when a random external API endpoint starts to time out
You should add something like https://pypi.org/project/circuitbreaker/
Continuously failing external requests should not make each one of your responses slow.
Re: Django 3.1
#25OT Question : When choosing a stack for creating sites, would you choose Django over ASP.NET Core or PHP? If so, why?
[deleted]
Re: Django 3.1
#26OT Question : When choosing a stack for creating sites, would you choose Django over ASP.NET Core or PHP? If so, why?
Speed of development. Django dev is really rapid.
Re: Django 3.1
#27JSONField has been an absolute godsend in combination with Django's ORM. I had been using it with Postgres and will likely keep our backend the same, but I cannot recommend it enough. You will have to write some validation and schema code on top if you want your data to have similar (but weaker) guarantees to the usual typed fields; the benefits from the flexibility you get are immeasurable though.
In projects I've been involved with, storing JSON in the database has often turned out to be a mistake.
Django models create a well-defined self-documenting structure for your schema, are easy to evolve using migrations, and there's a wealth of tooling built on top. IMHO, these far outweigh the perceived convenience of simply storing some stuff in a JSON field.
If you find yourself implementing your own validation and schema code for JSON fields, I'd say it's a sign that you should probably stop and migrate the data to Django models instead.
There are some cases when storing JSON is fine, of course, but in my experience they are few and far between.
Re: Django 3.1
#28Earlier quoted context omitted.
Well, if you have external API calls in your Django app and you are running sync (which I would absolutely advice, with running async it is really easy to get an unpredictable performance which is sometimes hard to track down) having the ability to run some views async is really crucial. Otherwise your application might me humming along smoothly at some point and coming to a sudden complete standstill or performance…
> plummets when a random external API endpoint starts to time out You should add something like https://pypi.org/project/circuitbreaker/ Continuously failing external requests should not make each one of your responses slow.
Interesting, will certainly try it out, thanks!
> Continuously failing external requests should not make each one of your responses slow.
It is not really a matter of the responses becoming slow, the problem is that if you are running sync with i.e 6 application server processes and you have just 6 hits on an endpoint in your app that is hung up on an external API call your application stops processing requests altogether.
Re: Django 3.1
#29Earlier quoted context omitted.
You only know python.
I am good with Python and C#
Then ASP.NET is probably the superior choice.
C# is a better language by far and the .NET runtime is a better runtime by far.
It only ever makes sense to use Python for data-science one-offs and munging if you have competency in Java/C#/etc. It's not a language well suited to application development.
Re: Django 3.1
#30Slightly OT: How does HN feel about the recent craze to make web python asynchronous? To me, the performance gains are dubious in many cases and the complexity overhead of handling cooperative multitasking just seems like a step back for a language like python.
Well, if you have external API calls in your Django app and you are running sync (which I would absolutely advice, with running async it is really easy to get an unpredictable performance which is sometimes hard to track down) having the ability to run some views async is really crucial. Otherwise your application might me humming along smoothly at some point and coming to a sudden complete standstill or performance…
Isn't that why gunicorn(+gevent) was implemented and does the switching behind the scenes w/o waiting that api call to finish? Is there a good reason I should manually "await" network calls from now on?