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

Django 4.0

djangoproject.com

Post reply on HN
Print view View original

191–200 of 226 posts

Re: Django 4.0

#191

Post by sam_goody »

OT, but considering the audience...

I have a side project / website that I want to work on. I have over a decade experience with PHP and JS in various forms, but am willing to try something new.

The idea of compiled languages don't appeal to me, so am not really interested in Go, Rust or Dart. It looks like either Django, Elixir, or PHP - but am open to other ideas.

Anyone with enough experience to tell me confidently that it is worth Django or Elixir? Anyone can give a five line overview of the differences vs PHP or Node?

And along the way, am I the only one who is confused by what seems too many environments and package managers? (from venv/virtualenv[1] to pip/easy_install to wheels/eggs)

[1]: https://stackoverflow.com/q/41573587/87520

Re: Django 4.0

#192

Post by jph »

sam_goody wrote: post #191

OT, but considering the audience... I have a side project / website that I want to work on. I have over a decade experience with PHP and JS in various forms, but am willing to try something new. The idea of compiled languages don't appeal to me, so am not really interested in Go, Rust or Dart. It looks like either Django, Elixir, or PHP - but am open to other ideas. Anyone with enough experience to tell me confidentl…

IMHO, Elixir & Phoenix are such a breath of fresh air, plus power, plus adaptability, and I love the functional capabilties. On the other hand, if your want lots of numeric computation tooling, AI/ML, stats, etc. then Python & Django have better/more math-adjancent integrations.

Re: Django 4.0

#193

Post by wiredfool »

WD-42 wrote: post #153
wiredfool wrote: post #24

Earlier quoted context omitted.

There is at least one way that migrating a + b is different than migrate a + migrate b, in ways that you can then only incrementally migrate your project rather than building from scratch. It’s mainly in post migrate actions, and specifically for me adding a group for permissions.

If you write manual migrations, then it's often worth it to write the reverse function (in your case, deleting that group) so that you avoid this situation.

It’s not the back and forth, it’s that a migration in b that requires the post migrate step from a will fail if both migrations are run in one shot, (say, because you’re bootstrapping a new dev or test db) but it will work when done incrementally (such as during development or deployment).

Re: Django 4.0

#194

Post by bgdkbtv »

sam_goody wrote: post #191

OT, but considering the audience... I have a side project / website that I want to work on. I have over a decade experience with PHP and JS in various forms, but am willing to try something new. The idea of compiled languages don't appeal to me, so am not really interested in Go, Rust or Dart. It looks like either Django, Elixir, or PHP - but am open to other ideas. Anyone with enough experience to tell me confidentl…

No difference, it is just a matter of preference and selecting the best tool for the job. Often times the best tool for the job is the one that you know how to use really well.

If you’re good with Laravel for example, no need to switch to Django or Elixir and vice versa. Stick with what you know and you’ll be a happier developer.

Re: Django 4.0

#195

Post by rowanseymour »

tfehring wrote: post #98
rowanseymour wrote: post #57

Earlier quoted context omitted.

I think that was a fair criticism a year ago, and it's hard to believe it took this long to get a sane dependency management system, but now the answer is use poetry every time.

I can't recommend using Poetry in production - I've had massive headaches with it due to https://github.com/python-poetry/poetry/issues/697 Basically if you have two dependencies that depend on the same package, but depend on different versions or non-overlapping ranges of versions, Poetry's only solution is "tell the maintainers of your dependencies to update their pyproject.toml" - building your package will just f…

But doesn't even pip take that strict approach now?

Re: Django 4.0

#196

Post by valbaca »

nisegami wrote: post #55
rlawson wrote: post #45

Django has allowed me to enjoy some side entrepreneurship. I have released three products as a solo part time dev that I would never have been able to do in a reasonable time using Java/Spring (my strongest stack). My first project went nowhere, but the second generated 1k+ a month and sold for 50k, and the third one is following a similar trajectory. My advice - keep it simple - function based views - centralize acc…

>avoid fat models, use a service layer I had not heard the term "fat models" before so I googled it. It did not go in the direction I expected.

Yeah, I think "deep model" (versus shallow) a more accurate and less punny phrase.

Re: Django 4.0

#197

Post by alanwreath »

