201–210 of 239 posts
I would question choosing Python for large server projects because the performance ceiling is so low. At least with the "middle tier" performance languages such as Java / C# you are unlikely to require a complete language switch as the project scales.
With cloud and infinite horizontal scaling...hitting that performance ceiling is an indication of a poor design.
My experience doing perf optimizations in real world systems with many many people writing code to the same app is a lot of inefficiencies happen due to over fetching data, inefficiencies caused by naively using the ORM without understanding the underlying cost of the query, and lack of actual profiling to find where the actual bottlenecks are (usually people writing dumb code without realizing it's expensive). Sure,…
I increasingly lean towards plain SQL over ORMs. It requires greater familiarity with SQL but I prefer that over greater familiarity with ORM-specific syntax that doesn’t translate across frameworks or languages. In addition, you can prototype new queries and profile existing queries in the database and copy-paste directly into your code.
And to me, SQL is the easiest language to learn and read of all, and while I understand doing basic marshalling of SQL records into objects is tedious, its really not hard at all, and it just saves so so much heartache down the road.
The exception might be very basic CRUD apps that are meant to be used by third parties and want to support multiple backends like mysql/postgres/whatever. There might be other exceptions as well where you are just trying to prototype/find market fit, but for a typical project that you know is going to be used in a real way, the risks just don't outweigh the benefits IMHO.
Some of the team griped a bit, but I absolutely think it was the right move in hindsight. At least once a year I would hear about an outage due to an ORM gone wild, and these outages were usually prolonged by the fact that things function, and then there is finger pointing between the DB/DBAs and the app developers, etc.
Earlier quoted context omitted.
It needs to be emphasized how artificial these benchmarks really are. Here is the source for the Fortunes C# benchmark: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... There's no routing or templating, it just writes a bunch of strings. No one would build an actual web app this way. The only C# benchmarks that are remotely realistic are the mvc variants, starting with aspcore-mvc-ado-pg at number 79.
https://github.com/TechEmpower/FrameworkBenchmarks/wiki/Proj... Routing is required, but generally the rules allow things to be "reasonable" and "acceptable", which lets all these weird implementations through. Honestly, they should remove the "Implementation approach" column, because basically every implementation is marked as "realistic", making it meaningless.
https://github.com/TechEmpower/FrameworkBenchmarks/blob/5b0e...
I mean I guess technically that's routing but it's not remotely realistic. Only the mvc variants use the actual framework's routing system.
Earlier quoted context omitted.
With cloud and infinite horizontal scaling...hitting that performance ceiling is an indication of a poor design.
This is false, since it is not always easy (or even possible) to horizontally scale a work-load.
Earlier quoted context omitted.
That 7 million requests per second is achieved by writing a hard coded plain text HTTP response string directly to the client... it is so far disconnected from any real world use case that the number is basically meaningless.
It's still 8th in the composite benchmark. And the criticism you're leveling would affect the entire benchmark design, rather than a particular framework score, no? [1] https://www.techempower.com/benchmarks/#section=data-r20&hw=...
Indeed. The problem is that many of the scores in the top 100 are really misleading because no one building a web app would implement things that way. There is still some value in the lower down benchmarks but you have to basically read the underlying source to determine if the implementation is remotely realistic or not. For starters I would ignore anything classified as "platform" which is described as:
Platform, meaning a raw server (not actually a framework at all). Good luck! You're going to need it.
Edit: I looked into the "asp.net core" composite score a bit more, it looks like those benchmarks are based on the aforementioned "platform" implementations for each test. I actually think this score is even more misleading than the individual benchmarks. At least the individual benchmarks show you the difference between "aspcore" (platform), "aspcore-mw" (middleware-only), and "aspcore-mvc" (full framework with routing).
Here are recalculated composite scores based on the more realistic implementations (aspcore-mvc, aspcore-mvc-ado-pg, aspcore-mvc-dap-pg, aspcore-mvc-ef-pg):
ASP.NET Core MVC with ADO.NET (raw SQL): 3029
ASP.NET Core MVC with Dapper: 2591
ASP.NET Core MVC with Entity Framework: 2195
My experience doing perf optimizations in real world systems with many many people writing code to the same app is a lot of inefficiencies happen due to over fetching data, inefficiencies caused by naively using the ORM without understanding the underlying cost of the query, and lack of actual profiling to find where the actual bottlenecks are (usually people writing dumb code without realizing it's expensive). Sure,…
There is lots of truth to this. Some ORMs like Django perform joins in very unsuspecting ways. A simple example is, say, foreign keys. Trying to access the foreign key of an object by doing `book.user.id` does an additional query for the user table to get the ID. It's less known that the id is immediately available by just doing `book.user_id` instead. I've spent time optimising things like text searches down from 20…
Earlier quoted context omitted.
This is false, since it is not always easy (or even possible) to horizontally scale a work-load.
If you've made it impossible or just difficult to scale horizontally in the server world, yeah, you've got a bad design.
1. how your solution is designed (your point, and I agree this is often done poorly)
2. the problem / work-load you are trying to scale (my point).
Edit:
Another example. Can you rewrite NGINX in a slower language and use horizontal scaling to fix it? Of course not, because that horizontal scaling would itself leverage NGINX (or something like it)!
Related to ORMs/queries/performance, I have found the following combination really good: * aiosql[0] to write raw SQL queries and having them available as python functions (discussed in [1]) * asyncpg[2] if you are using Postgres * Map asyncpg/aiosql results to Pydantic[3] models * FastAPI[4] Pydantic models become the "source of truth" inside the app, they are designed as a copy of the DB schema, then functions rece…
Earlier quoted context omitted.
I agree with your general take on developer productivity, but I don't feel that modern JS is significantly messier than Python, at least not to a level where it significantly impacts productivity (I'd rather avoid a debate on the abyssal depths of the language, eg, type coercion) I feel about the same amount of grievances with both. For instance I dislike Python's async and functional semantics ( list(map(lambda n...…
Thanks for the JS perspctive. Since my frontend work mostly involves hacking together prototypes and trying to integrate some JS libs in as quickly as possible, I guess I am kind of biased.