DEV Community: Krun_Dev

The Unofficial MojoWiki

Krun_Dev — Mon, 11 May 2026 22:38:46 +0000

Don't Give Up on Mojo Just Yet: The Survival Manual Modular Forgot to Write

The honeymoon phase with the Mojo programming language is usually short. It starts with a clean install and ends abruptly when you hit your first undocumented toolchain crash, a silent PATH ghost, or a borrow checker error that makes Rust look like child's play. Most developers hit these walls, realize the official documentation is missing the "how-to-fix-this-mess" section, and immediately retreat to the safety of Python.

But the problem isn't necessarily the language—it is the massive information gap between the clean, sanitized marketing hype and the gritty, production-grade reality of a toolchain still in heavy development. If you have spent more time debugging your environment than writing kernels, you are not alone. You have simply hit the "early adopter tax" that no one likes to talk about on stage.

I have spent months documenting the rough neighborhood of Mojo development. While the official docs show you the dream of a unified AI stack, I have spent that time mapping the mines, the pitfalls, and the architectural dead-ends. The result is the Unofficial MojoWiki: an exhaustive engineering audit of over 50 real-world pitfalls, architectural traps, and "hour-one" failures that stop production builds in their tracks. This is the manual that helps you move past the "Hello World" stage and into actual systems engineering.

What they are not telling you in the official release notes

We are skipping the boilerplate and the fan-boy enthusiasm. This isn't a fan-site; it is a cold, technical autopsy of Mojo's current production state as of mid-2026. Official sources are great at telling you what a language can do, but they are notoriously bad at telling you what it cannot do yet, or where it fails in silence. In the full manual, we tackle the cynical reality of the current ecosystem:

Toolchain Instability and Ghost Commands: Why the Modular CLI occasionally forgets your PATH after a minor update and how to manually re-link your environment when the auth server decides to time out without an error message.
The Hidden Python Interop Tax: Everyone talks about how easy it is to call NumPy, but no one mentions the hidden cost of tensor copies and the pointer-chasing overhead that can wipe out your performance gains before your specialized kernel even starts.
Memory Ownership Scars: Navigating the brutal transition from Python’s carefree garbage collection to Mojo’s strict ownership model. We look at why your values "do not live long enough" and how to solve lifetime errors without resorting to memory-unsafe hacks.
The SIMD Alignment Trap: Why your "optimized" code might be running at scalar speeds because the compiler decided to fall back to a slower path in silence rather than flagging an alignment error.
Partial Concurrency Implementation: The real state of async/await. We discuss why parallelize works like a charm but the high-level async model still faces stability issues in high-load production environments.

The Engineering Guide for Those Who Stayed

If you are tired of the sanitized, perfect world described by PR departments and you actually need to know why your binary size just tripled or why the LSP is leaking 4GB of RAM in VS Code, this guide is for you. I have categorized every major bottleneck I found—from binary bloat and cryptic MLIR syntax errors to the nuances of struct vs class memory layout.

This isn't just a list of bugs; it is a strategic map for engineers who have decided to stick with Mojo despite the friction. It is about understanding the "why" behind the crashes. We cover the environment variables that actually matter, the build flags that Modular keeps tucked away in their GitHub issues, and the workarounds for the current lack of a mature package manager.

This is the Unofficial MojoWiki. It is rough, it is human, and it is built for developers who need to ship working binaries, not just read pitch decks. Mojo is a masterpiece of modern engineering, but it is a wild animal that needs to be tamed. I have documented the first 50 hours of hell so you can skip the frustration and get straight to the part where you build something world-changing.

If you are ready to stop fighting the toolchain and start mastering the machine, the full engineering deep-dive is live and updated for the 2026 reality. Stop guessing, start engineering, and let's see what Mojo can really do when you know where the traps are hidden.

For a more detailed breakdown, head over to MojoWiki — where we have covered nearly every solution to your engineering headaches and production pains.

Keep an eye out for updates at krun.pro

Rust Generator yield

Krun_Dev — Sun, 10 May 2026 20:36:59 +0000

Rust Generator yield: What the Compiler Builds Under async/await

Every async function in Rust is a compiler-generated state machine built on generators. Yield is not a niche feature — it is the foundation of async/await. Most developers use it without realizing it can inflate memory usage and binary size significantly.

The compiler transforms each await into a suspension point and builds an enum where every state represents a stage of execution. This enum is wrapped into a Future and driven by poll(). Execution resumes exactly where it stopped, using a match-based dispatch.

The critical detail: all variables alive across an await are stored inside the state. They are not dropped — they are preserved. If a large object exists at that point, it becomes part of the state machine until completion. The size of the future equals its largest state, even if rarely used.

Nested async calls make this worse. Each function embeds its own state machine, and sizes compound, not linearly but multiplicatively. Real-world cases show futures exceeding hundreds of kilobytes, which can break memory-constrained systems.

Execution is cooperative: no threads, no stack switching. The executor repeatedly polls the state machine, and a waker schedules it when I/O is ready. This is efficient — but only if state size is under control.

