DEV Community: Chris

title: Mutex vs RwLock vs ArcSwap. A when-to-use-what memo

Chris — Fri, 07 Aug 2026 06:04:25 +0000

This is a memo to future me, for when I get rusty (yes).

Coming from TypeScript and Python, shared-state concurrency is a topic we literally never had to deal with — the runtime dealt with it for us. Rust hands you the steering wheel, and in exchange makes the worst crash a compile error. This is my map of the territory: what a data race actually is, when to use Mutex vs RwLock vs ArcSwap, and why I shipped ArcSwap in a recent project.

The bug we never had to think about

A data race is: two threads touch the same memory, at least one of them writes, and nothing synchronizes them. The result isn't "sometimes wrong" — it's undefined behavior. Lost updates, torn values, and the compiler optimizing your code under the assumption that races can't happen, so "it looks fine on my machine" means nothing.

The classic minimal case — two threads doing count += 1. That's a read, a modify, and a write; interleave two of them and an increment vanishes.

Why we never saw this in our world: Python has the GIL — one thread executes bytecode at a time. JavaScript is one thread with an event loop. We had race conditions — two awaits interleaving around a check-then-act — but never data races, because there was never true simultaneous memory access.

That distinction matters, so to be precise about what Rust does and doesn't do:

Data race — memory-level, UB. Rust makes this fail to compile.
Race condition — logic-level interleaving bug. Still entirely possible in Rust. The borrow checker is not a logic checker.

Rust's actual trick

Rust's borrow rule is: any number of readers or exactly one writer — &T xor &mut T. That's usually explained as a memory-safety rule, but look again: it's literally the definition of data-race-freedom, enforced at compile time. Send and Sync extend the same rule across threads.

So when you genuinely need shared mutable state, you need something that restores that rule at runtime. That's all a Mutex<T> is — a queue to get a &mut T:

let state = Mutex::new(Stats::default());

let mut s = state.lock().unwrap(); // runtime-checked exclusive borrow
s.hits += 1;
// guard drops → unlocked → next thread's turn

Unlike most languages, the mutex owns the data. You can't reach the Stats without going through lock(), and unlock is Drop, so you can't forget it. Two entire bug classes gone by construction.

(That .unwrap() is policy, not laziness: a poisoned mutex means another thread panicked mid-update and the data may be half-written. Crashing beats trusting it.)

What the compiler can't choose for you is which tool. That's the rest of this memo.

Mutex — the default

Use when: shared state, any read/write mix, short critical sections. Which is most of the time.

An uncontended lock() costs on the order of tens of nanoseconds — it is almost never your bottleneck. The craft is in how you hold it, not whether you use it:

Compute outside the lock, mutate inside it.
Never hold a guard across IO, an .await, or a call into code you don't own.
Drop guards early — an explicit drop(guard) or a scoped block reads as intent.

Avoid when: reads vastly outnumber writes and measurably contend — that's the next rung. Not before you've measured.

RwLock — parallel readers, with fine print

Use when: many readers, rare writers, and — the part everyone skips — read sections long enough to actually overlap. A reader scanning a structure for microseconds while other readers do the same: that's the RwLock use case.

The fine print that makes it a sidegrade more often than people admit:

Acquiring a read lock still performs an atomic read-modify-write on the shared lock word. On a hot path, that one cache line ping-pongs across every core — short, frequent reads can be slower than a plain Mutex.
Writer fairness in std is OS-dependent; writers can starve under heavy read load.
Consistency only exists while you hold the guard. Re-lock, and the world may have changed between.

Avoid when: reads are short and hot (Mutex wins), or when writes replace the whole value anyway — because then there's a tool with no lock at all.

ArcSwap — replace, don't mutate

Use when: read-mostly data whose updates are wholesale replacements — nobody ever edits one field in place; a new complete version supersedes the old one. Config reloads, routing tables, in-memory indexes.

use arc_swap::ArcSwap;

static CONFIG: ArcSwap<Config> = /* ... */;

// reader — no lock, effectively wait-free, coherent snapshot
let cfg = CONFIG.load();
serve(&cfg);

// writer — build a complete new value off to the side, swap once
CONFIG.store(Arc::new(next_config));

Readers get an Arc snapshot: always a complete version, never a half-updated one. Writers pay the full rebuild cost, but nobody waits for them. In-flight readers keep the old version alive until they're done with it; new readers see the new one immediately.

Avoid when: updates are small and frequent relative to the value (rebuilding the world to change one field is silly), or writers need read-modify-write semantics (two concurrent build-and-swap writers will lose one update — that path needs rcu() or a lock again).

Why I shipped ArcSwap this time

Real case from a recent project: an in-memory search index, rebuilt whenever the upstream data changes (a version counter tells us when). The requirements, written out honestly:

Queried on every request. The read path is the hot path; reads must be as close to free as possible.
Every query must see a coherent index. Half-rebuilt is worse than stale.
Rebuilds are slow — normalizing thousands of rows takes real milliseconds. Queries cannot wait behind that.
Updates are rare and wholesale. Nothing ever edits one entry in place.

Score the candidates:

Mutex — serializes every query. Dead on requirement 1.
RwLock, mutating in place — the write lock is held for the entire rebuild. Dead on 3, and every query still pays the lock-word ping-pong from the fine print above.
RwLock, build-then-swap — build the new index off to the side, take the write lock only to swap the value. Closer! The write lock is now held for nanoseconds. But readers still pay an atomic RMW per query, and at that point you've hand-implemented half of ArcSwap with the slow half left in.
ArcSwap — a query is a pointer load; the swap is instant; a slow query that started before the swap simply finishes on the old index while new queries use the new one. Every requirement, no residue.

Requirement 4 is what makes it clean. ArcSwap isn't "a better RwLock" — it's the right shape because the data's lifecycle is replace-not-mutate. If my index needed in-place edits, this whole analysis flips.

The actually interesting part: who frees the old one?

Here's the question that hooked me on this topic. After the swap, a slow query is still reading the old index. When is it safe to free it?

This is the memory reclamation problem, and it's the real hard part of lock-free reading — not the swap, the free. You can't free while an invisible reader might still hold a pointer, and by definition lock-free readers don't announce themselves.

