DEV Community: Aditya Rawas

What Zig Feels Like Coming from Go: A Systems Programming Comparison

Aditya Rawas — Sun, 20 Sep 2026 09:15:09 +0000

Originally published at adityarawas.in

Zig has been circling the edges of backend and systems engineering conversations for a few years now, but the recent wave of "coming from X to Zig" posts signals something worth paying attention to: engineers who live in garbage-collected, batteries-included languages like Go are starting to poke at it seriously. If you write Go for a living and you're curious whether Zig deserves a slot in your toolbox, this is the comparison that actually matters — not Zig vs Rust, but Zig vs the language you already ship to production every day.

Why Go Developers Are Looking at Zig

Go was designed to eliminate cognitive overhead: garbage collection, a single formatting style, a small keyword set, and a standard library that just works. Zig takes almost the opposite bet — no hidden control flow, no hidden allocations, no garbage collector — but it borrows Go's obsession with simplicity in spirit. Both languages reject C++-style feature creep. Both ship a single official toolchain. Both have "there's one way to do it" energy.

The difference is what they optimize for. Go optimizes for engineering velocity at scale — teams, services, microservices, distributed systems. Zig optimizes for control — predictable performance, zero hidden costs, and direct hardware access. If you've ever hit a GC pause in a latency-sensitive Go service or fought cgo to call into a C library, you've already felt the itch that Zig scratches.

Memory Management: Explicit vs Automatic

This is the single biggest mental shift.

// Go: the garbage collector owns this
func loadConfig() *Config {
    cfg := &Config{Name: "prod"}
    return cfg // GC tracks lifetime automatically
}

// Zig: you own this, and you must free it
const std = @import("std");

fn loadConfig(allocator: std.mem.Allocator) !*Config {
    const cfg = try allocator.create(Config);
    cfg.* = Config{ .name = "prod" };
    return cfg; // caller is responsible for allocator.destroy(cfg)
}

There's no GC in Zig. Every allocation goes through an explicit Allocator interface that you pass around like a dependency. This sounds tedious until you realize it's actually a feature: you can swap in an arena allocator for a request handler, a fixed-buffer allocator for embedded work, or a general-purpose allocator with leak detection for tests — all without changing your business logic.

var gpa = std.heap.GeneralPurposeAllocator(.{}){};
defer {
    const leaked = gpa.deinit();
    if (leaked == .leak) std.debug.print("memory leak detected\n", .{});
}
const allocator = gpa.allocator();

Go developers used to defer cleanup() will feel at home with Zig's defer and errdefer — the syntax is nearly identical, but the responsibility is heavier because there's no safety net underneath it.

Error Handling: Similar Philosophy, Different Enforcement

Go's if err != nil pattern gets mocked constantly, but Zig actually doubles down on the same idea — explicit errors as values, no exceptions — while making it compiler-enforced instead of convention-based.

func readFile(path string) ([]byte, error) {
    data, err := os.ReadFile(path)
    if err != nil {
        return nil, fmt.Errorf("reading file: %w", err)
    }
    return data, nil
}

fn readFile(allocator: std.mem.Allocator, path: []const u8) ![]u8 {
    const file = try std.fs.cwd().openFile(path, .{});
    defer file.close();
    return file.readToEndAlloc(allocator, std.math.maxInt(usize));
}

The ! before the return type marks this as an "error union" — the function returns either the value or one of a defined set of errors. The compiler forces you to handle it with try, catch, or an explicit switch on the error set. Unlike Go, you cannot silently ignore an error by accident — there's no equivalent of forgetting the if err != nil check, because unhandled error unions won't compile.

Error Handling Comparison