Python and Rust generators look similar but behave very differently. Python generators are heap-based and managed by the runtime. Rust generators are stackless, strictly typed, and require pinning to guarantee memory stability. Resume arguments are enforced at compile time, not runtime.

Async in Rust is effectively a generator wrapped as a Future. Yield maps to a pending state, completion maps to ready. This is not an abstraction — it is the actual implementation.

The main issue in production is state size growth. Since the largest state defines memory usage, deeply nested async flows can create oversized futures. The common fix is heap allocation via boxing, which limits size but adds overhead.

Generators are still unstable due to self-referential memory problems. Pin ensures safety but adds complexity. Stable alternatives include iterator-based patterns, macro-based generators, and upcoming language features designed to simplify this model.

Bottom line: Rust async is explicit state machines. If you ignore how state is built and stored, you risk hidden memory costs and performance issues.

Learn more on this page https://krun.pro/rust-generator-yield/ — the full deep-dive on Rust Generator yield: What the Compiler Actually Builds Under async/await

Python modern toolchain

Krun_Dev — Fri, 08 May 2026 13:14:28 +0000

Your Python Toolchain Is Costing You Real Money — And You're Probably Fine With That

Let's be honest. Most Python teams in 2026 are still running flake8, black, isort, and Poetry side by side like it's 2021. Three separate lint processes, a formatter that argues with your import sorter, a dependency manager with a 40-second install time, and a pyproject.toml that looks like it was configured by a committee. Nobody chose this setup deliberately — it just accumulated, sprint by sprint, like technical debt usually does.

The uncomfortable question: how much CI time does your team burn per week on tooling that has already been replaced by something an order of magnitude faster?

The Numbers Are Not in Your Favor

Ruff — a Python linter and formatter written in Rust — lints the entire CPython repository (680 000+ lines) in under 0.5 seconds. Flake8 takes 30–40 seconds on the same codebase. That's not a benchmark cherry-picked from a blog post. That's reproducible on your machine, today.

Do the math for your team. If lint runs on every PR and your pipeline takes 35 seconds just for code quality checks — across 10 engineers, 4 PRs a day — you're burning roughly 23 minutes of CI compute daily on a solved problem. Ruff collapses that to under a minute. Ruff replaces flake8, black, and isort as a single binary with zero configuration conflicts, because there's only one tool making decisions.

That's not hype. That's arithmetic.

Poetry Had Its Moment. uv Is What Happens Next.

uv is the dependency manager that Poetry should have been. Faster resolution, a readable lockfile, native PEP 735 support for dependency groups, and a single binary that also replaces pipx for tool management. The migration from Poetry to uv involves exactly three things: reformatting pyproject.toml to standard [project.dependencies], replacing poetry install with uv sync --frozen, and updating your CI cache path from Poetry's global store to ~/.cache/uv.

The result is reproducible builds that don't require Poetry to be installed anywhere — just uv. On a cold CI runner, uv sync on a medium-sized FastAPI service completes in under 8 seconds. Poetry on the same project: 45–60 seconds. This is the kind of improvement that makes DevOps people genuinely happy, which is rare enough to be worth mentioning.

Pyright Strict Mode Is Not a Punishment — It's a Safety Net You Didn't Know You Needed

The moment you enable Pyright strict mode on a real codebase, you get a red wall of errors. Most teams turn it off and go back to typeCheckingMode = "basic" within an hour. That's the wrong move. The errors it surfaces — untyped decorators, missing return annotations, unknown member types from third-party libraries — are real bugs waiting to happen in production, not style pedantry.

The trick is incremental adoption. Enable strict per-module, not globally. Fix reportMissingTypeArgument first — it's mechanical and automatable. Use ParamSpec to type decorators properly instead of reaching for Any. Add stub packages for boto3, requests, redis from PyPI rather than sprinkling # type: ignore everywhere and hoping for the best.

The Distroless Angle Nobody Talks About

Combining uv with a distroless Docker base image produces Python containers below 80 MB with no shell, no package manager, and no attack surface beyond what your application actually needs. The multi-stage Dockerfile pattern — uv in the builder stage, gcr.io/distroless/python3-debian12 as runtime — is reproducible, auditable, and passes most enterprise security scans without extra hardening. It also forces the architectural discipline of proper logging and tracing instead of docker exec debugging, which is where containerized services should be anyway.

The full write-up covers all of this in detail — real pyproject.toml configs you can copy directly, the exact Dockerfile with uv sync and nonroot user, Pyright strict error categories ranked by fix complexity, private PyPI index configuration in uv, and a minimal microservice template that ditches setup.py, requirements.txt, and every other config file that doesn't belong in a modern Python project.

Full article with configs, Dockerfiles, and Pyright fixes: the complete version is available on https://krun.pro/python-modern-toolchain/ — written for developers who've already heard the pitch and want the implementation details.

Developer Burnout: Meaningless Work

Krun_Dev — Tue, 05 May 2026 22:08:44 +0000

We’re Not Burned Out — We’re Just Building Things Nobody Cares About

I’ve seen a pattern in software teams that nobody really wants to say out loud.

Developers aren’t burning out because they work too much. Some of the most drained engineers I know are working 30–35 hours a week, fully remote, with “reasonable” deadlines.

