pdhborges

Web dev context here. Just from the top of my head: django-constace breaks storage format with no built-in no downtime transition, django-modeltranslations, want to add translations to a heavily used field and you are using a database without transactional ddl good luck with that, django-importexport used a savepoint per row making it useless if you want to import csvs with a few thousand rows, requests doesn't officialy declare thread safety, I could go on and on ...

> Auth is a solved problem

It is solved until you have to integrate with third party home grown implementations and providers that implement the specs except for a little bit of behavior that is not in the spec.

Well if your working set fits RAM your tables will be stored in memory in the shared buffers.

Some people use the ORM models as pure persistence models. They just define how data is persisted. Business models are defined elsewhere.

I think makes sense when you application grows larger. Domains become more complex and eventually how data is persisted can become quite different from how it is represented in the business domain.

How much time did the PyAST_mod2obj actually take? The rewritte is 16x faster but the article doesn't make it clear if most of the speedup came from switching to the ruff parser (specially because it puts the GC overhead at only 35% of the runtime).

It doesn't to be puzzling just read the motivation section of https://peps.python.org/pep-0703/

> But once your tables start to grow it will become misery to work with.

I buy the data layout argument for databases with clustered tables without any smi-sequencial uuid support. But the storage argument looks vanishingly applicable to me: if someone needs to add a column to one of these tables it basically offsets a 4 byte optimization already.

I'll be blunt, having experienced the damage caused by DRF Model* accelerators in mid sized codebases I just hate it.

CRUD stops being CRUD quickly, these CRUD accelerators just intruduce more non linearity into the development. Its easy to hit a wall and hack around the accelerator to make a little bit custom behaviour leaving behind API implementations that are totaly "irregular" from each other each one mixing different low level changes in the middle of high level accelerators.

If a government is small does it have enough power to impose the rule of law and be an economic and social moderator ?

Congrats to the team. I think it is particularly impressive (and a bit scary) that DDL changes are also synchronized to the clients automatically!

They are not polyfills. Multiple scheduling modes are provided for libraries that are not thread safe (it's a total mess and I avoid these wrappers like the plague)

Is this resource up to date? ALTER TABLE ADD FOREIGN KEY NOT VALID (PARENT) shows a stronger lock than ALTER TABLE ADD FOREIGN KEY (PARENT) while the PG docs says that the locks should be the same.

Isn't a Pareto optimal solution always at the edge of the feasible space?

Should this be the take away? It looks to me that people are building pipelines without taking into account that they change roles every time they have to build a package, from a package consumer to a package packager. Even if the package developers set an upper bound on the build dependency it is the packagers responsibility to provide a deterministic build environment.

If you need to buy into the async ecosystem for some special reason my recomendation is to:

- pick a mature ASGI server

- pick a framework and libraries that have been designed from the start with async in mind. Be suspicious of libraries that support sync and async APIs without clear guard rails between the too implementations

- avoid setups where you have multiple event loops in a single process.

Look at the intended semantics [1], and then read the implementation [2]. Can you figure out if the implementation is correct? Can you infer the possible limitations of the approach at glance? Can your async library actually handle being called with multiple event loops installed?

I have zero trust in this code and I have been bitten by fixes to this library that introduced deadlocks in my own code.

[1] https://github.com/django/asgiref#synchronous-code--threads.

[2] https://github.com/django/asgiref/blob/main/asgiref/sync.py#...

I'll have zero trust running async Django until all sync_to_async and async_to_sync calls are removed from the code base.

In my current codebase there is a lot more overriding going on than simply implementing the retrieve/list/etc... methods. On a quick review I found overrides for: - get_object - get_serializer_class - perform_create - get_queryset - get_serializer_context - perform_destroy

I read the article and I'm left scratching my head why this advice doesn't apply to DRF.

The DRF Generic ViewSets and Views provide maximum magic plus they also shift part of the creation process into Model Serializers. Doing anything custom with this setup involves overriding bunch of methods and chasing their original definitions through an handfull of mixins.

With the Vector API comming I don't see this PR going through. A light search on the OpenJDK mailing list found no discussion.

There is a good article [1] discussing this state of affairs where application developers are straight jacked because they end up integrating too many systems and there is no distributed transaction covering them all.

[1] https://queue.acm.org/detail.cfm?id=3025012

Scala is probably not a good example because if you need some quick and dirty printing you can override toString and keep the rest of the generic code intact. In OCaml, Rust and Haskell you would have to add type constraints in a bunch of places to make println! T.to_string and show work.

Tom DeMarco expressed the same exact point:

> https://www.computer.org/csdl/magazine/so/2011/06/mso2011060...

Is there a backup for all the problems and solutions?

More examples: the browser can display pictures because there is a media type for them, same for sounds and videos.

There is one book about the CPython internals: https://realpython.com/products/cpython-internals-book/.

You can also explore the CPython dev guides: https://devguide.python.org/internals/.

Kdiff3 is still developed. You can download newer versions here: https://download.kde.org/stable/kdiff3/

I'll rephrase my point:

  This dismissal of business requirements as not generating technical problems big enough to require deep work is very interesting.

This dismissal of business requirements as not technical is very interesting.

Don't you ever get business requirements that touch hundreds of existing use cases? Or business requirements that sudenly require paying atention to concurrency in multiple parts of the code? Or business requirements that introduce processes that produce and process huge amounts of data?

  For these 64-bit index entries we’d expect to have to scan roughly:
  index_row_size⋅rows=2⋅64bit⋅10^5=1.5MiB

Where do the 10^5 rows come from? With a composite index and a point query doesn't the database scan just the 100 returned rows?