I just had a rude-awakening reminder that we desperately need more tools for low-traffic communication.

TL;DR: Managed to find a setup that lets me, among other things, write this post — while on the plane — because some internet was leaking through.

But it is be the next post. For now, a quick rant.

Longer story: due to multiple rebookings on my flight from Germany to the West Coast (screw you, Condor), my final leg was delayed by 24 hours. Because of this I missed telling a friend our breakfast would not happen. Totally my fault.

Logistics were hell. Barely slept. Eventually I made it to my seat and zoned out right away. Then I wake up after a nap, automatically tap the calendar icon on my phone, and see or scheduled breakfast scheduled. In ten minutes. While I’m flying over Greenland.

I rush to buy the in-flight internet to apologize profusely. It doesn’t work on my laptop. I try from the phone. Miraculously, one email goes through. I see his reply… with a question. And I can’t respond because connectivity.

But now I’m awake. And angry. And still an engineer.

Even DNS doesn’t work — my server’s hostname doesn’t resolve. But I find an IP of a random work staging server in the old copy of the /etc/hosts file, SSH into it, and from there, use nslookup to resolve the IP address of a serve that is truly mine.

Quest mode on!

Text-mode Google via lynx is unusable, because of that stupid cookie popup. After some trial and error, I get DuckDuckGo working in links. Too slow to research. Can’t log into ChatGPT, of course, not even worth trying. DeepSeek via the text-mode browser doesn’t work, it needs JavaScript. Ah! DeepSeek!

Instant sudo apt-get install ollama. Can't list model names from the command line. Back to the "browser" with DuckDuckGo. Found it — deepseek-r1. A minute later, I have a weak but usable text-mode model to prompt.

Now: why does ssh -X fail? Turns out the X server system isn’t included on macOS. Found out XQuartz will do. DeepSeek can’t give me the exact URL, but DuckDuckGo can. Download to the server: done. Copying the .dmg to the laptop will take over an hour.

(Still, it's possible. Latency’s in low hundreds of ms. So SSH at least is usable — not pleasant, but usable.)

And then I realize I’m an idiot. SOCKS proxy to the rescue. I tried with -D 5000:5000, it did not work, and I could not understand what's wrong with port 5000 — thought it could be my MacBook or this inflight Intenet. But I can run a local piece of code on port 3000 — just checked. So back to this quest, now that I have DeepSeek. Alas, it's just -D 5000 to spin up that proxy.

Arc, Chrome, Brave — none let me set proxy settings in-browser. But the system-wide config works. And I’m online.

Gmail, apparently, has discontinued its JavaScript-free mode, shame. So no email. But Telegram Web works just fine, and here I am.

To close out this rant-ey post: I firmly believe that in 2025 it is a crime against humanity that we don’t have Starlink on every Europe-to-the-US flight.

Thanks for reading my rant. The very next post is more about tech, inspired by the above.

We, as the tech community, badly lack low-traffic-friendly tools.

Why is there no text-mode messenger client? Signal? Slack? I’d love to be an occasional user. And it’d be lightning-fast — single-digit milliseconds.

As a Vim user, I’d appreciate that. I’m sure many would too — folks who’d rather not leave the terminal for second-long tasks.

Outages are terminal-heavy. Old-school SREs still use IRC (!) because it’s more reliable and faster. If I’m already in the terminal, why shouldn’t the “chat window” be just a tab away?

Imagine a terminal UI like lazygit — the one in the screenshot. I don’t use it, but it’s a great UX reference.

Most engineers have a Linux box or two they can SSH into. I’d love a Linux user account where the login shell is a console-first messenger. Open the connection, handshake via asymmetric crypto, and you're chatting securely over Signal or something similar.

My nerdy belief: if I need to send or receive 3KB of text, total network usage should be ~3KB plus ~100 bytes of metadata. That’s it.

This post (and the rant right above it) are ~3KB each. Twenty SMS messages.

For comparison, I’m still on the plane, and I waited for this screenshot to finish uploading over my tunneled proxy from the earlier post. The image is nearly 300x that size!

Two more thoughts — because this is one of my favorite rabbit holes:

One: the Web3 crowd gets it.

Among all tech spaces I’ve touched, it’s the core Web3 engineers who consistently think in terms of lightweight, sovereign, secure comms.

While I’m still on the edge of protocol-core Web3 — we’re building a near-chain system at work — I’m tempted to dive deeper. Rust is great, and I’ve written about it plenty. This may well be the next step for me.

Two: SSH is overrated and nearly obsolete.

Security-wise, too few understand how the client and server interact. Did you know your SSH client will try all your keys unless your .ssh/config says otherwise? I’m no expert, but that smells like metadata leakage. Especially with a misconfigured server or a MITM in play.

And simplicity? Forget it. Too many protocols.

Back in the day, I could implement RSA from scratch. Long multiplication, modular arithmetic — done. Honestly, I probably still could. The math is trivial and BigInteger comes for free now. RSA in Python will definitely fit on a T-shirt.

Web3 has better ideas. Take WalletConnect. If we’re dreaming of a secure, ASCII-only, low-traffic messenger, here’s what I want:

1) A wallet app on a 100% air-gapped phone — any Web3 wallet would do.