And still — they feel completely done with it.

Not tired. Not stressed. Just… disconnected.

The Real Problem Isn’t Workload

We’ve been sold a very simple story: burnout = too much work.

So the solution is always the same — take breaks, reduce hours, rest more.

But that advice completely falls apart in real teams.

Because people aren’t collapsing from exhaustion. They’re collapsing from doing work that doesn’t seem to matter.

You Ship Features. Nothing Changes.

You build something. It goes live. Everyone moves on.

No one talks about it again. No visible impact. No real feedback.

Sometimes it quietly gets disabled a few months later and nobody even notices.

That’s not burnout from overwork. That’s burnout from irrelevance.

Feature Factories Are Killing Motivation

Most teams don’t build products. They produce output.

Features are shipped because they were planned — not because they were proven to matter.

Success is measured in velocity, not in whether anything actually improved for a user.

So developers keep shipping, keep closing tickets, keep moving… but nothing meaningful changes.

That’s Where Motivation Dies

Most developers don’t hate coding.

They hate coding when it doesn’t connect to anything real.

When effort and outcome are disconnected long enough, motivation doesn’t fade slowly — it just shuts off.

At some point, you stop caring not because you’re lazy, but because caring doesn’t change anything.

This Isn’t a “Take a Break” Problem

This isn’t solved by vacations, meditation, or better time management.

Because the issue isn’t energy. It’s meaning.

And you can’t rest your way out of something that feels pointless.

The Uncomfortable Truth

A lot of what we call “developer burnout” is actually just long-term exposure to meaningless work.

And once you start seeing it, it’s hard to unsee it.

Not every team has this problem. But many do — quietly, structurally, and consistently.

Full Article

If this hits close to home, I broke it down in detail here:

Read the full article

Why AI Code That Looks Correct Still Breaks Real Backend Systems

Krun_Dev — Sat, 02 May 2026 20:42:18 +0000

AI Code Not Working in Real Projects

The gap between “code that works in isolation” and code that survives in production is where most AI-assisted development failures begin. Tools like ChatGPT or Copilot generate code in a simplified execution model: no real middleware chains, no legacy constraints, no hidden coupling, no operational history.

Production systems are the opposite. They are stateful, layered, and full of implicit contracts that are never explicitly described in prompts. This is why AI-generated code often compiles and passes local tests but breaks when integrated into a real backend.

Why AI Generated Code Works in Isolation but Fails in Production

Isolation tests create a misleading signal of correctness. A function may validate tokens, transform data, or query a mock database perfectly in a sandbox environment. However, once placed into a real execution chain, it interacts with middleware, caching layers, authentication pipelines, and side effects that were never part of the prompt context.

The failure is not logical — it is environmental. The AI has no visibility into execution order, shared state, or framework-specific lifecycle hooks, so it generates correct logic for a system that does not match your actual architecture.

AI Code Breaks Backend Assumptions

Backend systems rely on implicit contracts between layers: services, repositories, controllers, and error-handling middleware. These contracts are rarely visible in code snippets but are critical for system stability.

AI-generated implementations often violate these boundaries by returning null instead of throwing typed exceptions, or by bypassing centralized error handlers. These issues rarely crash the system — instead, they silently corrupt observability and make debugging significantly harder.

Silent Failure Patterns in Data Access Layers

One of the most common issues appears in repository and service layers. AI-generated code tends to simplify error handling, often catching exceptions and returning fallback values without propagating failure states properly.

This breaks system-wide assumptions about consistency and error propagation. The frontend or downstream services may interpret invalid states as valid responses, resulting in incorrect rendering or silent logic failures.

Business Logic Is the First Thing AI Gets Wrong

AI models struggle most with domain-specific rules. Pricing engines, discount logic, and permission systems often depend on internal constraints that are not visible in training data or prompt context.

As a result, generated implementations may look correct in unit tests but diverge from the authoritative business rules in production systems, especially when edge cases or enterprise-specific rules are involved.

Context Collapse in Large Codebases

Even modern LLMs with extended context windows cannot fully represent a real production system. A backend with hundreds of modules, services, and dependencies far exceeds practical prompt limits.

This forces the model to infer missing structure, which leads to statistically plausible but architecturally incorrect assumptions. Over time, this produces duplicated logic and inconsistent patterns across the codebase.

Inconsistent Output Across Sessions and Files

Because each AI interaction is stateless, identical tasks can produce different architectural decisions depending on what context is included in the prompt. This creates fragmentation when multiple developers or multiple sessions generate code for the same system.

The result is inconsistent patterns for error handling, service abstraction, and data flow — all of which appear locally correct but diverge globally.

How AI Code Damages System Architecture

The most expensive impact of AI-generated code is not functional bugs, but architectural degradation. Small shortcuts accumulate over time and erode separation of concerns.

AI Introduces Tight Coupling Between Layers

Without full architectural context, AI tends to collapse boundaries between layers. Controllers may directly access databases, or UI logic may depend on raw API responses instead of stable domain abstractions.

Each individual change appears harmless, but collectively they remove the system’s ability to evolve safely.