Aspect	Go	Zig
Error type	`error` interface	Error set (enum-like, compile-time checked)
Enforcement	Convention (`if err != nil`)	Compiler-enforced (`try`/`catch`)
Wrapping errors	`fmt.Errorf("%w", err)`	Error sets can merge (`ErrorA \
Stack traces	Manual ({% raw %}`pkg/errors`, `runtime.Caller`)	Built-in with `error return trace` in debug builds
Ignoring errors	Possible (forgetting the check)	Not possible — must explicitly discard
Panics	`panic()`/`recover()`	`unreachable`, explicit crashes, no recover by default

Compile-Time Metaprogramming: `comptime` vs Generics

Go got generics in 1.18, and they're useful but limited — type parameters, constraints, no compile-time code execution. Zig's comptime is a different beast entirely: it lets you run arbitrary Zig code at compile time, including generating types.

// Go generics: type-parameterized, but no compile-time logic
func Map[T, U any](items []T, fn func(T) U) []U {
    result := make([]U, len(items))
    for i, item := range items {
        result[i] = fn(item)
    }
    return result
}

// Zig comptime: generate a type based on a compile-time parameter
fn Vector(comptime T: type, comptime size: usize) type {
    return struct {
        data: [size]T,

        pub fn sum(self: @This()) T {
            var total: T = 0;
            for (self.data) |v| total += v;
            return total;
        }
    };
}

const Vec3f = Vector(f32, 3);

There's no separate "template language" like C++ — comptime code is just Zig, executed by the same compiler, at compile time instead of runtime. This is more powerful than Go generics but comes with a steeper learning curve. Go's generics were deliberately kept simple to avoid this complexity; Zig went the other direction on purpose.

Concurrency: Goroutines vs Manual Control

This is where Go's design philosophy pulls furthest ahead for typical backend work. Goroutines and channels are a first-class, batteries-included concurrency model:

func fetchAll(urls []string) []Result {
    results := make(chan Result, len(urls))
    for _, url := range urls {
        go func(u string) {
            results <- fetch(u)
        }(url)
    }
    out := make([]Result, 0, len(urls))
    for range urls {
        out = append(out, <-results)
    }
    return out
}

Zig historically shipped an async/await model but pulled it out of the language in late 2023 pending a redesign — as of the versions being discussed in these "coming from" posts, concurrency in Zig means threads, thread pools, and manual synchronization primitives from the standard library.

const std = @import("std");

fn worker(result: *i32, value: i32) void {
    result.* = value * value;
}

pub fn main() !void {
    var results: [4]i32 = undefined;
    var threads: [4]std.Thread = undefined;

    for (0..4) |i| {
        threads[i] = try std.Thread.spawn(.{}, worker, .{ &results[i], @as(i32, @intCast(i)) });
    }
    for (threads) |t| t.join();

    std.debug.print("{any}\n", .{results});
}

If your workload is I/O-bound web services with thousands of concurrent connections, Go's runtime scheduler is doing you enormous favors for free. Zig gives you the primitives, not the scheduler — you build (or import) your own event loop if you need one.

Cross-Compilation: Zig's Killer Feature

This is the one area where Zig genuinely embarrasses Go, and it's worth calling out because it has real DevOps implications. Go's cross-compilation is already good (GOOS=linux GOARCH=arm64 go build), but Zig's zig cc has become popular as a drop-in cross-compiling C/C++ toolchain, and native Zig cross-compilation is just as trivial:

# Native Zig cross-compilation, no external toolchain needed
zig build-exe main.zig -target aarch64-linux-musl -O ReleaseFast
zig build-exe main.zig -target x86_64-windows-gnu
zig build-exe main.zig -target wasm32-wasi

Many teams now use zig cc inside Go's own build pipeline to cross-compile CGO-dependent Go binaries for musl/Alpine targets, sidestepping glibc version hell entirely:

FROM golang:1.23-bookworm AS builder
RUN apt-get update && apt-get install -y zig || \
    (curl -L https://ziglang.org/download/0.13.0/zig-linux-x86_64-0.13.0.tar.xz | tar -xJ -C /usr/local && \
     ln -s /usr/local/zig-linux-x86_64-0.13.0/zig /usr/local/bin/zig)

WORKDIR /app
COPY . .
ENV CC="zig cc -target x86_64-linux-musl"
ENV CGO_ENABLED=1
RUN go build -ldflags="-linkmode external -extldflags -static" -o app .

FROM scratch
COPY --from=builder /app/app /app
ENTRYPOINT ["/app"]

This trick alone is why a lot of Go engineers have Zig installed on their machines without writing a single line of Zig application code.

Standard Library Philosophy

Go's stdlib is broad and stable — net/http, encoding/json, database/sql cover most backend needs out of the box, and backward compatibility is a near-religious commitment (Go 1 compatibility promise). Zig's stdlib is smaller, still pre-1.0, and breaking changes between minor versions are common and expected. This matters practically:

Factor	Go	Zig
Stability guarantee	Go 1 compatibility promise since 2012	None — pre-1.0, breaking changes every release
Package manager	Go modules (mature, `go.mod`)	Zig package manager (new, still evolving)
HTTP server in stdlib	`net/http`, production-grade	`std.http`, functional but less battle-tested
Build tool	`go build`	`zig build` (also a general-purpose build system for C/C++)
Binary size	Larger (includes runtime + GC)	Smaller (no runtime, no GC)
Learning curve	Shallow	Steep (manual memory, comptime)

That "None" under stability guarantee is not a minor footnote — it's the reason most engineers currently treat Zig as an exploration language or a tool for specific tasks (cross-compiling, WASM targets, embedded, replacing C dependencies) rather than a wholesale Go replacement in production services.

Where Each Language Actually Wins

Go wins when you're building:

HTTP APIs, gRPC services, microservices at scale
Anything where team velocity and hiring pool matter more than raw performance
Systems where GC pauses in the low milliseconds are acceptable
Long-term maintainability with a stable, boring toolchain

Zig wins when you're building:

CLI tools and libraries that need to cross-compile to obscure targets
Performance-critical hot paths where GC pauses are unacceptable (game engines, audio, real-time systems)
Replacements for C/C++ dependencies where you want memory safety improvements without a runtime
WASM modules where binary size and startup time matter

A realistic pattern emerging in 2026: teams keep their services in Go and reach for Zig (or zig cc) specifically for cross-compilation tooling, CGO replacement, or isolated performance-critical modules compiled to a shared library and called from Go via CGO or a sidecar process.

// #cgo LDFLAGS: -L. -lzigmath
// #include "zigmath.h"
import "C"

func FastCompute(x float64) float64 {
    return float64(C.fast_compute(C.double(x)))
}

Key Takeaways

Zig has no garbage collector and no hidden allocations — every allocation is explicit via an Allocator you pass around, unlike Go's automatic GC.
Zig's error handling is philosophically similar to Go's (errors as values, no exceptions) but compiler-enforced through error unions and try/catch, making silent error-swallowing impossible.
comptime in Zig is significantly more powerful than Go generics, letting you execute arbitrary code at compile time to generate types, at the cost of a steeper learning curve.
Go's goroutines and channels remain unmatched for I/O-bound concurrent workloads; Zig currently offers only threads and manual synchronization after removing its async/await model.
Zig's cross-compilation story is best-in-class and is already being adopted inside Go build pipelines via zig cc to solve CGO/glibc portability headaches.
Go's standard library stability (the Go 1 compatibility promise) versus Zig's pre-1.0 breaking changes is the main reason Zig isn't yet a production-service replacement for most teams.
The pragmatic 2026 pattern is hybrid: Go for services and business logic, Zig for cross-compilation tooling, performance-critical modules, or replacing legacy C dependencies.
If you're evaluating Zig, start with a CLI tool or a CGO replacement rather than rewriting a production service — it's the lowest-risk way to learn the language's real tradeoffs.

Cloudflare Quick Tunnels: Expose Local Servers to the Internet Without a VPS

Aditya Rawas — Sat, 19 Sep 2026 07:39:46 +0000

Originally published at adityarawas.in

Every developer has hit this wall: you've got a server running on localhost:3000, and you need someone outside your network to hit it. A webhook provider needs a public URL. A client wants to see a live demo. A teammate needs to test your API from their phone. The usual answer has been ngrok, but ngrok's free tier throttles you, rotates URLs, and gates useful features behind a paywall. Cloudflare Quick Tunnels solve the same problem, for free, with no account required, and they've quietly become one of the most useful tools in a backend developer's toolkit.

This post covers what Quick Tunnels are, how they differ from full Cloudflare Tunnels, when to use them versus alternatives like ngrok or localtunnel, and how to wire them into real Node.js, Docker, and webhook-testing workflows.

What Are Cloudflare Quick Tunnels

A Quick Tunnel is a temporary, ephemeral tunnel created by the cloudflared binary that exposes a local port to a public *.trycloudflare.com URL. No Cloudflare account, no DNS setup, no zone configuration. You run one command, get a URL, and traffic routes through Cloudflare's edge network straight to your machine.

Under the hood, cloudflared establishes an outbound connection from your machine to Cloudflare's network. Because the connection is outbound-initiated, you don't need to open inbound firewall ports or configure NAT — which is the same trick full Cloudflare Tunnels use for production ingress, just without the persistent hostname and dashboard config.

# Install cloudflared (macOS)
brew install cloudflared

# Install cloudflared (Linux, Debian/Ubuntu)
curl -L --output cloudflared.deb https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb

Once installed, exposing a local server takes one line:

cloudflared tunnel --url http://localhost:3000

You'll see output like:

+--------------------------------------------------------------------------------------+
|  Your quick Tunnel has been created! Visit it at:                                    |
|  https://random-words-here.trycloudflare.com                                         |
+--------------------------------------------------------------------------------------+

That URL is live, HTTPS-terminated, and publicly routable the moment it prints.

Quick Tunnels vs Named Cloudflare Tunnels

Cloudflare offers two very different tunnel experiences, and conflating them causes confusion in production planning.

Feature	Quick Tunnel	Named Cloudflare Tunnel
Setup time	Seconds, zero config	Requires Cloudflare account + domain
URL	Random `trycloudflare.com` subdomain	Custom domain you control
Persistence	Ephemeral, dies when process stops	Persistent, survives restarts
Authentication	None	Cloudflare Access / Zero Trust policies
Use case	Demos, webhook testing, quick sharing	Production ingress, internal apps
Config file	Not needed	`config.yml` with ingress rules
DNS management	None	Managed via Cloudflare dashboard/API
Cost	Free, unlimited	Free tier available, scales with Zero Trust plan
Uptime guarantees	None — treat as disposable	Production-grade, designed for always-on services

If you need a stable URL for a webhook integration that lives for months, use a named tunnel. If you need to show a coworker a UI bug in the next five minutes, Quick Tunnels win every time.

Setting Up a Named Tunnel for Production Use

Since Quick Tunnels are explicitly not meant for anything long-lived, it's worth knowing the upgrade path. Named tunnels require a Cloudflare account with a zone (domain) added.

# Authenticate cloudflared with your Cloudflare account
cloudflared tunnel login

# Create a persistent named tunnel
cloudflared tunnel create my-app-tunnel

# Route a subdomain to the tunnel
cloudflared tunnel route dns my-app-tunnel app.yourdomain.com

Then define ingress rules in a config file:

# config.yml
tunnel: my-app-tunnel
credentials-file: /root/.cloudflared/<tunnel-id>.json

ingress:
  - hostname: app.yourdomain.com
    service: http://localhost:3000
  - service: http_status:404

Run it as a persistent process:

cloudflared tunnel run my-app-tunnel

This is the same underlying mechanism as Quick Tunnels — an outbound connection to Cloudflare's edge — but with a stable hostname, TLS cert managed automatically, and optional Zero Trust access policies layered on top.

Practical Use Case: Testing Webhooks Locally

Webhook-driven integrations (Stripe, GitHub, Twilio, Slack) are the single most common reason developers reach for tunneling tools. You can't register localhost as a webhook endpoint, so you need a public URL that forwards to your dev machine.

Here's a minimal Express server set up to receive a Stripe webhook, exposed via Quick Tunnel:

// server.js
import express from "express";

const app = express();
app.use(express.json());

app.post("/webhooks/stripe", (req, res) => {
  console.log("Received webhook event:", req.body.type);
  res.status(200).send("ok");
});

app.listen(3000, () => console.log("Listening on port 3000"));

node server.js
cloudflared tunnel --url http://localhost:3000

Take the printed trycloudflare.com URL, register it as your Stripe webhook endpoint (https://random-words.trycloudflare.com/webhooks/stripe), fire a test event from the Stripe dashboard, and watch it land in your terminal in real time. No deploy, no staging environment, no ngrok account wall.

Handling Restarts and URL Rotation

The catch with Quick Tunnels: every time you restart cloudflared, you get a new random URL. For long debugging sessions this is fine. For anything you need to reference repeatedly, script around it:

#!/bin/bash
# start-tunnel.sh
cloudflared tunnel --url http://localhost:3000 2>&1 | \
  grep --line-buffered "trycloudflare.com" | \
  tee tunnel-url.log

Or parse the URL programmatically in Node.js by spawning the process and reading stdout:

import { spawn } from "child_process";

const tunnel = spawn("cloudflared", ["tunnel", "--url", "http://localhost:3000"]);

tunnel.stderr.on("data", (data) => {
  const output = data.toString();
  const match = output.match(/https:\/\/[a-zA-Z0-9-]+\.trycloudflare\.com/);
  if (match) {
    console.log("Tunnel is live at:", match[0]);
    // e.g. auto-update webhook registration via API here
  }
});

This is exactly the kind of pattern you'd wire into a CI job that spins up an ephemeral preview environment and auto-registers it with a third-party service for integration testing.

Running Quick Tunnels Inside Docker

If your app is containerized, you can run cloudflared as a sidecar container without installing anything on the host.

# docker-compose.yml
version: "3.8"
services:
  app:
    build: .
    ports:
      - "3000:3000"

  tunnel:
    image: cloudflare/cloudflared:latest
    command: tunnel --url http://app:3000
    depends_on:
      - app

docker compose up
docker compose logs tunnel | grep trycloudflare.com

This pattern is useful for demoing a fully containerized stack to stakeholders without touching your cloud provider, and it keeps the tunnel's lifecycle tied to docker compose down — no orphaned processes hanging around exposing your machine after you've moved on.

Cloudflare Quick Tunnels vs ngrok vs localtunnel

Tool	Free tier limits	Custom domains	Setup friction	Persistent URLs	Notes
Cloudflare Quick Tunnel	Unlimited, no account	No (random subdomain)	Lowest — one binary, one command	No	Backed by Cloudflare's global edge
ngrok	Rate-limited, session caps	Paid only	Low, requires account + authtoken	Paid only	Rich dashboard, request replay
localtunnel	Unlimited but unreliable uptime	No	Very low, npm install	No	Community-run servers, frequent downtime
Cloudflare Named Tunnel	Unlimited	Yes, your own domain	Medium, requires zone setup	Yes	Best for production-grade exposure

For one-off sharing and webhook debugging, Quick Tunnels beat ngrok's free tier outright — no signup, no rate limiting on basic HTTP proxying, and it's backed by Cloudflare's infrastructure rather than a single relay server.

Security Considerations

Quick Tunnels expose whatever is running on that port to the entire internet the instant the tunnel is up. There's no authentication layer by default.

Never run a Quick Tunnel against a server with unauthenticated admin routes.
Add your own auth middleware before exposing anything beyond a static demo.
Treat the URL as effectively public even though it's hard to guess — bots do scan trycloudflare.com ranges.
For anything handling real user data or payment info, use a named tunnel with Cloudflare Access policies instead.

A minimal auth guard for a Node.js server you're about to tunnel:

app.use((req, res, next) => {
  const token = req.headers["x-tunnel-secret"];
  if (token !== process.env.TUNNEL_SECRET) {
    return res.status(401).send("Unauthorized");
  }
  next();
});

Troubleshooting Common Issues

Tunnel connects but requests time out: Check that your local service is actually bound to the port you passed to --url, and that it's listening on 0.0.0.0 or localhost, not restricted to an internal Docker network alias if you're running cloudflared outside the container.

"failed to sufficiently increase receive buffer size" warning: Harmless on most systems, but on Linux you can silence it by tuning net.core.rmem_max:

sudo sysctl -w net.core.rmem_max=2500000

WebSocket connections drop: Quick Tunnels support WebSockets out of the box, but double-check your local server explicitly upgrades connections and isn't blocking the Upgrade header behind a proxy layer you forgot about.

Random URL changes every restart: Expected behavior — this is a fundamental tradeoff of the "quick" tier. If it's a blocker, invest 15 minutes setting up a named tunnel instead.

Key Takeaways

Cloudflare Quick Tunnels expose localhost to a public HTTPS URL with a single cloudflared tunnel --url command — no account, no DNS, no config file.
They're ideal for webhook testing, live demos, and short-lived sharing sessions, not for production traffic.
URLs are randomly generated and ephemeral — they change on every restart, so don't hardcode them anywhere long-lived.
For persistent, branded URLs with authentication, upgrade to a named Cloudflare Tunnel with Zero Trust Access policies.
Quick Tunnels beat ngrok's free tier for basic HTTP exposure since there's no rate limiting or signup wall.
Run cloudflared as a Docker sidecar to tunnel containerized apps without installing anything on the host.
Always add your own authentication layer before exposing anything beyond a throwaway demo — Quick Tunnels have zero built-in access control.
The underlying mechanism (outbound-only connections to Cloudflare's edge) is the same tech that powers Cloudflare's production-grade Zero Trust tunneling, just without the persistence layer.

How GLM Built Its Own Inference Infrastructure: A Deep Dive for Backend Engineers

Aditya Rawas — Fri, 18 Sep 2026 07:37:32 +0000

Originally published at adityarawas.in

Most engineers reading about "AI inference infrastructure" skip straight past it, assuming it's ML research territory. It isn't. GLM's writeup on building its own inference stack is fundamentally a distributed systems and backend engineering story — request batching, connection pooling, load balancing, caching layers, and horizontal scaling under brutal latency constraints. If you build APIs in Go or Node.js, or you've fought with Docker and Kubernetes to keep p99 latency sane, this is your domain. Let's break down what GLM actually did and how the same patterns apply to systems you build every day.

Why Inference Infrastructure Is a Backend Problem, Not Just an ML Problem

Serving a large language model at scale looks less like "running a model" and more like operating a high-throughput, stateful API gateway with wildly uneven request costs. A prompt with 50 tokens and one with 8,000 tokens hit your compute budget completely differently — there's no fixed-cost request like a typical REST endpoint.

GLM's core challenge mirrors what you'd face building any large-scale service:

Variable request cost — similar to file uploads vs. simple GET requests, but the variance is 100x-1000x
Stateful sessions — KV cache persistence across a conversation, similar to session affinity in load balancers
Batching under latency pressure — grouping requests without blowing SLAs, like Kafka consumer batching
Heterogeneous hardware pools — GPUs of different generations, similar to mixed EC2 instance fleets

If you've tuned a Node.js connection pool or written a custom Go load balancer, you already have the mental model. The complexity is in the constraints, not the concepts.

The Core Architecture: Prefill/Decode Separation

The single biggest architectural decision GLM made — and one that's become industry standard — is splitting inference into two distinct phases handled by separate compute pools:

Prefill Phase

Processing the input prompt. This is compute-bound and highly parallelizable — think of it like a batch job that chews through all input tokens at once to build the initial KV cache.

Decode Phase

Generating output tokens one at a time, autoregressively. This is memory-bandwidth-bound, not compute-bound. Each step depends on the previous token, so it can't be parallelized the same way.

Request Lifecycle:
  Client → API Gateway → Router
                            │
                ┌───────────┴───────────┐
                ▼                       ▼
         Prefill Pool             Decode Pool
      (compute-optimized)    (memory-bandwidth-optimized)
                │                       │
                └──────► KV Cache ◄─────┘
                      (shared/transferred)

Why does this matter to you as a backend engineer? Because it's the same pattern as separating your write path from your read path in a database architecture — different bottlenecks require different scaling strategies. GLM scales prefill and decode pools independently based on their respective load characteristics, exactly how you'd separate a CPU-bound image resizing service from an I/O-bound API gateway.

Request Batching: The Real Performance Lever

Here's where it gets interesting for anyone who has written a batching layer in Node.js or Go. GLM implements continuous batching, which dynamically adds and removes requests from an in-flight batch instead of waiting for a fixed batch window.

A naive batching implementation (the kind you'd reach for first) looks like this:

// Naive fixed-window batching - what NOT to do at scale
class NaiveBatcher {
  constructor(batchSize = 32, maxWaitMs = 50) {
    this.queue = [];
    this.batchSize = batchSize;
    this.maxWaitMs = maxWaitMs;
  }

  async enqueue(request) {
    return new Promise((resolve) => {
      this.queue.push({ request, resolve });
      if (this.queue.length >= this.batchSize) {
        this.flush();
      } else if (this.queue.length === 1) {
        setTimeout(() => this.flush(), this.maxWaitMs);
      }
    });
  }

  flush() {
    const batch = this.queue.splice(0, this.batchSize);
    processBatch(batch); // one-shot, blocks until all done
  }
}

The problem: a single long-running request in the batch holds up every other request until it finishes. GLM's continuous batching approach instead treats each generation step as an insertion/eviction point — a request that finishes early frees its slot immediately for a new one, rather than waiting for the whole batch to complete.

// Simplified continuous batching scheduler in Go
type InferenceSlot struct {
    RequestID string
    KVCache   *KVCacheHandle
    Done      bool
}

type Scheduler struct {
    mu       sync.Mutex
    slots    []*InferenceSlot
    maxSlots int
    pending  chan *Request
}

func (s *Scheduler) Step() {
    s.mu.Lock()
    defer s.mu.Unlock()

    // Evict completed slots, backfill from pending queue
    for i, slot := range s.slots {
        if slot.Done {
            select {
            case next := <-s.pending:
                s.slots[i] = newSlot(next)
            default:
                s.slots[i] = nil
            }
        }
    }
    s.runDecodeStepOnActiveSlots()
}

This is directly analogous to how a well-tuned Go worker pool should reclaim goroutines the instant a task finishes rather than draining fixed-size batches — the difference between throughput-optimized and latency-optimized systems.

Caching: KV Cache Is Just a Specialized LRU

GLM's infrastructure leans heavily on KV cache reuse — avoiding recomputation of the prefill phase when a conversation continues with the same prefix. If you've built a caching layer with Redis, this concept transfers almost directly.

Traditional Web Cache	LLM KV Cache
Keyed by URL/query hash	Keyed by token prefix hash
Stores rendered response	Stores attention key/value tensors
Evicted via LRU/TTL	Evicted via LRU + memory pressure
Lives in Redis/Memcached	Lives in GPU HBM, offloaded to CPU RAM/disk
Cache hit = skip DB query	Cache hit = skip prefill compute
Invalidated on data change	Invalidated when conversation diverges

GLM implements prefix caching — if two requests share the same system prompt or conversation history, the KV cache for that shared prefix is reused instead of recomputed. This is exactly like caching a partially-rendered template fragment.

// Conceptual prefix cache lookup — same pattern as HTTP cache middleware
function getCachedPrefix(conversationHistory, cacheStore) {
  const prefixHash = hashTokens(conversationHistory);
  const cached = cacheStore.get(prefixHash);

  if (cached) {
    return { kvCache: cached.kvCache, startToken: cached.length };
  }
  return { kvCache: null, startToken: 0 };
}

The eviction policy GLM describes — combining recency with memory pressure across GPU tiers — is functionally an LRU cache with tiered storage, the same pattern CDNs use for hot/warm/cold object storage.

Load Balancing Across a Heterogeneous GPU Fleet

Standard round-robin load balancing fails badly for inference because requests aren't uniform cost. GLM's routing layer factors in:

Current KV cache occupancy per node
Queue depth per node
Request's estimated context length
Whether the node already holds a cached prefix for this session

This is essentially consistent hashing with load awareness — similar to what you'd build with a custom nginx upstream selector or a service mesh's weighted routing, except the weights are computed dynamically from real-time GPU memory state rather than static config.

# Analogous concept in traditional infra: least-connections + sticky sessions
upstream inference_pool {
    least_conn;
    server node1.internal:8080 max_fails=3;
    server node2.internal:8080 max_fails=3;
    sticky cookie srv_id expires=1h;
}

GLM's router does this at a finer grain — per-request, factoring in cache locality — which is closer to how Kubernetes' topology-aware routing or a custom gRPC client-side load balancer with health-aware weights would behave.

Networking: Why gRPC and Custom Protocols Win

For inter-node communication (transferring KV cache between prefill and decode pools), GLM avoids REST/JSON entirely. The overhead of JSON serialization for multi-gigabyte tensor transfers would be disastrous. Instead, this space consistently uses:

RDMA / InfiniBand for GPU-to-GPU transfer where available
gRPC with protobuf for control-plane messages (scheduling, health checks)
Custom binary protocols for KV cache serialization

If you're building Node.js or Go microservices and still default to JSON REST for internal service-to-service communication, this is the reminder that protocol choice matters as data volume grows. The same principle that makes protobuf preferable to JSON for a 50KB payload becomes an absolute requirement at gigabyte scale.

// gRPC service definition style used for control-plane in inference systems
service SchedulerService {
  rpc RegisterNode(NodeInfo) returns (RegisterAck);
  rpc RequestSlot(SlotRequest) returns (SlotAssignment);
  rpc ReportHealth(HealthPing) returns (HealthAck);
}

message SlotAssignment {
  string node_id = 1;
  int32 slot_index = 2;
  bytes kv_cache_handle = 3;
}

Autoscaling: Beyond CPU/Memory Metrics

Standard Kubernetes HPA scales on CPU/memory utilization. That metric is nearly useless for inference workloads, where GPU memory occupancy and queue depth matter far more. GLM's infrastructure uses custom metrics for scaling decisions — a pattern directly portable to any Docker/Kubernetes deployment running specialized workloads.

# Kubernetes HPA with custom metrics (Prometheus adapter)
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: inference-decode-pool
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: decode-pool
  minReplicas: 4
  maxReplicas: 64
  metrics:
    - type: Pods
      pods:
        metric:
          name: gpu_memory_occupancy_percent
        target:
          type: AverageValue
          averageValue: "80"
    - type: Pods
      pods:
        metric:
          name: request_queue_depth
        target:
          type: AverageValue
          averageValue: "10"

This is the exact pattern you'd use scaling a Node.js service on event loop lag instead of CPU percentage, or scaling a Go service on channel backlog depth instead of generic memory usage. Custom metrics beat generic resource metrics whenever your bottleneck isn't the generic resource.

Comparison: Inference Infra Patterns vs. Standard Backend Patterns

Inference Infra Concept	Standard Backend Equivalent
Prefill/decode separation	Read/write path separation
Continuous batching	Dynamic worker pool with slot reclaim
KV cache / prefix caching	Redis/CDN caching with LRU eviction
Cache-aware load balancing	Consistent hashing + sticky sessions
GPU memory occupancy scaling	Custom-metric HPA (queue depth, lag)
RDMA/gRPC binary transfer	Protobuf over gRPC for internal RPC
Node health/queue depth routing	Weighted least-connections LB
Speculative decoding	Optimistic concurrency / prefetching

Applying These Patterns Without Building an LLM Stack

You don't need GPUs to benefit from this. Any system with high request-cost variance benefits from the same architecture:

// Example: applying prefill/decode-style separation to a document processing API
// "Prefill" = parsing/OCR (compute-bound, parallelizable)
// "Decode" = incremental summarization (sequential, memory-bound)

async function processDocument(doc) {
  const parsed = await parsePool.submit(doc);       // scales on CPU
  const summary = await summarizePool.submit(parsed); // scales on model calls/sec
  return summary;
}

The mental shift is: stop treating your service as one monolithic scaling unit. Profile which phase of a request is bottlenecked by what resource, split it into its own pool, and scale each pool on the metric that actually reflects its bottleneck.

Key Takeaways

Prefill/decode separation is a general pattern — split compute-bound and memory-bound phases of any pipeline into independently scaled pools.
Continuous batching beats fixed-window batching whenever request duration varies significantly; reclaim slots the instant they free up.
KV cache is architecturally identical to LRU + tiered storage caching you already know from Redis/CDN design — prefix hashing enables reuse across requests.
Load balancing under variable request cost needs real-time state awareness (queue depth, cache locality), not simple round-robin.
Internal service communication should move to gRPC/protobuf or binary protocols once payload size or frequency makes JSON overhead measurable.
Autoscale on the metric

CUDA for Rust: A Practical Guide to Nvidia's Native GPU Programming Support

Aditya Rawas — Thu, 17 Sep 2026 07:00:09 +0000

Originally published at adityarawas.in

Nvidia just gave systems programmers a reason to care about Rust beyond web servers and CLI tools. The announcement of native GPU programming support in Rust — dubbed the "two tracks" approach for writing CUDA kernels — signals that Nvidia is done treating Rust as a third-party curiosity and is now investing in first-class tooling. If you've ever fought with unsafe blocks in rust-cuda community crates or dealt with brittle FFI bindings to C++ CUDA code, this changes the calculus significantly.

This is a big deal for anyone building GPU-accelerated infrastructure — ML training pipelines, data processing engines, or custom inference servers — who wants memory safety without giving up raw throughput. Let's break down what actually changed, how it compares to the existing C++/CUDA workflow, and how to get a kernel running today.

What Nvidia Actually Announced

Nvidia's "two tracks" strategy refers to two distinct ways developers can now write GPU kernels in Rust:

Track One — CUDA Rust (low-level): A near-1:1 mapping to CUDA C++ semantics, giving you direct control over thread blocks, shared memory, warps, and memory coalescing. Think of this as "Rust wearing a CUDA C++ trench coat" — same mental model, safer syntax.
Track Two — High-level GPU abstractions: A more ergonomic, iterator-style API (similar to rayon for CPU parallelism) that compiles down to efficient kernels without requiring you to manually manage grid/block dimensions for every operation.

This dual approach mirrors how Rust itself handles systems programming: you can drop into unsafe for full control, or stay in safe, ergonomic Rust for 90% of your code. Nvidia is explicitly targeting both the performance-obsessed kernel author and the application developer who just wants GPU acceleration without becoming a CUDA architecture expert.

Why This Matters Now

For the last decade, GPU programming in Rust meant relying on community projects:

rust-cuda (via ptx-builder and nvptx64-nvidia-cuda target)
wgpu for cross-platform compute shaders
cudarc for safer FFI bindings to the CUDA driver API

These worked, but none had Nvidia's official backing, meaning no guaranteed compatibility with new CUDA toolkit releases, no first-party debugging tools (cuda-gdb, nsight), and constant risk of breakage across driver updates. Official support means Rust kernels get the same tooling maturity C++ has enjoyed since CUDA's inception in 2007.

CUDA C++ vs CUDA Rust: A Practical Comparison

Before jumping into code, it's worth understanding where Rust actually helps and where it doesn't.

Aspect	CUDA C++	CUDA Rust
Memory safety	Manual, no compiler guarantees	Borrow checker prevents data races in host code
Kernel launch syntax	`<<<blocks, threads>>>` macro syntax	Explicit function calls with typed launch configs
Build tooling	`nvcc` + Makefiles/CMake	`cargo` + `rustc` with PTX backend
Error handling	Manual `cudaError_t` checks	`Result<T, CudaError>` with `?` operator
Package management	vcpkg/Conan (fragmented)	Cargo (unified, mature ecosystem)
Debugging tools	`cuda-gdb`, Nsight (mature)	Nsight support in progress, PTX-level debugging works
Learning curve	Steep — manual memory management everywhere	Moderate — safety rails reduce common bugs
FFI interop with C++ CUDA libs	Native	Requires `bindgen` or `cxx` crate
Community crates ecosystem	Massive (cuDNN, cuBLAS, Thrust)	Growing, some gaps remain
Compile-time kernel verification	Limited	Stronger — type system catches more at compile time

The takeaway: Rust doesn't make your kernels magically faster. The GPU doesn't care what language emitted the PTX. What Rust buys you is fewer footguns on the host side — the code managing memory allocation, kernel launches, and data transfer between host and device, which is historically where most CUDA bugs live (use-after-free on device pointers, mismatched grid dimensions, forgotten cudaFree calls).

Setting Up Your First CUDA Rust Kernel

Here's a minimal walkthrough assuming Nvidia's tooling is installed alongside the standard CUDA Toolkit.

Prerequisites

# Install the nightly toolchain (required for GPU codegen features)
rustup toolchain install nightly
rustup component add rust-src --toolchain nightly

# Add the CUDA target
rustup target add nvptx64-nvidia-cuda

# Verify CUDA toolkit is present
nvcc --version

Project Structure

gpu-vector-add/
├── Cargo.toml
├── build.rs
├── src/
│   ├── main.rs        # host code
│   └── kernel.rs       # device code compiled to PTX

Writing the Kernel (Track One — Low-Level)

// src/kernel.rs
#![no_std]
#![feature(abi_ptx)]

use core::arch::nvptx;

#[no_mangle]
pub unsafe extern "ptx-kernel" fn vector_add(
    a: *const f32,
    b: *const f32,
    c: *mut f32,
    n: i32,
) {
    let idx = nvptx::_thread_idx_x() + nvptx::_block_idx_x() * nvptx::_block_dim_x();
    if idx < n {
        let i = idx as usize;
        *c.add(i) = *a.add(i) + *b.add(i);
    }
}

This looks almost identical to the equivalent CUDA C++ kernel — that's intentional. Track One prioritizes familiarity for engineers porting existing CUDA codebases.

// Equivalent CUDA C++ for comparison
__global__ void vector_add(const float* a, const float* b, float* c, int n) {
    int idx = threadIdx.x + blockIdx.x * blockDim.x;
    if (idx < n) {
        c[idx] = a[idx] + b[idx];
    }
}

Host Code to Launch the Kernel

// src/main.rs
use cust::prelude::*;
use std::error::Error;

fn main() -> Result<(), Box<dyn Error>> {
    let _ctx = cust::quick_init()?;

    let ptx = include_str!(concat!(env!("OUT_DIR"), "/kernel.ptx"));
    let module = Module::from_ptx(ptx, &[])?;
    let stream = Stream::new(StreamFlags::NON_BLOCKING, None)?;

    let n = 1_000_000;
    let a: Vec<f32> = (0..n).map(|x| x as f32).collect();
    let b: Vec<f32> = (0..n).map(|x| (x * 2) as f32).collect();

    let d_a = a.as_slice().as_dbuf()?;
    let d_b = b.as_slice().as_dbuf()?;
    let mut d_c = DeviceBuffer::<f32>::zeroed(n)?;

    let func = module.get_function("vector_add")?;
    let (grid, block) = (256, 1024);

    unsafe {
        launch!(func<<<grid, block, 0, stream>>>(
            d_a.as_device_ptr(),
            d_b.as_device_ptr(),
            d_c.as_device_ptr(),
            n as i32
        ))?;
    }

    stream.synchronize()?;

    let mut result = vec![0f32; n];
    d_c.copy_to(&mut result)?;

    println!("First 5 results: {:?}", &result[..5]);
    Ok(())
}

Notice the Result propagation with ? — every CUDA API call that could fail returns a typed error instead of a raw cudaError_t you have to remember to check. This alone eliminates a huge class of silent failures in production ML pipelines.

Track Two — The High-Level Abstraction

For teams that don't need warp-level control, Nvidia's ergonomic API looks closer to this:

use gpu_compute::prelude::*;

fn main() -> GpuResult<()> {
    let device = GpuDevice::default()?;

    let a = device.upload(&vec![1.0f32; 1_000_000])?;
    let b = device.upload(&vec![2.0f32; 1_000_000])?;

    let c = a.zip(b).map(|(x, y)| x + y).collect(&device)?;

    println!("Sum computed on GPU, first value: {}", c[0]);
    Ok(())
}

No grid/block math, no manual PTX compilation step, no explicit stream synchronization. This is the track most application developers will actually use — think of it as rayon, but the work executes on the GPU instead of CPU threads.

Build Configuration

Cross-compiling to PTX requires a build script to invoke the nightly compiler with the correct target:

// build.rs
use std::process::Command;

fn main() {
    let out_dir = std::env::var("OUT_DIR").unwrap();

    let status = Command::new("cargo")
        .args([
            "+nightly", "rustc",
            "--release",
            "--target", "nvptx64-nvidia-cuda",
            "-p", "kernel",
            "--", "-Z", "build-std=core",
        ])
        .status()
        .expect("failed to build PTX kernel");

    assert!(status.success());
    println!("cargo:rerun-if-changed=src/kernel.rs");
    println!("cargo:rustc-env=OUT_DIR={}", out_dir);
}

# Cargo.toml
[dependencies]
cust = "0.3"

[build-dependencies]

Performance Considerations

Rust's zero-cost abstractions theoretically hold on GPU targets, but there are real caveats:

Register pressure: Rust's iterator chains in Track Two can generate more instructions than hand-tuned CUDA C++ if the compiler fails to fully inline and unroll loops. Always profile with nsight-compute before assuming parity.
Shared memory access: Track One gives you the same __shared__ semantics via nvptx intrinsics, but the ergonomics are rougher — expect more unsafe blocks than idiomatic Rust elsewhere.
Warp divergence: Same rules apply as C++ CUDA. Rust's type system won't save you from writing branch-heavy kernels that stall warps.
Occupancy tuning: Grid/block sizing still requires manual tuning based on your GPU's SM count and register file size — no language abstracts this away yet.

# Profile your kernel exactly like you would with CUDA C++
ncu --set full ./target/release/gpu-vector-add
nsys profile --stats=true ./target/release/gpu-vector-add

Where This Fits in a Real Stack

If you're running inference servers or data pipelines in Go or Node.js, the practical integration pattern looks like this:

// Go service calling into a Rust CUDA library via FFI
package main

/*
#cgo LDFLAGS: -L./target/release -lgpu_kernels
#include "gpu_kernels.h"
*/
import "C"
import "fmt"

func main() {
    result := C.run_vector_add()
    fmt.Println("GPU computation triggered from Go:", result)
}

Compile the Rust crate as a cdylib, expose a C ABI with #[no_mangle] extern "C", and you get GPU acceleration in services that otherwise have no business touching CUDA directly. This is the same pattern teams have used for years with C++ CUDA libraries — now with a safer implementation underneath.

Common Pitfalls

Forgetting #![no_std] in kernel code — the device target has no OS, no heap allocator by default, and no standard library support for most std types.
Mismatched PTX versions — kernels compiled with a newer nvptx64-nvidia-cuda target than your installed driver supports will fail at runtime with an opaque CUDA_ERROR_INVALID_PTX.
Assuming safe Rust everywhere — kernel entry points and raw pointer arithmetic inside __global__-equivalent functions require unsafe. The safety guarantees mostly benefit host-side orchestration code.
Ignoring stream synchronization — async kernel launches without proper stream.synchronize() calls will silently read stale device buffers, a bug that's just as easy to introduce in Rust as C++.

Key Takeaways

Nvidia's "two tracks" approach gives you low-level CUDA C++-equivalent control (Track One) and a high-level ergonomic API (Track Two) — pick based on whether you need warp-level tuning or just GPU-accelerated data pipelines.
CUDA Rust doesn't make kernels inherently faster than C++; PTX is PTX regardless of source language. The win is safer host-side memory and error handling.
The cust crate plus official Nvidia tooling replaces fragmented community solutions like rust-cuda and manual bindgen FFI bridges.
You still need `unsafe

Java 27 Explained: New Features, JVM Changes, and What It Means for Backend Developers

Aditya Rawas — Wed, 16 Sep 2026 07:59:09 +0000

Originally published at adityarawas.in

Java 27 shipped this week, and if you've spent the last few years building on Node.js or Go while watching Java from a distance, this release is worth a second look. The JVM has quietly become one of the fastest-moving runtimes in the industry — six-month release cadence, aggressive feature previews, and a garbage collector that no longer makes anyone nervous about pause times. This isn't your enterprise-Java-from-2015 story anymore.

This deep-dive breaks down what actually changed in Java 27, why it matters if you're running polyglot infrastructure with Node.js or Go services, and how to think about JVM-based backends in a Docker-first, cloud-native world.

What's Actually New in Java 27

Java follows a strict six-month release train (March and September each year), and Java 27 is the September 2026 release. Unlike LTS releases (21, 25), Java 27 is a short-term feature release — but it's where the interesting previews graduate before landing in the next LTS (Java 29, expected 2028).

Structured Concurrency Goes Final

After multiple preview rounds since Java 21, Structured Concurrency (JEP scope, finalized in 27) is no longer a preview feature. This is arguably the biggest deal in the release.

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    Supplier<User> userTask = scope.fork(() -> fetchUser(userId));
    Supplier<List<Order>> ordersTask = scope.fork(() -> fetchOrders(userId));

    scope.join();
    scope.throwIfFailed();

    return new UserProfile(userTask.get(), ordersTask.get());
}