2) Mnemonic-based login. Just a 12-word key — not a “wallet” in the money sense, just your identity. No funds required, no tax/reporting stress.

3) And a VT100-style ASCII “messenger client” with basic encryption. It boots, handshakes, opens your chat shell. Think SSH replacement + terminal-mode messenger server.

In fact, I'd prefer the terminal from (3) over SSH once mature — especially if it supports passkeys natively, which it surely will.

By super-lightweight I mean: it fits on a T-shirt. If it can be typed from memory, it’s good. 99.9% of people won’t rebuild it, but that short reference implementation must exist.

Cypherpunks got it right printing source code on shirts. That’s how we got PGP, HTTPS, and all those lovely privacy things.

That spirit — radical auditability, minimalism, transparency — is mostly lost now. Except, maybe, at the heart of crypto.

And yes, this would work over deep-packet-inspected networks too. Every message is just an HTTP request, not even HTTPS.

If someone has built this already — I’d love to hear. Maybe the Discord or Bluesky team shipped something in their labs? Maybe it exists and just needs visibility?

Besides, with LLM-assisted coding the game is only getting more fun! The T-shirt code could be a prompt for DeepSeek and the hash of the model to use — so an offline device with the model and toolchain can build the secure setup we need, just by being fed the OCR’d T-shirt!

I'm still in this love/hate relationship with Discord.

On the one hand it's a powerful platform built on solid engineering principles, that does, unlike Slack, keep messages forever. Which is great.

On the other hand its UX is bloated, and often times I quite literally click on the wrong button. What are "boosts" after all?

Is it most definitely on purpose that they are not hidden under some hamburger menus, right? My take, which I'd be comfortable betting far more than even money on, is that Discord's PMs are sincerely trying to have more people try these "boosts", while I personally believe a good platform can exist just fine without them.

Anyway. Just now I wanted to share a link to a profile of a friend I chat with on Discord. Literally, "it's this dude on Discord, pls message him directly".

And for whatever reason I can find the "copy profile link" option anywhere. None. Zilch.

For myself too. There's no "permalink". There's just "Copy Username".

Any reason to not have discord.gg/u/${username} copy-paste-able by default? Or discord.eth/${username}. Or literally any means to copy and paste one thing, instead of my having to manually type in "his discord is", followed by pasting his handle?

Although I'm probably complaining too much. Telegram also just copies the username. For a channel, yes, the full paste-able link is there. For me personally, just the `@`-handle.

Perhaps it is indeed time for the next-gen messaging platform!

• Full interoperability with existing platforms, at least with the users who have enabled it explicitly — I sure will for myself.

• Full data sovereignty. "Take your data with you" is a default option. One-click configuration for incremental ongoing encrypted backups to any major data storage provider.

• Full end-to-end encryption by default, via an open protocol, and including using an external air-gapped security device for those who are truly paranoid.

• Zero need to install anything: spin up an open-source Docker container and use localhost:3000 safely and securely

• And make it trivial for anyone who has their own domain to add a page to "message them" right there.

For bonus points and for monetization:

• Spam-free, so that anyone who I do not know will have to pay some ten cents to message me. I'll pay them back implicitly if I respond, but unsolicited "add to contacts" will be as good as gone.

• And perhaps integrate it with some calendar for scheduling, so that people can collect payments if they are indeed selling their time for money. Accept any form of payment, and send funds to the recipients in any form. So that it's also a bridge between credit cards and Metamask and what not. Take some ~3% cut, so that the platform is cash-positive.

Why does the ☝ not exist yet? I'd definitely claim my short vanity name and use it right away. And for "cold inbound messages" I will absolutely switch to sharing the link to this platform instead of my email or my phone number.

After all, wasn't it the goal of every single messaging platform since ~2005 to kill email? Last time I checked — today — email is very much alive and well. So, these other platforms are clearly underexecuted to my taste.

So, to add to the list of functional requirements above: there should be a trivial way to "email this person's messenger inbox", as in, to send an email by adding some domain to their username on this platform, knowing full well they will receive this email. Perhaps straight into their junk folder unless the sender has either paid those ten cents, or has plenty of mutual friends with the recipient.

There's one thought I keep talking about but have not put down in writing yet. IMHO it's interesting by itself, and in the day & age of AI-assisted vibe coding, things get even more exciting.