Invisible Production Bugs and State Corruption

The most dangerous failures are not exceptions, but subtle inconsistencies: race conditions, partial updates, and incorrect assumptions about data presence.

These issues only surface under real load conditions, distributed execution, or concurrent operations — making them difficult to reproduce in local environments.

Preventing AI-Induced System Drift

The solution is not avoiding AI tools, but constraining them with system-aware infrastructure: codebase indexing, architecture enforcement, and strict type validation.

Without these guardrails, AI will always optimize for local correctness instead of global system consistency.

You can learn more on the page https://krun.pro/why-ai-code-breaks/
— an in-depth analysis and breakdown by Krun Dev.

Why Mojo Fails Before Benchmark

Krun_Dev — Tue, 28 Apr 2026 15:30:56 +0000

Why Your Mojo System Design Fails Before the First Benchmark

Running Mojo but seeing benchmarks that mirror your old Python code is not a coincidence—it’s architectural debt. Mojo exposes low-level performance tools, but carrying over Python habits will hurt you fast. The closer you get to the metal, the more your script-like patterns backfire.

Quick Takeaways

Remaining in Python-interop mode incurs reference counting overhead that wipes out Mojo's performance benefits.
Object lists generate cache misses; SIMD-aligned Structs avoid them, delivering measurable speed-ups.
Mojo's borrow checker errors almost always result from ownership violations: owned, borrowed, and inout are explicit and essential.
parallelize() is safe only when workers do not share mutable memory. Otherwise, you invite race conditions.

The Python Brain Trap

Developers transitioning from Python often assume performance comes automatically. It doesn’t. Mojo provides SIMD, manual memory control, and zero-cost abstractions, but you must actively apply them. Writing Mojo code that mimics Python structures leads to severe slowdowns. PythonObject types carry reference counting costs—tight numeric loops can lose 40–60% of execution time.

Python-Interop: A Performance Dead Zone

The Python interop layer exists for migration convenience, not throughput. Using Python lists, Python functions, or PythonObject types inside Mojo kernels turns your code into a thin CPython wrapper. Every attribute access, length check, or loop iteration passes through Python’s runtime, killing performance.

Reference Counting: The Hidden Tax

Reference counting in PythonObject types introduces unpredictable micro-stalls in loops. Production Mojo code should convert Python data at the boundary and immediately switch to native Mojo types like DTypePointer, Tensor, or SIMD vectors for internal computation.

Memory Layout: Keeping the CPU Happy

Cache locality dominates performance. L1 caches are small (32–64 KB), so sequential memory access in contiguous arrays drastically reduces cache misses. Lists of heap-allocated objects scatter data, causing costly cache misses and slowing loops.

Structs vs Object Lists

Mojo beginners often model data as lists of structs (AoS). Iterating fields in such lists forces the CPU to load entire objects. A struct of arrays (SoA) keeps fields contiguous, enabling SIMD operations and prefetching, often yielding 4–8x speed improvements on numeric kernels.

struct ParticleSystem:
 var x_positions: DTypePointer[DType.float32]
 var y_positions: DTypePointer[DType.float32]
 var masses: DTypePointer[DType.float32]
 var count: Int

Heap Allocation in Loops

Allocating inside hot loops is costly. Each allocation invokes the memory allocator and triggers eventual garbage collection. Pre-allocate buffers outside loops and reuse them for maximum performance.

Borrow Checker and Ownership

Mojo enforces ownership similar to Rust, preventing segmentation faults and silent corruption. Variables can be owned, borrowed, or inout. Misusing them, especially owned after a transfer, leads to runtime crashes.

Safe Parallelism

parallelize() is easy but dangerous. Only partition data into isolated chunks for workers. Each worker should write to its own buffer, then reduce results sequentially. Shared mutable memory leads to unpredictable race conditions and inconsistent outcomes.

Five Best Practices for Mojo System Design

Use @value for pure data structs only: Avoid shallow copies of heap pointers.
Pre-allocate outside hot loops: Reuse buffers to avoid repeated allocation costs.
Pointer is powerful but dangerous: Use Pointer[T] only when ownership system cannot express requirements.
Understand decorator semantics: Overuse of @always_inline or @parameter can backfire.
Profile first: Focus on memory layout and cache misses before algorithm tweaks.

EEAT Takeaways

This article provides deep, expert insight into Mojo’s system-level design challenges. It emphasizes why Python habits harm performance, how memory layout affects cache efficiency, and how ownership and parallelism must be managed carefully. By following these principles, developers can transform script-like Mojo prototypes into high-performance kernels.

Krun Dev
krun.pro

Garbage Collection in Rust Without a Single unsafe Block

Krun_Dev — Fri, 24 Apr 2026 20:16:50 +0000

Mastering Garbage Collection in Rust without a single unsafe block

Let’s be real: most Rust GC libraries have a dirty secret buried in their Cargo.toml. They claim to be "memory safe" but immediately reach for unsafe blocks the moment a cyclic graph appears. They’ll tell you that managing back-references and complex object ownership is "impossible" within the borrow checker’s constraints. But that’s just a lack of imagination. You don't need raw pointers to build a high-performance collector; you need a better architecture. By swapping raw pointer manipulation for arena-based indices, we move the safety burden from your tired brain to the Rust compiler, where it belongs.