Compare this to how you'd write the equivalent in Node.js:

const [user, orders] = await Promise.all([
  fetchUser(userId),
  fetchOrders(userId),
]);

Node's Promise.all has always made concurrent I/O trivial. Java's problem was never expressing concurrency — it was managing the lifecycle and error propagation of concurrent tasks cleanly. Structured concurrency finally gives Java a scoped, cancellation-aware model that doesn't leak threads when one branch fails. If you've dealt with orphaned threads in a CompletableFuture chain, you'll appreciate this.

Virtual Threads Are Now the Default for Executors

Virtual threads (Project Loom) became stable in Java 21, but Java 27 makes Executors.newVirtualThreadPerTaskExecutor() the recommended default for most server frameworks, including Spring Boot 4.x and Micronaut. The practical effect: you can write blocking-style code that scales like async code.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    IntStream.range(0, 10_000).forEach(i ->
        executor.submit(() -> handleRequest(i))
    );
}

Ten thousand virtual threads cost you kilobytes, not megabytes. This directly attacks the reason people reached for Node.js's event loop or Go's goroutines in the first place — thread-per-request without the memory tax.

Pattern Matching for `switch` Gets Deconstruction Patterns

Record patterns now support nested deconstruction in switch, finalized after being in preview since Java 21/22.