First off, I have to confess: I do have some "hierarchy of complexity" of software engineering tasks deep in my mental model of the world. Curiously, this "hierarchy" maps literally 100% to the order in which the AI "takes over" our jobs.

And this hierarchy has one fundamental axis — which is: how difficult it is to generate a good test suite for a piece of code.

In other words, if you need to assess the correctness of some black-box solution, for some problems this is trivial, while for others it's nearly impossible.

The nerd in me also wants to say that the problem space should be "convex," as in, it should be "friendly" towards making incremental improvements. Deriving a private key from the public one is a "trivial-to-verify" problem, but knowing that the solution is trivial to verify tells us, hopefully, nothing about how to approach it. Most problems are not like this, though.

So, when it comes to verifying the correctness of the solution, my simple heuristic is: the more straightforward this verification is, the "easier" the problem itself is.

For instance, rendering a web page correctly and making sure it is responsive is something that is trivial to check. A median human being who knows nothing about software engineering can tell a correctly rendered, quick-to-use website or app from a bad one.

On the other hand, a problem such as the query optimization engine for a distributed, guaranteed-consensus, latency-sensitive database service is very, very hard. I would go as far as saying that, oftentimes, for a problem of this complexity, one has to completely reverse-engineer the "black box" solution they are asked to test in order to even begin reasoning about what the difficult corner cases should look like.

Another angle to take is: how difficult is it to create training data?

ACM ICPC or Leetcode-style problems have this wonderful property that, once you have seen plenty of them, you know damn well what the corner cases to consider are. The above is even more true when it comes to tech interviewing. So, when it comes to "reasoning" — whether performed by the model or by the neurons existing in meat-and-flesh — enough experience of seeing similar problems translates directly to being able to predict pitfalls and to avoid them.

Which effectively means that the "competitive programming" degree of complexity is now mostly conquered by the AI. As in, a junior-ish engineer who is eager to learn and who is armed with a powerful AI will generally be able to produce a decent solution that fits the requirements — as long as they are allowed to spend several quality hours with the AI.

Since it does not require an insane amount of human comprehension to fully internalize the problem down to the degree where one can say, "I can do O(N) modify time with O(1) query time, or I can do O(1) modify time with O(N) query time, so to optimize for both here's an O(log N) / O(log N) solution that uses some balanced trees plus whatever deques or heaps that need to be there."

Optimizing database queries, on the other hand, is where in-depth intelligence and in-depth reasoning is still needed.

Although, zooming out even further, I'm quite content with the idea that it's the nerd in me speaking. Unfortunately to me — but, likely, fortunately for the planet! — most human beings do not truly care about the above. Which is also great in its own way, of course.

I try not to write about politics, but sometimes — for my own selfish reasons — I feel it's better to speak than stay silent.

It’s about Elon Musk.

Back during his first beef with Trump, I said (elsewhere) that he was picking the wrong hill to die on. But even then, I had a strong suspicion Musk was on my side.

That is: the somewhat neurodivergent, first-principled, “don’t betray me and keep your word” side.

I’m the first to call Musk out on his missed timelines. But as a friend of mine recently put it: “Lying to investors is a crime; lying in presentations is what high-profile CEOs do for a living.”

Much as I’d love a world where founders are accountable, today’s system over-rewards overpromising — both in business and in politics. If you want to "win bigly", you have to live with that. Even if it’s deeply uncomfortable.

So when I try to put myself in Musk’s shoes, I can’t help but sympathize.

First, the political left throws him under the bus — refusing to even mention Tesla in the EV discussion, and wasting billions pretending Starlink and Superchargers don’t exist, even while claiming to fight the very problems they solve.

Musk sees things are in emergency mode. So he buys Twitter and releases the Files.

When the left refuses to engage, he pivots hard right. Seems like a calculated gamble. He steps back from CEO roles in all his companies to work on DOGE. His net worth drops by over $100B while he tries to optimize government spending.

That too feels calculated. But as someone mildly autistic myself, I can’t help but respect it.

And what happens next? A betrayal. A bill that reverses everything promised — to him and to the public. Senators who voiced opposition quietly vote for it. The bill guts DOGE’s work and slashes EV credits.

I don’t necessarily view Musk as the savior of humanity. But I do believe that with stakes this high, and with his Mars dream being part of his core identity, his goals are very aligned with those of reasonable Americans.

Politics is a mess. The economy’s unsustainable. The social situation is fragile. Think tanks in the US are looking for their next martyr to unleash social unrest. Overall, the world is sliding toward instability.

All Musk really needs is ten more years of relatively sane, functioning capitalism. And honestly, that’s what most people want.

I’d personally pay ~20% of my net worth today just to insure against a meltdown in the next decade. Because if things hold, I know what to do with my life. If they don’t — well, all bets are off.