Every ecosystem has an answer:

GC languages — the collector solves it invisibly. This is why lock-free structures are "easy" in Java, and why we never learned any of this in Python/TS: the GC was quietly doing reclamation for us the whole time.
RCU (Linux kernel) — wait until every CPU passes a quiescent state, then free.
Hazard pointers — readers publish "I'm holding this" before dereferencing.
Epoch-based reclamation (crossbeam) — generation stamps; free when every thread has moved past the old epoch.
Arc — a reference count. The last reader to drop the snapshot frees it. Deterministic, no GC pauses, no epochs.

That last one is ArcSwap's answer, and it's worth sitting with: Rust solves the reclamation problem with the same ownership system that made the data race a compile error. The slow query owns a share of the old index; when the last share drops, the memory goes. It's ownership all the way down.

Async footnote

Two things worth pinning, because the folklore is wrong:

std::sync::Mutex is fine — usually preferred — in async code for short critical sections. Tokio's own docs say so. tokio::sync::Mutex exists for one job: holding a lock across an .await. And wanting that is usually a design smell — restructure to lock-copy-drop, await, re-lock. (Caveat: that changes semantics — state can move between the two locks. If the whole span genuinely must be exclusive, that's when the async mutex earns its place.)
ArcSwap is especially pleasant in async: load_full() gives you an owned Arc that crosses .await freely. No guard, no Send drama — the snapshot is just a value.

The memo itself

Situation	Reach for
Shared state, mixed read/write, short ops	`Mutex`
Long read sections, rare writes, measured contention	`RwLock`
Read-mostly + wholesale replacement + hot read path	`ArcSwap`
Counter, flag, version number	`AtomicU64` / `AtomicBool`
Must hold exclusivity across `.await`	`tokio::sync::Mutex`
It's actually a pipeline, not shared state	channels / ownership

The ladder underneath the table: don't share; share frozen; Mutex; and everything above that gets earned with a measurement, not a vibe.

Future me: you probably want the Mutex.

I Bolted a Rust Sidecar onto a Streamlit App, and the Reason Was Memory, Not Speed

Chris — Tue, 04 Aug 2026 07:10:52 +0000

TL;DR

A Streamlit dashboard for retail foot traffic analysis needs typeahead search over about 1.2 million store locations in Japan. Streamlit's execution model makes per-keystroke interaction structurally awkward, and the search itself needs Japanese text normalization plus partial matching that a simple substring filter cannot express.

The fix is a small Rust service running beside the Streamlit container, serving search from an in-memory index.

The decisive reason for Rust was not raw speed. It was that a single Rust process can put a 210 MB index on the heap and let every CPU core read it concurrently. Node and Python cannot, and that turns into a multiple of the memory bill. Everything else in the design follows from that one fact.

The app and the data model

The product is an internal analytics dashboard for retail location intelligence. A user picks store locations and gets a report about who visits them: catchment areas, travel time isochrones, visitor demographics, and comparisons over time. It is built in Streamlit, which lets a small team ship data-heavy tooling in Python without a frontend build pipeline.

The data model has two levels, and they matter for everything downstream.

A chain is a brand or operator. A POI (point of interest) is one physical location belonging to that chain. So a convenience store brand is a chain, and each of its several thousand branches is a POI. There are roughly 11,000 chains and roughly 1.2 million POIs.

The display label for a location joins the two:

{chain name} - {location name}

That separator is presentation only. It is not part of the data and, as it turns out, it must not be part of the search text either.

The selection UI mirrors the hierarchy. Pick one or more chains, then pick locations within them, then render the report. That two step flow is where the trouble starts.

What Streamlit's execution model does to interactivity

Streamlit's core idea is that your script is the UI. On every interaction it reruns the script from the top, and whatever widget calls execute produce the current view. It is a genuinely elegant model for dashboards, and it removes an enormous amount of frontend work.

It also means there is no cheap way to handle "the user typed one character."

A rerun re-executes the whole script. Caching helps, and the usual toolkit is @st.cache_data, st.session_state, and fragments to limit what re-renders. But the mental model is still full script execution per interaction, and a per keystroke rerun over a report heavy page is not something you want to attempt.

The escape hatch is a custom component, which runs as JavaScript in an iframe and talks to Python over a message bridge. That works well, with one catch: sending a value back to Python triggers a rerun. So a component that filters a list has two options. Either it round trips to Python on every keystroke, incurring a rerun each time, or it receives all its options up front and filters entirely client side.

The second option is the only viable one, and it sets a hard ceiling: every candidate the user might search has to be in the browser before they type.

That is why the UI is two step. Sending 1.2 million options to the browser is not an option, so users must narrow by chain first. To keep even that tolerable, the app builds several layers of caching in front of the database: a shared Redis layer holding the chain list with a one day TTL, plus per chain caches of the location lists, so that a coordinator round trip to the Postgres cluster happens at most once per chain.

All of that work is compensating for a constraint that has nothing to do with the data and everything to do with where the filtering happens.

Three ways the search itself is hard

Even setting the delivery problem aside, the matching is not trivial.

Users do not think chain first

The two step flow assumes you know the brand before you know the store. Real usage is often the reverse. Someone wants "the locations in this district," across brands. The hierarchy in the data model got baked into the interaction model, and it should not have been.

Japanese text has many spellings for one string

A single name can appear in katakana or hiragana, full width or half width, with historical or modern kanji forms, and with Unicode variation selectors attached. These are entirely different byte sequences that a human reads as identical.

Unicode NFKC normalization handles width and compatibility forms. It does not handle the kanji variants, which are common in Japanese business names. So the normalization pipeline runs NFKC first, then a Japanese transliteration library for script folding, historical character forms, iteration marks, and variation selector removal, then lowercasing and punctuation stripping.

The important property is that normalization is additive, not destructive. The original text is kept for display, and the normalized text is stored as a separate derived column. Normalization is lossy and one way, so there is no reverse function. You match against the derived column and you display the original.

struct Corpus {
    display: Vec<String>,   // shown to the user, never modified
    search:  Vec<String>,   // normalized, matched against, never shown
}