The core shift is simple: use a Vec-backed arena. Instead of juggling *mut T and praying you don't hit a use-after-free, you operate with u32 indices. This isn't just a workaround—it’s a robust design pattern that turns pointer arithmetic into bounds-checked lookups. It’s clean, it’s readable, and it’s 100% compliant with the strict rules of Safe Rust. No "trust me, bro" comments required in the source tree.

Eliminate raw pointer manipulation using Vec-backed arenas

The foundation of this zero-unsafe approach is the Heap struct, which acts as the sole owner of all objects. When you allocate something, you don't get a direct reference; you get a Gc<T> handle. This handle is a lightweight Copy type containing an index and a generation counter. By using indices instead of pointers, we let the CPU’s MMU and Rust’s runtime handle the heavy lifting of memory validation. If you try to access a stale handle, the system doesn't segfault—it simply returns None. LGTM, right? It’s the kind of stability that lets you ship on Fridays without breaking a sweat.

Implementing mark-and-sweep algorithm for heterogeneous object graphs

How do we reclaim memory without falling back on Arc or Rc? We build a classic two-phase mark-and-sweep collector. In the marking phase, we start from the "roots"—the Root<T> handles living on your stack—and traverse the graph. Each heap-allocated type implements a Trace trait, which is the contract telling the collector: "Hey, here are the other indices I’m holding." We use a simple Vec<u32> as a worklist to color the graph. Since we're just iterating over vectors and hash sets, the borrow checker remains perfectly happy. No pointer magic, just pure logic.

Managing Rooted handles with RAII to prevent memory leaks

The real secret sauce is how we handle liveness. A Root<T> isn't just a wrapper; it’s an RAII guard. As long as that Root is in scope, the object is shielded from the collector. The moment it drops, it unregisters itself from the root set. We use Rust’s lifetime system ('heap) to ensure you can't sneak a root past the lifetime of the heap itself. It’s a structural guarantee that prevents premature collection and dangling handles before they even happen. It's not just "safe"—it's architecturally impossible to mess up.

Scale memory management with generation counters and slots

Standard advice often pushes Arc<RwLock<T>> for shared state, but if you’re building a scripting engine or a complex DOM, Arc is a trap. It can't handle cycles, leading to silent memory leaks that bloat your process until it hits the OOM killer. Our arena-based GC solves this because it doesn't care about reference counts; it only cares about reachability. If the root set can't find you, you're gone. It’s a much more powerful liveness criterion that handles the "spaghetti graphs" of modern apps with ease.

Handling TypeId for dynamic dispatch in typed arenas

To keep things fast and type-safe, we utilize per-type arenas keyed by TypeId. This avoids the "vtable tax" of wrapping everything in a Box<dyn Trace>. When you call heap.alloc::<T>(), the system dispatches to the correct typed vector. This keeps your data contiguous in memory, which is a massive win for cache locality. We’re not just building a safe collector; we’re building an efficient one that respects the hardware while playing by the rules of the language.

At the end of the day, safe Rust is about making the right thing the easy thing. By moving your object graph into an arena, you trade a tiny bit of raw pointer speed for a massive gain in maintainability and correctness. Stop fighting the borrow checker and start using it to build better tools. Stay sharp, and keep those tags closed.

To master the technical implementation of zero-unsafe GC architecture in Rust and see the code in action, visit my site.

Kotlin 2.3.21 Fixes

Krun_Dev — Thu, 23 Apr 2026 22:18:23 +0000

Kotlin 2.3.21: The Release That Finally Makes KMP Build Performance Predictable

Kotlin 2.3.21 is one of those releases you don’t notice from the changelog, but you feel immediately if you work with Kotlin Multiplatform in production. It doesn’t introduce flashy language features — it fixes the stuff that quietly destroys developer productivity: broken incremental builds, unstable Wasm compilation, and fragile iOS linking via SPM.

For teams building high-load systems, shared codebases, or multi-target apps (Android, iOS, WebAssembly), this release is less about “new Kotlin features” and more about restoring trust in the build system. The K2 compiler finally behaves like a stable foundation instead of experimental infrastructure.

Kotlin Wasm incremental build performance improvements

One of the biggest pain points in Kotlin/Wasm was unpredictable incremental compilation. A small change in a shared module could trigger full rebuilds or backend failures due to klib metadata invalidation. Kotlin 2.3.21 introduces per-symbol fingerprinting inside klib metadata, which allows the incremental compilation engine to correctly detect what actually changed.

In real-world KMP projects, this means a rebuild that previously took 20–45 seconds or failed entirely now completes in a few seconds. The important part is not just speed — it’s consistency. Developers can iterate without constantly falling back to clean builds, which fundamentally changes the feedback loop in Wasm development.

Kotlin KMP iOS SPM linking issues resolved

Another major improvement is in Kotlin/Native integration with Swift Package Manager. Before 2.3.21, static frameworks built with isStatic = true often failed with unresolved arm64 symbols, forcing teams to manually inject linkerOpts and maintain fragile build workarounds.

