Comment by BiteCode_dev | Hacker News Reader

Comment by BiteCode_dev | Hacker News Reader

Sensible decision, although hardly a surprise or a killer feature for something that is a major version bump.

I assume the async story is going to be more fun.

By the way, if you are looking for a good key/value store with expiration without the need to setup redis, have a look at the excellent diskcache:

https://pypi.org/project/diskcache/

It is based on sharded sqlite files, and it's surprisingly capable, even in multiprocessing based env like a django site.

Sqlite is really showing up in all sort of use cases these days, like huey, a task queue that doesn't need any broker to be installed to be useful: https://pypi.org/project/diskcache/

Now things can get fun...

With supervisord (supervisord.org) you can manage multiple processes, and with fastapi + starlette, you can serve your WSGI site without a proxy pass, including static sites: https://fastapi.tiangolo.com/advanced/wsgi/

Then with shiv you can bunddle all that in a pyz file: shiv.readthedocs.io/

Meaning you can now just upload a pyz file to your server, run python on it, and that's it, you have a full stack deployed, with a web framework, db, caching, task queues, static file serving, which can handle around 100k visitor each day without a sweat.

No more infra needed. Just Python code, all bundle in one file.

That's really neat.

But then how do I do microservices in a monorepo based SPA server rendered running on kubernetes?

Also, pair it with Unpoly, tailwind and slippers and you get a pretty amazing frontend setup as well.

https://unpoly.com/

https://mitchel.me/slippers/

Last year I tried Huey for a project where usage was very lightweight. Performance was more than enough with SQLite. Unfortunately Huey with SQLite was not great at handling unexpected crashes like server and docker restarts.

Switching to Redis solved all of these issues.

Maybe it's better now.

>you can serve your WSGI site without a proxy pass, including static sites

What about HTTPS?

Totally agree on hoping there is at least some movement forward on async--particularly async ORM. I love Django and DRF. It is my go-to for a lot of things, but the lack of async support is increasingly a problem for more organizations. Honestly, it would not surprise me that if a solid, kitchen sink web framework emerges in golang, Django will be abandoned rather quickly.

2 cents.

I love Django but it seems like such a limitation for certain workloads. You can often work around some of these issues with Celery but still…

.Net already offers a kitchensink with async, it’s growing a lot and is much more attractive than a decade ago.

Yes, maybe in 10 years when this Go framework catches up with all the features and becomes as battle proven, well documented, maintained and funded as Django and somehow we know is not yet another thing that will be abandoned next year.

I've been writing web applications using python and django for close to 15 years now. Smooth, concise and stable. Doing the same using a verbose and boilerplate heavy language like golang doesn't sound attractive to me, at all.

Not sure I understand the fuss about upgrades either, at my current job I've gone from python 2 to 3 and from Django 1.8 all the way to 3.2 LTS without too many headaches. The release notes provide detailed instructions on what is deprecated and what you should do to fix it.

The Go hype is as bad as the frontend hype in my opinion.

If you're replacing Django with Go then either you never needed Django, or you have no idea what you're getting into.

At a previous job backend team decided to replace rails "because monolith slow ruby not fun anymore" with Go. Three years later they were still reimplementing things rails gives you since day 1. I've seen abominations as doing migrations as SQL scripts ran by cobbled together bash scripts because "as we don't have orms then orms are bad".

No need to say now they're about 4 years in and the one still running the business and making all the money is the monolith, not all the Go microservices around it.

Go is a replacement for c/c++, maybe java and for building infrastructure probably.

If you're using it for doing CRUD forms, you're using it wrong.

Out of curiosity: what features from Ruby are they reimplenting? I have no experience in Ruby but in a few other languages and framworks. And having encountered something missing yet when writing Go web services.

I've not even mentioned Ruby.

Rails. Features of rails.This is exactly the problem...people focus so much on the language they forget the ecosystem they're in, and the ecosystems matters a lot more than the syntax or the performance.

> And having encountered something missing yet when writing Go web services

How do you do form validations, translations, database access, migrations, email sending, background jobs that don't die on a deployment, user authentication, file uploads, caching, etc?

Of course all of this can be done, you just need to take 100 decisions and tie together 256 libraries many of them probably abandoned in a few years from now.

If you don't need any of that, then just what I said before: ok, you never needed rails from the get go.

GP (BiteCode_dev) made a valuable comment for how we can build a easily deployable python application with

>web framework, db, caching, task queues, static file serving, which can handle around 100k visitor each day without a sweat.

i.e. with 4-5 large dependencies of frameworks, libraries, software etc.

In Go you can off the bat reduce those dependencies to 1 or 2, even completely eliminate them, you get deployable package and async for free with faster development cycle and lesser headaches of managing dependencies in the long run.

Interesting. I'll look into some of those projects.

I think you put the wrong link for Huey, btw.

Yep: https://huey.readthedocs.io/en/latest/

Reply on news.ycombinator.com