This is the same relationship a database has with its indexes. Use the index to find the row, then read the row.

Substring matching answers the wrong question

Here is the case that rules out a simple filter. Because a location name almost never repeats its own chain name (measured at 99.6% of records), the searchable text has to be the chain and the location concatenated, so that a query spanning both still matches.

But then a user types the brand plus a district, and the stored record has extra words in the middle. The query is genuinely not a substring of the record. haystack.contains(query) returns false, and no amount of optimization fixes that, because "does this contain that" is the wrong question.

The right question is "how much of this query does this record cover," which requires breaking the query into pieces and scoring partial matches.

The constraint that picked the language

The index has to live in memory. Roughly 210 MB for the text plus the postings, based on the layout described below, loaded once at startup and then serving every keystroke without touching Redis or the database.

The question that decided everything: what happens when you want more than one CPU core?

Node runs JavaScript on one thread, so one core. Four cores means four processes, and processes do not share heaps. That is four copies of the index. worker_threads does not rescue this, because each worker gets its own V8 isolate with its own heap. The only shareable thing is a SharedArrayBuffer, which holds raw bytes and no objects.

Python threads do share a heap, but the GIL means only one runs bytecode at a time. Sharing without parallelism. The standard fix is multiprocessing, which lands right back at N isolated heaps. Free threaded Python changes this and is worth watching, but it was not an option here.

Rust runs N OS threads inside one process, and threads share an address space. One index, every core reading it concurrently, no locks required because nothing mutates after load.

Runtime	Shares one heap	Uses N cores	Index copies on 4 cores
Node, cluster	no	yes	4
Node, worker_threads	no	yes	4
Python, threads	yes	no	1, serialized
Python, multiprocessing	no	yes	4
Rust, tokio	yes	yes	1

At 210 MB per copy that is the difference between provisioning around 1 GB and around 2 GB per container, plus four independent cold start loads on every deploy instead of one.

That is the argument. Not that Rust is fast. That one process can hold one index and let every core read it.

How the service is built

Three layers and one rule.

controller   HTTP only. Parse query params, call the service, serialize.
service      Pure logic. Imports no web framework and no storage client.
repository   I/O. Fetches bytes, returns plain domain types.

The rule is that service never imports the web framework or the storage driver. That single constraint is what keeps storage swappable, and it is worth more than any amount of interface ceremony.

Data flows one direction:

Postgres (source of truth)
   |  batch job builds a versioned snapshot
   v
Redis (distribution, not a request path dependency)
   |  loaded once at boot, and on refresh
   v
Process memory (answers every request)

Redis is a delivery mechanism, not a cache in front of queries. Once a process has loaded, Redis can go down and search keeps working. Snapshots publish blue green: write every chunk of the new version, verify, then flip a single pointer key. A reader sees the old version entirely or the new one entirely, never a mix.

The in memory layout is columnar rather than an array of structs:

// not this
struct Record { group: String, name: String, key: String }
let records: Vec<Record>;

// this
struct Corpus {
    groups:    Vec<String>,   // deduplicated, referenced by index
    group_idx: Vec<u32>,      // which group each record belongs to
    names:     Vec<String>,
    keys:      Vec<String>,
    search:    Vec<String>,   // normalized
}

"Record 7" does not exist as an object. It is the number 7, used to index every array. Two consequences.

Deduplicating the group name costs 4 bytes per record instead of a full string. With 11,000 distinct groups across 1.2 million records, that is roughly 4.8 MB instead of roughly 65 MB for identical information.

Search runs entirely on integers. A candidate set of 300 is 2.4 KB of numbers, not 300 objects. Strings are touched only for the handful of results actually returned, and the response payload is built on demand rather than stored per record.

The index

Japanese has no spaces, so splitting on whitespace is not available. Morphological analysis works but needs a dictionary measured in tens of megabytes. The alternative is n-grams, and bigrams are the practical choice: one character is not selective enough, three means short queries match nothing.

"alphabeta"  ->  al  lp  ph  ha  ab  be  et  ta

Invert it, so each bigram maps to the records containing it:

"ph" -> [7, 91, 2043, ...]
"ha" -> [7, 512, ...]

A query then looks up its own bigrams, tallies how many each record matched, weights rare bigrams above common ones with standard IDF (ln(N / df)), keeps the top few hundred, and reranks those with more expensive checks. Partial coverage gets partial credit, which is exactly what substring matching could not express.

The layout matters more than the algorithm. A hash map from bigram to a vector of IDs means one heap allocation per bigram, plus hash overhead, plus per vector capacity slack, which measures at roughly 4 to 5 times the memory of the alternative.

The alternative is CSR, borrowed from sparse matrix code. Concatenate every posting list into one flat array and keep an array of offsets:

offsets:  [ 0,        3,          7,     8,      12 ]
postings: [ 7,91,2043 | 5,7,88,90 | 3 | 12,44,55,67 ]

A posting list becomes a slice, &postings[offsets[b]..offsets[b+1]]. Two allocations for the whole index instead of hundreds of thousands, and every list is contiguous so hardware prefetching works. Build it by counting occurrences, prefix summing the counts into offsets, allocating exactly once, then filling. That is counting sort, and it is the entire trick.

Concurrency, measured

Tokio is an M:N scheduler. Many cheap tasks are multiplexed onto a small number of OS worker threads, one per core by default. Each .await is a yield point, and between yield points a task owns its worker outright.

Which means async provides no parallelism for CPU bound work. Parallelism comes from having N worker threads. A handler that never awaits is a synchronous function wearing an async hat.

Pinning a runtime to a fixed worker count and giving it 8 tasks, each needing 200 ms of pure CPU:

worker_threads( 1) -> 1600 ms
worker_threads( 2) ->  800 ms
worker_threads( 4) ->  400 ms
worker_threads( 8) ->  200 ms

Perfectly linear. Note that one worker is essentially the Node model, and no amount of async beats 1600 ms with one pair of hands.

The matching trap is blocking a worker. The same 8 requests, three handler styles:

CPU bound directly on the worker    1645 ms
offloaded via spawn_blocking         412 ms
real awaited IO                      413 ms