The issue was rooted in incomplete parsing of SPM binary metadata. Kotlin 2.3.21 fixes this by properly resolving .pbe package graphs and feeding correct dependency paths into the LLVM linker pipeline. As a result, most manual linker configuration hacks can now be removed.

For teams maintaining KMP iOS production apps, this directly reduces build complexity and eliminates one of the most frustrating classes of “works locally but fails in CI” errors.

Kotlin K2 compiler compatibility and multi-module visibility fixes

K2 introduced stricter compilation rules, but in earlier versions it overreached in some cases. One of the most disruptive issues was incorrect handling of protected companion object members in multi-module projects, where valid inheritance-based access patterns were rejected.

Kotlin 2.3.21 aligns compiler behavior with the language specification. Subclasses can now correctly access protected companion members across modules without triggering false compilation errors. This removes the need for architectural workarounds introduced during K1 → K2 migration phases.

For large codebases, this is not just a fix — it’s cleanup of accumulated technical debt caused by compiler inconsistency.

Gradle build performance and CI/CD optimization in Kotlin 2.3.21

Beyond compiler fixes, Kotlin 2.3.21 improves Gradle task behavior, particularly around Android build pipelines. Tasks like MergeMappingFileTask previously re-executed unnecessarily due to overly broad input tracking. This led to wasted time in release builds, especially in large monorepos.

The fix improves input/output declaration accuracy, allowing Gradle to properly reuse cached results and avoid redundant execution. In large-scale projects, this translates into noticeable CI/CD time savings and better remote cache hit rates.

Combined with reduced compiler memory usage, this release makes parallel builds more efficient in shared CI environments, where resource constraints often become a bottleneck.

Why Kotlin 2.3.21 matters for Kotlin Multiplatform development in 2026

What makes Kotlin 2.3.21 important is not any single feature, but the cumulative effect of removing build system unpredictability. Kotlin Multiplatform has always been powerful but fragile at the edges — especially when dealing with Wasm, iOS linking, and incremental compilation across large module graphs.

This release addresses those exact failure points. It doesn’t change how you write Kotlin code. It changes whether your builds behave consistently when your system scales.

For teams running KMP in production, the upgrade is less about new capabilities and more about stability: faster incremental builds, fewer CI failures, and a compiler that finally behaves predictably under real-world load.

Full breakdown of the Kotlin 2.3.21 update is available at https://krun.pro/kotlin-2-3-21/
.
If you’re working with Kotlin Multiplatform or production systems, it’s worth reading to understand what actually changed under the hood.
Take a look and get familiar with the real impact of this release in a practical engineering context.

Kotlin in Production Backend Systems

Krun_Dev — Thu, 23 Apr 2026 15:10:20 +0000

What Actually Breaks When Kotlin Hits Production Load

Kotlin feels great—until prod traffic shows up and starts asking uncomfortable questions. Most teams celebrate the migration from Java somewhere around “less boilerplate, nicer syntax,” and then move on. That’s exactly where Kotlin backend production issues begin, hiding behind clean code and waiting for real load to expose them.

This isn’t about Kotlin being bad. It’s about misunderstanding what Kotlin actually is: a thin, elegant layer on top of the JVM. And the JVM doesn’t magically become nicer just because your code does. Garbage collection, heap pressure, thread pools, blocking I/O—those are still running the show. Kotlin just makes it easier to write code that accidentally stresses all of them faster.

Coroutines are the biggest example. They look like lightweight magic—spin up thousands, no problem. Except they don’t run on magic, they run on a finite thread pool. Throw one blocking call into the mix (hello JDBC, hello legacy HTTP client), and suddenly your “highly concurrent” system is just a queue waiting for threads to free up. From the outside: random latency spikes. From the inside: you quietly DDoS’d your own thread pool.

Then comes observability. Classic logging assumes one request = one thread. Coroutines don’t play that game. Execution jumps threads, and your trace IDs don’t come along for the ride unless you explicitly force them to. The result? Logs that look complete but tell you nothing. Traces that start strong and then just… vanish. Not a bug—just missing context propagation that nobody wired up.

And yes, Kotlin’s famous null safety. Works great—right until external data enters the system. Reflection-based tools like Jackson don’t care about your non-null types. They’ll happily inject nulls into places your compiler swore were safe. You won’t notice until runtime, under load, when something explodes far away from where the data came in.

The pattern is consistent: Kotlin doesn’t introduce most of these problems—it hides them better. The teams that succeed with Kotlin backend systems treat it like what it is: JVM engineering with nicer syntax. They audit blocking calls, profile allocation rates, wire up context propagation early, and assume external data will break their type guarantees.

Write Kotlin for humans. Debug it like a JVM system. That’s the difference between “it works on staging” and “it survives production.”

Senior Python Challenges

Krun_Dev — Thu, 23 Apr 2026 12:51:19 +0000

Senior Python Challenges: What I Learned After Moving From Writing Code to Running Systems in Production

Working with Python as a senior developer feels very different from writing scripts or building small services. At scale, the language stops being “simple and forgiving” and starts exposing every architectural decision you made earlier. What used to be elegant code in development often becomes a performance bottleneck, a concurrency trap, or a silent reliability risk in production.