So yes. I can’t predict where this third party stuff leads. But I find comfort in thinking that Musk is saying: “F**k it. I need the world not to fall apart. This isn’t about ambition. The situation is forcing my hand. I don’t want to win — I just don’t want to lose. And they’ve left me no choice.”

“To execute on my vision, I need to protect myself — and by extension, the country and the world — from civilizational collapse. That collapse might excite some ideologues, but it doesn’t get us to Mars. So I’ll interfere. Even if it means taking on the risks that keep growing exponentially.”

Forgive the pathos, but from the game theory standpoint, this feels like a historic moment. I’d compare it to the Cuban Missile Crisis.

Back then, the U.S. used brinkmanship — raise the risk of mutual destruction to ~30%, then slowly de-escalate.

If you’re trying to push humanity forward on the Kardashev scale, I can totally see why Musk feels now is the time to place bold bets.

I'm starting to understand the value of a large screen.

A screen is large enough when it makes me not want to maximize every window!

On a smaller screen, pretty much for any deep work, "more is better". When the real estate of available pixels is in short supply, our brains learn how to quickly positions window "on the desktop one to the left", "one alt-tab / cmd-tab away", etc.

When getting used to a large screen, the first instinct that goes away is using more screen space. Because more is just too much, overwhelmingly too much. Especially with high resolution, when I can read a lot of small text here, there, and everywhere.

And it begins to make sense to think of how to arrange windows on the screen, not windows scattered across virtual desktops.

And once my brain entered this mode, I am fully embracing that more is better. As in, I can see myself using a ~50" monitor these days. Sure, I will not use most of its "screen area". But the thought that I can position another piece of documentation or what not and not get lost is a positive emotion in and of itself.

To put it blunt, I feel liberated, as opposed to claustrophobic, when working on multiple things at once on this large screen. Before, I used to close windows habitually, and even to reboot at times, just to keep this "psychological clean slate" clean enough. Now it's just meh. Keep calm and carry on. Not really important, as I can see everything that my system runs in one glance.

Of course if the argument is that a large screen is not a necessity but consumerism and/or acquired taste — can't argue against this. Guess I'm just sold. Amen.

PS: High resolution, high refresh rate, and low end-to-end latency is absolutely a must! I always knew it, but now I can tell for sure. Especially since I had a chance to compare different options firsthand, while configuring OS-es and cables. So, please, 120Hz at least.

PPS: Yes, I can still do a lot in the terminal. But I can now have six full terminals side by side, yay!

And PPPS: I'm still very curious about coding in VR glasses. Too afraid to try out myself, since, in my worldview, every other passenger on a transatlantic flight should be using them — so either the quality is not yet good enough, or the adoption is not there yet, which also likely means sub-par products. But can't wait for this era of my life to start some time in the next several years.

We're trying to make the Tail at Scale guest talk happen on August the 14th, Thursday, on my SysDesignMeetup.

Morning US time, evening Europe time.

This is the paper, by Jeff Dean and Luiz André Barroso. It covers many topics dear to my heart, such as how to measure latencies properly, and what is request hedging.

And Jordan, the speaker, knows this material in depth, and presents it well — I saw him perform firsthand and I loved the talk.

If you want to make it, please vote on the best time slot in SysDesignMeetup's #general Slack, channel, and use this link to join if you're not there yet.

Thursdays are generally not as good as Saturdays, while the topic is super cool. We will record it, but more live questions and engagement is always great. So this is one of those few cases where I'm not shy to openly say it's appreciated if you could share this post with friends who are into SysDesign! 😎

Imagine a successful software company trying to hire a bunch of people who live in a small town about an hour’s drive from the office.

And let’s say all of them are actually eager to commute — otherwise the analogy falls apart.

An obviously good idea is to run a shuttle. That way, instead of spending two hours a day driving, these people can spend two hours working. Or at least resting or prepping for the day — anything’s better than white-knuckling a steering wheel. Let's also imagine this is the future, and the bus is equipped with comfortable private rooms, conferencing setups, stable connectivity, and a smooth road. All the tech we could dream of.

From a cost-effectiveness standpoint, this is a no-brainer. You’re saving ~50 people two hours a day. That’s 100 productive hours, daily. The cost? A driver, the lease or rental on a nice bus, and fuel. Totally worth it.

But now, suppose for legal or compliance reasons — let’s say it’s a defense contractor — the company isn’t allowed to rent or lease the bus. The rule is: employees can’t be transported in third-party-owned vehicles.

Does that change the economics? Not at all. The solution is obvious: buy the bus. Problem solved. Security concerns handled. And in the long run, ownership is probably cheaper than leasing anyway — especially if you're allowed to trade the bus in later.

Silly example? Maybe. But this is exactly what the economics look like when comparing renting vs. buying GPUs to run large language models for AI-assisted coding.

A small GPU cluster powerful enough to run a serious reasoning model costs about as much as a decent shuttle bus. Both to rent and to buy.

