Ah yes, MinIO, that open source S3 alternative that got archived last week.
To me that's the biggest problem when self-hosting services.
On day to day operations, some times it just breaks and the time to get it back varies from a couple of hours to a couple of days.
And for the longer term you regularly have to upgrade things yourself which takes time and energy and is stressing for stateful deployment.
And then you have it, at some point maintainers are just exhausted and the project is gone.
I had a similar experience where someone that had prior experience with django while we were using sqlalchemy started to design a django-like ORM on top of sqlalchemy.
Of course it took him some time to get working, was a hell to understand and extend and most importantly lacked support for basic features.
Fortunately it was limited to a small isolated service but I can imagine the damage on the long term if you continue that route on what becomes a huge monolith after a few years.
The goal of the article is not to know the exact numbers by heart, duh!
Care about orders of magnitude instead, in combination with the speed of hardware https://gist.github.com/jboner/2841832 you'll have a good understanding of how much overhead is due to the language and the constructs to favor for speed improvements.
Just reading the code should give you a sense of its speed and where it will spend most time.
Combined with general timing metrics you can also have a sense of the overhead of 3rd party libraries (pydantic I'm looking at you).
So yeah, I find that list quite useful during the code design, likely reduce time profiling slow code in prod.
In that time the java app parsed 50 strings for object hierarchies (using a regex that isn't cached) and extracted values from a request object to a processing object, handled errors, and logged results.
3 times.
This is the naive version of that code, because "I will parallelize it later" and I was just getting the logic down.
Turns out, when you use programming languages that are fit for purpose, you don't have to obsess over every function call, because computers are fast.
I think people vastly underestimate how slow python is.
We are rebuilding an internal service in Java, going from python, and our half assed first attempts are over ten times faster, no engineering required, exactly because python takes forever just to call a function. The python version was dead, and would never get any faster without radical rebuilds and massive changes anyway.
It takes python 19ns to add two integers. Your CPU does it in about 0.3 ns..... in 2004.
That those ints take 28 bytes each to hold in memory is probably why the new Java version of the service takes 1/10th the memory as well.
22ns might be about 100 processor instructions. Somehow I doubt that any programming language can parse 50 strings in 100 instructions, let alone with naive code.
Python is slow but in my experience (that mostly relates to web services and data processing) I found that I/O was by far the biggest bottleneck. Waiting for the database, another http service or local storage, which often takes more than 1ms anyway.
Well you nailed it, the language you're looking for is SQL.
There's a reason why duckdb got such traction over the last years.
I think data scientists overlook SQL and Excel like tooling.
But on the other hand, that's doesn't mean SQL is ideal - far from it. When using DuckDB with Python, to make things more succinct, reusable and maintainable, I often fall into the pattern of writing Python functions that generate SQL strings.
But that hints at the drawbacks of SQL: it's mostly not composable as a language (compared to general purpose languages with first-class abstractions). DuckDB syntax does improve on this a little, but I think it's mostly fundamental to SQL. All I'm saying is that it feels like something better is possible.
About the cookie banners, I'm honestly not sure it's a regulation issue.
For >90% of the websites the "reject all" option have no impact on user experience, so either everybody is breaching or the banner is useless in the first place.
Do you get prompted for the choice the next time you visit the website? Are they websites you need to log in to? Those are really the only user experience things that would be obvious in most instances — everything else is just pure data mining for usage analytics (::knowing wink::) and overt tracking. Some sites absolutely do not respect any of the choices, but that’s not the normal behavior.
reply