record Point(int x, int y) {}
record Line(Point start, Point end) {}

static String describe(Object shape) {
    return switch (shape) {
        case Line(Point(var x1, var y1), Point(var x2, var y2))
            when x1 == x2 -> "vertical line";
        case Line l -> "diagonal or horizontal line";
        default -> "unknown shape";
    };
}

This is Java catching up to destructuring patterns TypeScript developers take for granted, but with exhaustiveness checking baked into the compiler.

ZGC Becomes Fully Generational and Default for Most Workloads

The Z Garbage Collector's generational mode (introduced in 21) is now the default GC for new applications without explicit configuration. Sub-millisecond pause times regardless of heap size are no longer an opt-in feature — they're the baseline.

# Java 27 — no flags needed for generational ZGC
java -jar app.jar

# Java 21 — required explicit opt-in
java -XX:+UseZGC -XX:+ZGenerational -jar app.jar

For teams running Java in Kubernetes with tight memory limits, this matters more than any language feature.

Java 27 vs Node.js vs Go: A Backend Engineer's Comparison

Aspect	Java 27	Node.js 22+	Go 1.23+
Concurrency model	Virtual threads + structured concurrency	Single-threaded event loop + worker threads	Goroutines + channels
Startup time	Slower (JVM warmup, improving with CDS/AppCDS)	Fast	Fastest
Memory footprint	Higher baseline, improved by ZGC	Low-moderate	Very low
Type system	Static, nominal, pattern matching	Dynamic (TS adds static layer)	Static, structural
GC pause times	Sub-ms with generational ZGC	N/A (V8 GC, generally fine)	Sub-ms, simple GC
Container image size	Larger, mitigated by jlink custom runtimes	Small (Alpine-based)	Smallest (static binaries)
Ecosystem maturity	Extremely mature (Spring, Micronaut, Quarkus)	Mature, fragmented	Mature, opinionated
Best fit	Large enterprise systems, long-lived services	I/O-heavy APIs, real-time apps	Infra tooling, CLIs, microservices

The takeaway isn't "Java wins" or "Go wins" — it's that Java 27 closes the gap on concurrency ergonomics and memory efficiency that used to be Go and Node's biggest advantages.

Running Java 27 in Docker: A Practical Setup

If you're deploying Java 27 services alongside your Node.js and Go microservices, container size and startup time are where Java traditionally loses. Java 27 with jlink custom runtimes closes that gap significantly.

# Stage 1: Build a custom minimal JRE
FROM eclipse-temurin:27-jdk-alpine AS jlink
WORKDIR /app
COPY . .
RUN jlink \
    --add-modules java.base,java.net.http,java.sql \
    --strip-debug \
    --no-man-pages \
    --no-header-files \
    --compress=2 \
    --output /custom-jre

# Stage 2: Minimal runtime image
FROM alpine:3.20
COPY --from=jlink /custom-jre /opt/jre
COPY --from=jlink /app/target/app.jar /app/app.jar
ENV PATH="/opt/jre/bin:${PATH}"
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

This custom-JRE approach can shrink a 300MB+ base image down to 60-80MB, comparable to a typical Node.js Alpine image and much closer to Go's static binary footprint.

Enabling Class Data Sharing for Faster Cold Starts

Cold start time is Java's Achilles heel in serverless and autoscaling environments. AppCDS (Application Class Data Sharing) mitigates this significantly in Java 27:

# Generate the CDS archive during build
java -XX:ArchiveClassesAtExit=app.jsa -jar app.jar

# Use it at runtime
java -XX:SharedArchiveFile=app.jsa -jar app.jar

In practice, this can cut startup time by 30-40% — meaningful if you're running Java in Kubernetes with horizontal pod autoscaling and expect pods to come up quickly under load.

Migration Considerations from Java 21/25 LTS

If you're on Java 21 LTS (the current dominant production version), moving to Java 27 isn't mandatory since it's not an LTS release. But there are reasons to track it:

Preview feature stabilization — features you might be using with --enable-preview flags in 21 or 25 are now stable in 27, meaning you can drop those flags.
Spring Boot and Quarkus alignment — major frameworks typically ship compatibility updates targeting the newest non-LTS release to test forward compatibility before the next LTS.
Deprecation cleanup — Java 27 removes several APIs deprecated since Java 9 (notably remnants of the old Security Manager and some legacy java.rmi internals). Run your test suite with --release 27 before committing.

# Check compilation compatibility against Java 27 without switching runtimes
javac --release 27 -Xlint:all Main.java

For teams not ready to move off Java 21 LTS, the pragmatic path is to track Java 27 in a staging environment, validate framework compatibility, and wait for Java 29 LTS in 2028 for production migration.

Why This Matters Beyond the JVM Ecosystem

Even if you never touch Java, this release is a signal worth reading. The industry-wide trend — Go's goroutines, Node's async/await, Java's virtual threads, even Rust's async runtimes — is converging on the same idea: make concurrency cheap and structured, and let developers write straight-line code.

Java 27 proves that a 30-year-old, historically verbose language can modernize its concurrency model without breaking backward compatibility — something JavaScript's ecosystem has struggled with (see: the CommonJS/ESM split) and Go has mostly avoided by being younger and more disciplined from day one.

If you're architecting a polyglot system — Go for infra tooling, Node for edge APIs, Java for core business logic — Java 27's improvements mean you can lean on the JVM for high-throughput, long-lived services without the historical memory and startup-time penalties.

Key Takeaways