A developer will likely be in AI-assisted coding mode for about two hours a day — same as our commuters.

And the power costs? Surprisingly comparable. The kilowatt-hours needed to move 50 people vs. the energy to run high-quality LLM queries aren’t wildly different.

So, if your company isn’t allowed — or doesn’t want — to trust its codebase to a cloud-hosted model, the answer is simple.

Buy the bus.

About Windsurf. Apparently my take is far from conventional, so I'll journal it here.

Feel free to comment on what a terrible person I am, or what’s rationally or morally flawed about this view. Seriously.

First things first: clearly the regular employees of Windsurf are on the losing end of this stick. I genuinely feel bad for you folks. Most of you worked hard based on the promise of a bright future. And the way the deal collapsed — not to mention how things were handled while it was still alive — left you with almost no good options.

That said, here’s my moral take.

Windsurf gambled. Hard. They aimed for a sky-high valuation, and in my book, that’s okay — if you’re planning to grow your revenue and profitability proportionally. But the higher the valuation you chase while fundraising, the steeper the fall if it doesn’t pan out.

Honestly, if I were a Windsurf employee, I wouldn’t have been celebrating when that deal was first announced. Quite the opposite — I’d be interviewing around. The odds of the deal collapsing are just too high. And if it does go through? Great. You get a lump sum either way.

In fact, I would’ve been candid during interviews:

“I’d love to keep building the best AI-assisted code editor. But my current employer is gambling too hard to my taste, and I’m concerned that the upcoming deal — whether it closes or not — will cripple my ability to stay on that mission.”

And if someone truly joined Windsurf to build the best AI-assisted IDE, I’m 100% sure they’ll land on their feet in no time. There are hundreds of companies building their own models right now! At least half of them would love to ship a great IDE alongside that model.

There’s so much important work to be done. Have those models generate SQL queries, eBPF rules, Rego policies, coq proofs — and auto-generate tests alongside the code as well. Help model-training teams with synthetic data and tighter automatic feedback loops. Endless amounts of deep, meaningful, technical work.

So: do I feel bad for Windsurf employees?

You gambled by staying with the company. It didn’t go your way. Yes, maybe on paper you had a meaningful net worth that just got wiped out. But that’s life with venture capital. Dust off, move on. That’s how the game is played.

In fact, I’d say I feel more sympathy for early, small-check investors than for employees.

Employees walked away with experience, networks, and shiny resume badges. Early investors? They had little to no influence over how the company was run and walked away with almost nothing.

I can imagine myself in that position — begging the founders to stop playing with fire and just focus on building the damn product. But those prayers would’ve gone unheard. And the founders? Well, they turned out fine, more or less.

So yeah — in my moral model, it’s the powerless early investors who deserve more pity than the employees.

They bet on a promising team. And then they watched, helplessly, as that team Martingale-gambled the company to death.

Sad — but not uncommon. At the end of the day, life is just a series of gambles. Thankfully, we have plenty of EV-positives ones to choose from in today's world, and we have a chance to place our bets accordingly throughout our lives. Far better than some 200 or 500 years ago. So, be grateful and move on.

To the employees: you gained valuable experience, made connections, and earned a major line on your resume. Use it wisely.

To everyone, employees and investors alike: embrace that even expected-value-positive bets don’t always work out. Unless you’re willing to risk it all, diversify your skills and your portfolio. Aggressively.

Full disclosure: I actually used Windsurf myself about six months ago. I think I even left them my credit card info. Not sure if I ever got charged (I switched to Cursor later), but I’m speaking from firsthand experience here.

And here comes the official #announcement.

We have a talk planned on The Tail at Scale paper by Jeff Dean and Luiz André Barroso!

Jordan West is an Engineering Manager at Netflix and a Cassandra committer. He’s worked on large scale deployments of Cassandra for the past 7 years and distributed databases for the past 10. He is passionate about growing the Cassandra community and working on large scale distributed systems.

Save the date, Thursday, August the 14th:

San Francisco, USA 10:00 am PDT
New York, USA 1:00 pm EDT
London, United Kingdom 6:00 pm BST
Amsterdam, Netherlands 7:00 pm CEST
Istanbul, Turkey 8:00 pm EEST

Google Calendar event: link.
See you at http://zoom.dima.ai!

I love factoids that sound almost unbelievable, and yet are more true than false. Especially when they touch on juicy subjects.

Here are two of my all-time favorites:

The first successful act of alchemy may have been performed by a communist.

Barack Obama literally won with a slogan that can be traced back to North Korea.

First, alchemy. If we take alchemy literally — the transmutation of elements — then basic chemistry doesn’t qualify. But nuclear reactions absolutely do. Which means the first man-made alchemic transformation legitimately was the Trinity test. And if we’re crediting one man for it, that would be Oppenheimer — who, in turn, may well have been a communist, or at least loosely affiliated.

