DEV Community: Khaja Hussain

What Switching From C# to Rust Actually Taught Me

Khaja Hussain — Sat, 11 Jul 2026 09:01:28 +0000

I've spent most of my career writing C#. ASP.NET Core, EF Core, the whole ecosystem — it's productive, well-documented, and I've never had a real complaint about it. This isn't a "C# vs Rust, one wins" post. C# remains one of my favorite languages to build with. This is just about why I got curious about Rust, and what I noticed when I actually rewrote something instead of just reading takes about it.

Why I got curious in the first place

Three things kept pulling my attention:

No GC pauses. C#'s garbage collector is well-engineered, but it still pauses your program at moments it chooses, not you. For latency-sensitive work, that unpredictability is worth understanding better.
Compile-time memory safety. Rust catches null references and data races at compile time instead of at runtime. A different tradeoff, not a "fix" for something broken in C#.
Ownership. People kept describing it as a big deal. I wanted to actually understand why instead of nodding along.

The first two weeks were genuinely hard — I fought the borrow checker constantly, rewriting the same function three times before it compiled. It clicked faster than I expected though, and it left me with a better mental model for shared state in general, one that's helped me even back in C#. I ended up collecting everything I wish someone had told me going in over at Rust Tutorial — more on that at the end, if ownership is the part that's holding you back.

The project: a real-time order tracker

To compare the two properly, I built a small dummy project — a real-time order tracking service. Incoming order events update in-memory state, and connected dashboards get live updates over a WebSocket. It's a common shape: inventory systems, delivery tracking, live ops dashboards.

C# version: ASP.NET Core minimal API, SignalR for the WebSocket push, a ConcurrentDictionary for state.
Rust version: axum for HTTP/WebSockets, tokio as the runtime, state behind an Arc<Mutex<HashMap>>.

Nothing production-grade — just enough of a real workload to notice actual differences instead of comparing "Hello World" benchmarks, which don't tell you much.

What felt different, not better or worse

The frameworks themselves were both pleasant to use. What changed was how explicit I had to be:

Shared state. C#'s ConcurrentDictionary just worked — I trusted the library and moved on. Rust made me spell out the Arc<Mutex<...>> at every point it was touched. More typing, but I came away understanding my own concurrency model better.
Errors. A malformed event in the C# version could throw from a background task and, if I'd missed a try/catch, fail quietly. Rust's Result made every fallible step something I had to explicitly acknowledge.
Nulls. "Order not found yet" was a null check I could forget in C#. In Rust it's Option, and the compiler won't let it slide.

None of this means Rust is "better" — it just made assumptions in my C# code more visible, which was uncomfortable at first and useful by the end.

Quick, informal numbers (not a real benchmark)

Full transparency: this was a five-minute wrk run on my own laptop, not a controlled test environment. Don't read too much into the exact figures — but the general pattern lined up with what's commonly reported elsewhere too.

	C# (ASP.NET Core)	Rust (axum)
Idle memory footprint	~110 MB	~9 MB
Cold start time	~1.2s	~40ms
Requests/sec (simple load test)	~9,000	~34,000
p99 latency	~42ms	~6ms
Deploy artifact	App + .NET runtime	Single ~6MB binary

The gap narrowed once .NET's JIT fully warmed up under sustained load — it's genuinely competitive once hot. Rust's edge was most consistent in memory footprint and tail latency, which tracks: no GC means no surprise pause landing in your worst-case requests.

Where Rust felt rougher

To keep this balanced:

Compile times grew noticeably slower than C#'s as the project did.
Ecosystem gaps — some things .NET gives you out of the box (certain auth patterns, mature ORMs) took more assembly in Rust's crates.
The learning curve is real. Not the right moment to introduce it if your team is shipping next week.

When I'd reach for which

Situation	I'd reach for
Typical CRUD app / internal business tool	C# — EF Core and the .NET ecosystem get you there faster
Team is already deep in .NET, tight deadline	C# — the right call, no reason to add a learning curve under pressure
Real-time systems where latency predictability matters	Rust — no GC pause means a flatter tail latency
Memory-constrained environments (containers, edge, embedded)	Rust — the footprint difference is real and adds up at scale
Need a small, dependency-free deployable binary	Rust — one binary, nothing else to ship
Rich enterprise integrations (auth providers, ORMs, admin tooling)	C# — still the deeper batteries-included ecosystem
Want to learn something that reshapes how you think about memory and concurrency	Rust — worth the rough two weeks even if you never ship it