This is a summary of the problems I repeatedly run into in real systems, why they happen, and how I approach them today—not in theory, but in production environments where downtime and latency actually matter.

Performance: When Clean Code Stops Being Fast Code

One of the first lessons I learned the hard way is that Python performance is rarely about syntax. It’s about how much work the interpreter is forced to do at runtime.

A simple loop that looks harmless in code review can become a serious issue under load.


import time

def slow_sum(n):
    result = 0
    for i in range(n):
        result += i
    return result

start = time.time()
slow_sum(10**7)
print(time.time() - start)

In isolation, this looks fine. In production, it becomes a measurable latency spike when called repeatedly. What changed my approach was learning to stop assuming “readable Python is always acceptable Python under scale.”

The fix is rarely micro-optimization. It is choosing the right abstraction level from the start.


def fast_sum(n):
    return sum(range(n))

The real senior-level shift here is discipline: I profile first, and only then decide whether pure Python is even justified.

Concurrency: The GIL Reality Check

Early in my career, I assumed threads meant parallelism. Python quickly corrected that assumption.

The Global Interpreter Lock (GIL) changes how concurrency actually behaves in CPU-bound workloads. Adding threads often makes things worse, not better.


import threading

def cpu_task(n):
    count = 0
    while count < n:
        count += 1

Even when I scale this with multiple threads, the result is still serialized execution under the interpreter.

What I had to internalize is simple: threads in Python are not a performance tool for CPU-heavy work.

Real scaling starts only when I move to separate processes:


from multiprocessing import Pool

def cpu_task(n):
    return sum(i * i for i in range(n))

with Pool(4) as p:
    results = p.map(cpu_task, [10**7] * 4)

This mental model shift—from “parallel threads” to “isolated processes”—is one of the most important transitions in senior Python work.

Async Systems: Where Bugs Stop Being Visible

Async Python is powerful, but it’s also one of the easiest places to introduce invisible production issues.

What I’ve learned is that async failures rarely crash systems—they degrade them silently.


import asyncio

async def fetch_data(n):
    await asyncio.sleep(n)
    return n

async def main():
    results = await asyncio.gather(fetch_data(1), fetch_data(2))
    print(results)

asyncio.run(main())

The danger here is not the syntax. It is mixing blocking and non-blocking code in ways that only appear under load.

My rule now is strict: if a function is async, nothing inside it should block. Ever.

Memory: The Slowest Type of Production Failure

Memory issues are dangerous because they don’t fail immediately. They accumulate.

Circular references, hidden caches, or long-lived objects can silently grow memory usage until the system becomes unstable.


import gc

a = []
b = [a]
a.append(b)

del a, b
gc.collect()

What I learned is that garbage collection is not a safety net for architecture mistakes. It is just cleanup, not control.

In real systems, I now treat memory as a design constraint, not an implementation detail.

Testing: When Mocks Start Hiding Real Problems

One of the most misleading things in Python systems is over-mocked testing. It creates confidence that does not survive production.


from unittest.mock import MagicMock

service = MagicMock()
service.fetch_data.return_value = {"id": 1}

This kind of test passes easily, but it often stops validating real behavior.

What I rely on now is dependency injection and realistic integration paths instead of heavy mocking. It keeps tests closer to actual system behavior.


class DataFetcher:
    def __init__(self, client):
        self.client = client

    def get_data(self):
        return self.client.fetch()

This structure is far more stable when systems evolve.

Dependencies: The Silent Source of Production Breakage

Dependency management is one of those problems that looks solved until it isn’t. Conflicts, transitive upgrades, and version drift can break systems without any code changes.


# requirements.txt
Django==4.2
requests==2.32

What I’ve learned is that reproducibility matters more than convenience. I now treat environment consistency as part of system design, not setup.

Tools that lock dependency graphs are not optional in production systems—they are mandatory.

Security: The Small Mistakes That Become Incidents

Security issues in Python are usually not complex. They are simple mistakes in unsafe assumptions.


cursor.execute(f"SELECT * FROM users WHERE id={user_input}")

This kind of pattern is still surprisingly common in legacy systems.

The safe version is always explicit and parameterized:


cursor.execute("SELECT * FROM users WHERE id=?", (user_input,))

What I learned is that security is not a feature you add later—it is something you enforce in every layer of data handling.

Conclusion: Senior Python Work Is System Thinking, Not Syntax

At this level, Python is no longer about writing code that works. It is about building systems that stay stable under load, scale without surprises, and fail in predictable ways.

Performance, concurrency, memory, testing, dependencies, and security are not separate topics—they are interconnected failure surfaces.

The biggest shift in my own thinking was realizing this: Python does not hide complexity. It reveals it over time.

Senior development is not about avoiding problems. It is about designing systems where problems are visible, isolated, and controllable before they reach production.
Source: https://krun.pro/mastering-senior-python-pitfalls/

10 Python Pitfalls

Krun_Dev — Wed, 22 Apr 2026 21:45:21 +0000

10 Python Pitfalls That Scream You Are a Junior Developer

