A Reality Check on Rewriting in Rust

Posted on by
Reply

JetBrains published a guest post by the cot.rs maintainers reviewing what actually happened when open source and commercial teams rewrote existing software in Rust, rather than relying on the hype. The findings are more nuanced than the “rewrite it in Rust” slogan suggests, since some performance gains come from Rust specific advantages such as auto vectorization or a concurrency model that makes correct parallel merge sort easier to implement, while other gains come simply from a team rewriting a project from scratch with decades of hindsight and no legacy production constraints. Separating those two causes matters, because a team that attributes a speedup to the language alone may be signing up for a multi year rewrite when a more modest refactor in the existing codebase would have delivered most of the same benefit. (btw, I have ranted here how hard it is to switch to a Rust style of programming)

The failures documented in the post are just as instructive as the wins. Cloudflare shipped an unwrap that took down a request scoring component, sudo-rs echoed a partially typed password back to the terminal after a timeout, and the first CVE in the kernel’s Rust code came from a race condition inside an unsafe block, which is a reminder that memory safety guarantees hold only within the boundaries a team actually enforces. Prisma abandoned its Rust query engine due to skill set gaps and deployment complexity, and Loglog Games left Rust after three years because the language rewarded refactoring more than the fast iteration a game studio needed; both cases show that a rewrite can be technically sound and still fail the organization that undertook it.

This same discipline shows up in Raphael Bauer’s older but still circulating argument for defaulting to PostgreSQL over a specialized database, message queue, or search engine for as long as the workload allows it. The underlying principle in both pieces is the same, even though the technologies are unrelated: reducing the number of moving parts in a system, or the number of languages and services a team must operate, tends to matter more for long term velocity than the theoretical ceiling of any single component. Rust’s own authors reach the same conclusion from the opposite direction, recommending incremental expansion into a codebase rather than a full rewrite, since the projects that succeeded at large scale, such as the Linux kernel and Windows, expanded gradually and kept the surrounding system running throughout.

The broader point for engineering leadership is that technology selection benefits from being evaluated against the operational cost of running it, not against the best case demo of a new tool, and that a decision made for good reasons in 2015 deserves the same scrutiny when reapplied to a system in 2026.

Sources:

Blazingly Fast or Blazingly Hyped? A Reality Check on Rewriting in Rust


https://www.raphaelbauer.com/posts/postgresql-everything/

DuckDB and Spark – Parquet

Posted on by
Reply

After this post from Matt Martin, I was curious if his findings would hold for Parquet files. I ran two reproducible, Docker-based experiments, using identical resources and the same 1,000-file Parquet dataset, with correctness checks to ensure both engines produced matching results. In the analytical query test, DuckDB’s median processing time was 3.1 seconds versus Spark’s 17.1 seconds, making DuckDB 5.52× faster. In the compaction test, which read, sorted, and merged the source files into a new compressed Parquet file, DuckDB finished in a median of 9.5 seconds versus Spark’s 60.4 seconds, a 6.35× advantage.

https://www.linkedin.com/feed/update/urn:li:activity:7494050617556987905/

https://github.com/sergiorgiraldo/tst1/tree/master/duck

Shopify: Scaling inventory reservations

Posted on by
Reply

Many architecture discussions start with choosing the right database, and we recently went through a similar decision in our own project, where our understanding of the data model made a strong case for a distributed database and a master-node architecture; the expected access and partitioning patterns did not materialize as the system evolved, so we eventually moved to a non-distributed database to simplify the landscape and remove distribution costs that were no longer giving us enough value. Shopify’s inventory reservation migration is a reminder that a useful question would be if the whole transaction path is understood well enough to identify the actual constraint.

Shopify moved inventory reservations from Redis into MySQL so reservations and the inventory ledger could participate in the same ACID transaction, which removed a class of consistency problems created by coordinating state across two systems.

The interesting part is what happened after the database design worked; throughput still hit a ceiling, query latency remained acceptable, and CPU was not saturated, so the team instrumented connection usage by business process and found that other checkout work was holding connections longer than expected. After reducing reads and transactions on the primary database, and revisiting an old InnoDB concurrency setting, the system moved past the previous limit, which reinforces a point that applies well beyond MySQL: bottlenecks often appear at the boundary between components, not inside the component receiving the most attention.

I will remember this in my future architecture reviews. When the numbers do not agree with the current diagnosis, expand the observability boundary before settle on a conclusion.

https://shopify.engineering/scaling-inventory-reservations

World Bank: The Promise of Artificial Intelligence

Posted on by
Reply