The rule that falls out: if it does not .await and takes more than about a millisecond, it does not belong on a worker thread. The index build takes about 14 seconds, so it goes to the blocking pool. Blocking a worker for 14 seconds on a 4 core box costs 25% of capacity, health checks included.

The shared state itself is an atomically reference counted pointer, which is what makes the one copy design work. Handing it to a request costs a pointer and a counter bump rather than the data:

clone the shared pointer      11.46 ns
deep copy the same payload    51.7 ms   (1M strings)

Roughly four and a half million times apart. That gap is the entire argument for shared ownership, and it is why per request state is 8 bytes rather than 210 MB.

Numbers

Dev machine, 12 cores, synthetic workloads unless marked otherwise.

Metric	Value	Source
POIs	~1.2 million	actual
Chains	~11,000	actual
Location names not containing their chain name	99.6%	actual
Snapshot on the wire	~49 MB gzipped	actual
Steady state index memory	~210 MB	estimated from layout
Same index under a 4 process runtime	~840 MB	estimated
Text normalization	~12 microseconds per record	measured
Full index build	~14 seconds, single threaded	measured
Shared pointer clone	11.46 ns	measured
Deep copy, 1M strings	51.7 ms	measured
Worker scaling, 8 x 200 ms tasks	1600 / 800 / 400 / 200 ms	measured
Blocking vs offloaded	1645 ms vs 412 ms	measured

Lessons worth keeping

Build the slow version first. The plan deliberately runs a naive linear scan over plain vectors before the inverted index and the compact layout. It provides a correctness baseline and a number to beat. Skipping to the clever version leaves you unable to tell whether it is right or whether it helped.

Normalization belongs in exactly one place. Precomputing normalized text in the Python batch job would save the 14 second build, at the cost of two implementations of the same function in two languages that must agree byte for byte forever. When they drift, queries normalize one way and the index another, and search silently returns nothing. No error, no crash, just empty results. Paying 14 seconds on a background thread is clearly the better trade.

Health checks must gate on readiness. A fresh instance needs most of a minute to fetch, decompress, parse, and normalize before it can answer anything. If the health endpoint returns 200 during that window, the load balancer routes real users to an empty index and they get zero results with no error. That presents as a search bug and is actually a deployment bug.

The UI shape was a data model leak. Chain first selection existed because the delivery mechanism could not handle anything else, not because users think that way. Moving search server side did not just make it faster, it removed a step that should never have been there.

The interesting conclusion is that the decisive factor was not throughput. It was that one process can hold one index and let every core read it. Once that became the binding constraint, most of the rest of the design followed on its own.

Azura: local-first personal assistant (feedback wanted)

Chris — Fri, 14 Nov 2025 12:04:16 +0000

Hey devs 👋

I'm working solo on a project called Azura and I’d love blunt technical + product feedback before I go too deep.

TL;DR

Local-first personal AI assistant (Windows / macOS / Linux)
Runs 7B-class models locally on your own machine
Optional cloud inference with 70B+ models (potentially up to ~120B if I can get a GPU cluster cheap enough)
Cloud only sees temporary context for a given query, then it’s gone
Goal: let AI work with highly personalized data while keeping your data on-device and making AI compute more sustainable by offloading work to the user’s hardware

Think of it as Signal, but for AI:

private by default
transparent about what leaves your device
and actually usable as a daily “second brain”.

Problem I’m trying to solve

Most AI tools today:

ship all your prompts and files to a remote server
keep embeddings / logs indefinitely
centralize all compute in big datacenters

That’s bad if you want to:

use AI on sensitive data (legal docs, internal company info, personal notes)
build a long-term memory of your life and work
not rely 100% on someone else’s infrastructure for every tiny inference

On top of that, current AI usage is very cloud-heavy. Every small task hits a GPU in a datacenter, even when a smaller local model would be good enough.

Azura’s goal:

Let AI work deeply with your personal data while keeping that data on your device by default, and offload as much work as possible to the user’s hardware to make AI more sustainable.

Core concept

Azura has two main execution paths:

Local path (default)
- Desktop app (Win / macOS / Linux)
- Local backend (Rust / llama.cpp / vector DB)
- Uses a 7B model running on your machine
- Good for:
  - day-to-day chat
  - note-taking / journaling
  - searching your own docs/files
  - “second brain” queries that don’t need super high IQ
Cloud inference path (optional)
- When a query is too complex / heavy for the local 7B:
  - Azura builds a minimal context (chunks of docs, metadata, etc.)
  - Sends that context + query to a 70B+ model in the cloud (ideally up to ~120B later)
- Data handling:
  - Files / context are used only temporarily for that request
  - Held in memory or short-lived storage just long enough to run the inference
  - Then discarded – no long-term cloud memory of your life

Context engine (high-level idea)

On top of “just call an LLM”, I’m experimenting with a structured context engine:

Ingests:
- files, PDFs, notes, images
Stores:
- embeddings + metadata (timestamps, tags, entities, locations)
Builds:
- a lightweight relationship graph (people, projects, events, topics)
Answers:
- “What did I do for project A in March?”
- “Show me everything related to ‘Company A’ and ‘pricing’.”
- “What did I wear at the gala in Tokyo?” (from images ingested)

Standard RAG is part of this, but the goal is an ongoing personal knowledge base that the LLM can query, not just a vector search API.

All of this long-term data lives on-device.

Sustainability angle (important to me)

Part of the vision is:

Don’t hit a giant GPU cluster for every small query.
Let the user’s device handle as much as possible (7B locally).
Use big cloud models only when they actually add value.

Over time, I’d like Azura to feel like a hybrid compute layer:

Local where possible,
Cloud only for heavy stuff,
Always explicit and transparent.
And most of all, PRIVATE.

What I’d love feedback on

Architecture sanity
- Does the “local-first + direct cloud inference” setup look sane?
- Any better patterns you’ve used for mixing on-device models with cloud models?
Security + privacy model
- For ephemeral cloud context: what would you need to see (docs / guarantees / telemetry) to trust this?
- Anything obvious I’m missing around temporary file handling?
Sustainability / cost
- As engineers: do you care about offloading compute to end-user devices vs fully cloud?
- Any horror stories optimizing 7B vs 70B usage that I should know about?
Would you actually use this?
- If you’re into self-hosting / local LLMs:
  - What’s missing for this to replace “Ollama + notebook + random SaaS” for you?

