<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Go Standard Library Mastery on Atharva Pandey</title><link>https://atharva.page/series/go-standard-library-mastery/</link><description>Recent content in Go Standard Library Mastery on Atharva Pandey</description><generator>Hugo</generator><language>en-us</language><copyright>Copyright ©</copyright><lastBuildDate>Sat, 05 Jul 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://atharva.page/series/go-standard-library-mastery/index.xml" rel="self" type="application/rss+xml"/><item><title>Lesson 8: strings and bytes Builders — Stop concatenating in loops</title><link>https://atharva.page/post/go/go-stdlib-strings-bytes/</link><pubDate>Sat, 05 Jul 2025 00:00:00 +0000</pubDate><guid>https://atharva.page/post/go/go-stdlib-strings-bytes/</guid><description>&lt;p&gt;String concatenation with &lt;code&gt;+&lt;/code&gt; is one of the most common performance bugs I see in Go code reviews. Not because developers are careless, but because the bug is invisible — the code looks clean and correct. &lt;code&gt;result += piece&lt;/code&gt; is obvious. The quadratic memory behavior that follows is not.&lt;/p&gt;
&lt;p&gt;The &lt;code&gt;strings&lt;/code&gt; and &lt;code&gt;bytes&lt;/code&gt; packages are where Go provides the right tools for this job. &lt;code&gt;strings.Builder&lt;/code&gt; and &lt;code&gt;bytes.Buffer&lt;/code&gt; are both efficient for incremental string construction, but they&amp;rsquo;re not the same type and the choice between them matters in specific cases. Beyond building strings, these packages contain functions that have non-obvious but significant performance implications: &lt;code&gt;strings.Contains&lt;/code&gt; vs &lt;code&gt;strings.Index&lt;/code&gt;, &lt;code&gt;strings.Split&lt;/code&gt; vs &lt;code&gt;strings.SplitN&lt;/code&gt;, and the ones people reach for that they shouldn&amp;rsquo;t.&lt;/p&gt;</description></item><item><title>Lesson 7: context Internals — How cancellation propagates under the hood</title><link>https://atharva.page/post/go/go-stdlib-context/</link><pubDate>Thu, 22 May 2025 00:00:00 +0000</pubDate><guid>https://atharva.page/post/go/go-stdlib-context/</guid><description>&lt;p&gt;&lt;code&gt;context.Context&lt;/code&gt; is the most important type in Go&amp;rsquo;s standard library that most people use by convention without fully understanding. You pass it as the first argument to functions. You check &lt;code&gt;ctx.Done()&lt;/code&gt; in goroutines. You create derived contexts with &lt;code&gt;context.WithTimeout&lt;/code&gt;. It works — until it doesn&amp;rsquo;t, and you have a goroutine that doesn&amp;rsquo;t cancel when the parent context does, or a context that leaks forever because you forgot to call the cancel function.&lt;/p&gt;</description></item><item><title>Lesson 6: sync Package Complete Guide — Mutex, Once, Pool, Map — when to use each</title><link>https://atharva.page/post/go/go-stdlib-sync/</link><pubDate>Sat, 22 Mar 2025 00:00:00 +0000</pubDate><guid>https://atharva.page/post/go/go-stdlib-sync/</guid><description>&lt;p&gt;The &lt;code&gt;sync&lt;/code&gt; package is where Go&amp;rsquo;s concurrency tools live when channels aren&amp;rsquo;t the right answer. &lt;code&gt;sync.Mutex&lt;/code&gt;, &lt;code&gt;sync.RWMutex&lt;/code&gt;, &lt;code&gt;sync.WaitGroup&lt;/code&gt;, &lt;code&gt;sync.Once&lt;/code&gt;, &lt;code&gt;sync.Pool&lt;/code&gt;, &lt;code&gt;sync.Map&lt;/code&gt; — each one solves a specific problem, and using the wrong one is a reliable way to introduce bugs or performance regressions. I&amp;rsquo;ve misused all of them at various points.&lt;/p&gt;
&lt;p&gt;The general guidance is channels for communication, mutexes for protecting shared state. But within the mutex family, the choice between Mutex, RWMutex, and sync.Map has performance implications that matter in hot paths. And sync.Pool is frequently misunderstood — it&amp;rsquo;s not a general-purpose object pool; it&amp;rsquo;s a GC-aware buffer recycler.&lt;/p&gt;</description></item><item><title>Lesson 5: os and filepath — Cross-platform file operations that actually work</title><link>https://atharva.page/post/go/go-stdlib-os-filepath/</link><pubDate>Wed, 22 Jan 2025 00:00:00 +0000</pubDate><guid>https://atharva.page/post/go/go-stdlib-os-filepath/</guid><description>&lt;p&gt;Go&amp;rsquo;s &lt;code&gt;os&lt;/code&gt; and &lt;code&gt;path/filepath&lt;/code&gt; packages are among the most underappreciated in the standard library. Most developers know &lt;code&gt;os.Open&lt;/code&gt;, &lt;code&gt;os.Create&lt;/code&gt;, and &lt;code&gt;os.ReadFile&lt;/code&gt;. Far fewer know &lt;code&gt;os.MkdirAll&lt;/code&gt;, &lt;code&gt;os.CreateTemp&lt;/code&gt;, &lt;code&gt;filepath.WalkDir&lt;/code&gt;, or the difference between &lt;code&gt;path&lt;/code&gt; and &lt;code&gt;path/filepath&lt;/code&gt; — which is the difference between code that works everywhere and code that silently breaks on Windows.&lt;/p&gt;
&lt;p&gt;I maintain a CLI tool that runs on macOS, Linux, and Windows. The file operation bugs I&amp;rsquo;ve shipped have taught me exactly which parts of these packages require care.&lt;/p&gt;</description></item><item><title>Lesson 4: time Package Gotchas — Timezones, monotonic clocks, and the bug in your cron</title><link>https://atharva.page/post/go/go-stdlib-time/</link><pubDate>Mon, 18 Nov 2024 00:00:00 +0000</pubDate><guid>https://atharva.page/post/go/go-stdlib-time/</guid><description>&lt;p&gt;The &lt;code&gt;time&lt;/code&gt; package looks straightforward right up until the moment a bug report arrives saying &amp;ldquo;the nightly job didn&amp;rsquo;t run last Sunday.&amp;rdquo; It never runs on the Sunday when daylight saving time ends. Because that Sunday has 25 hours, and the cron expression fires twice at the ambiguous time, and the second firing is skipped because the code thinks it already ran. I&amp;rsquo;ve debugged this exact bug, and the root cause is always the same: someone — usually me — assumed time is simpler than it is.&lt;/p&gt;</description></item><item><title>Lesson 3: encoding/json Beyond Basics — Custom marshalers, streaming, and the traps</title><link>https://atharva.page/post/go/go-stdlib-json/</link><pubDate>Mon, 30 Sep 2024 00:00:00 +0000</pubDate><guid>https://atharva.page/post/go/go-stdlib-json/</guid><description>&lt;p&gt;&lt;code&gt;encoding/json&lt;/code&gt; is one of the first packages every Go developer uses and one of the last they fully understand. The basic &lt;code&gt;json.Marshal&lt;/code&gt; / &lt;code&gt;json.Unmarshal&lt;/code&gt; API is approachable. But the package contains a whole layer of capabilities — custom marshaling, streaming decoders, &lt;code&gt;json.RawMessage&lt;/code&gt; for deferred parsing, interface-type fields, and a surprising number of edge cases — that separate the code that works in demos from the code that works in production with adversarial inputs.&lt;/p&gt;</description></item><item><title>Lesson 2: io Patterns — Reader, Writer, and the composability that makes Go great</title><link>https://atharva.page/post/go/go-stdlib-io/</link><pubDate>Fri, 16 Aug 2024 00:00:00 +0000</pubDate><guid>https://atharva.page/post/go/go-stdlib-io/</guid><description>&lt;p&gt;The &lt;code&gt;io&lt;/code&gt; package is three hundred lines of interface definitions and a handful of utility functions. It is also the spine of the entire Go standard library. Every package that reads or writes data — &lt;code&gt;os&lt;/code&gt;, &lt;code&gt;net&lt;/code&gt;, &lt;code&gt;compress/gzip&lt;/code&gt;, &lt;code&gt;crypto/tls&lt;/code&gt;, &lt;code&gt;encoding/json&lt;/code&gt;, &lt;code&gt;bufio&lt;/code&gt; — does it through &lt;code&gt;io.Reader&lt;/code&gt; and &lt;code&gt;io.Writer&lt;/code&gt;. Once you understand these two interfaces, the standard library clicks into place as one coherent system.&lt;/p&gt;
&lt;p&gt;I spent my first few months with Go treating &lt;code&gt;io.Reader&lt;/code&gt; as the thing that HTTP response bodies happen to be. It wasn&amp;rsquo;t until I built a streaming CSV processor — piping data from S3 through gzip decompression into a CSV parser, all without loading the file into memory — that I understood what the interfaces were actually designed for.&lt;/p&gt;</description></item><item><title>Lesson 1: net/http Deep Dive — The most important package you use wrong</title><link>https://atharva.page/post/go/go-stdlib-net-http/</link><pubDate>Tue, 02 Jul 2024 00:00:00 +0000</pubDate><guid>https://atharva.page/post/go/go-stdlib-net-http/</guid><description>&lt;p&gt;Every Go web service I&amp;rsquo;ve reviewed starts with &lt;code&gt;net/http&lt;/code&gt;. Most of them use it correctly for the obvious parts and incorrectly for the subtle ones. The package API is deceptively simple — &lt;code&gt;http.HandleFunc&lt;/code&gt;, &lt;code&gt;http.ListenAndServe&lt;/code&gt;, and you&amp;rsquo;re serving HTTP. But the design decisions underneath — how request routing works, what a &lt;code&gt;Handler&lt;/code&gt; actually is, how the server manages connections, what the default timeouts are — contain enough traps to keep a senior engineer busy for a week.&lt;/p&gt;</description></item></channel></rss>