Java 27 finalizes Structured Concurrency, giving the JVM a scoped, cancellation-safe concurrency model comparable in ergonomics to Promise.all in Node.js.
Virtual threads are now the recommended executor default, letting you write blocking-style code that scales to tens of thousands of concurrent tasks with minimal memory overhead.
Generational ZGC is the default garbage collector, delivering sub-millisecond pause times without manual JVM tuning.
Pattern matching with record deconstruction in switch brings Java closer to TypeScript-style destructuring, with compiler-enforced exhaustiveness.
Docker image sizes for Java services can shrink dramatically using jlink custom runtimes — from 300MB+ down to 60-80MB.
AppCDS cuts cold-start times by 30-40%, addressing Java's biggest weakness versus Go and Node in autoscaling environments.
Java 27 is not LTS — track it in staging, but plan production migrations around Java 29 LTS in 2028.
The broader trend across Java, Go, and Node.js is convergence: cheap, structured concurrency primitives that let developers write simple, straight-line code for complex I/O workloads.

RubyGems Supply Chain Vulnerability: What the OpenAI Bot Incident Teaches About Node.js and npm Security

Aditya Rawas — Tue, 15 Sep 2026 02:18:29 +0000

Originally published at adityarawas.in

A caching bug in RubyGems sat quietly in production infrastructure until OpenAI's crawler bots stumbled into it while indexing package metadata. The bots didn't exploit it — they just triggered enough unusual traffic patterns that someone noticed the cache was serving stale, potentially poisoned package data to legitimate gem install requests. That's the kind of story that should make every Node.js and npm maintainer sit up, because the underlying failure mode — trusting a package registry's caching layer without verifying integrity end-to-end — is not a Ruby problem. It's a package manager problem, and npm has had its own version of this fire drill more than once.

This post breaks down what actually happened with the RubyGems caching vulnerability, why it matters even if you've never written a line of Ruby, and what concrete steps you should be taking right now to harden your Node.js supply chain against the same class of bug.

What Happened with RubyGems

The short version: RubyGems runs a CDN-backed caching layer in front of its package index to handle the volume of gem install and bundle install requests hitting the registry every second. Caching layers like this are standard — npm, PyPI, and crates.io all do something similar. The problem was a cache-key collision bug that could cause the CDN to serve one package's metadata (or in some edge cases, gem contents) for a request meant for a different package or version.

Under normal traffic, this bug was rare enough to go unnoticed. It took the unusual, high-frequency, pattern-heavy request behavior of OpenAI's bots — which were scraping gem metadata for training or indexing purposes — to expose the cache poisoning at scale. Tenderlove's writeup describes discovering mismatched gemspecs being served under the wrong package names, which is about as close to a worst-case supply chain scenario as you can get without an actual malicious actor involved.

No evidence surfaced that this was exploited maliciously before discovery. But the mechanism was there: an attacker who understood the cache-key logic could have engineered collisions deliberately, poisoning the cache so that a popular gem name resolved to attacker-controlled code for some subset of installs.

Why This Isn't a "Ruby Problem"

Every language ecosystem with a centralized package registry and a CDN cache in front of it has this exact attack surface. The RubyGems team happened to get lucky — a benign, high-volume crawler exposed the bug before someone weaponized it. npm has no structural immunity here. The npm registry (registry.npmjs.org) sits behind Cloudflare, and cache-key logic bugs are a class of vulnerability, not a one-off Ruby mistake.

How This Maps to the npm Ecosystem

npm has already dealt with adjacent issues — typosquatting, dependency confusion, and compromised maintainer accounts pushing malicious versions. A caching layer bug would be a new vector on top of an already crowded threat model. Here's the comparison of attack classes you should have on your radar:

Attack Vector	Mechanism	Real-World Precedent	Primary Defense
Cache poisoning	CDN serves wrong package metadata/tarball for a request	RubyGems 2026 incident	Subresource integrity checks, lockfile hashes
Dependency confusion	Public package name shadows internal private package	2021 npm dependency confusion attacks	Scoped packages, registry allowlists
Typosquatting	Malicious package with name similar to popular one	`crossenv` vs `cross-env`	Manual review, automated name-similarity scanning
Maintainer account takeover	Compromised credentials push malicious version	`event-stream`, `ua-parser-js` incidents	2FA enforcement, provenance attestation
Post-install script abuse	Malicious `postinstall` runs arbitrary code	Countless npm incidents	`--ignore-scripts`, sandboxed CI

Cache poisoning is the least understood of these because it doesn't require compromising a maintainer or publishing a malicious package at all. It exploits infrastructure you don't control and can't audit directly.

Verifying Package Integrity in npm Right Now

The good news: npm already has tooling to mitigate exactly this class of bug, and most teams aren't using it correctly.

Lockfile Integrity Hashes

Every entry in package-lock.json (or pnpm-lock.yaml, or yarn.lock) includes an integrity hash — a SHA-512 checksum of the exact tarball npm expects to install.

"node_modules/lodash": {
  "version": "4.17.21",
  "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
  "integrity": "sha512-v2kDEe57lecTulaDIuNTPy3Ry4//eEeLnUdyaP7ARaJd6BwQNCoQcJqp8jVXasjrgFwtNs2mAAAoyaJ1TVQMHA=="
}

If a CDN cache poisoning bug served a different tarball than expected, npm's install process would catch the mismatch as long as you're actually installing from a lockfile with npm ci rather than npm install.

# Vulnerable to silent resolution drift
npm install

# Enforces lockfile integrity, fails hard on mismatch
npm ci

npm ci refuses to modify the lockfile and validates every downloaded package against its recorded hash. If a cache poisoning bug served the wrong tarball, npm ci would throw an integrity error instead of silently installing malicious code. This is table stakes for CI/CD pipelines and shouldn't be optional.

Auditing What's Actually Installed

npm audit --audit-level=high
npm audit signatures

npm audit signatures (available since npm 9.5) verifies package provenance signatures against the registry's public key, which is a direct defense against exactly the kind of cache-serving-wrong-content scenario RubyGems hit.

Enforcing Provenance

npm's provenance feature ties published packages to their build origin using Sigstore, generating a cryptographically verifiable attestation that a package was built from a specific commit in a specific CI pipeline.

npm publish --provenance

As a consumer, you can check whether a dependency has provenance attached:

npm view <package-name> --json | jq '.dist.attestations'

If more of the ecosystem adopted this, cache poisoning attacks become far less useful — an attacker could serve a poisoned tarball, but it wouldn't carry a valid provenance attestation, and tooling could flag the mismatch automatically.

Hardening Your CI/CD Pipeline

Assume for a moment that npm's registry cache has the exact same class of bug RubyGems just found. What would actually stop it from biting you in production?

1. Pin Exact Versions, Not Ranges

{
  "dependencies": {
    "express": "4.19.2"
  }
}

Not ^4.19.2, not ~4.19.2. Exact pinning combined with lockfile integrity checks closes the gap where a cache bug resolves a version range to unexpected content.

2. Use a Private Registry Proxy

Tools like Verdaccio, Artifactory, or Nexus let you cache and vet packages internally instead of hitting the public registry cache directly on every CI run.

# .npmrc pointing at an internal proxy
registry=https://npm.yourcompany.com/
always-auth=true

This doesn't eliminate the upstream cache risk, but it gives you a control point where you can pin known-good tarball hashes independently of npm's own CDN behavior.

3. Disable Lifecycle Scripts in CI

npm ci --ignore-scripts

Cache poisoning combined with a malicious postinstall script is the nightmare scenario — arbitrary code execution during install, triggered by a supply chain bug you had no way to detect. Disabling scripts in CI (and running them explicitly, audited, only when needed) closes that door.

4. Automate Dependency Diffing

npm diff --diff=package-lock.json --diff=package-lock.json.new

Or use lockfile-lint:

npx lockfile-lint --path package-lock.json \
  --allowed-hosts npm \
  --validate-https \
  --validate-integrity

This catches unexpected registry URLs, protocol downgrades, or missing integrity fields — exactly the artifacts a cache poisoning attack would leave behind.

Detecting Anomalies Like OpenAI's Bots Did (By Accident)

The RubyGems bug was found because unusual bot traffic patterns surfaced inconsistent responses. You can build similar detection into your own dependency pipeline without needing a crawler bot to stumble into it for you.

// scripts/verify-lockfile-integrity.js
const fs = require('fs');
const crypto = require('crypto');
const https = require('https');

function fetchTarball(url) {
  return new Promise((resolve, reject) => {
    https.get(url, (res) => {
      const chunks = [];
      res.on('data', (chunk) => chunks.push(chunk));
      res.on('end', () => resolve(Buffer.concat(chunks)));
      res.on('error', reject);
    });
  });
}

async function verifyPackage(name, resolvedUrl, expectedIntegrity) {
  const tarball = await fetchTarball(resolvedUrl);
  const hash = crypto.createHash('sha512').update(tarball).digest('base64');
  const computed = `sha512-${hash}`;

  if (computed !== expectedIntegrity) {
    console.error(`INTEGRITY MISMATCH: ${name}`);
    console.error(`Expected: ${expectedIntegrity}`);
    console.error(`Got:      ${computed}`);
    process.exit(1);
  }

  console.log(`✓ ${name} verified`);
}

async function main() {
  const lockfile = JSON.parse(fs.readFileSync('package-lock.json', 'utf8'));
  const packages = lockfile.packages || {};

  for (const [path, meta] of Object.entries(packages)) {
    if (!meta.resolved || !meta.integrity) continue;
    await verifyPackage(path, meta.resolved, meta.integrity);
  }
}

main().catch((err) => {
  console.error(err);
  process.exit(1);
});

Run this as a scheduled CI job, independent of your normal install step. If a cache poisoning bug is actively serving mismatched tarballs, this catches it by re-fetching and re-hashing packages outside the normal install path, rather than trusting whatever the registry cache handed you the first time.

What Registry Operators Should Be Doing

This isn't only a consumer-side problem. If you run any kind of internal package registry, artifact repository, or CDN-fronted service that serves versioned content, the RubyGems incident is a direct lesson:

Cache keys must include full content hashes, not just name+version. Name+version collisions are exactly what caused this bug.
Cache invalidation on integrity mismatch, not just TTL expiry. A stale cache entry serving wrong content should fail loudly, not silently serve old data.
Log cache hit/miss ratios per package and alert on anomalies. Sudden shifts in miss rates for a specific package can indicate exactly the kind of collision RubyGems experienced.
Rate-limit and fingerprint bot traffic separately from human traffic, since aggressive crawlers are precisely the load pattern that surfaces caching edge cases first.

Key Takeaways

A RubyGems CDN caching bug served mismatched package metadata, discovered only because OpenAI's bots generated unusual high-volume traffic patterns.
Cache poisoning is a distinct supply chain attack class from typosquatting or account takeover — it exploits registry infrastructure, not maintainer trust.
Always use npm ci in CI/CD pipelines instead of npm install to enforce lockfile integrity hash verification.
Run npm audit signatures and adopt npm publish --provenance to get cryptographic build attestations, not just checksum matching.
Pin exact dependency versions and disable lifecycle scripts (--ignore-scripts) in CI to reduce the blast radius of a poisoned tarball.
Build independent integrity-verification jobs that re-fetch and re-hash dependencies outside your normal install path, rather than trusting the registry cache once.
If you operate a private registry or CDN-backed package cache, key your cache entries on full content hashes, not just name and version.
Supply chain security bugs surface through unusual traffic patterns — instrument your own registries and proxies to detect the same anomalies OpenAI's bots exposed by accident.

Docker for Developers: Containers, Images, and Compose Explained

Aditya Rawas — Tue, 15 Sep 2026 00:37:18 +0000

Originally published at adityarawas.in

If you've ever heard "works on my machine" — Docker is the solution. Docker lets you package your application and all its dependencies into a single unit called a container that runs identically everywhere: your laptop, a teammate's Linux machine, or a cloud server.

This guide explains containers from first principles, then walks through building, running, and composing Docker-based applications — with a real Node.js example throughout.

Containers vs Virtual Machines

Before Docker, the standard way to isolate software environments was a Virtual Machine (VM). A VM emulates an entire computer — CPU, memory, disk, and a full operating system — on top of a hypervisor.

Containers are fundamentally different:

	Virtual Machine	Docker Container
OS	Full guest OS per VM	Shares host OS kernel
Size	Gigabytes	Megabytes
Startup	Minutes	Milliseconds
Isolation	Strong (hardware-level)	Good (process-level)
Performance	~10-15% overhead	Near native

A container is just a process running on the host OS, isolated using two Linux kernel features:

Namespaces — isolate the process's view of the system (filesystem, network, PID, users)
cgroups — limit the process's resource usage (CPU, memory, I/O)

Docker provides the tooling to create, run, and manage these containers.

Core Concepts

Images

A Docker image is a read-only template that defines everything needed to run your application: the OS base layer, runtime, dependencies, app code, and startup command.

Images are built in layers. Each instruction in a Dockerfile adds a layer on top of the previous one. Layers are cached and shared — if 10 images all use the same Node.js base layer, that layer is stored once on disk.