Second, Obama’s campaign slogan, “Change we need.” Every Russian speaker knows the iconic Soviet rock song with a chorus about our hearts and eyes longing for change — sometimes even translated as “Changement.” The band is Kino, and it's as iconic in the USSR’s as Pink Floyd or Deep Purple is in the English-speaking world. Its frontman, Viktor Tsoi, was half-Korean. And his roots trace back to a region that, by today’s borders, lies within North Korea.

Not sure which of the two makes me smile more. Both are equally hilarious and absurd.

Is there a metric similar to DMIPS but for distributed concensus?

Clearly, by “DMIPS per watt” alone servers will beat laptops, laptops will beat smartphones, smartphones will beat Pi, and Pi will beat Arduino.

But we are no longer in the world of compute. We’re in the world of durability.

And when it comes to durability, a larger number of geo-distributed nodes in fault-uncorrelated areas is better than clustered centralization.

Clearly, if strong consistency is the goal, Google Spanner will beat Ethereum by a wide margin. And Ethereum will beat Bitcoin by a wide margin.

But here it’s not so simple. And perhaps Solana or Substrate nodes run on thousands of Pi-s will turn out better than a small number of semi-centralized mining pools.

Is there even a metric that would let us compare apples to apples and oranges to oranges here?

Back in my PokerStars days, we built a cool C++ framework that made it agnostic for developers whether their tests were run locally in one process, locally in Docker, or spread across several machines.

The goal was to enable the user to focus on the test scenarios while the framework ensured the execution by running the tests in various ways. Granted, we didn’t go all-in, but it still helped us in certain situations — particularly when dealing with nontrivial distributed consensus business logic, protocol-level intricacies, and especially at the intersection of the two.

Now that I’m working with Rust, this past weekend I decided to experiment with testcontainers. It offers similar functionality and has effectively become the de facto standard for running Docker-powered tests within Rust.

My goal was to have the test binary spawn one or more containers that implement the business logic — so that the integration test code could communicate with these containers, and the containers could interact with each other. A typical test setup might include Redis, Postgres, and one or more user services.

The user services are built as libraries, so starting them as standalone binaries requires only a one-liner main() function.

Back in my C++ days, I’d use macros and type lists, so that the running test binary could locate its own path from argv[0], wrap this binary in a thin container, and start it up.

I almost did this with testcontainers in Rust. Almost. I found the binary path, mounted the correct directory, ensured it was executable, and avoided any manual Docker or Cargo build steps inside or outside the container.

But no luck.

Then it hit me, about 1.5 hours later: it’s not about the paths, permissions, or the scratch vs. Alpine vs. Debian/Ubuntu issue.

The problem is that my host machine is a Mac. Despite sharing the same CPU family, a Mac binary won’t natively run when executed from within a Linux container. Classic mistake!

So, back to square one. I’ll need to rebuild the test binaries, which might actually work out better in the long run. On the bright side, I know how to do incremental builds by mounting the relevant directory and .gitignore-ing it.

Off we go again. Automated testing FTW!

Worthy of writing this down.

My understanding of the job market in tech can be well approximated with a simple heuristic.

There is a talent arms race going on. On one side, we have hype-seeking VCs that are selling the idea that AI will change everything dramatically, and very soon. On the other hand, we have conservative companies that are perfectly happy paying a corporate subscription for "yet another developer-performance-increasing IDE" and do not see how LLMs helping with coding constitutes a major boost in productivity.

It's the same story all over again.

Rationally, being conservative pays off. There are plenty of stories that AI assistance does not make better coders, and that relying on AI agents too much, in fact, slows down development, not accelerates it. There are real companies that conducted layoffs based on their projections of AI "taking over," and are now quietly hiring back the same people for the same positions.
Hype-creators, though, will sell the same story as all the last times. Yes, extrapolation does not show that game-changing AI is around the corner. But extrapolation should not apply if we're at the early stage of the hockey stick movement.

So it's the classic one again: the game of FOMO vs. FOLLI.
When Fear of Missing Out is high, people will invest in the craziest things ever — things no sane person would take seriously without the hype. When Fear of Looking Like an Idiot is high, no investor would lead the round with you, but they'd gladly join if some big name is already in play.

Right now, we're at the FOLLI moment when it comes to resuming tech hiring.

There is also the "first mover's disadvantage" at play.

On one hand, the industry will do well if we collectively agree there's no tangible game-changing value that AI can bring for the next ~5 years, and just begin hiring and doing business as usual.

On the other hand, the hype is real, and many — if not most — people would (unrealistically!) give it at least a 1% chance that things will change dramatically within the next several months, not years.

So, no company wants to be the one everybody will be pointing fingers at if they resume hiring now, only to soon learn how much of a "loser move" it was.