Elon Musk knows how to promote himself, he said recently that AI and robots will replace all jobs, and that working will become optional. It is a memorable line, and it travels fast. I read last week the World Bank’s World Development Report 2026: The Promise of Artificial Intelligence, and the picture it paints is far more grounded. It is the first comprehensive assessment of what AI means for the 6.8 billion people living in low and middle income countries, and the jobs finding deserves attention. Roughly 4.5 percent of jobs in those economies are amenable to automation by generative AI, against 14.2 percent in high income countries, while 16.2 percent are amenable to being complemented by AI. The report is direct about it: AI is not yet replacing large numbers of jobs in most developing countries. For most of the world, the immediate story is augmentation, not elimination.

I am an optimistic guy but not to the level of Pollyanna. The report is candid about real pressure on call centres and business process outsourcing, about early evidence that entry level white collar postings have thinned in India and China (i see this in my banking industry for sure), and about the dependency risk that comes with a handful of companies controlling the frontier. But the binding constraint it identifies is not runaway machines. It is reliable electricity, internet access, education, and local language data. In Sub-Saharan Africa, nearly one third of rural schools still lack dependable power. It argues that countries should be blinded neither by the hype nor the hysteria, and offer a plain framework instead: adopt, adapt, then advance. What stays with me is how much of this looks less like a technology story and more like an old fashioned development story wearing new clothes.

https://www.worldbank.org/en/publication/wdr2026

XY Python Library

Posted on by
Reply

It is hard to get impressed by libraries, too many new, too many often. XY got me. Python charting, Rust core, and the number that stopped me is in their benchmark table: 1M points renders in 0.084 s, 100M points in 0.081 s. That’s not a speedup, it’s a flat line across two orders of magnitude, the 100M case is marginally faster than the 1M one. What that flatness tells you is that render cost has stopped being O(N). Above ~200k rows XY quits drawing one marker per row and computes a density surface in Rust, bounded by your screen resolution: cost tracks pixels, not rows. The residual ~80 ms is fixed overhead, build the spec, ship typed binary buffers instead of JSON, land a stable frame. Every exact-marker path scales the way you’d expect; Matplotlib crosses a second around 3M, Plotly around 2.5M.

The obvious objection is that aggregation is a lie you tell your users. XY’s answer is that canonical f64 columns stay in Python, so zoom re-runs the same pipeline over the new range and drills back to exact rows, and a selection returns the original rows. They also published the density=False line with same engine and no aggregation credit, 100M exact markers in 1.34 s! Well, take with a grain salt because it’s only version 0.0.4, nevertheless it is promising for a stuff we use a lot

https://github.com/reflex-dev/xy

The collapse of the web as we know it

Posted on by
Reply

On March 5th, TheNumbers.com, the film industry’s most trusted box office database, went dark without warning. It came back a week later stripped down, missing historical charts, movie pages, and its report builder. The cause was not a single dramatic event, it was a slow collapse under a combination of pressures that most small, independent websites are not built to survive. Founder Bruce Nash later revealed that only 10% of the site’s traffic came from actual human visitors, the rest was AI crawlers and agentic bots hitting a thirty year old system with 160,000 legacy files. Buried in that traffic were also signs of deliberate probing, likely aimed at accessing box office data before it went public, since prediction markets use those numbers to settle real money bets.

The deeper issue here is not that one site got hacked, it is that the assumptions the open web was built on no longer hold. Data quality and traffic volume are no longer reliable indicators of a site’s health, resilience against automated extraction now matters just as much, and any business relying on a single, aging web presence should treat that infrastructure as a liability to be actively managed, not a static asset to be left alone. And scarier, for the small website mantainer, it is a Davi-Goliath battle that most of them does not know how to fight.

https://stephenfollows.com/p/what-just-happened-to-thenumberscom-should-worry-us-all

Digital Euro

Posted on by

If you work in the finance sector, specially in Europe, this is a must-read, the announcement of the digital euro pilot.

– this is not a digital coin;
– this is more like a payment hub, think of PIX in Brazil;
– the ECB issues and underwrites the transfer, but distribution stays through banks and licensed PSPs.

https://www.ecb.europa.eu/press/pr/date/2026/html/ecb.pr260714~8cd07d9d45.en.html

Entire.io

Posted on by

I just got my invire for entire.io, it is really cool, incredibly ui, easy cli. It does not track only what changed in the commit, it captures the entire session I had with claude, the prompt, answers, tool calls, token usage, top! I was mantaining a very naive tracker keeping the guids so I could return to a session, dont need it anymore. well, until they charge me an arm and a leg 🙂

https://github.com/sergiorgiraldo/entire101/