<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Go on Asadbek Kurbonov</title><link>https://advenn.github.io/blog/tags/go/</link><description>Recent content in Go on Asadbek Kurbonov</description><generator>Hugo -- 0.148.0</generator><language>en-us</language><lastBuildDate>Mon, 24 Nov 2025 22:00:00 +0100</lastBuildDate><atom:link href="https://advenn.github.io/blog/tags/go/index.xml" rel="self" type="application/rss+xml"/><item><title>When You Can't Find the Bug: Architecting Around Production Issues</title><link>https://advenn.github.io/blog/posts/go-python-architecture/</link><pubDate>Mon, 24 Nov 2025 22:00:00 +0100</pubDate><guid>https://advenn.github.io/blog/posts/go-python-architecture/</guid><description>&lt;p>&lt;em>This is Part 2 of a series. Read &lt;a href="../pandas-vs-polars-in-production/">Part 1: Pandas vs Polars in Production - Performance Comparison&lt;/a> for the background on the Polars migration.&lt;/em>&lt;/p>
&lt;hr>
&lt;p>After migrating from Pandas to Polars, CPU performance improved dramatically—but a memory problem persisted. Despite extensive debugging, I couldn&amp;rsquo;t identify the root cause. So I made a pragmatic decision: architect around it.&lt;/p>
&lt;p>This is the story of splitting a monolithic Python application into a Go orchestration service with Python workers, not because I fully understood the problem, but because I needed production to be stable.&lt;/p></description></item></channel></rss>