My prediction is that, slowly but surely, the industry will resume. There's just too much money to be made, and all tech companies, big and small, still have a large premium per engineer.

Besides, with return-to-office accelerated by AI-powered interview cheating, I sincerely believe it's a no-brainer: if a local candidate is willing to show up in the office and passes the interview, there's just no reason not to hire them. Especially given that the market is low and engineers do not expect comp figures like those from 2019/2020.

I'm afraid to be wrong, but all signs are, in my humble opinion, pointing at the industry resuming its "business as usual" sometime soon. Until the next organic economic cycle hits. They are some 10..12 years long these days.

Published my thoughts on the very idea of durability scaling far beyond the "eleven nines" guarantee people expect these days: https://dimakorolev.substack.com/p/durability-of-distributed-systems

The other day I was reading about democracy, and one idea stuck with me.

What if, instead of getting a signal from a popular vote, a country ran a lottery — randomly selecting a handful of "governors" from the population — and then, after several months of well-compensated, rigorous education, those who passed a final exam would take up actual governing responsibilities?

Sure, it’s not a new idea. It’s been critiqued heavily. It definitely wouldn’t work in any modern country with millions of citizens and complex international relationships to nurture. But it’s a fascinating thought experiment.

My immediate next thought was: what if a company, not a country, could be run this way?

Well, no. That'd be even worse. Because with a country, there’s at least some base-level assumption of loyalty among its citizens. In other words, if a hostile actor wanted to bribe (okay, lobby) enough lottery-selected governors to shift decisions in their favor, the cost would be prohibitively high — most of those people would strongly identify with the nation they’re governing.

But with a company? Not so much. For most employees — and even many shareholders — companies are fungible. So if someone gets to influence a key decision in a way that harms the company and benefits a competitor, we can bet the competitor will find a way to exploit that.

Which means these "short-term governors" in a corporate setting would need to be compensated very well — with rewards tied directly to long-term outcomes. They’d need to earn a lot, but only if the company thrives after N years. And, ideally, they should lose something if it doesn’t.

And that reveals a beautiful structure — both game-theoretically and morally.

First, this is why founders run companies: they’re the only ones with more or less well-aligned incentives with respect to long-term outcomes. Second, it’s clear that anyone working alongside founders on big decisions needs real skin in the game — past and future (hence why it’s basically impossible to be responsible for major outcomes and not be paid well). Third, plot twist, this is almost exactly what proof-of-stake manages to codify and monetize.

One interesting afterthought: if a company could be run this way, with random lottery selection, the candidates should probably score highest on some kind of "loyalty test."

Which is where my inner Socrates immediately pushed back. Why rely on loyalty (hello, Jonathan Haidt and The Righteous Mind) when well-crafted incentives can do the job? And, surprise: they do.

I wouldn’t claim that modern multinational corporate incentives are making the world a better place — or making workers and the public better off.

But I would say that the system of incentives we have today works extremely well at: a) sustaining itself, b) maximizing shareholder value, and c) predicting the behavior of the broader world.

The biggest shift in my own corporate thinking over the past decade was realizing how few layers of hierarchy you need to climb before it becomes completely unclear whose incentives are aligned with what.

Being invited into the Big Rooms at first gave me the feeling I am in the Memento movie — staring at conflicting signals, knowing some must be false, but realizing the situation was closer to a zero-sum Werewolves game than any kind of value-creating collaboration.

Myself, I’ve learned to navigate that game a bit, and even enjoy it at times. There’s a deeper link here to my thoughts on the role of the jester joined with the éminence grise, and the unavoidable (and perhaps morally justifiable) Machiavellian nature of inner-circle dynamics of the higher-ups.

But that’s a story for another post.

Good news: Meld works on a Mac now.

Bad news: How can I sleep now knowing something is messing with my /dev/null?

Here was meant to be a short and sharp post about how awesome Rust macros are: syntax-aware and general-purpose powerful.

Not saying they are perfect, but as someone who used metaprogramming and macros in C++ extensively, I have to say Rust has them designed really well if you want the power of Haskell plus the flexibility of, well, C++ with AST-traversing compile-time logic. With clean error messages too.

Except ... I could not find a way to apply something like #[ntest::timeout(300000)] to an arbitrary function.

To a #[test] yes. But why not just make it trivial to annotate any function with a timeout, so that it would return a sum type of some InTime(R) or Timeout?

Well, as I said, macros in Rust are great. And Rust has a lot of useful code coming with Cargo. But not everything we need is there. Sigh.

PS: My use case was actually the opposite! I have a test that does have a timeout, but the part that I do not control is something I'd love to have excluded from the time-kept part — specifically, the docker pull part from testcontainers, which times out my very reasoable tests when run on Github. Alas, that's probably too much to ask.