Next steps

Right now I’m:

Testing 7B models on typical consumer hardware
Designing the first version of the context engine and schema

If this resonates, I’d really appreciate:

Architecture critiques
“This will break because X” comments
Ideas for must-have features for a real, daily-use personal AI

Thanks for reading 🙏

Happy to dive into any part in more detail if you’re curious.

You Only Really Need to Learn 2 Languages to Succeed

Chris — Fri, 27 Jun 2025 16:12:59 +0000

Most developers are told they need to learn dozens of languages to stay competitive. One for scripting, one for frontend, one for backend, one for systems, and another five because "they’re trending."

But in reality?

You only need two.
Not any two, but one from each of these two fundamental categories:

🔹 1. A High Level Language (With Garbage Collection)

These are your productive, developer-friendly languages. They manage memory for you, offer rich ecosystems, and help you ship fast.

Examples:

TypeScript
Go
Python
Java
C#

Use these when building:

Web apps
APIs
Scripts
Automation
Data pipelines

🔸 2. A Low Level Language (Without Garbage Collection)

These languages give you precise control over memory and performance. They are used when predictability, speed, or system-level access matters.

Examples:

Rust
C++
C
Zig

Use these for:

Game engines
OS development
Embedded systems
Performance-critical code
Security and cryptography work

🎯 Why Just These Two?

Because most real-world software problems fall into one of these buckets:

High level orchestration like building logic, connecting services, and managing flows
Low level performance like speed, memory management, and hardware interaction

If you can write both, you can:

Build a full stack system on your own
Write efficient backend services and embedded agents
Move between startup MVPs and military-grade firmware

🔧 Smart Pairings

GC Language	Non-GC Language
Go	C++
TypeScript	Rust
Python	C
Java	Rust

You do not need to master all of them. Just pick one solid language from each group and go deep.

🧠 Depth Over Breadth

Mastering a garbage-collected language makes you productive
Mastering a non-GC language makes you powerful

You do not need to chase trends. You need to understand tradeoffs, how systems work, how memory is managed, and how to scale clean code.

Everything else is just syntax.

✅ TLDR

You only really need to learn two languages:

One that frees you to move fast
One that forces you to think clearly

Learn them deeply
Build boldly
Forget the noise

Stop Overengineering in the Name of Clean Architecture

Chris — Sun, 11 May 2025 03:15:29 +0000

Clean Architecture is a great concept. It’s meant to help you write maintainable, modular, and scalable software.

But too many developers treat it like a religion. They follow it blindly, stuffing projects with unnecessary layers, abstractions, and patterns. All in the name of “clean code.”

Let’s be honest, Clean Architecture is often overused, not because the ideas are bad, but because people overengineer the implementation.

A Quick Joke (That Some Devs Write Unironically)

Here’s an example of multiplying two numbers implemented with an absurd number of patterns:

// overengineered-multiplier.ts

// Interface
interface IMultiplier {
  multiply(a: number, b: number): number;
}

// Singleton
class MultiplierService implements IMultiplier {
  private static instance: MultiplierService;

  private constructor() {}

  static getInstance(): MultiplierService {
    if (!MultiplierService.instance) {
      MultiplierService.instance = new MultiplierService();
    }
    return MultiplierService.instance;
  }

  multiply(a: number, b: number): number {
    return a * b;
  }
}

// Adapter
interface IMultiplierInput {
  x: number;
  y: number;
}

class InputAdapter {
  constructor(private readonly rawInput: [number, number]) {}

  adapt(): IMultiplierInput {
    return { x: this.rawInput[0], y: this.rawInput[1] };
  }
}

// Decorator
class LoggingMultiplierDecorator implements IMultiplier {
  constructor(private readonly inner: IMultiplier) {}

  multiply(a: number, b: number): number {
    console.log(`Logging: Multiplying ${a} * ${b}`);
    const result = this.inner.multiply(a, b);
    console.log(`Logging: Result is ${result}`);
    return result;
  }
}

// Proxy
class MultiplierProxy implements IMultiplier {
  constructor(private readonly target: IMultiplier) {}

  multiply(a: number, b: number): number {
    if (typeof a !== 'number' || typeof b !== 'number') {
      throw new Error('Invalid input types');
    }
    return this.target.multiply(a, b);
  }
}

// Abstract Factory
interface IMultiplierFactory {
  create(): IMultiplier;
}

class RealMultiplierFactory implements IMultiplierFactory {
  create(): IMultiplier {
    const singleton = MultiplierService.getInstance();
    const withLogging = new LoggingMultiplierDecorator(singleton);
    const withProxy = new MultiplierProxy(withLogging);
    return withProxy;
  }
}

// Usage
const rawInput: [number, number] = [6, 9];
const adapted = new InputAdapter(rawInput).adapt();

const factory = new RealMultiplierFactory();
const multiplier = factory.create();

const result = multiplier.multiply(adapted.x, adapted.y);
console.log(`Final Result: ${result}`);

All of this just to calculate 6 * 9. This is what happens when design patterns become cosplay.

The Real Problem: Over-Abstraction

Clean Architecture promotes decoupling. That’s good. But too many devs interpret that as "abstract everything."

Example:

interface IUserRepository {
  findById(id: string): Promise<UserDTO>;
}

class UserRepositoryImpl implements IUserRepository {
  constructor(private db: PrismaClient) {}

  async findById(id: string): Promise<UserDTO> {
    return await this.db.user.findUnique({ where: { id } });
  }
}

Then you add a use case on top:

class GetUserByIdUseCase {
  constructor(private repo: IUserRepository) {}

  async execute(id: string): Promise<UserDTO> {
    return this.repo.findById(id);
  }
}

All of this for one database call. This isn’t clean it’s waste.

Common Overengineering Patterns

1. Interfaces and Implementations for Everything

Blindly creating an interface and a class for every service adds friction without real value.

Use it when:

You actually have multiple implementations
You’re building a plugin system or SDK

Don’t use it when:

You only have one implementation
You’re doing it "just in case"

2. Use Case Classes for Simple Logic

class CreatePostUseCase {
  execute(input: CreatePostDTO): Promise<PostDTO> {
    return this.postRepo.create(input);
  }
}

This is a one-line call. Wrapping it in a class adds nothing. Use a service or method directly unless business logic really requires separation.

3. DTO Explosion

type Post = { id: string; title: string; content: string };
type CreatePostDTO = { title: string; content: string };
type PostResponseDTO = { id: string; title: string; content: string };

If the structure is the same across layers, reuse the object. You don’t need a new DTO for every transition unless there’s a reason.

4. Domain Models with No Behavior

class User {
  constructor(public id: string, public name: string) {}
}

If your "domain entity" is just a data wrapper, it’s not a domain model. Add behavior or don’t abstract.

5. Dependency Injection Overkill

@Module({
  providers: [
    { provide: IUserService, useClass: UserServiceImpl },
    { provide: IUserRepository, useClass: UserRepositoryImpl }
  ]
})

DI containers are great. But if you’re not benefiting from polymorphism or dynamic injection, just instantiate the class.

What You Should Do Instead

Start simple. Build complexity only when needed.
Abstract with intent. Not everything needs to be swappable.
Refactor later. Let the structure grow organically as the app gets more complex.
Optimize for clarity. Not for pleasing architecture diagrams.

Clean Code Is Not More Code

Good code is:

Easy to read
Easy to test
Easy to change

It’s not defined by how many layers, decorators, or design patterns it uses.

Final Thoughts

Clean Architecture should serve your code, not the other way around.

It’s a tool, not a rulebook. Use it to solve complexity not to create it.

TLDR

Avoid This	Do This Instead
Interface and Impl for everything	Use one class until you actually need two
Use cases for CRUD logic	Use simple services or methods
Separate DTOs for same shapes	Reuse types where possible
DI for everything	Instantiate directly when practical
Layers for layers’ sake	Let structure grow with real needs

Build software, not monuments.

Of course, if your goal is job security, then by all means abstract everything. Write five layers per feature, name nothing clearly, and inject interfaces into factories into services into use cases. Once the codebase hits 100,000 lines, no one will know what’s going on but you. Congratulations, you’re now unfireable LOL.

TypeScript + Rust: All You Need in 2025

Chris — Sun, 11 May 2025 02:59:58 +0000

Let’s be real. The software landscape is bloated. Between AI hyped frameworks and the constant cycle of JS libraries trying to reinvent the wheel, it’s easy to get lost chasing tech for the sake of it.

But if you're trying to actually build something valuable in 2025, not just keep up with Hacker News, you really only need two languages:

TypeScript and Rust

Why TypeScript?

Because 90 percent of products today touch the web. And when it comes to frontend, API clients, or even backend services, nothing is more practical than TypeScript.

You get type safety without the Java boilerplate
You get first class tooling with VSCode, ESLint, Bun, tsup
You can build full stack apps across Next.js, Node, Cloudflare Workers, Firebase
You move fast without breaking everything

It’s the language of the web. Period

Why Rust?

Because when performance, memory safety, and scale matter, Rust is unmatched

C level performance with zero segfaults
Compiles to WebAssembly or runs as a blazing fast backend
Handles AI pipelines, edge compute, custom databases, file systems
Gives you memory control and fearless concurrency for real workloads

You are not wasting CPU cycles on garbage collection or runtime bugs

What About the Others?

Python
Nice syntax until the codebase grows. The type system is glued on, not designed in. Static analysis is a mess and errors sneak in constantly

Go
Go is great for building simple tools quickly, but it can become a liability at scale. Discord famously dropped Go from their caching system after the garbage collector became a bottleneck. While that specific issue was later addressed, GC performance can still be unpredictable under heavy load. If you need fine-grained control or predictable latency, Go might not cut it.

Java
Enterprise hell. Verbose classes, XML config files, Spring Boot complexity. Java is built for a different era. If you are building modern software today, why are you still using it

Real World Example

In my current projects

Frontend and admin dashboards: TypeScript with React, Chakra, Next.js
Backend logic, APIs, authentication, realtime: TypeScript with NestJS, Firebase, Cloud Run
Data processing, local AI, indexing: Rust with REST API, image parsing, zip and file system crawling
Vector search and storage orchestration: Rust with Qdrant and PostgreSQL

One stack
End to end control
No bloat
No regrets

Final Thoughts

If you master TypeScript and Rust, you are not a JS dev
You are not a systems dev
You are a full spectrum engineer who can build anything from the interface to the infrastructure

In a world filled with AI noise, cloud saturation, and latency pressure

That’s all you need

What are you building with in 2025
Let’s talk in the comments

Don’t Use SQL If Your Client Doesn’t Know What They Want

Chris — Sun, 11 May 2025 02:46:56 +0000

Firestore saved me from schema hell

If you’re building for a client who keeps shifting the goalpost, here’s some honest advice:

Avoid SQL until the spec is stable.
You’ll save yourself from endless migrations, broken data, and wasted hours.

💥 Why SQL is a bad idea in chaotic projects

Every schema change = manual migration
Every migration = rollback risk
Every miscommunication = broken relations or corrupted data

It’s like building a skyscraper with a blueprint drawn in crayon.

✅ Why Firestore (NoSQL) saved me

No migrations
Just start writing data. Add new fields whenever. No tables to alter. No DB admin.
Nested data, no problem
Need a user profile with 5 settings and a subcollection of comments? Firestore handles that like it’s native.
Speed over structure
Perfect for MVPs. When the client changes their mind (again), you don’t have to rewrite half your DB logic.
Schema-less = stress-less
You don’t get yelled at for not “planning ahead.” You just ship.

⚖️ But if you have to use SQL…

Some teams/projects require relational DBs. Here are tools that make the pain tolerable:

Prisma Type-safe, declarative schema, powerful migration engine
Knex.js + Objection.js Mature and battle-tested in Node environments
Atlas by Ariga Clean migration workflows, good for CI/CD
Supabase 🔥 Firebase-like developer experience on top of PostgreSQL
- Instant APIs
- Auth + storage included
- Web UI for managing schema/migrations
- Great for teams that need SQL but want NoSQL-level velocity

