More studies needed to confirm this, it is a single data point. Still it looks like Rust could take the HPC world by storm once it gets a better GPGPU story (still early days there).

Or why you shouldn't insert an abstraction just for the sake of it. Also clearly not all abstractions are created equal.

A good reason to use more modern C++20 APIs for parsing code.

Excellent piece which shows why React (or Angular) is almost always a bad choice and that you'd be better off banking on the underlying web platform. It leads to better user experience full stop. The article also goes in great length debunking the claims which keep React dominant.

OK, the numbers are indeed impressive. And it's API is fully compatible apparently, looks like a good replacement if you got Pandas code around.

Nice paper which debunks the choice of the language as an important factor for energy efficiency. The previous papers had a too simple model, this one puts forth a more complete causal model. There are many factors at play regarding energy efficiency, the programming language itself is not really one of them.

Data layout is essential for performance reasons. It is too often overlooked. If you want real speed you need to help the memory subsystem.

I'm not sure I'm sold on this one. Interesting food for thought but I'll have to mull it over for a while I think. I'm concerned about the performance implications of querying like this.

Several ways to deal with the task, which are the performance implications? Clearly coroutines aren't the best tool for the job here.

Nice results. Interesting implementation too. I wonder if some of it will make its way to the glibc or musl.

If you still needed to be convinced you need to use std::array and std::span, here is the proof.

Good reminder that packing your data is generally the right move when squeezing for performances.

Looks like there is still some work required on QUIC. There is a path forward though.

An old article but a good reminder: you have to choose between latency and throughput, you can't have both in the same system.

Interesting reason which would explain the Selenium flakiness. It's just harder to write tests with race conditions using Playwright.

SIMD is hard to use, not all problems can apply to it. But when they can, the performance gain can be great.

Interesting, it confirms garbage collectors can be the source of unrecoverable performance degradation in request based systems.

Or why anticipating too much is merely a gamble. You can be lucky, but how often will you be? Also I agree that in such cases the performance will be impacted longer term leading to a death by thousands of paper cuts.

Compile time reflection in C++ will indeed be a big deal.

Interesting dive into some of the performance improvements introduced into recent CPython releases.