Python looks easy at first, but when your project hits production and heavy load, small mistakes can become big problems. This article covers 10 common pitfalls that slow your code, waste memory, and reveal you as a junior. If you want Python that runs fast, stays stable, and scales in 2026, this guide is for you.

One common trap is mutable default arguments. Using lists or dictionaries as default parameters might seem handy, but Python creates the object once when the function is defined, and it gets shared across all calls. Data from one request can leak into another. The fix is to use None and create the object inside the function so each call starts fresh.

Performance bottlenecks are everywhere. Heavy for-loops trigger type checks, lookups, and memory tasks for every item. On large datasets, this slows everything down. List comprehensions, generator expressions, or NumPy vectorization are faster and more efficient.

The Global Interpreter Lock (GIL) is often misunderstood. It blocks multiple threads from running Python bytecode at the same time, which limits CPU-bound tasks. Using the multiprocessing module spins up separate processes for each core and bypasses GIL.

Memory management is another issue. Loading large datasets into memory at once can crash production. Generators let you process items one at a time, keeping memory use low and predictable.

Type hinting is essential. Dynamic typing is fine for small projects, but in larger codebases, missing hints lead to bugs. Tools like Mypy or Pyright catch errors before runtime and improve IDE autocompletion. Treat type hints as contracts between parts of your code.

Async code has its pitfalls. Blocking calls inside async functions stop the event loop. Use awaitable, non-blocking calls and libraries like httpx or motor to maintain concurrency.

Pythonic encapsulation avoids unnecessary boilerplate. Instead of writing explicit getters and setters for everything, use property decorators to keep your classes clean and readable.

Error handling matters. Catch only expected exceptions and use context managers to manage resources. Blindly swallowing errors hides bugs and can make production unstable.

Advanced data structures matter for performance. Using dictionaries for millions of objects wastes memory. Data classes or named tuples reduce overhead, provide structure, and are easier to debug.

Efficient iteration is key. Avoid complex nested loops and use the itertools module. Functions like chain let you iterate over multiple collections without creating temporary lists in memory.

Mastering these pitfalls will make your code more stable, readable, and ready for high-load systems. Writing clever code is fun, but writing code that runs well in production is what separates juniors from senior Python developers.

https://krun.pro/10-python-anti-patterns/

Kotlin Coroutines in Production

Krun_Dev — Wed, 22 Apr 2026 21:36:15 +0000

Your Coroutines Work Locally. Then Production Happens.

You wrote the async code. It's elegant, non-blocking, and runs beautifully on your machine. Then you deploy — and somewhere around 3 AM, Grafana wakes you up with a memory graph that looks like a ski slope. Welcome to Kotlin Coroutines in Production.

This guide skips the Hello World phase entirely. It's about what happens when real load hits — thread starvation, silent memory leaks, and exception handlers that don't actually handle anything. The kind of bugs that only show up at scale and only at the worst possible time.

Scopes, Supervisors, and Why the Wrong Choice Crashes Everything

Most developers treat coroutineScope and supervisorScope as roughly the same thing. They are not. With coroutineScope, one failing child cancels the parent and every sibling — great for all-or-nothing operations, catastrophic for independent tasks. In production, supervisorScope is almost always the right call. Understanding the difference between coroutineContext vs coroutineScope vs supervisorScope is what separates code that survives partial failures from code that doesn't.

Exception Handling That Actually Works

Wrapping await() in a try-catch is not enough. By the time your catch block runs, the parent scope may already be cancelling. Exceptions in coroutines behave differently depending on whether you used launch or async — and a "swallowed" exception in production means 500 errors with no logs on the backend, or an "App has stopped" dialog on Android. The right pattern is a CoroutineExceptionHandler installed at every root scope, paired with supervisorScope to contain blast radius.

Thread Starvation and the Custom Dispatcher You Actually Need

Dispatchers.IO is a reasonable default. It is not enough when you mix non-blocking code with slow legacy database drivers under serious load. The answer is a custom coroutine dispatcher for heavy IO — an isolated fixed thread pool for the slow stuff, so the rest of your app stays responsive. Pair that with limitedParallelism(n) on Dispatchers.Default to cap background CPU work, and you have a proper bulkhead that keeps your latency-sensitive paths alive when everything else is under pressure.

Leaks, Ghosts, and the Danger of GlobalScope

A coroutine lives in memory as long as its Job is active. Lose the reference, and you have a ghost — running, consuming resources, invisible. The most common cause is GlobalScope used for "just a quick task." The diagnostic tool is DebugProbes from kotlinx-coroutines-debug: it dumps every active coroutine with a stack trace so you can see exactly what's suspended and why. The long-term fix is simpler — never break the parent-child hierarchy, and always bind coroutines to a lifecycle-aware scope.

If It Works on Your Machine, That Is Not Enough

Structured concurrency pitfalls in large-scale systems, state confinement without locks, the island effect that leaves thousands of zombie tasks burning CPU — it's all in the full article.

Production won't wait for you to finish the docs. But reading this first might mean you actually sleep through the night.

https://krun.pro/kotlin-coroutines-in-production/