Why Supabase is different

Even though it’s SQL under the hood, Supabase makes schema changes easier to manage. You can:

View and edit tables in the dashboard
Auto-generate APIs
Roll back or push migrations with Git workflows

It's a great compromise if your project is too relational for Firestore but still in flux.

TL;DR

If the client says “we’re still figuring it out,” avoid SQL unless you enjoy stress.

✅ Use Firestore when things are unstable or MVP
✅ Use Supabase if you need SQL but want NoSQL flexibility
✅ Use proper migration tools (Prisma, Knex, Atlas) if you're stuck with raw SQL

Choose tools that match the reality of the project, not what sounds good on paper.

I Started My Own Company at 20 and Landed a $70K Contract. Here's What I'm Building Next

Chris — Sun, 11 May 2025 02:41:10 +0000

At 20 years old, I took the leap and officially founded my first company. I’ve been a software engineer since I was 15, leading teams, shipping products, and consulting. But this is different. This is mine.

Just days after incorporation, I closed a $70,000 contract. No funding. No connections. No fancy pitch decks. Just proof of work, relentless execution, and solving real problems fast.

Now I’m channeling that momentum into building something much bigger.

Introducing NousCore My Legacy Project

I won’t spill everything. There are too many eyes and too many people trying to ride waves they didn’t earn.

But here’s what I can share:

• It’s an AI-native platform that runs on the edge, not in the cloud
• It’s built for performance, privacy, and permanence
• It combines my love for systems programming, local-first data, and real-world utility
• It’s memory-efficient, resilient, and doesn’t need a datacenter to function

Think of it as a personal AI system that works for you and not for advertisers, not for surveillance, and not for data farms.

Why I’m Doing This

I’m tired of bloated software and overengineered cloud stacks that leak data and burn budgets. I want to create something powerful, self-contained, and private. Something that lasts.

This isn’t just a product. It’s a statement.

What's Next

I’ll be documenting parts of my journey (without giving away the sauce). From technical breakdowns to startup realities.

If you're into AI, systems design, or just want to build things that matter, follow along.

Let’s make tech that respects people again.

Stop Letting AI Do Your Thinking For You

Chris — Thu, 24 Apr 2025 03:36:12 +0000

Lately it feels like roles are reversing.

Instead of developers using AI as a tool, they are becoming tools for AI.

People plug their entire codebase into Copilot or Cursor, click accept like it is gospel, and think they are building software. You are not. You are just pasting code with no idea where it came from or how it fits into the system you are supposed to understand.

Let me be clear:

I use AI. I use ChatGPT. But I use it like a scalpel, not a crutch.

I do not touch Copilot. I do not rely on Cursor. Why?

Because the second you offload thinking, you lose track of context.

And context is the only real superpower a software engineer has.

No AI today not ChatGPT, not Claude, not anything can keep track of your mental model. They do not know the trade-offs you made last sprint. They do not remember that one brittle API you agreed to avoid touching until Q3. They do not understand why you chose composition over inheritance in a specific module that is now quietly holding your whole app together.

But you do.

Your brain does.

And when you give up your role as the system’s architect to let some autocomplete guess what you need, you become the assistant, not the engineer.

AI is a hammer. You are still the one swinging it.

Use AI to accelerate your thinking. Ask it to break down a regex, write a first draft of a boring config, or summarize documentation. Fine. Great. But never let it own the architecture. Do not let it become your crutch for avoiding complexity.

Because if you do, one day you will open your codebase and realize you do not even recognize the thing you built.

And worse, you will not know how to fix it.

If this resonates, drop your thoughts. I am all for AI, but we need to stop worshipping it like it is the engineer. It is not. You are.

How I Made My SaaS "Students Only" Without School IDs Using WHOIS and GPT

Chris — Thu, 24 Apr 2025 00:49:18 +0000

In building my resume review SaaS tailored for students and 転職活動 (career change) seekers in Japan, I faced a simple question:

"How do I restrict access to just students without relying on official university logins or SheerID?"

A lot of companies solve this using school issued IDs, OAuth through G Suite for Education, or even SheerID verification. But all of those come with integration complexity, potential friction, and worst of all kill the speed and ease of my UX.

So I built something better.

✅ The Goal: Students Only Access With Just an Email

My signup form asks for a university email. That’s it. If your domain is a real school, you’re in. If it’s not, you’re blocked. No ID upload. No OAuth. No API dependency.

⚙️ The Stack

Backend: Node.js (NestJS)
Database: Firestore (for whitelist and blacklist)
External Tools:
- WHOIS lookup
- OpenAI GPT API
No SheerID. No OAuth. No .edu requirement

💡 The Logic

User submits an email like someone@s.chibakoudai.jp
I extract the domain: s.chibakoudai.jp
Check my Firestore whitelist and blacklist
If unknown, use WHOIS and GPT to verify

🔍 WHOIS and GPT Magic

If the domain isn’t already in my whitelist, I check WHOIS to get metadata like:

Organization name
Registrant info
Domain category (often .ac.jp, .edu, etc.)

Then I feed that WHOIS data into ChatGPT with a prompt like:

"Is this domain associated with an educational institution? Just return Yes or No."

If GPT says yes → ✅ add to whitelist

If GPT says no → ❌ add to blacklist and block the user

✨ Example Code Snippet

const whoisData = await lookupWhois(domain);
const prompt = `Is this domain from a university or educational institution?\n\nWHOIS:\n${whoisData}`;

const gptResult = await openai.chat.completions.create({
  model: 'gpt-4',
  messages: [{ role: 'user', content: prompt }],
});

const isSchool = gptResult.choices[0].message.content.includes('Yes');

🧠 Why It Works

Fast UX — Users don’t need to upload IDs or register school portals
Self expanding list — My whitelist grows automatically as GPT verifies new domains
Low Cost — GPT and WHOIS is cheaper and faster than commercial APIs

🔐 What About Abuse