So, am I dropping C#?

Not even close. For CRUD apps and business logic, C# is still one of the most productive languages I know, and that hasn't changed. What changed is that I now have another tool for the specific cases where predictable latency and a small footprint actually matter — and Rust earned that spot honestly.

If you're curious about Rust coming from C

If you want the official deep reference, The Rust Book is where most of the Rust community points beginners first. Alongside that, I also put together a helpful website while working through ownership and borrowing myself — plain explanations, runnable examples, nothing assumed: Rust Tutorial.

If you're a C#/.NET dev thinking about giving Rust a try, either one is a solid place to start.

Have you made a similar jump — from C#, Java, Go, or anywhere else? Curious what surprised you.

I Compared TOON vs Minified JSON Using OpenAI’s Tokenizer

Khaja Hussain — Tue, 12 May 2026 00:29:29 +0000

Recently I noticed a lot of developers talking about TOON:

TOON GitHub repository

The idea behind TOON is interesting. Instead of sending traditional JSON, TOON tries to reduce token usage and make data more compact for LLMs.

Since token costs are becoming a real concern for AI products, I wanted to test it myself.

Not theoretically.
Not with benchmarks from slides.
Just a simple real-world comparison.

I used OpenAI’s tokenizer tool and compared:

TOON format
Minified JSON

For the conversion process, I used:

JSON to TOON Converter
JSON Parser
Compare Text

Minified JSON:

{"user":{"id":1001,"name":"Khaja","email":"khaja@example.com","roles":["admin","developer"],"settings":{"theme":"dark","notifications":true}}}

TOON version:

user:
id: 1001
name: Khaja
email: khaja@example.com
roles[2]: admin,developer
settings:
theme: dark
notifications: true
`

TOON Result: Tokens: 37
Minified JSON Result: Tokens: 38

That means TOON saved only 1 token in this example.

Honestly, that surprised me.

So… Is TOON Useful?

I think the answer is: yes, but with nuance.

TOON is not “bad.”
In fact, I actually like the direction.

It makes developers think seriously about:

token efficiency
AI-friendly data formats
prompt optimization
serialization overhead

Those are important conversations.

But after testing it, I’m not convinced that TOON alone will dramatically reduce costs for most companies.

In many cases:

removing whitespace already gives huge savings
gzip/brotli compression already works extremely well
AI models are already heavily trained on JSON structures

So the practical gains may be smaller than the hype suggests.

But Small Savings Can Still Matter at Scale

Here’s the interesting part.

Even tiny optimizations matter when companies process millions of requests.

Imagine:

10 million API calls
large AI prompts
multiple agents
long conversation histories

Saving even 1–2% tokens at scale could potentially save hundreds or thousands of dollars over time.

So I do understand why people are excited about TOON.

The Bigger Challenge: Ecosystem

Personally, I think TOON’s biggest challenge is not token count.

It’s ecosystem adoption.

JSON already has:

mature tooling
validators
parsers
database support
IDE integrations
API ecosystem dominance

Replacing that is extremely difficult.

In real production systems, compatibility usually matters more than tiny syntax improvements.

My Take

After testing both formats, my conclusion is:

TOON introduces interesting ideas
token savings appear modest in smaller examples
the ecosystem challenge is massive
but the conversation around AI-native serialization formats is valuable

I don’t think JSON is disappearing anytime soon.

But I do think experiments like TOON push the industry forward.

And honestly, that’s a good thing.

Would love to hear what other developers think or any suggestion what to compare next.

A free, high-performance backend for small projects — Cloudflare Workers in 10 minutes

Khaja Hussain — Sun, 03 May 2026 11:00:22 +0000

Every developer wants the same thing: a free way to run small backend tasks. A webhook for a side project. A contact form handler. An OG image generator. A small proxy to hide an API key. Things that handle a few hundred requests a week. They do not need a $20/month server, an Azure Function App you will forget about next month, or a new Lambda that takes an hour to set up.

I have had this problem for years. Most of my work is in .NET shops — AWS for production, Azure for clients on the Microsoft stack. Both are great for real workloads. Both feel like overkill when the actual task is "send me an email when a Stripe customer pays."

Last weekend I needed exactly that webhook. Spinning up a new Function App for one endpoint felt silly. Adding it to an existing production API would mix two unrelated things — the next person reading the code would wonder why a billing handler was sitting inside the customer-facing app. Every option I knew was way too much setup for one tiny task.

So I finally tried something I had been avoiding for three years: Cloudflare Workers. It solved the problem in ten minutes. Free, no credit card, deployed to 300+ data centres. Here is how it went, and why I should have tried it sooner.

Why I had been ignoring Cloudflare Workers

Three reasons:

No .NET story. I work in C#. Writing JavaScript at the edge felt like a whole new world just to deploy one small function.
The marketing made it look like big-company infra. Every Workers post I had read mentioned Durable Objects, R2, KV, Queues, AI bindings. It looked like a big platform you commit to, not a tool you grab for one task.
I thought the free tier was a trick. "100,000 requests per day" sounded like a number with hidden conditions and a credit-card requirement.

None of those were true.

The 10 minutes

Install Wrangler, the Cloudflare CLI:

npm install -g wrangler
wrangler login

The login opens a browser. Click approve and you are done. No credit card asked. I checked twice — I have been burned before.

Scaffold a project:

npm create cloudflare@latest stripe-webhook
cd stripe-webhook

Pick "Hello World" Worker, JavaScript, skip the deploy step. The generator puts everything in one folder. Open src/index.js and replace the default code with this:

export default {
  async fetch(request, env) {
    if (request.method !== 'POST') {
      return new Response('POST only', { status: 405 });
    }

    let event;
    try {
      event = await request.json();
    } catch {
      return new Response('Invalid JSON', { status: 400 });
    }

    if (event.type === 'checkout.session.completed') {
      const amount = event.data.object.amount_total / 100;
      const email = event.data.object.customer_email;

      await fetch('https://api.resend.com/emails', {
        method: 'POST',
        headers: {
          'Authorization': `Bearer ${env.RESEND_KEY}`,
          'Content-Type': 'application/json',
        },
        body: JSON.stringify({
          from: 'alerts@mydomain.com',
          to: 'me@mydomain.com',
          subject: `New payment: $${amount}`,
          text: `${email} just paid $${amount}.`,
        }),
      });
    }

    return new Response('ok', { status: 200 });
  },
};

Run it locally:

npm run dev
# Ready on http://localhost:8787

Send a fake Stripe payload with curl. Worked on the first try.

Deploy it:

npx wrangler deploy

Eight seconds later it printed a *.workers.dev URL. Total bundle size: 1.2 KB. I pointed Stripe's webhook config at that URL, sent a test event from the Stripe dashboard, and the email arrived in my inbox before the dashboard finished refreshing.

The part that surprised me

The free tier really is 100,000 requests a day. No credit card. The Worker runs in 300+ Cloudflare data centres at the same time. A Stripe webhook from San Francisco hits the San Jose data centre, my email goes out from Resend's nearest server, and the whole round trip takes under 200ms. No cold start. No Function App I have to remember to delete next month before it starts billing me.

If you store a webhook secret with wrangler secret put STRIPE_WEBHOOK_SECRET and verify the signature (you should — Stripe sends a Stripe-Signature header for this), the whole thing is still about 60 lines of code.

One gotcha worth knowing

If the request body is invalid JSON, request.json() throws a SyntaxError and Cloudflare returns a generic 500. That is bad for any user-facing endpoint, and it is worse for Stripe — Stripe retries on 5xx errors, so a broken parser quietly turns into duplicate retries while your dashboard looks fine. Wrap the parse in a try/catch and return a 400 with a clear message. Stripe webhook payloads are also big and hard to read; pretty-printing them with a JSON formatter and JSON viewer makes debugging much faster. I learned the try/catch lesson the hard way — one panicked late-night Stripe dashboard refresh.

What I would do differently next time

Use Workers first for any small task that needs an HTTP endpoint. That is a much bigger category than just "webhook" — link shorteners, OG image generators, form handlers, edge auth, JSON proxies, internal Slack bots. Trying it is one npm create command away.

I feel a bit silly for waiting three years. The mental model is one sentence: a Worker is a function that takes a Request and returns a Response. That is the whole platform. Everything else (KV, Durable Objects, AI bindings) is optional. If you want the full step-by-step instead of the highlights here, this Cloudflare Workers deploy guide covers the whole setup with a real validating endpoint, the free-tier limits in detail, and a few more gotchas to know before you ship.

If you have been avoiding Workers like I was, try it on the next small task you hit. Fifteen minutes will tell you if it fits how you think. For me, it did.

Understanding Protocol Buffers: A Fast Alternative to JSON

Khaja Hussain — Sun, 15 Dec 2024 20:36:23 +0000

In the world of data interchange, JSON (JavaScript Object Notation) has been a long-standing favourite. It’s simple, human-readable, and works seamlessly across platforms. For many use cases, JSON is “good enough.” But as systems scale, and the need for speed and efficiency increases, JSON’s text-based format can become a bottleneck.

That’s where Protocol Buffers (Protobuf) come in. Developed by Google, Protobuf is a powerful, compact, and lightning-fast data serialization format that has become a popular choice for modern applications.

Why Consider Protocol Buffers Over JSON?
Compactness: JSON’s text-based format can result in larger payloads. Protobuf, on the other hand, uses a binary format, which dramatically reduces the size of the data.

Speed: Protobuf’s binary format is faster to serialize (convert data to a transferable format) and deserialize (convert back to usable data).

Schema Evolution: Protobuf includes a schema that defines the structure of your data, making it easier to evolve your APIs without breaking backward compatibility.

Efficiency at Scale: For applications with high traffic or limited bandwidth (e.g., mobile apps, IoT devices), Protobuf’s efficiency can result in lower latency and better performance.

Protocol Buffers: A Smarter Way to Handle Data
In the world of data interchange, JSON (JavaScript Object Notation) has been a long-standing favorite. It’s simple, human-readable, and works seamlessly across platforms. For many use cases, JSON is “good enough.” But as systems scale, and the need for speed and efficiency increases, JSON’s text-based format can become a bottleneck.

Why Consider Protocol Buffers Over JSON?
Compactness: JSON’s text-based format can result in larger payloads. Protobuf, on the other hand, uses a binary format, which dramatically reduces the size of the data.

Speed: Protobuf’s binary format is faster to serialize (convert data to a transferable format) and deserialize (convert back to usable data).

Schema Evolution: Protobuf includes a schema that defines the structure of your data, making it easier to evolve your APIs without breaking backward compatibility.

Efficiency at Scale: For applications with high traffic or limited bandwidth (e.g., mobile apps, IoT devices), Protobuf’s efficiency can result in lower latency and better performance.

A Quick Comparison: JSON vs. Protobuf
Let’s take a simple example. Imagine you’re sending information about a user:

Using JSON:

{
  "id": 123,
  "name": "John Doe",
  "email": "john.doe@example.com"
}

This is straightforward and human-readable. But it’s also relatively large because of all the extra characters like {}, :, and the field names.

Using Protobuf:
First, you define a schema (usually in a .proto file):

message User {
  int32 id = 1;
  string name = 2;
  string email = 3;
}

When serialized to binary format, this same data is compacted into a tiny, efficient payload—unreadable to humans but incredibly fast for computers to process.

When to Stick with JSON
JSON is still a fantastic choice for many use cases:

If human-readability is a priority (e.g., logging or configuration files).
For simple, low-traffic systems where performance isn’t critical.

When to Use Protobuf
If your application needs to:

Handle large-scale data exchange (e.g., microservices, real-time APIs).
Operate under bandwidth constraints (e.g., mobile or IoT devices).
Ensure compatibility while evolving the API schema.

JSON is like the comfortable, everyday car you drive around town—reliable and easy to use. Protobuf, on the other hand, is a sleek sports car—designed for speed, efficiency, and high performance. While JSON is great for most day-to-day tasks, Protobuf shines when you need to go the extra mile.

So, whether you stick with JSON or make the leap to Protobuf depends on your needs. But if you’re building for the future and performance is key, Protobuf is a solid choice to keep things running smoothly.

Some helpful links to understand Protobuf and Json:

Protocol Buffers Documentation
protobuf
Json
JSON in API Development