But I may well take the standard route of just instrumenting the very test code with timeout logic via a trivial assert! on tokio::timeout with .await. Rust is both strongly typed and clean enough to read, and the idea to not "pollute" the very test logic with the timeout in favor of a function-level annotation was too good to be true anyway.

Before I complain again about how slowly Web3 is taking over the world, let me ask the lazy web in here first.

Do we have a “bring your own stablecoin wallet” banking service available in any first-world country yet?

The idea is simple: the user holds custody of a wallet — multisig, hardware, whatever they prefer.

In addition to using their Web3 wallet app, they link this account to a Web3 Bank — an entity with a full banking license — which lets them:

∙ Send and receive transfers to/from non-Web3 entities,
∙ Perform exchanges and trading,
∙ Open leases and credit lines under well-defined contracts.

Crucially, the user can always take their funds elsewhere, or bank with multiple Web3 Banks simultaneously. The wallet remains the source-of-truth for funds and transaction history. If anything changes, the Bank App simply reflects the latest state.

Every operation still requires a signature from the user's wallet — self-custody means the Bank has no authorization over the account.

This model also eliminates overdraft fees — a blockchain wallet can’t be overdrawn.

Of course, the Web3 Bank could still offer non-custodial accounts. For example, I could open N accounts for N auto-pays (Internet, utilities, etc.). In these cases, the Bank defines the terms — perhaps allowing small overdrafts. I'd love to see something like: “You can overdraft up to $100 for free if repaid in 3 business days; after that, fees and interest apply.”

Naturally, this should be fully tax-transparent. In the US, say I receive an ACH paycheck into this bank — anything above $1K could auto-transfer into my USD stablecoin account.

All stablecoin accounts should be included in a downloadable annual tax report. Withdrawals from the wallet outside the Bank are treated like cash. Deposits must be marked, so the IRS can confirm income has been taxed.

Does something like this exist — even in a basic form?

It’d be embarrassing if I kept ranting about the lack of progress while Block, Binance, or Coinbase quietly shipped exactly this.

The MVP for me to start using it:

⒈ Receive my paycheck in stablecoins to a self-custody wallet,
⒉ Pay bills via ACH from that wallet,
⒊ Invest in Web3 assets, with a downloadable, IRS-friendly ledger.

And yes — opening an account should be trivial, ideally online.

There are remote KYC notary services in the US. I’d happily call in, pledge to transfer a small lump sum from my legacy bank, even share the account details over the call to fund the initial deposit. The Web3 Bank sets everything up and initiates, say, a $1,000 transfer.

As soon as I see $1,000 leave my old account, I know the new one is live — and I link my personal, just-created, stablecoin wallet to it.

Ah, and this Bank's ATMs should be directly connected to the tied stablecoin accounts — as long as the user still authorizes every cash withdrawal transaction. Deposits are, obviously, free.

I'd happily pay $50/month to try this out.

Perhaps Block or Binance or Coinbase already offer something like this in the US?

Or perhaps there are banks outside the US that can do the job — I'd happily try Dubai or Bahamas or Argentina, as long as the created account can accept US paychecks.

As a civilization — are we there yet?

Heard an interesting theory which I can’t quickly prove or disprove.

Apparently there exists no publicly available Rust compiler binary that can be complied without a previous version of a Rust compiler.

One could say: sure! Compile the previous previous previous … version from C/C++, then take it from there up the tree.

Alas, this is not the case. As in: several people tried, and they abandoned the idea — it proved to be more difficult than it seems.

So, for more reasons to put one’s the tin foil hat on: We truly cannot know with certainty that the very production-grade Rust compiler is not compromised.

There simply exists no trivially reproducible build from fully auditable source code only.

Full disclosures, to outline my position:

1) This is a problem well worth fixing.
2) Rust is a great and safe language.
3) Supply chain attacks are real and scary.

~ ~ ~

Although on the latter front I am to this day confused why Rust still uses OS-provided crypto libraries.

The way I see it there exists no sane world in which the community would not want to have a Rust-first dependency-free SSH client/server.

(It may well use just one cipher and not be SSH-compliant — as long as it’s secure there’s no need to support the bloated design-by-committee standard.)

And there exists no sane world in which basic SSL/PGP operations are not contained 100% in fully open source peer-reviewed and ledger-Merkle-proof-stamped history of code that anyone can audit in full. In Rust. With no unsafe blocks.

As in, the entire chain of commits should be cut in stone for eternity, with proofs published on every major blockchain regularly. And the code that implements the above may well use some of the earliest Rust dialects for extra safety. After which it’s a moral duty of every security-related Rust crate to move to using this Rust-native encryption/decryption/signing code.

But alas, we’re not there yet. Even for operations as self-contained as basic Web3 protocols, such as WalletConnect.

I hope it’s just a matter of time though. Let’s not attribute to malice what can be adequately explained by different priorities of a still-young ecosystem.