Django for me has been a solid API gateway. That said I would appreciate an API-centric iteration of it. Something like how Laravel has Lumen. Even if they would make Django ORM available as a separate library it would make me glad. I can’t say I’m overly enamored by the red wave that has passed over python. The only things I really like it for (so far) are when I wish to make concurrent http calls. For whatever reason, I don’t enjoy it as much when I’m trying to serve multiple requests. I prefer keeping requests read only or at most job launching.

Re: Django 4.0

#198

Post by robomartin »

strzibny wrote: post #168
robomartin wrote: post #115

Love Django, yet the transition from local development to deployment, in my opinion, continues to be just plain ugly and painful. I've written about this before. I think the stock Django dev configuration needs to change to something that is equivalent to a reasonable deployment on a common VPS, whatever that means. The development server is a nice trick, but the things you have to do to move to a real server are pai…

What do you find hard in particular? systemd service + gunicorn is not that bad, I think. You can have simple deployment and graceful restarts[0]. [0] https://nts.strzibny.name/gunicorn-graceful-restarts/

Not sure that your link is an answer to my comment.

Whatever the case may be, I can take a single VPS and multi-host a bunch of domains, each with it's own Wordpress installation, DB, etc. Virtual hosts makes this possible. It's stupid simple. Getting a single Django application running under a single domain on a VPS is a nightmare. Particularly when you consider everything you have to do to migrate from the development environment to production.

This is why we do not do any Django development using the standard installation and go right wo running it just like production on either virtual machines or a dedicated on-premises Linux server. The development environment is as close to an exact match as the production environment. No SQLite, no runserver, no nonsense with static files, etc. This is what I think the Django project needs to really think about working on. There is no reason to have a crippled development environment at all. The base installation ought to be setup to migrate to a standard Linux host (not something purpose-built like Heroku) without much friction. If you are doing a more complex site with multiple servers, load balancing, etc., you are on your own.

I truly think adoption would be far greater if the deployment experience was sensible. I have talked to people who absolutely gave up on Django because going from development to production was a nightmare without spending money on far more expensive servers and services they should. This is an application (Django) that should easily run on any Linux server. The fact that companies were created to facilitate deployment says it all.

Re: Django 4.0

#199

Post by fastball »

windexh8er wrote: post #44
Majestic121 wrote: post #14

We went all in on FastAPI with my team, but we're hit the issue that the projects of Tiangolo (FastAPI, SQLModel, Typer) seem to be turning pretty much unmaintained : https://github.com/tiangolo/fastapi/discussions/3970 We've already been hit by multiple bugs with fixing PR opened, but left to rot, and missing documentation : the 'tutorial' documentation is great, but if you want a reference you have to go read the c…

Genuinely curious how you happened to choose FastAPI over something more in the middle, like Flask? I tried a few tools in FastAPI, and it's fantastic for those, but I think I'd still stick with Flask for something more well rounded (not just as an API server).

I used to really like Flask but after trying FastAPI I doubt I'd ever go back. I even rewrote the entire backend for our product in FastAPI and unlike some rewrites I've done in the past am 100% happy with this one. Major benefits for us:

- Faster in general than Flask (thanks to starlette / uvicorn)

- asyncio libs in Python are generally beating out others in terms of perf (e.g. asyncpg vs psycopg2). This isn't to start a whole "asyncio is faster" flamewar, not saying that's necessarily true. Just that it seems the people who are building in asyncio are also people who care about perf, which I do as well. The (non-asyncio) Python community has neglected perf for a bit too long imo.

- asynchronous style works much better with things like WebSockets, which we use

- Auto-generating an OpenAPI schema[1] is nice to have.

- Using type hints for things simultaneously encourages mildly "safer" code while also giving better auto-complete suggestions

[1] https://api.supernotes.app/docs/swagger

Re: Django 4.0

#200

Post by wartijn_ »

kolanos wrote: post #140

Feels more like a Django 3.3 release than a 4.0 -- was expecting Django 4.0 to deliver the promised ORM async support.

Django releases time based and a version 3.3. was part of the plan. 4.0 is released right now because it is December 2021. The versions after that will be 4.1, 4.2, 5.0, 5.1 etc. [0] It's different from how many other projects work but not unique, Ubuntu works in a similar way for example.

And although it might be different form what you're used to, I really like it. If you check their documentation, you can see exactly when they'll make breaking changes and features will be deprecated and removed.

[0] https://www.djangoproject.com/download/

Post reply on HN