Containers

A container is a running instance of an image. You can run many containers from the same image simultaneously. The container adds a thin writable layer on top of the image layers for any changes made at runtime.

Image (read-only layers):
  ubuntu:22.04 base
  node:20 runtime
  npm install output
  app source code

Container (writable layer on top):
  runtime logs, temp files, etc.

Registry

Images are stored in a registry. Docker Hub is the default public registry. Private registries include AWS ECR, GitHub Container Registry, and Google Artifact Registry.

Installing Docker

Download Docker Desktop from docker.com. It includes the Docker daemon, CLI, and Docker Compose.

Verify the installation:

docker --version
# Docker version 27.x.x

docker run hello-world
# Pulls the hello-world image and runs it — confirms Docker is working

Essential Docker Commands

# Images
docker pull node:20-alpine       # Download an image
docker images                    # List local images
docker rmi node:20-alpine        # Remove an image

# Containers
docker run node:20-alpine node --version   # Run a command in a container
docker run -it ubuntu bash                 # Interactive terminal
docker ps                                  # List running containers
docker ps -a                               # List all containers (including stopped)
docker stop <id>                           # Stop a container
docker rm <id>                             # Remove a stopped container

# Logs and inspection
docker logs <id>                           # View container output
docker exec -it <id> sh                    # Shell into a running container
docker inspect <id>                        # Full container metadata

Writing a Dockerfile

A Dockerfile is a text file with instructions for building an image. Each instruction becomes a layer.

Here's a production-ready Dockerfile for a Node.js application:

# Stage 1: Install dependencies
FROM node:20-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --only=production

# Stage 2: Build (if needed — e.g. TypeScript)
FROM node:20-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 3: Production image
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production

# Copy only what's needed
COPY --from=deps /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist
COPY package.json ./

EXPOSE 3000
CMD ["node", "dist/index.js"]

This uses a multi-stage build — a critical pattern for production images:

The deps and builder stages contain dev tools and source files
The final runner stage only has the compiled output and production dependencies
The final image is dramatically smaller because the intermediate stages are discarded

Common Dockerfile Instructions

Instruction	Purpose
`FROM`	Base image to build from
`WORKDIR`	Set the working directory for subsequent instructions
`COPY`	Copy files from host into the image
`RUN`	Execute a command during build (creates a new layer)
`ENV`	Set environment variables
`EXPOSE`	Document the port the app listens on (doesn't publish it)
`CMD`	Default command to run when the container starts
`ENTRYPOINT`	Fixed command (CMD becomes arguments to it)

Building and Running Your Image

# Build the image — tag it with -t
docker build -t my-app:latest .

# Run a container from it
docker run -d \
  --name my-app \
  -p 3000:3000 \
  --env-file .env \
  my-app:latest

Flags explained:

-d — detached mode (runs in background)
--name my-app — give the container a name
-p 3000:3000 — map port 3000 on the host to port 3000 in the container
--env-file .env — load environment variables from a file

The `.dockerignore` File

Just like .gitignore, a .dockerignore file tells Docker what to exclude when copying files into the image:

node_modules
.git
.env
dist
*.log
.DS_Store

Always add node_modules — if it's not ignored, Docker copies your local modules into the image before running npm ci, which bloats the image and can cause platform-specific binary conflicts.

Volumes: Persisting Data

Containers are ephemeral — when a container is removed, all its data is gone. Volumes solve this by mounting storage that lives outside the container lifecycle.

# Named volume — Docker manages the storage location
docker run -d \
  --name my-postgres \
  -v postgres-data:/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD=secret \
  postgres:16

# Bind mount — maps a host directory into the container (useful in development)
docker run -d \
  -v $(pwd)/src:/app/src \
  -p 3000:3000 \
  my-app:dev

Use named volumes in production (Docker manages them, they survive container restarts). Use bind mounts in development (changes to host files are immediately reflected in the container).

Networking

Containers can communicate with each other through Docker networks.

# Create a network
docker network create my-network

# Connect containers to it
docker run -d --network my-network --name app my-app:latest
docker run -d --network my-network --name db postgres:16

# Inside the app container, connect to Postgres using its container name as hostname
# postgresql://db:5432/mydb

Containers on the same network can reach each other by container name — Docker's internal DNS resolves them automatically.

Docker Compose: Multi-Container Applications

Real applications have multiple services — a web server, a database, a cache. Docker Compose lets you define and run all of them with a single file.

# docker-compose.yml
services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgresql://postgres:secret@db:5432/myapp
      - REDIS_URL=redis://cache:6379
    depends_on:
      db:
        condition: service_healthy
      cache:
        condition: service_started
    volumes:
      - ./src:/app/src   # hot reload in development

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: myapp
      POSTGRES_PASSWORD: secret
    volumes:
      - postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

  cache:
    image: redis:7-alpine
    volumes:
      - redis-data:/data

volumes:
  postgres-data:
  redis-data:

docker compose up -d          # Start all services in the background
docker compose logs -f app    # Follow logs for the app service
docker compose down           # Stop and remove containers
docker compose down -v        # Also remove volumes (WARNING: deletes data)

With this setup, a new developer on your team only needs to run docker compose up to get a fully working local environment — no manual database installation, no version conflicts.

Layer Caching: Making Builds Fast

Docker caches each layer. If a layer's instruction and its inputs haven't changed, Docker reuses the cached layer instead of re-running the instruction. This makes rebuilds fast.

The order of instructions matters — put the things that change least at the top:

# Good — dependencies rarely change, so this layer is cached on most rebuilds
COPY package.json package-lock.json ./
RUN npm ci

# Source code changes often — copy it after installing dependencies
COPY . .

If you copy the entire source first and then run npm ci, every code change invalidates the npm install layer and triggers a full reinstall.

Production Best Practices

Use specific image tags, not latest:

# Bad — unpredictable, breaks builds when the image updates
FROM node:latest

# Good — deterministic builds
FROM node:20.17-alpine3.20

Run as a non-root user:

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

Don't store secrets in images: Use environment variables or secret management tools (AWS Secrets Manager, HashiCorp Vault). Never COPY .env into an image.

Scan images for vulnerabilities:

docker scout cves my-app:latest

Keep images small: Use Alpine-based images (node:20-alpine instead of node:20). Alpine is ~5MB vs ~150MB for the Debian-based default. Use multi-stage builds to exclude build tools from the final image.

Key Takeaways

A container is an isolated process — it shares the host OS kernel but has its own filesystem, network, and process space via Linux namespaces and cgroups.
A Docker image is a read-only stack of layers; a container adds a writable layer on top.
The Dockerfile defines how to build your image — put slow-changing layers (dependencies) before fast-changing ones (source code) to maximize cache hits.
Multi-stage builds keep production images small by separating build-time tools from runtime output.
Volumes persist data beyond a container's lifecycle — use named volumes in production, bind mounts in development.
Docker Compose orchestrates multi-container applications with a single YAML file, making local development reproducible.
Always use specific image tags, non-root users, and externalized secrets in production.

JavaScript Promises and Async/Await Explained: A Complete Guide

Aditya Rawas — Tue, 15 Sep 2026 00:36:18 +0000

Originally published at adityarawas.in

Asynchronous programming is one of the most important — and most misunderstood — parts of JavaScript. Whether you're fetching data from an API, reading files in Node.js, or querying a database, you're doing async work. Promises and async/await are the modern tools for handling it.

This guide takes you from the original callback problem all the way through Promise internals, chaining, error handling, parallel execution, and async/await — with practical patterns you can use immediately.

The Problem: Callback Hell

Before Promises, async operations were handled with callbacks — functions passed as arguments that get called when the operation completes.

getUserById(1, function(err, user) {
  if (err) return handleError(err);
  getPostsByUser(user.id, function(err, posts) {
    if (err) return handleError(err);
    getCommentsForPost(posts[0].id, function(err, comments) {
      if (err) return handleError(err);
      console.log(comments);
    });
  });
});

This pattern — called callback hell or the pyramid of doom — has real problems:

Error handling must be repeated at every level
Logic is deeply nested and hard to read
Sequential async steps become tangled
Adding retry logic or timeouts is painful

Promises were introduced in ES6 (2015) to solve this.

What is a Promise?

A Promise is an object representing the eventual completion or failure of an asynchronous operation. It acts as a placeholder for a value that doesn't exist yet.

A Promise has three possible states:

State	Meaning
Pending	The async operation is still running
Fulfilled	The operation completed successfully (has a value)
Rejected	The operation failed (has a reason/error)

Once a Promise is fulfilled or rejected, it is settled — it never changes state again.

Creating a Promise

const promise = new Promise((resolve, reject) => {
  // Simulate an async operation
  setTimeout(() => {
    const success = true;
    if (success) {
      resolve("Data loaded"); // fulfills the promise
    } else {
      reject(new Error("Network failure")); // rejects the promise
    }
  }, 1000);
});

The Promise constructor takes an executor function that receives two callbacks:

resolve(value) — call this when the operation succeeds
reject(reason) — call this when it fails

Consuming Promises with `.then()` and `.catch()`

promise
  .then((value) => {
    console.log(value); // "Data loaded"
  })
  .catch((error) => {
    console.error(error.message); // "Network failure"
  })
  .finally(() => {
    console.log("Done — runs regardless of outcome");
  });

.then(onFulfilled) — runs when the promise resolves
.catch(onRejected) — runs when the promise rejects
.finally(callback) — runs in both cases (cleanup, hiding spinners, etc.)

Promise Chaining

The real power of Promises comes from chaining — each .then() returns a new Promise, so you can chain operations that depend on each other without nesting.

fetchUser(1)
  .then((user) => fetchPosts(user.id))     // returns a new Promise
  .then((posts) => fetchComments(posts[0].id))
  .then((comments) => console.log(comments))
  .catch((error) => console.error(error)); // catches any error in the chain

Compare this to the callback version above — the logic is flat, readable, and has a single error handler.

Returning Values in `.then()`

Whatever you return from a .then() callback becomes the resolved value of the next Promise in the chain:

Promise.resolve(5)
  .then((n) => n * 2)   // returns 10
  .then((n) => n + 3)   // returns 13
  .then((n) => console.log(n)); // 13

If you return a Promise, the chain waits for it to settle before continuing.

Error Handling

A .catch() at the end of a chain catches any rejection from any step above it:

fetchUser(1)
  .then((user) => {
    if (!user.active) throw new Error("User is deactivated");
    return fetchPosts(user.id);
  })
  .then((posts) => processPosts(posts))
  .catch((error) => {
    // Catches: network errors, thrown errors, or rejected promises
    console.error("Something went wrong:", error.message);
  });

You can also place .catch() in the middle of a chain to recover from errors and continue:

fetchUser(1)
  .catch(() => getGuestUser())  // fallback if fetchUser fails
  .then((user) => renderProfile(user));

Always Handle Rejections

Unhandled promise rejections crash Node.js processes (since Node 15+) and log warnings in browsers. Always add a .catch() or use try/catch with async/await.

Running Promises in Parallel

When you have multiple independent async operations, run them in parallel instead of sequentially.

`Promise.all` — All Must Succeed

const [user, posts, settings] = await Promise.all([
  fetchUser(1),
  fetchPosts(1),
  fetchSettings(1),
]);

Runs all three in parallel — total time ≈ slowest single request
If any promise rejects, the whole Promise.all rejects immediately
Use when you need all results and any failure should stop everything

`Promise.allSettled` — Collect All Results

const results = await Promise.allSettled([
  fetchUser(1),
  fetchPosts(1),
  fetchSettings(1),
]);

results.forEach((result) => {
  if (result.status === "fulfilled") {
    console.log(result.value);
  } else {
    console.error(result.reason);
  }
});

Waits for all promises to settle regardless of success or failure
Use when you want all results and partial failures are acceptable

`Promise.race` — First One Wins

const result = await Promise.race([
  fetchData(),
  new Promise((_, reject) => setTimeout(() => reject(new Error("Timeout")), 5000)),
]);

Resolves or rejects as soon as the first promise settles
Useful for implementing timeouts

`Promise.any` — First Success Wins

const result = await Promise.any([
  fetchFromServer1(),
  fetchFromServer2(),
  fetchFromServer3(),
]);

Resolves with the first fulfilled promise
Only rejects if all promises reject (throws AggregateError)
Useful for trying multiple sources and taking whichever responds first

Async/Await

Async/await is syntax sugar over Promises — it doesn't replace them, it makes them look like synchronous code.

The `async` keyword

Adding async before a function makes it always return a Promise:

async function greet() {
  return "Hello"; // automatically wrapped in Promise.resolve("Hello")
}

greet().then(console.log); // "Hello"

The `await` keyword

await pauses execution inside an async function until the Promise settles:

async function loadUserData() {
  const user = await fetchUser(1);       // waits for this to resolve
  const posts = await fetchPosts(user.id); // then waits for this
  return { user, posts };
}

This is equivalent to the .then() chain, but reads like synchronous code.

Error Handling with try/catch

async function loadUserData() {
  try {
    const user = await fetchUser(1);
    const posts = await fetchPosts(user.id);
    return { user, posts };
  } catch (error) {
    console.error("Failed to load data:", error.message);
    return null;
  }
}

Common Async/Await Mistakes

Mistake 1: Forgetting `await`

// Wrong — `user` is a Promise, not the resolved value
async function getUser() {
  const user = fetchUser(1); // missing await
  console.log(user.name);   // undefined
}

// Correct
async function getUser() {
  const user = await fetchUser(1);
  console.log(user.name);
}

Mistake 2: Sequential `await` When Parallel is Possible

// Slow — runs one after the other (sum of both delays)
async function slow() {
  const user = await fetchUser(1);
  const posts = await fetchPosts(1);
}

// Fast — runs in parallel (max of both delays)
async function fast() {
  const [user, posts] = await Promise.all([fetchUser(1), fetchPosts(1)]);
}

This is the single most common performance bug in async code. If two operations don't depend on each other, always parallelize with Promise.all.

Mistake 3: `await` Inside `.forEach()`

// Wrong — forEach doesn't wait for async callbacks
async function processAll(ids) {
  ids.forEach(async (id) => {
    await processItem(id); // these all fire simultaneously, forEach returns immediately
  });
}

// Correct — sequential with for...of
async function processAll(ids) {
  for (const id of ids) {
    await processItem(id);
  }
}

// Correct — parallel with Promise.all
async function processAll(ids) {
  await Promise.all(ids.map((id) => processItem(id)));
}

Mistake 4: Unhandled Rejections

// Dangerous — if fetchData() rejects, the error is silently swallowed
async function load() {
  const data = await fetchData(); // no try/catch
}

// Safe
async function load() {
  try {
    const data = await fetchData();
  } catch (err) {
    handleError(err);
  }
}

Real-World Example: Fetching API Data

Here's a complete pattern for fetching data with proper error handling and loading states:

async function fetchUserProfile(userId) {
  const controller = new AbortController();
  const timeout = setTimeout(() => controller.abort(), 10000); // 10s timeout

  try {
    const response = await fetch(`/api/users/${userId}`, {
      signal: controller.signal,
    });

    if (!response.ok) {
      throw new Error(`HTTP error: ${response.status}`);
    }

    const user = await response.json();
    return user;
  } catch (error) {
    if (error.name === "AbortError") {
      throw new Error("Request timed out");
    }
    throw error;
  } finally {
    clearTimeout(timeout);
  }
}

Promises vs Async/Await: When to Use Which

Situation	Recommendation
Simple single operation	Either — async/await is more readable
Chaining multiple operations	Async/await
Parallel operations	`Promise.all` / `Promise.allSettled`
Utility functions returning promises	Return a Promise directly
Event handlers	Async/await with try/catch
Legacy `.then()` chains you're refactoring	Async/await

In practice, most modern codebases use async/await for control flow and Promise.all for parallelism, with .catch() reserved for one-liners.

How Promises Fit in the Event Loop

Understanding where Promises sit in the event loop explains some subtle timing behaviors:

Promise callbacks (.then(), .catch()) are scheduled as microtasks
Microtasks run before the next macrotask (setTimeout, setInterval, I/O)

console.log("1");

setTimeout(() => console.log("2"), 0);

Promise.resolve().then(() => console.log("3"));

console.log("4");

// Output: 1, 4, 3, 2

Even though setTimeout has a delay of 0ms, the Promise microtask (3) runs before it (2). This is why deeply nested Promise chains can occasionally starve the macrotask queue.

For a deeper look at the event loop phases — timers, I/O, and libuv — see Is Node.js Single-Threaded or Multi-Threaded?.

Key Takeaways

A Promise is an object that represents a value available now, in the future, or never — in one of three states: pending, fulfilled, or rejected.
Promise chaining with .then() flattens nested async logic into readable sequential steps.
Promise.all runs operations in parallel and fails fast; Promise.allSettled collects all results regardless of failure.
async/await is syntax sugar over Promises — it makes async code look synchronous without blocking the thread.
The most common async bug is sequential await where Promise.all should be used.
Promise callbacks run as microtasks — before setTimeout and other macrotasks.
Always handle rejections with .catch() or try/catch to avoid unhandled rejection crashes.

React Hooks Explained: useState and useEffect in Depth

Aditya Rawas — Tue, 15 Sep 2026 00:36:16 +0000

Originally published at adityarawas.in

React Hooks, introduced in React 16.8, changed how we write components. Before hooks, state and lifecycle logic required class components. Now, useState and useEffect let you add the same capabilities to simple functions.

This guide covers both hooks deeply — how they work under the hood, when to use them, and the subtle bugs that trip up even experienced React developers.

What Are Hooks?

Hooks are functions that let you "hook into" React's internal state and lifecycle systems from function components. They always start with use.

The rules are strict:

Only call hooks at the top level — never inside loops, conditions, or nested functions
Only call hooks from React function components (or custom hooks)

These rules exist because React tracks hooks by their call order. If a hook runs conditionally, the order changes between renders and React's internal state tracking breaks.

`useState`: Managing Component State

The Basics

import { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

useState(initialValue) returns an array with two elements:

The current state value (count)
A setter function (setCount) that triggers a re-render when called

State Updates Are Asynchronous

React batches state updates and re-renders once after event handlers complete. This means reading state immediately after setting it gives the old value:

function Counter() {
  const [count, setCount] = useState(0);

  function handleClick() {
    setCount(count + 1);
    console.log(count); // Still 0 — state hasn't updated yet
  }
}

The Functional Update Form

When the next state depends on the previous state, use the functional update form — pass a function to the setter instead of a value:

// Unsafe — can use a stale value of count
setCount(count + 1);

// Safe — always uses the latest state
setCount((prevCount) => prevCount + 1);

This matters when multiple updates happen in the same render cycle:

function handleTripleIncrement() {
  // Bad — all three read the same stale `count` value, result: count + 1
  setCount(count + 1);
  setCount(count + 1);
  setCount(count + 1);

  // Good — each sees the result of the previous, result: count + 3
  setCount((c) => c + 1);
  setCount((c) => c + 1);
  setCount((c) => c + 1);
}

State with Objects

When state is an object, you must spread the previous state when updating — useState does not merge objects like setState in class components:

const [user, setUser] = useState({ name: "Aditya", age: 28, city: "Pune" });

// Wrong — replaces the entire state object, losing `name` and `city`
setUser({ age: 29 });

// Correct — spread previous state, then override the field you want
setUser((prev) => ({ ...prev, age: 29 }));

Lazy Initial State

If computing the initial state is expensive, pass a function — it only runs once on mount:

// Bad — parses JSON on every render (even though only the first matters)
const [data, setData] = useState(JSON.parse(localStorage.getItem('data')));

// Good — function only runs once
const [data, setData] = useState(() => JSON.parse(localStorage.getItem('data')));

`useEffect`: Handling Side Effects

What is a Side Effect?

A side effect is anything that reaches outside the component's render — fetching data, subscriptions, timers, manually updating the DOM, logging.

React's render must be pure — the same props/state always produces the same JSX. Side effects live in useEffect.

Basic Syntax

useEffect(() => {
  // Side effect code runs after render
  document.title = `Count: ${count}`;
});

Without a second argument, this effect runs after every render. That's rarely what you want.

The Dependency Array

The second argument to useEffect controls when the effect re-runs:

// Runs once on mount only (empty array = no dependencies)
useEffect(() => {
  fetchData();
}, []);

// Runs on mount AND whenever `userId` changes
useEffect(() => {
  fetchUser(userId);
}, [userId]);

// Runs after every render (omit the array entirely)
useEffect(() => {
  logRender();
});

The rule: every reactive value used inside the effect (props, state, variables derived from them) must be in the dependency array. The react-hooks/exhaustive-deps ESLint rule enforces this automatically.

Fetching Data with useEffect

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let cancelled = false; // prevents stale state updates

    async function fetchUser() {
      try {
        setLoading(true);
        const res = await fetch(`/api/users/${userId}`);
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        const data = await res.json();
        if (!cancelled) setUser(data);
      } catch (err) {
        if (!cancelled) setError(err.message);
      } finally {
        if (!cancelled) setLoading(false);
      }
    }

    fetchUser();

    return () => {
      cancelled = true; // cleanup — ignore result if component unmounts
    };
  }, [userId]); // re-fetch whenever userId changes

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error: {error}</p>;
  return <p>{user?.name}</p>;
}