Domains like gmail.com or yahoo.co.jp get instantly rejected
Once flagged, a domain is blacklisted and denied forever
This isn’t a hardcore identity proof — it’s smart friction

🚀 Outcome

Zero authentication integrations
Super smooth UX
Only real students can register
No need to deal with Japanese school bureaucracy (trust me, that’s worth it)

🤖 TLDR

I used WHOIS and GPT to check if an email domain belonged to a school and whitelist it automatically. No OAuth. No ID. Just a clever prompt and database check. Lightweight, fast, and clean.

If you want to implement this or have questions, feel free to drop a comment. Happy to share the logic in more detail

And if you’re working on an AI SaaS and want to avoid auth complexity this might be the easiest "student only" gate you'll ever build.

How I Landed a $150K Contract at 20 While Everyone Else Was Virtue Signaling

Chris — Tue, 22 Apr 2025 10:24:31 +0000

Let’s be real

Most of what you see online from “young founders” is noise

Pitch decks, buzzwords, hackathon demos, endless posts about “building in public”

No users, no product, no revenue

Just vibes

Meanwhile, I’m 20

No college

No investor

No clout

Just skill and execution

And with that alone, I closed a $150,000 contract to build a full-scale SNS platform from the ground up

This post isn’t about bragging

It’s about showing you that you don’t need credentials when you can provide undeniable value

What I Did (That Most Don’t)

1. I shut up and learned to build

I didn’t waste my time posting “day 34 of building my startup” or preaching on LinkedIn

I spent my time mastering:

Full stack engineering (React, NestJS, PostgreSQL, etc.)
Real world infrastructure (GCP, Docker, Firebase, Cloud Run)
Clean architecture, auth systems, deployment pipelines
Systems that actually scale

While others were building MVPs with no understanding of backend security or performance, I built real, working apps

2. I made my skills public through work

No resumes. Just output

I didn’t tell people I could build, I showed them

I took smaller gigs early, overdelivered, built trust, and made sure everything I touched was undeniably professional

Design. Docs. Architecture. Deployment

All clean. All tight

When the $150K opportunity came, there was no question of "can you handle this"

They already knew I could

3. I didn’t act like a founder, I acted like an engineer

I didn’t wear a fake CEO badge or pretend I was changing the world

I scoped the problem, broke it down, communicated clearly, and delivered a real execution plan

That alone made me stand out more than any mission statement ever could

Why It Worked

Because companies don’t care about your startup story

They care about whether you can deliver something that works, that scales, and that solves a problem

I didn’t pretend to be a visionary

I just did the work, and that work turned into value which turned into a $150K payout

Final Words

If you’re young and trying to get in

Stop trying to look impressive. Be useful

Stop preaching about disruption. Start delivering output

Let your craft speak for itself

Because in the end

Value over virtue signaling

Results over resumes

Execution over excuses

I’m 20, I didn’t go to college, and I’m already profiting with skill alone

You can too if you stop playing the game everyone else is playing

Why I Never Use Optimistic Updates (And Why You Might Regret It Too)

Chris — Sat, 19 Apr 2025 14:16:57 +0000

If you’ve built anything with React, Vue, or any modern frontend framework, you’ve probably come across the idea of optimistic UI updates. It sounds fancy. It sounds fast. It even feels good. Until it doesn’t.

Let me tell you why I almost never update state optimistically anymore, and why you might want to think twice before doing it too.

⚡ What Is an Optimistic Update?

Optimistic updates mean changing the UI before you know if the backend operation actually succeeded. For example, you click "like" on a post, and the heart icon turns red immediately, before the API call finishes.

setLiked(true) // optimistic update
await api.likePost(postId)

If something fails, you roll it back:

catch (error) {
  setLiked(false) // rollback
}

Seems harmless, right?

❌ Why I Stopped Using Optimistic Updates

1. Edge Cases Multiply Fast

Every time you write an optimistic update, you're creating an alternate reality. Now you have to write logic to reconcile the optimistic state with the real state if:

The request fails
The data changes from another tab or user
The user undoes the action before the request finishes
The server responds with something unexpected like validation or sanitization

That’s four edge cases for one button. Multiply that across a large app and your UI becomes a ticking time bomb.

2. Rollbacks Are a UX Nightmare

Users hate seeing the UI revert. Imagine typing a message, seeing it appear instantly, and then it disappears because the server threw a 500.

Yes, you can show toasts like “Action failed,” but most people don’t read those. It just feels like your app is broken or buggy.

3. It Breaks Consistency

Your UI state and your backend state go out of sync on purpose when you use optimistic updates. That’s dangerous.

Consistency between client and server is everything in multi-user apps. If you break that contract, you introduce bugs that are extremely hard to debug, especially when multiple users are involved.

4. You’re Not Facebook

Optimistic updates are mostly popularized by companies that can afford massive infra and logic to handle them properly.

You probably have:

A few devs, maybe just you
No conflict resolution backend
No retry queue
No live event stream syncing the UI

Without all of that, optimism is a luxury you can’t afford.

🧠 What I Do Instead: Pessimistic + Immediate Feedback

I do this:

setLoading(true)
await api.likePost(postId)
setLiked(true)
setLoading(false)

And optionally show a spinner or skeleton. Sure, it's 100 to 300 ms slower, but I:

Don’t need to roll anything back
Don’t need to guess what the server will return
Keep the UI and backend state always in sync
Avoid writing extra logic for "what if it fails"

Clean code. Predictable behavior. No surprise bugs at 3 am.

🔄 When I Do Use Optimistic Updates

Okay, I lied a little. I’ll use optimistic updates if and only if:

The failure state doesn't matter, like liking a post that no one else sees
The action is idempotent
I have background sync or retry logic
I’m willing to tolerate inconsistency

In most CRUD apps, not worth it.

💡 Final Thoughts

Optimistic updates are like gambling. Sometimes you win. But when you lose, the debugging cost is massive.

Instead of betting that your API won't fail, just build for the world we live in. A world where servers crash, networks flake, and users click faster than requests resolve.

You don’t need optimism. You need resilience.

✍️ What do you think? Do you use optimistic updates in your app? Have they bitten you before? Let’s talk in the comments.