DEV Community: Venkat

Why Rust Feels Hard (And Why That's Actually the Point)

Venkat — Sat, 09 May 2026 18:05:09 +0000

Part 1 of the "Rust Without the Headache" series

Let me tell you about the bug that broke me.

I was working on a Python service—nothing crazy. Just a background worker that processed incoming data and wrote results to a database. It ran fine for months. Then one day in production, around 2 AM, it started corrupting data. Silently. No exception, no stack trace. Just wrong numbers in the database.

It took me three days to find the problem. A dictionary was getting mutated by one part of the code while another part was reading from it. Completely valid Python. The interpreter was totally fine with it. My users were not.

I'd seen similar things happen in .NET too—race conditions, null reference exceptions that only showed up under load, or async code that deadlocked because someone forgot a ConfigureAwait(false). The runtime would just shrug and carry on. Meanwhile, I'd be debugging for days.

That's when I started looking at Rust.

My First Impression (and probably yours too)

I opened the Rust book, got about two chapters in, and immediately felt like I was being lectured by a very strict professor who kept saying "no" without fully explaining why.

"No, you can't use that variable anymore."
"No, you can't mutate this here."
"No, no, no."

I remember thinking: Why is this so hard? Python and .NET don't make me jump through these hoops. Why can't Rust just trust me?

So I closed the book and went back to what I knew. Classic move, right?

The Second Attempt (that actually stuck)

A few months later, a coworker showed me something that changed my perspective. He was building a small CLI tool in Rust—nothing fancy, just something that read a config file and made an HTTP request. What struck me wasn't the code. It was how calm he was about deploying it.

"I just don't worry about it," he said. "If it compiles, it works."

I thought he was exaggerating. He wasn't.

That's when I realized something: The borrow checker wasn't being mean to me. It was being honest with me. All those silent bugs I'd chased in Python and .NET—the ones that only showed up at 2 AM under weird conditions—Rust was forcing me to think about them up front.

The Mindset Shift

Here's what I started to understand:

In Python, you write code and hope it works. You test it. You run it. You deploy it. And maybe weeks later, it blows up in a way your tests never caught. Then you debug. Then you fix. Then you pray.

In .NET, it's better—the compiler catches more, and the type system helps. But you still get null references. You still get race conditions. You still get ObjectDisposedException from async code that ran in the wrong order. The runtime is friendly, but friendly doesn't mean safe.

In Rust, the compiler is like that strict professor who won't let you hand in an assignment until every single problem is fixed. It feels annoying in the moment. But here's the thing—once you pass, you pass. No late-night surprises. No silent corruption.

What This Series Will Do For You

Look, I'm not going to pretend I'm a Rust expert or that I never fight with the compiler anymore. I do. But I've learned to stop fighting against it and start working with it. And that's what this series is about.

We're going to take the painful parts of Rust—borrowing, lifetimes, Result vs panic, Send and Sync—and I'm going to explain them the way I wish someone had explained them to me. No academic papers. No cryptic compiler error printouts without context. Just real examples from someone who came from Python and .NET and needed Rust to make sense.

Here's the full roadmap for all 10 parts:

Part 1: Why Rust Feels Hard (And Why That's Actually the Point) — You are here. The bug, the frustration, and why sticking with it is worth it.

Part 2: Ownership — the valet key, the library book, and the pen — I'll explain ownership and borrowing using three simple analogies. By the end, you'll know why Rust won't let you use something after it's been taken away.

Part 3: Lifetimes — the rental agreement that saved my data — This is the part everyone's scared of. But once you think of lifetimes like a rental agreement (you can't stay after the lease ends), it actually makes sense.

Part 4: Smart pointers — Box, Rc, and why the heap isn't scary — Coming from .NET or Python, you've used the heap forever without thinking about it. I'll show you when you need Box, when to use Rc, and why reference counting isn't cheating.

*Part 5: Fearless concurrency — Arc, Mutex, and the multi-lane highway *— Remember that dictionary bug that broke me? Rust makes that impossible to compile. We'll use highway analogies to understand threads, sharing, and locking without losing your mind.

Part 6: Types and error handling — goodbye null, hello Option — You'll never have to check for null again. I'll show you how Option and Result replace all that defensive garbage, and why ? is better than try-catch.

Part 7: Traits and generics — polymorphism without inheritance — If you've used interfaces in C# or duck typing in Python, traits will feel familiar. But different. I'll show you the "ah-ha" moment.

Part 8: Unsafe — the construction zone and when to enter it — Yes, you can do raw pointer stuff. No, you probably shouldn't. But when you need to, here's how without setting your foot on fire.

Part 9: One real Axum app — every concept in context — We'll build a small web server with Axum. You'll see ownership, lifetimes, error handling, and concurrency all working together in a real project.

Part 10: Where to go from here — building real projects and staying out of tutorial hell — Next steps. The best crates. How to keep learning without getting stuck. And permission to still be frustrated sometimes.

Where You'll Still Get Frustrated (Being Honest)

I'm not selling magic. Rust still has rough edges. Compile times can be slow. Some error messages are still cryptic (though way better than they used to be). And sometimes you'll write something that feels obviously correct and the compiler just says "nope."

You'll get frustrated. You'll want to quit. You might go back to Python or C# for a weekend just to feel productive again.

That's fine. I did too.

But here's what I can promise: If you stick with it through this series, you'll start to feel something unexpected. Not mastery—that takes time. But trust. You'll start to trust that when your Rust code compiles, it's actually going to do what you meant. Not what you accidentally typed.

And coming from languages like Python and .NET, where the runtime happily says "sure, let's try that" right before falling on its face... that feeling is worth the headache.

Next Up

In Part 2, we're going to write some real Rust code. And yes, we'll make the borrow checker angry. On purpose. So you can see what it's actually trying to tell you.

See you there.

Building a Zero-Knowledge Dating Platform for HIV-Positive Communities

Venkat — Mon, 02 Mar 2026 19:31:02 +0000

Erlang, Vue, and client-side encryption — by design, not as an afterthought.

A close friend of mine works as an AIDS counsellor.

One day she told me something I couldn't shake:

"My clients want companionship. They want marriage. They want normalcy.
But they're terrified of being exposed."

She'd seen it over and over. People who were HIV-positive, stable on treatment, undetectable — but isolated. Dating apps didn't feel safe. Disclosure was complicated. A screenshot could cost someone their job. A database breach could shatter a life.

Then she asked me:

"Can you build something for them? But it has to be completely private."

Not "secure enough." Not "we encrypt passwords."

Completely private.

That's where this started — and where HIVPositiveMatches.com came from.

Why Traditional Dating Apps Are Dangerous for This Community

Most dating platforms are built on a silent assumption: the server is a trusted party.

The server stores your profile
The server reads your profile
The server decides who sees your profile
The server can be breached, subpoenaed, or misused

For most people, that's an acceptable tradeoff. For HIV-positive communities, it isn't. Disclosure can affect employment, housing, family relationships, and mental health. The fear isn't paranoia — it's grounded in real consequences that real people have faced.

Privacy here isn't a feature. It's psychological safety.

So I flipped the premise entirely:

What if the server never sees plaintext user data at all?
Not at rest. Not in logs. Not in admin dashboards. Not even temporarily.

That question led to a zero-knowledge architecture.

The Core Principle: The Server as a Blind Courier

Instead of a traditional CRUD backend that owns your data, the server becomes:

A cryptographic relay
A coordination layer
A match facilitator
Not a data owner

Everything meaningful happens on the client. The server passes sealed envelopes. It never opens them.

The Stack

Layer	Technology
Backend	Erlang + Yaws
Frontend	Vue 3 + Naive UI
Auth	Google OAuth
Cryptography	TweetNaCl (client-side)
Key derivation	Handle + PIN (deterministic)
Encryption	Hybrid symmetric + asymmetric

Each choice was made with one question in mind: does this require the server to see sensitive data? If yes, we found another way.

Step 1: Authentication vs. Identity

Google OAuth handles login and identity verification — nothing more.

Once authenticated:

The email is encrypted client-side
Only a hash of the encrypted email is stored for lookup
The server sees: OAuth provider, user role, membership tier

That's it. No name. No email in plaintext. No profile data of any kind.

If the database leaks tomorrow, the attacker gets a list of meaningless hashes.

Step 2: Profiles Are Encrypted Before They Leave the Browser

When a user builds their profile, this is what happens in the browser:

A symmetric AES key is generated locally
The entire profile is encrypted with that key
Only the encrypted blob — and the wrapped key — are sent to the server

What the database actually stores:

Encrypted profile vault
Encrypted card preview
Wrapped encryption keys
Public keys
Search-safe hashed fields

The server never holds readable health data, lifestyle information, or personal details. Not because we deleted it — because we never had it.

Step 3: No Passwords — Deterministic Key Derivation

Traditional passwords are a liability. Reset flows, storage, hashing — every step is a potential leak.

Instead, users choose a handle and a PIN. These become salt inputs for key derivation, entirely in the browser. The PIN is never transmitted. Never stored. The server cannot brute-force vaults even under a court order.

The result: a login flow that feels simple, backed by cryptographic guarantees that don't depend on us doing the right thing.

Step 4: Public/Private Keys for Matching

Each user generates a key pair in the browser:

Public key → sent to the server
Private key → encrypted locally using the PIN, never leaves the device in plaintext

When two users match, vault keys are exchanged through a controlled wrapping flow:

User A's vault key is wrapped with their public key
The server re-wraps it with User B's public key
User B's frontend unwraps it locally

Think of it like a courier passing a sealed envelope to a new recipient — resealing it without ever reading what's inside.

At no point does the server retain readable profile data from either user.

Step 5: Erlang for Reliability at Scale

Erlang wasn't chosen for novelty. It was chosen because this system demands:

Massive concurrency — many users, many cryptographic operations
Fault tolerance — processes fail safely and independently
Predictable performance — no surprises under load

Yaws serves dynamic HTML with embedded session markers that Vue hydrates on the frontend. The result is a modern UI backed by a backend that is minimal, resilient, and has been battle-tested for decades in telecoms.

Step 6: AI Matching Without Exposing Interests

Compatibility can't be computed server-side if the server can't read profiles. So we moved it to the browser.

Each client:

Generates embeddings locally from profile content
Normalizes and binarizes them
Sends only non-reversible binary hashes to the server

The server compares hashes using Hamming distance. It never sees raw interests, lifestyle traits, or "about me" text. AI-powered matching — without the AI ever knowing who it's matching.

The next article in this series goes deep on how that works.

Threat Model: What Happens When Everything Goes Wrong?

Scenario	What the attacker gets
Database leak	Encrypted blobs. Unreadable.
Rogue admin	Nothing. No plaintext to access.
Server compromise	No sensitive data to steal.
Network interception	TLS + client-side encryption.
Legal pressure / subpoena	Server literally cannot decrypt anything.

This isn't security through obscurity. The server cannot betray users — not because we promise it won't, but because it architecturally cannot.

That distinction matters. Promises can be broken. Math can't.

What Building This Taught Me

Most systems are designed around: "How do we store and use data?"

This one is built around: "How do we avoid ever possessing data?"

That shift changes everything — UX, backend design, matching logic, error handling, recovery flows. It forces a kind of humility: assume the server is a liability, not a guardian. Design accordingly.

It also changes what it means to be accountable. I cannot read my users' profiles. That's not a limitation — it's the point.

What's Coming Next

This post is the foundation. The series continues with:

Part 2: Zero-knowledge filtering using 32-bit bitmasks (next)
Part 3: AI embeddings + Hamming distance matching
Part 4: Key-wrapping flows in practice
Part 5: Account recovery without exposing secrets
Part 6: UX patterns for client-side encryption

This project started because a counsellor wanted her clients to feel safe finding love.

It became one of the most technically challenging — and meaningful — systems I've ever built.

For sensitive communities, privacy-first design isn't optional. It's the only ethical choice.

Rediscovering C++: Building a High-Performance Blog Engine in 2026

Venkat — Wed, 25 Feb 2026 05:45:47 +0000

I've been a programmer for… well, a long time. My early days were spent in the computer lab, practicing C and C++ on floppy disks — yes, actual floppy disks. After finishing my engineering degree, I drifted into Oracle ERP and database-heavy business applications. The problem? I loved coding, but my day-to-day was mostly SQL scripts and reports. Hands-on software engineering felt like a distant memory.

The Journey Back to Programming

Fast forward to the pandemic era: remote work opened new doors. I finally had time to dive back into programming. I explored Erlang and Elixir, played around with eex, leex, and heex, and even worked on a small Elixir project. But frameworks were moving fast — LiveView, EEx → LEEx changes, constant churn.

I experimented with a few other stacks. I tried the static HTML + dynamic marker approach in Rust (Actix) — caching the shell and letting the frontend hydrate the SPA worked beautifully. I also experimented with Erlang’s Yaws, using persistent_term for caching, which was actually where the idea first clicked for me.

That’s when I thought: “Huh… if this can be done there, why not in C++?” Go Fiber was fun for prototypes, and Rust (Axum, Actix) was powerful, but I wanted to explore modern C++. One weekend, I stumbled upon an article about C++’s new features — smart pointers, co_await, coroutines — and it hit me. C++ had evolved tremendously in the past 20+ years. Could I build something high-performance, scalable, and modern in C++?

The answer was yes, and that’s how my journey with Drogon C++ and Vue Naive UI began.

Architecture Overview

The architecture grew from a simple idea: serve a fast, server-rendered HTML shell, then hand off interactivity to the SPA. Here's how it works in practice:

Template Caching System

I built a TemplateCache singleton in C++ that loads the static HTML shell once, splits it at a dynamic marker (), and caches it in memory. This makes per-request rendering nearly free:

auto [before, after] = TemplateCache::instance().get();
std::string body = before;
body += "<div id=\"app\" data-initial-route=\"" + path + "\"></div>";
body += after;

Key Components

Server-side control – The backend holds the routes, knows the state of the application, and serves the initial page. No CORS issues, no REST API boilerplate just to get started.

SPA hydration – The <div id="app"> marker hands over the page to a frontend framework (Vue in my case, but it could be React, Svelte, or SolidJS). The frontend hydrates the page and takes over reactivity, giving a full SPA experience.

Async-ready backend – I designed the architecture so async DB queries can be added cleanly using C++20 coroutines (co_await). This makes it easy to fetch dynamic content without blocking threads.

Scaling & deployment – Containers and Traefik handle load balancing. Multiple replicas of the same service can run, and because the static shell is cached, initial page rendering is consistent and fast.

Flexibility – This setup decouples the backend and frontend enough that I can experiment with different frontend frameworks without touching the core C++ server. The backend just serves the shell + dynamic markers.

The Technical Stack

Backend: Modern C++ with Drogon

Drogon Framework: High-performance HTTP application framework
C++20 Features: Coroutines, smart pointers, RAII
Template System: Custom caching layer for optimal performance
Container Ready: Docker + Traefik for production deployment
Frontend: Vue.js Ecosystem

Vue 3: Reactive frontend framework
Naive UI: Clean, modern component library
SPA Architecture: Full client-side routing and state management
Framework Agnostic: Easy to swap for React, Svelte, or others

Implementation Deep Dive

The Template Cache Pattern
The core innovation is the template caching system. Instead of rendering HTML on every request, we:

Load the base HTML template once at startup
Split it at the app marker ()
Cache both parts in memory
Assemble responses by injecting dynamic content between cached parts

This approach gives us:

Near-zero template rendering overhead
Consistent response times
Memory-efficient caching
Easy dynamic content injection

Async Database Integration

With C++20 coroutines, adding async database operations becomes elegant:

// Hypothetical async DB query
co_await auto posts = db.query("SELECT * FROM posts WHERE active = 1");
std::string dynamicContent = renderPosts(posts);

The coroutine support means we can handle thousands of concurrent requests without blocking threads on I/O operations.

Frontend Hydration Strategy

The frontend receives a server-rendered shell with routing information:

html
<div id="app" data-initial-route="/blog/my-post"></div>

Vue then hydrates this element and takes over:

const app = createApp(App);
const initialRoute = document.getElementById('app').dataset.initialRoute;
app.mount('#app');
router.push(initialRoute);

Why This Approach Works

I want to be clear: this isn't about saying other stacks are bad. Laravel, Django, Elixir, Go, Rust — all great choices.

For me, it was about experimenting with C++ and seeing how far I could take it. With modern C++ features — smart pointers, RAII, co_await — building this architecture was surprisingly straightforward.

The Benefits I Discovered
Performance by Design – Compiled C++ backend with memory-efficient caching delivers consistently fast responses.

Developer Experience – Modern C++ feels nothing like the C++ of the '90s. Smart pointers eliminate most memory management headaches, and coroutines make async code readable.

Deployment Simplicity – Single binary deployment with no runtime dependencies makes containerization trivial.

Frontend Freedom – The backend serves a generic HTML shell, so I can experiment with any frontend framework without backend changes.

Scaling Characteristics – Multiple stateless instances behind a load balancer, with shared caching strategies when needed.

Real-World Performance
In early testing, the template caching approach delivers:

Sub-millisecond template rendering for cached shells
Minimal memory footprint compared to interpreted languages
Excellent CPU utilization under load
Fast cold starts in containerized environments

The combination of compiled performance and modern async patterns creates a compelling foundation for high-traffic applications.

Lessons Learned

What Worked Really Well

No CORS drama – Because the server holds the routes and serves the initial page, I don't have to fight cross-origin requests for SPA hydration.

Server maintains control – The backend is aware of the application state, initial routes, and template shell.

SPA flexibility – I can swap Vue for React, Svelte, or SolidJS without touching backend logic.

Performance matters – Cached static shell + dynamic marker approach ensures a fast first load, while async DB queries (when added) can handle personalized content efficiently.

Surprising Discoveries

Modern C++ is web-ready – Smart pointers, thread safety, and coroutines make high-performance, maintainable backend code feasible without the pain of manual memory management.

Drogon is production-ready – The framework handles HTTP/2, WebSockets, middleware, and all the modern web server features you'd expect.

Development velocity – Once the architecture was in place, adding new routes and frontend components became surprisingly fast.

Looking Forward

This experiment has rekindled my appreciation for C++ in the modern web development landscape. While it's certainly not the right choice for every project, there are compelling use cases:

High-performance APIs that need to handle thousands of requests per second
Real-time applications where latency matters
Resource-constrained environments where memory and CPU efficiency are critical
Long-running services where the compile-time investment pays dividends

The combination of C++20 features, mature frameworks like Drogon, and modern deployment practices makes C++ a viable option for web applications in 2026.

The finished product

https://thedeveloper.tech

Try It Yourself

If you're curious about modern C++ for web development:

Start with Drogon – The documentation is excellent and the framework handles the HTTP complexities
Experiment with coroutines – C++20's co_await makes async code much more manageable
Keep it simple – Start with basic request/response patterns before adding complex features
Leverage existing tools – Docker, monitoring, and deployment practices work just as well with C++

The web development landscape is vast, and there's room for many approaches. Sometimes, revisiting an old friend with fresh eyes can lead to surprisingly modern solutions.

What's your experience with C++ in modern development? Have you tried any compiled languages for web backends recently? I'd love to hear about your experiments in the comments!