Cleanup Functions

The function returned from useEffect is the cleanup function — React calls it before the effect runs again (due to a dependency change) and when the component unmounts.

useEffect(() => {
  const interval = setInterval(() => {
    setCount((c) => c + 1);
  }, 1000);

  return () => clearInterval(interval); // cleanup — prevents memory leaks
}, []);

useEffect(() => {
  const controller = new AbortController();

  fetch('/api/data', { signal: controller.signal })
    .then((res) => res.json())
    .then(setData);

  return () => controller.abort(); // cancel the in-flight request on cleanup
}, []);

Cleanup is essential for:

Cancelling fetch requests
Clearing intervals and timeouts
Unsubscribing from WebSocket connections or event listeners
Cancelling animations

Common useEffect Mistakes

Mistake 1: Missing Dependencies

// Wrong — `userId` is used inside but missing from the array
// The effect runs once on mount with the initial userId, never again
useEffect(() => {
  fetchUser(userId);
}, []); // eslint will warn about this

// Correct
useEffect(() => {
  fetchUser(userId);
}, [userId]);

Mistake 2: Object/Array Dependencies Causing Infinite Loops

Objects and arrays are compared by reference in JavaScript. A new object is created on every render even if its contents are the same — so putting it in the dependency array triggers the effect on every render.

function MyComponent({ config }) {
  // Bug — if config is created inline: <MyComponent config={{ debug: true }} />
  // A new object reference on every parent render → infinite loop
  useEffect(() => {
    setupLibrary(config);
  }, [config]);
}

Solutions:

Memoize the object with useMemo
Destructure primitive values from the object and use those as dependencies
Move the object outside the component if it never changes

Mistake 3: Fetching Without Cleanup

// Bug — if userId changes quickly (e.g. user types in a search box),
// multiple requests are in-flight. The last response might not be
// from the last request — race condition!
useEffect(() => {
  fetch(`/api/users/${userId}`)
    .then((r) => r.json())
    .then(setUser);
}, [userId]);

Always use the cancellation pattern (AbortController or a cancelled flag) shown in the fetch example above.

Mistake 4: Setting State Unconditionally on Unmounted Component

useEffect(() => {
  fetchData().then((data) => {
    setData(data); // might run after component unmounts — React warning
  });
}, []);

Fix with the cancelled flag or AbortController shown earlier.

The Mental Model: Synchronization, Not Lifecycle

The key to using useEffect correctly is to stop thinking about lifecycle methods (componentDidMount, componentDidUpdate, componentWillUnmount) and instead think about synchronization:

"This effect keeps [external system] synchronized with [these values]."

// Don't think: "run this when userId changes"
// Think: "keep the user profile in sync with userId"
useEffect(() => {
  fetchUser(userId);
  return () => cancelFetch();
}, [userId]);

This framing makes the dependency array obvious — whatever the effect needs to stay synchronized with goes in the array.

useState vs useReducer

As state logic grows more complex, useReducer is often cleaner than multiple useState calls:

// Multiple useState — works but gets unwieldy
const [name, setName] = useState('');
const [loading, setLoading] = useState(false);
const [error, setError] = useState(null);

// useReducer — groups related state together
const [state, dispatch] = useReducer(reducer, {
  name: '',
  loading: false,
  error: null,
});

Prefer useReducer when:

Multiple state values that change together
Next state depends on complex logic involving previous state
You find yourself passing many state setters down to child components

Practical Patterns

Debounced Search

function SearchBar({ onSearch }) {
  const [query, setQuery] = useState('');

  useEffect(() => {
    const timer = setTimeout(() => {
      onSearch(query);
    }, 400);

    return () => clearTimeout(timer); // cancel on every keystroke
  }, [query, onSearch]);

  return <input value={query} onChange={(e) => setQuery(e.target.value)} />;
}

Window Resize Listener

function useWindowWidth() {
  const [width, setWidth] = useState(window.innerWidth);

  useEffect(() => {
    const handleResize = () => setWidth(window.innerWidth);
    window.addEventListener('resize', handleResize);
    return () => window.removeEventListener('resize', handleResize);
  }, []); // no deps — addEventListener is stable

  return width;
}

LocalStorage Sync

function usePersistentState(key, defaultValue) {
  const [value, setValue] = useState(
    () => JSON.parse(localStorage.getItem(key) ?? 'null') ?? defaultValue
  );

  useEffect(() => {
    localStorage.setItem(key, JSON.stringify(value));
  }, [key, value]);

  return [value, setValue];
}

These patterns all follow the same structure: setup in the effect body, cleanup in the return function, dependencies declared honestly.

Key Takeaways

useState(initial) returns [currentValue, setter] — calling the setter triggers a re-render with the new state.
Use the functional update form setCount(c => c + 1) when the new state depends on the old state.
When state is an object, always spread previous state to avoid overwriting unrelated fields.
useEffect runs after render. The dependency array controls when it re-runs — an empty array means mount-only.
Every reactive value used inside an effect must be in the dependency array — use the ESLint rule exhaustive-deps to enforce this.
Always return a cleanup function for subscriptions, timers, and fetch requests to prevent memory leaks and race conditions.
Think of useEffect as synchronization, not as lifecycle hooks — this mental model makes dependencies obvious.
When state logic gets complex, migrate from multiple useState calls to useReducer.

Just Launched My Personal Website – Looking for Feedback! 👀

Aditya Rawas — Mon, 16 Jun 2025 04:54:35 +0000

Hey devs! 👋

I’m Aditya Rawas, and I’m excited to share my new personal website with you all:

👉 www.adityarawas.in

It’s live, it’s fast, and it’s built with one of my favorite tools lately — Astro!

👨‍💻 About Me

I’m a software engineer passionate about frontend frameworks, dev tooling, and building scalable apps. My current focus lies in:

Frontend development using React and Astro
Backend APIs with Go and Django
Performance-focused builds (Vite, Rspack, bundlers, etc.)
Developer experience (DX) tooling and framework architecture
Mentoring and knowledge-sharing within tech teams and open source

I work as part of a framework team that builds tools to help other devs move faster and build better. If you're into performance, code cleanliness, and DX — we probably have a lot in common!

🌐 About the Website – www.adityarawas.in

My site is more than a portfolio — it’s a personal knowledge hub, built entirely using Astro.

🔧 Tech Stack

Astro (for island architecture + Markdown support)
Tailwind CSS (for design system)
Markdown content for blog posts
Deployed via GitHub + CI

I chose Astro because I love the idea of sending zero JS where it's not needed, and it gives me the flexibility to progressively enhance my site as I grow it.

✨ What You'll Find Inside

✅ About Me

A concise intro to my background, experience, and what I care about in software development.

🛠 Projects

Live previews and links to some of the tools and apps I’ve built — from dev tooling to full-stack apps.

📖 Blog

Coming very soon — I’ll be sharing:

Deep dives into tools like Vite, Rspack, and Astro
Guides on building with Golang + modern frontend
My thoughts on clean code, team collaboration, and DX principles

📬 Contact

I’m always open to conversations — whether it's a project, feedback, or just tech talk.

🙏 Looking for Your Feedback!

I'd really appreciate it if you could check out the site and share your thoughts:

Does the design feel clear and focused?
Any UI/UX issues or performance bugs you noticed?
What content would you love to see on my blog?
Any Astro tips or cool ideas I should explore?

This is just v1 — I’ll keep iterating, and your feedback will directly shape how it evolves!

🤝 Let’s Connect

If you’re also working on your personal site, drop your link — I’d love to see it!

Find me online:

🌐 Website: www.adityarawas.in
🐦 Twitter/X: [@rawas_aditya](https://x.com/rawas_aditya)
💼 LinkedIn: [Aditya Rawas](https://www.linkedin.com/in/aditya-rawas/)

Thanks for reading — and extra thanks if you share your thoughts! Let’s keep building and learning together 🚀

Understanding the Barrel Pattern in JavaScript/TypeScript

Aditya Rawas — Sun, 15 Dec 2024 11:59:01 +0000

In large JavaScript and TypeScript projects, as the codebase grows, organizing modules and making imports manageable becomes crucial for maintainability and scalability. The Barrel Pattern offers a simple but effective way to simplify and streamline module exports and imports, especially in projects with complex directory structures. In this post, we’ll dive into the Barrel Pattern, understand its advantages, and see how to implement it effectively in TypeScript and JavaScript.

What is the Barrel Pattern?

The Barrel Pattern is a way of organizing exports in a project by consolidating them in a single file, usually named index.ts or index.js. Rather than importing modules individually from deeply nested paths, the Barrel Pattern lets you import everything from a single entry point, simplifying the import process and making the code more readable.

For example, instead of importing directly from specific module files:

import { UserService } from './services/UserService';
import { ProductService } from './services/ProductService';
import { OrderService } from './services/OrderService';

With a barrel file in place, you could import these all from a single entry point:

import { UserService, ProductService, OrderService } from './services';

Advantages of the Barrel Pattern

Simplifies Imports: With a single entry point for each module, your import statements are cleaner and shorter.
Reduces File Path Complexity: By consolidating imports, you reduce the need for long file paths, especially useful in large projects with deep folder structures.
Improves Code Readability: Organizing imports from a single source improves code readability, making it clear where each dependency is coming from.
Encourages Modular Design: Since barrel files naturally group related modules, they encourage modular design and more manageable code.
Improves Maintenance: If file paths change, you only need to update the path in the barrel file rather than in every import statement across the codebase.

Setting Up a Barrel File in JavaScript/TypeScript

Here’s how to set up and use the Barrel Pattern in a typical TypeScript project. Let’s assume you have the following directory structure:

src/
│
├── models/
│   ├── User.ts
│   ├── Product.ts
│   └── Order.ts
│
├── services/
│   ├── UserService.ts
│   ├── ProductService.ts
│   └── OrderService.ts
│
└── index.ts

Step 1: Creating Barrel Files

In each folder (like models and services), create an index.ts file that re-exports all modules within that folder.

`models/index.ts`

export * from './User';
export * from './Product';
export * from './Order';

`services/index.ts`

export * from './UserService';
export * from './ProductService';
export * from './OrderService';

Step 2: Importing from Barrel Files

Now, instead of importing individual modules, you can import them through the index.ts files.

For instance, to use the services:

import { UserService, ProductService, OrderService } from './services';

If you have a larger project, you could even create a root-level barrel file in src/index.ts to consolidate imports even further.

`src/index.ts`

export * from './models';
export * from './services';

Now, you can import all models and services from the root of your project:

import { User, Product, Order } from './models';
import { UserService, ProductService, OrderService } from './services';

Handling Name Conflicts

If you have multiple modules with the same export names, consider renaming them or exporting selectively:

// services/index.ts
export { UserService as UserSvc } from './UserService';
export { ProductService } from './ProductService';
export { OrderService } from './OrderService';

Caveats and Best Practices

Avoid Excessive Barrel Files: Using too many barrels can lead to dependencies that are harder to trace. Reserve barrels for truly grouped modules, like models or services.
Avoid Circular Dependencies: Be cautious with cyclic dependencies, which can occur if you re-export modules that depend on each other. TypeScript will throw errors if it detects these.
Optimize Import Statements: Even though barrels make imports more manageable, always verify that unused exports aren’t imported, as this could increase bundle size. Tree-shaking tools (like Webpack) can help optimize imports and remove unused code.
Use Explicit Exports When Possible: Although wildcard exports (export * from) are convenient, explicit exports make it easier to trace the source of each module.

Final Thoughts

The Barrel Pattern is a powerful organizational strategy for large JavaScript and TypeScript projects. By creating an entry point for each module group, it enhances code readability, maintains manageable imports, and keeps your project modular. However, it’s essential to avoid overusing barrel files and watch out for circular dependencies to ensure efficient and maintainable code.

Try implementing the Barrel Pattern in your project and see how much it can streamline your imports and improve your workflow!

Is Node.js Single-Threaded or Multi-Threaded? Unraveling the Mystery

Aditya Rawas — Fri, 29 Nov 2024 00:12:52 +0000

As a developer, you've probably heard about Node.js's event-driven, non-blocking I/O model, but a common question remains: "Is Node.js single-threaded or multi-threaded?"

The answer isn’t as straightforward as you might think. While Node.js runs JavaScript on a single thread, it has powerful multi-threading capabilities under the hood. This unique combination often leads to confusion, especially when deciding how to handle concurrent tasks or CPU-intensive operations.

Why Node.js Feels Single-Threaded

At its core, Node.js executes JavaScript code in a single-threaded environment, thanks to the V8 engine. The single-threaded nature is integral to its lightweight architecture, making it perfect for real-time applications and handling thousands of concurrent connections.

But here’s the twist: Node.js doesn’t stop at single-threaded execution. It has built-in mechanisms for handling multi-threading seamlessly, often without developers even noticing.

Where Multi-Threading Comes Into Play

Node.js uses a thread pool behind the scenes to manage I/O operations efficiently. Additionally, with the introduction of worker threads, developers can now explicitly create threads for CPU-intensive tasks, solving one of Node.js's biggest pain points.

Want to know how all of this works together to make Node.js a hybrid powerhouse? Dive deeper into the full blog for insights, code examples, and best practices:

👉 Read the Full Blog Here

Unlock the full potential of Node.js by mastering its threading capabilities!

DEV Community: Aditya Rawas

What Zig Feels Like Coming from Go: A Systems Programming Comparison

Why Go Developers Are Looking at Zig

Memory Management: Explicit vs Automatic

Error Handling: Similar Philosophy, Different Enforcement

Error Handling Comparison

Compile-Time Metaprogramming: comptime vs Generics

Concurrency: Goroutines vs Manual Control

Cross-Compilation: Zig's Killer Feature

Standard Library Philosophy

Where Each Language Actually Wins

Key Takeaways

Cloudflare Quick Tunnels: Expose Local Servers to the Internet Without a VPS

What Are Cloudflare Quick Tunnels

Quick Tunnels vs Named Cloudflare Tunnels

Setting Up a Named Tunnel for Production Use

Practical Use Case: Testing Webhooks Locally

Handling Restarts and URL Rotation

Running Quick Tunnels Inside Docker

Cloudflare Quick Tunnels vs ngrok vs localtunnel

Security Considerations

Troubleshooting Common Issues

Key Takeaways

How GLM Built Its Own Inference Infrastructure: A Deep Dive for Backend Engineers

Why Inference Infrastructure Is a Backend Problem, Not Just an ML Problem

The Core Architecture: Prefill/Decode Separation

Prefill Phase

Decode Phase

Request Batching: The Real Performance Lever

Caching: KV Cache Is Just a Specialized LRU

Load Balancing Across a Heterogeneous GPU Fleet

Networking: Why gRPC and Custom Protocols Win

Autoscaling: Beyond CPU/Memory Metrics

Comparison: Inference Infra Patterns vs. Standard Backend Patterns

Applying These Patterns Without Building an LLM Stack

Key Takeaways

CUDA for Rust: A Practical Guide to Nvidia's Native GPU Programming Support

What Nvidia Actually Announced

Why This Matters Now

CUDA C++ vs CUDA Rust: A Practical Comparison

Setting Up Your First CUDA Rust Kernel

Prerequisites

Project Structure

Writing the Kernel (Track One — Low-Level)

Host Code to Launch the Kernel

Track Two — The High-Level Abstraction

Build Configuration

Performance Considerations

Where This Fits in a Real Stack

Common Pitfalls

Key Takeaways

Java 27 Explained: New Features, JVM Changes, and What It Means for Backend Developers

What's Actually New in Java 27

Structured Concurrency Goes Final

Virtual Threads Are Now the Default for Executors

Pattern Matching for switch Gets Deconstruction Patterns

ZGC Becomes Fully Generational and Default for Most Workloads

Java 27 vs Node.js vs Go: A Backend Engineer's Comparison

Running Java 27 in Docker: A Practical Setup

Enabling Class Data Sharing for Faster Cold Starts

Migration Considerations from Java 21/25 LTS

Why This Matters Beyond the JVM Ecosystem

Key Takeaways

RubyGems Supply Chain Vulnerability: What the OpenAI Bot Incident Teaches About Node.js and npm Security

What Happened with RubyGems

Why This Isn't a "Ruby Problem"

How This Maps to the npm Ecosystem

Verifying Package Integrity in npm Right Now

Lockfile Integrity Hashes

Auditing What's Actually Installed

Enforcing Provenance

Hardening Your CI/CD Pipeline

1. Pin Exact Versions, Not Ranges

2. Use a Private Registry Proxy

3. Disable Lifecycle Scripts in CI

4. Automate Dependency Diffing

Detecting Anomalies Like OpenAI's Bots Did (By Accident)

What Registry Operators Should Be Doing

Key Takeaways

Docker for Developers: Containers, Images, and Compose Explained

Compile-Time Metaprogramming: `comptime` vs Generics

Pattern Matching for `switch` Gets Deconstruction Patterns

The `.dockerignore` File

Consuming Promises with `.then()` and `.catch()`

Returning Values in `.then()`

`Promise.all` — All Must Succeed

`Promise.allSettled` — Collect All Results

`Promise.race` — First One Wins

`Promise.any` — First Success Wins

The `async` keyword

The `await` keyword

Mistake 1: Forgetting `await`

Mistake 2: Sequential `await` When Parallel is Possible

Mistake 3: `await` Inside `.forEach()`

`useState`: Managing Component State

`useEffect`: Handling Side Effects