Rate limiting in payment systems is different from rate limiting in a typical web API. A false positive – rejecting a legitimate authorization – is a failed transaction. A customer’s card gets declined at checkout. That is not an acceptable failure mode.
\nA payment authorization pipeline typically looks like this:
\ngraph LR\n A[Card Network] -->|ISO 8583| B[Parser API]\n B -->|gRPC| C[Distributor API]\n C -->|gRPC| D[Account Service]\n C -->|gRPC| E[Risk Engine]\n C -->|gRPC| F[Ledger]
The rate limiter sits between the Parser API and the Distributor API. It must make a decision in under 1ms.
\n\nWarning
\nNever rate-limit at the card network ingress point. Network protocols like ISO 8583 have strict timeout windows. A delayed response is worse than a fast decline: it triggers a reversal cascade.
\n
The token bucket algorithm maintains a counter that refills at a fixed rate. Each request consumes one token.
\n\nTip
\nSet C to handle your peak burst (Black Friday spike) and r to your sustained p99 throughput. For authorization systems, measure both per-issuer and per-BIN to avoid penalizing an entire bank for one merchant’s spike.
\n
Tracks the exact timestamp of every request in a time window. Precise, but memory-intensive.
\nToken Bucket: O(1) memory, O(1) time, allows bursts. No per-client fairness without separate buckets. Best for global throughput protection.
\nSliding Window: Precise rate tracking, smooth distribution. O(n) memory for log variant, interpolation error for counter variant. Best for per-client or per-issuer fairness.
\nsequenceDiagram\n participant Client\n participant Region A\n participant Region B\n participant Redis\n Client->>Region A: Auth Request 1\n Client->>Region B: Auth Request 2\n Region A->>Redis: INCR counter\n Region B->>Redis: INCR counter\n Redis-->>Region A: count=1 (allow)\n Redis-->>Region B: count=2 (allow)
\n\nThe fundamental tension: strong consistency (single Redis) adds a network hop to every authorization, while eventual consistency allows brief over-admission. For payment systems, brief over-admission is almost always preferable to adding latency.
\n
type TokenBucket struct {\n mu sync.Mutex\n tokens float64\n capacity float64\n rate float64\n lastTime time.Time\n}\n\nfunc (tb *TokenBucket) Allow() bool {\n tb.mu.Lock()\n defer tb.mu.Unlock()\n now := time.Now()\n elapsed := now.Sub(tb.lastTime).Seconds()\n tb.tokens = math.Min(tb.capacity, tb.tokens+tb.rate*elapsed)\n tb.lastTime = now\n if tb.tokens >= 1 {\n tb.tokens--\n return true\n }\n return false\n}\n\nThis implementation uses a mutex for simplicity. In production, consider
\nsync/atomicwith CAS operations for lock-free performance, or a sharded bucket per goroutine with periodic merging.
\n\nDesign decisions for payment rate limiters:
\n\n
\n- Token bucket for global protection, sliding window for per-client fairness
\n- Local-first with async sync beats centralized coordination for latency
\n- Set capacity from measured burst patterns, not theoretical maximums
\n- Monitor rejection rate as a business metric, not just an infra metric
\n
Web API Rate Limiting: Return 429 Too Many Requests. Client retries with backoff. False positives are annoying but recoverable.
\nPayment Rate Limiting: Return decline response code in ISO 8583. No retry – transaction is failed. False positives are declined cards at checkout.
\nThe difference between rate limiting a REST API and rate limiting an authorization pipeline is the cost of a false positive. In payments, you are not protecting a server – you are deciding whether someone’s groceries get paid for.
\n" }, { "id": "https://ashwingopalsamy.in/library/notes/understanding-iso8583-bitmaps/", "url": "https://ashwingopalsamy.in/library/notes/understanding-iso8583-bitmaps/", "title": "Understanding ISO 8583 Bitmap Parsing", "content_text": "How ISO 8583 bitmaps declare which data elements are present, and how to parse them at authorization ingress.", "date_published": "2026-04-01T00:00:00.000Z", "tags": [ "notes" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ], "content_html": "Every ISO 8583 message begins with a Message Type Indicator (MTI), followed by one or two bitmaps that declare which data elements are present in the message.
\nA bitmap is a binary structure where each bit position corresponds to a data element. If bit N is set to 1, data element N is present in the message. If it is 0, the element is absent.
\nThe primary bitmap is always 64 bits (8 bytes). If bit 1 of the primary bitmap is set, a secondary bitmap follows, extending the field range from 65 to 128.
\nThe parsing logic is straightforward once you understand the bit layout:
\nfunc ParseBitmap(data []byte) (Bitmap, error) {\n if len(data) < 8 {\n return Bitmap{}, fmt.Errorf(\"bitmap data too short: %d bytes\", len(data))\n }\n\n primary := binary.BigEndian.Uint64(data[:8])\n bm := Bitmap{Primary: primary}\n\n if primary&(1<<63) != 0 {\n if len(data) < 16 {\n return Bitmap{}, fmt.Errorf(\"secondary bitmap indicated but data too short\")\n }\n bm.Secondary = binary.BigEndian.Uint64(data[8:16])\n bm.HasSecondary = true\n }\n\n return bm, nil\n}The elegance of this design is that the message is self-describing. No schema negotiation, no version headers, no content-type declarations. The bitmap IS the schema.
\nThis means a parser can handle any valid ISO 8583 message without knowing in advance which fields will be present. The bitmap tells it exactly what to expect and where to find it.
\nThe fmt.Errorf(\"context: %w\", err) pattern is the standard way to add context to errors in Go. But there are nuances worth knowing.
Always wrap with context that answers “what were you trying to do?” not “what went wrong?” The original error already says what went wrong.
\nBad: fmt.Errorf(\"error: %w\", err)\nGood: fmt.Errorf(\"parsing field DE%d: %w\", fieldNum, err)
On March 24, 2026, Callum McMahon at FutureSearch was testing a Cursor MCP plugin that pulled in litellm as a transitive dependency. Shortly after, his machine became unresponsive. He traced it to a newly installed litellm package.
\nLiteLLM is a Python library that works like a universal remote for AI APIs. 95 million downloads per month on PyPI. ~40,000 GitHub stars.
\nsequenceDiagram\n participant A as Attacker (TeamPCP)\n participant T as Trivy GitHub Repo\n participant CI as LiteLLM CI (GitHub Actions)\n participant P as PyPI Registry\n\n Note over A,T: March 1 - Initial Compromise\n A->>T: Submit malicious PR (Pwn Request)\n T-->>A: CI leaks personal access token\n Note over CI,P: March 24 - Package Takeover\n CI->>T: Pull trivy-action@latest (not pinned to SHA)\n T-->>CI: Serve compromised action\n CI-->>A: Leak PyPI publisher token\n A->>P: Publish litellm v1.82.7 (inline payload)\n A->>P: Publish litellm v1.82.8 (.pth persistence)
graph LR\n A[\"Trivy Repo\\n(compromised)\"] --> B[\"GitHub Bot Army\"]\n B --> C[\"PyPI Account Takeover\"]\n C --> D[\"LiteLLM v1.82.7 / v1.82.8\"]\n D --> E[\".pth Backdoor\"]\n E --> F[\"Credential Harvest\"]\n F --> G[\"Exfil Server (ICP Canister)\"]
The payload was triple-nested: a base64 blob decodes to an orchestrator script, which decodes a second base64 blob containing the harvester.
\ngraph TD\n ROOT[\".pth Backdoor\"]\n ROOT --> ENV[\"ENV Variables\"]\n ROOT --> AWS[\"~/.aws/credentials\"]\n ROOT --> DOTENV[\".env Files\"]\n ROOT --> PROC[\"/proc/self/environ\"]\n ROOT --> EXFIL[\"Outbound HTTP Exfil to ICP canister\"]\n ENV --> EXFIL\n AWS --> EXFIL\n DOTENV --> EXFIL\n PROC --> EXFIL
Two versions were published:
\nlitellm/proxy/proxy_server.py.pth file that executes every time Python starts\n\n\n
.pthfiles insite-packagesexecute code before your application begins, on every Python invocation: pytest, IDE language server, even pip install.
ls ~/.config/sysmon/sysmon.py 2>/dev/null && echo \"BACKDOOR FOUND\"\nfind $(python3 -c \"import site; print(' '.join(site.getsitepackages()))\") \\\n -name \"litellm_init.pth\" 2>/dev/null\n\n" }, { "id": "https://ashwingopalsamy.in/library/notes/consistent-hashing-distributed-caches/", "url": "https://ashwingopalsamy.in/library/notes/consistent-hashing-distributed-caches/", "title": "Consistent Hashing in Distributed Caches", "content_text": "How consistent hashing keeps cache keys stable when nodes join or leave, and why modular hashing fails under churn.", "date_published": "2026-03-15T00:00:00.000Z", "tags": [ "notes" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ], "content_html": "If anything shows up, upgrading the package is not enough. Rotate all LLM provider API keys, cloud credentials, GitHub and PyPI tokens, CI/CD secrets, and SSH keys. Rebuild from known-good images. The last known-clean version is 1.82.6.
\n
When you distribute data across multiple cache nodes, the naive approach is modular hashing: node = hash(key) % num_nodes. This works until you add or remove a node.
If you have 4 nodes and add a 5th, almost every key remaps to a different node. With hash(key) % 4 becoming hash(key) % 5, roughly 80% of your cache is invalidated instantly. Under load, this is a cache stampede.
Consistent hashing arranges the hash space into a ring. Each node is assigned one or more positions on the ring. A key is hashed to a position, and the first node clockwise from that position owns the key.
\nWhen a node joins, it takes responsibility for a portion of its neighbor’s range. When a node leaves, its range is absorbed by the next node clockwise. In both cases, only K/N keys need to move, where K is the total number of keys and N is the number of nodes.
Real implementations use virtual nodes – each physical node gets multiple positions on the ring. This smooths out the distribution and prevents hotspots caused by uneven hash space allocation.
\nGo 1.21 introduced log/slog in the standard library. For new projects, I now default to slog over zerolog.
The API is cleaner, it is part of the standard library (no dependency), and the handler interface makes it trivial to swap backends. The performance gap that once justified zerolog has narrowed significantly.
\n" }, { "id": "https://ashwingopalsamy.in/library/notes/uuids-for-idempotency/", "url": "https://ashwingopalsamy.in/library/notes/uuids-for-idempotency/", "title": "Why UUIDs Matter for Idempotency", "content_text": "Why idempotency keys matter in payments: processing the same authorization twice is worse than rejecting it.", "date_published": "2026-02-20T00:00:00.000Z", "tags": [ "notes" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ], "content_html": "In payment processing, processing the same authorization twice is worse than rejecting it. A customer charged twice loses trust immediately. Idempotency keys prevent this.
\nA client sends an authorization request. The network drops the response. The client retries. Without idempotency, the server processes the authorization again, resulting in a double charge.
\nThe client generates a UUID before the first attempt and includes it in every retry. The server checks: have I seen this UUID before? If yes, return the original response. If no, process the request and store the UUID with its response.
\nUUID v7 embeds a Unix timestamp in the first 48 bits, followed by random bits. This gives you:
\nI was working on a minimal word counter. Read from stdin, normalize the input, increment the value for the keys in a map[string]int. The output looked sorted. Alphabetically sorted.
I ran it again. Same order. Added more input. Still sorted.
\nAt that point, my instincts kicked in. Go maps are unordered. I knew that. So why was the output behaving so politely?
\nGo maps do not guarantee iteration order. Ever. The language spec is explicit.
\nA Go map is a hash table. Iteration walks buckets in a runtime-defined sequence, not key order.
\ngraph LR\n subgraph \"Hash Function\"\n H[\"hash(key)\"]\n end\n K1[\"a\"] --> H\n K2[\"b\"] --> H\n K3[\"m\"] --> H\n K4[\"1\"] --> H\n H --> B0[\"Bucket 0\\n1\"]\n H --> B1[\"Bucket 1\\n2\"]\n H --> B3[\"Bucket 3\\na\"]\n H --> B4[\"Bucket 4\\nb\"]\n H --> B6[\"Bucket 6\\nm\"]
Small number of keys, short ASCII strings, no map resizing during insertion. Under these conditions, hash values distribute nicely across buckets, and the bucket layout in memory often correlates with lexical order. By coincidence.
\ngraph TD\n S[\"Small ASCII key set\"]\n L[\"Large / diverse key set\"]\n S --> O1[\"Appears sorted (coincidence)\"]\n L --> O2[\"Visibly unordered (reality)\"]
Input keys: a b m x y z 1 2 9\n\nBuckets in memory order:\n[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11]\n 1 2 9 a b m x y z\n\nIteration walks buckets left to right:\n1 2 9 a b m x y zDigits first. Then letters. Within each group, alphabetical-looking. No sorting happened. Change the input distribution, force collisions, trigger a map resize, and this illusion breaks instantly.
\n\n\n" }, { "id": "tag:ashwingopalsamy.in,2025-11-20:books/database-internals", "url": "https://ashwingopalsamy.in/library/", "title": "Database Internals", "content_text": "", "date_published": "2025-11-20T00:00:00.000Z", "tags": [ "books" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "https://ashwingopalsamy.in/library/notes/go-floating-point-tolerance-testing/", "url": "https://ashwingopalsamy.in/library/notes/go-floating-point-tolerance-testing/", "title": "Floating-Point Tolerance Testing in Go", "content_text": "Why 0.1 + 0.2 isn't 0.3 in financial Go tests, and how to assert floating-point results with tolerance.", "date_published": "2025-08-17T00:00:00.000Z", "tags": [ "notes" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ], "content_html": "Deterministic-looking behavior does not imply guarantees.
\n
Last Tuesday, I was knee-deep in a financial calculation service when my tests started failing. You know that sinking feeling when 0.1 + 0.2 doesn’t equal 0.3? That was my afternoon.
This got me thinking about when we actually need tolerance-based comparisons versus when we’re just cargo-culting best practices.
\ngraph LR\n A[\"0.1 + 0.2\"] --> B[\"IEEE 754\"]\n B --> C[\"0.30000...04\"]\n D[\"0.3\"] --> E[\"IEEE 754\"]\n E --> F[\"0.29999...99\"]\n C --> G[\"Gap = epsilon\"]\n F --> G
I was working on a discount calculation system:
\nfunc calculateDiscount(price, rate float64) float64 {\n return price * rate\n}\n\nfunc TestDiscountCalculation(t *testing.T) {\n price := 29.99\n rate := 0.15\n expected := 4.4985\n result := calculateDiscount(price, rate)\n if result != expected {\n t.Errorf(\"got %v, want %v\", result, expected)\n }\n}With tolerance, you’d handle it like this:
\nfunc almostEqual(a, b, tolerance float64) bool {\n return math.Abs(a-b) <= tolerance\n}\n\nfunc TestDiscountCalculationWithTolerance(t *testing.T) {\n price := 29.99\n rate := 0.15\n expected := 4.4985\n result := calculateDiscount(price, rate)\n if !almostEqual(result, expected, 1e-9) {\n t.Errorf(\"got %v, want %v\", result, expected)\n }\n}Some comparisons are fine without tolerance:
\nif value == 0.0 { } // Zero has exact representation\nif math.IsNaN(result) { } // Special values\nif result == math.Inf(1) { } // Infinity comparisonsIf your floats haven’t been through different computational paths, exact comparison often works fine.
\nflowchart TD\n A[\"Comparing floats?\"] --> B{\"Result of\\narithmetic?\"}\n B -- Yes --> C[\"Use epsilon\"]\n B -- No --> D{\"Integer-\\nconvertible?\"}\n D -- Yes --> E[\"No epsilon needed\"]\n D -- No --> F{\"Currency?\"}\n F -- Yes --> G[\"Use integer cents\"]\n F -- No --> CHere’s a utility I use across projects:
\nconst DefaultFloatTolerance = 1e-9\n\nfunc FloatEquals(a, b float64) bool {\n return FloatEqualsWithTolerance(a, b, DefaultFloatTolerance)\n}\n\nfunc FloatEqualsWithTolerance(a, b, tolerance float64) bool {\n if math.IsNaN(a) && math.IsNaN(b) {\n return true\n }\n if math.IsInf(a, 0) && math.IsInf(b, 0) {\n return math.Signbit(a) == math.Signbit(b)\n }\n return math.Abs(a-b) <= tolerance\n}Use tolerance when your floats have been through computational journeys. Skip it for direct assignments, constants, and same-path calculations.
\n" }, { "id": "tag:ashwingopalsamy.in,2025-08-15:books/designing-data-intensive-applications", "url": "https://ashwingopalsamy.in/library/", "title": "Designing Data-Intensive Applications", "content_text": "", "date_published": "2025-08-15T00:00:00.000Z", "tags": [ "books" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "https://ashwingopalsamy.in/library/notes/runes-bytes-and-graphemes-in-go/", "url": "https://ashwingopalsamy.in/library/notes/runes-bytes-and-graphemes-in-go/", "title": "Runes, Bytes, and Graphemes in Go", "content_text": "Bytes, runes, and graphemes are not the same length: handling Tamil and emoji correctly in Go strings.", "date_published": "2025-08-09T00:00:00.000Z", "tags": [ "notes" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ], "content_html": "I once ran into this problem while handling names in Tamil and emoji in a Go web app: a string that looked short wasn’t, and reversing it produced gibberish.
\ngraph TD\n G[\"Grapheme Cluster\\n(what users see)\"]\n R1[\"Rune 1\\n(code point)\"]\n R2[\"Rune 2\\n(combining mark)\"]\n B1[\"Bytes\\n(1-4 per rune)\"]\n B2[\"Bytes\\n(1-4 per rune)\"]\n G --> R1\n G --> R2\n R1 --> B1\n R2 --> B2
Go represents strings as immutable UTF-8 byte sequences.
\ns := \"வணக்கம்\"\nfmt.Println(len(s)) // 2121 bytes, not visible symbols. Every Tamil character can span 3 bytes.
\nstring to []rune gives you code points.
rs := []rune(s)\nfmt.Println(len(rs)) // 77 runes, but some Tamil graphemes (like “க்”) combine two runes: க + ்.
\nGo’s standard library stops at runes. For visible character units, use github.com/rivo/uniseg.
for gr := uniseg.NewGraphemes(s); gr.Next(); {\n fmt.Printf(\"%q\\n\", gr.Str())\n}That outputs what a human reads: வ, ண, க், க, ம்.
\ngraph LR\n T[\"வணக்கம் (Tamil)\"]\n T --> |\"len()\"| BY[\"21 bytes\"]\n T --> |\"[]rune\"| RU[\"7 runes\"]\n T --> |\"uniseg\"| GR[\"5 graphemes\"]
| Task | \nApproach | \n
|---|---|
| Count code points | \nutf8.RuneCountInString(s) | \n
| Count visible units | \nGrapheme iteration (uniseg) | \n
| Reverse text | \nParse into graphemes, reverse slice, join | \n
| Slice safely | \nOnly use s[i:j] on grapheme boundaries | \n
Every time I see that GitHub repo go-is-not-good making the rounds again, I laugh. It’s always shared by people who mistake language cleverness for engineering.
\nLet me say this clearly: Go is not for everything. It was never meant to be. But if you’re building cloud-native systems, if you’re working with distributed architecture, if you’re running services in production that actually matter – Go is brutal, minimal, and effective.
\ngraph LR\n A[\"No generics\"] -- \"Go 1.18\" --> B[\"Resolved\"]\n C[\"No modules\"] -- \"Go 1.11\" --> D[\"Resolved\"]\n E[\"Error handling\"] --> F[\"By Design\"]\n G[\"Concurrency\"] --> H[\"Same as every lang\"]
Go 1.18 brought generics. Not the “look how clever I am” kind. The real-world, clean, no-BS kind. I’ve built production-grade code with generics in Go, and it’s boring in the best possible way.
\nI respect Go’s approach to error handling. It makes you look at your failure paths. There’s no magic trapdoor. You deal with errors explicitly, predictably, and with clarity. Now with errors.Is, errors.As, and errors.Join, it’s not even painful.
Go gives you the raw tools to build concurrent systems. It assumes the person writing the code knows what they’re doing. I respect that.
\nI’ve deployed Go services that boot in under 50ms and run for months without a hiccup. It doesn’t brag. It just works.
\ngraph LR\n A[\"Go\"] --> B[\"Ship fast, simple\"]\n C[\"Java / Spring\"] --> D[\"Medium complexity\"]\n E[\"Rust / Haskell\"] --> F[\"Complex, more guarantees\"]
I’ve built banking systems, transaction processors, and cloud-native APIs with Go. It’s not flashy. But Go keeps things simple and predictable, and that’s exactly what backend engineering demands.
\n" }, { "id": "tag:ashwingopalsamy.in,2025-06-15:watch/rookie", "url": "https://ashwingopalsamy.in/library/", "title": "Rookie", "content_text": "", "date_published": "2025-06-15T00:00:00.000Z", "tags": [ "watch" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "https://ashwingopalsamy.in/library/notes/go-goroutine-stack-growth/", "url": "https://ashwingopalsamy.in/library/notes/go-goroutine-stack-growth/", "title": "How Goroutine Stacks Grow and Shrink", "content_text": "How goroutine stacks grow and shrink in Go, and why that is what makes them feel lightweight.", "date_published": "2025-06-08T00:00:00.000Z", "tags": [ "notes" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ], "content_html": "If you ask any mid-senior Go dev what makes goroutines lightweight you’ll get the reply:
\n\n\nThey start with 2 KB of stack instead of 1 MB like OS threads.
\n
They’re not wrong. But they’re not thinking deep enough.
\nGo’s stack model isn’t just a small preallocated buffer; it’s a live, evolving region of memory that resizes in realtime, grows when needed, and shrinks.
\nGo’s runtime gives each new goroutine 2 KB of stack. But Go doesn’t panic when you blow past it – it grows the stack dynamically by allocating a new region (typically doubling the size) and copying the old stack frames over.
\ngraph LR\n A[\"New Goroutine\\n2 KB stack\"] --> B[\"Function\\nCall\"]\n B --> C{\"Stack\\nCheck\"}\n C -->|Enough| D[\"Continue\\nExecution\"]\n C -->|Overflow| E[\"Allocate\\n2x Stack\"]\n E --> F[\"Copy Old\\nFrames\"]\n F --> G[\"Update\\nPointers\"]\n G --> DEach goroutine has an upper stack limit of about 1 GB. Hit it and the program panics:
\nruntime: goroutine stack exceeds 1000000000-byte limit\nfatal error: stack overflowgraph TD\n S1[\"2 KB\\n(initial)\"] --> S2[\"4 KB\"]\n S2 --> S3[\"8 KB\"]\n S3 --> S4[\"16 KB\"]\n S4 --> S5[\"32 KB\"]\n S5 --> S6[\"...\"]\n S6 --> S7[\"~1 GB\\n(ceiling)\"]\n S7 -.->|\"GC shrink\\n(if idle + mostly unused)\"| S5\n S5 -.->|\"GC shrink\"| S3
When a stack outgrows its current allocation, Go allocates a new contiguous block at double the size, copies all frames, and adjusts every internal pointer.
\ngraph LR\n subgraph \"Old Stack (4 KB)\"\n O1[\"Frame 1\"]\n O2[\"Frame 2\"]\n O3[\"Pointer A\\n→ Frame 1\"]\n end\n subgraph \"New Stack (8 KB)\"\n N1[\"Frame 1\\n(copied)\"]\n N2[\"Frame 2\\n(copied)\"]\n N3[\"Pointer A'\\n→ Frame 1\\n(adjusted)\"]\n N4[\"Free Space\"]\n end\n O1 -->|copy| N1\n O2 -->|copy| N2\n O3 -->|\"adjust + copy\"| N3
\n\nStack growth can trigger GC pressure even without heap allocations. A runaway stack holds pointers that get scanned by GC. This is how your 5ms p99 turns into 100ms.
\n
There’s no tuning knob for stack size. No config. No CLI flag. The only way to manage it is through code discipline: avoid recursive goroutines unless they terminate quickly, don’t hold large structs deep in call graphs, and never assume goroutines are free.
\n" }, { "id": "https://ashwingopalsamy.in/library/notes/go-scheduler-infinite-loops/", "url": "https://ashwingopalsamy.in/library/notes/go-scheduler-infinite-loops/", "title": "Go Scheduler, Yield Points, and Infinite Loops", "content_text": "How Go's scheduler, yield points, and tight loops interact, and when a busy loop starves other goroutines.", "date_published": "2025-05-24T00:00:00.000Z", "tags": [ "notes" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ], "content_html": "I’ve been reviewing performance-critical code, and I keep coming back to this pattern:
\nfor {\n if condition {\n break\n }\n}versus
\ngo func() {\n for {\n // background processing\n }\n}()The runtime implications are fascinating.
\nGo’s scheduler uses a GMP model: Goroutines (G) run on Machine threads (M) via Processors (P). Each P has a local run queue plus a global run queue.
\ngraph TD\n subgraph \"Global Run Queue\"\n GQ[\"G5, G6, G7 ...\"]\n end\n subgraph \"P0 (Processor)\"\n LQ0[\"Local Queue:\\nG1, G2\"]\n LQ0 --> M0[\"M0\\n(OS Thread)\"]\n M0 --> CPU0[\"CPU Core 0\"]\n end\n subgraph \"P1 (Processor)\"\n LQ1[\"Local Queue:\\nG3, G4\"]\n LQ1 --> M1[\"M1\\n(OS Thread)\"]\n M1 --> CPU1[\"CPU Core 1\"]\n end\n GQ -.->|\"schedule\"| LQ0\n GQ -.->|\"schedule\"| LQ1\n LQ0 -.->|\"work steal\"| LQ1
sequenceDiagram\n participant S as Scheduler\n participant A as Goroutine A\n participant B as Goroutine B\n\n S->>A: Schedule on P0\n Note over A: Executing...\n A->>A: Channel send (yield point)\n A->>S: Yield control\n S->>B: Schedule on P0\n Note over B: Executing...\n B->>B: runtime.Gosched()\n B->>S: Yield control\n S->>A: Re-schedule on P0\n Note over A: Resumes execution
Since Go 1.14, sysmon detects goroutines running longer than ~10ms and forces preemption via SIGURG.
sequenceDiagram\n participant SM as sysmon\n participant G as Goroutine (tight loop)\n participant S as Scheduler\n\n G->>G: Running for >10ms (no yield points)\n SM->>SM: Detects long-running G\n SM->>G: Send SIGURG\n Note over G: Signal handler fires, saves state\n G->>S: Suspended\n S->>S: Schedule next goroutine\n S->>G: Re-schedule eventually
graph LR\n A{\"Need\\nconcurrency?\"}\n A -->|No| B[\"for {} loop\\n(direct execution)\"]\n A -->|Yes| C{\"Bounded\\nwork?\"}\n C -->|Yes| D[\"Worker Pool\\n(fixed goroutines)\"]\n C -->|No| E{\"I/O or\\nCPU bound?\"}\n E -->|I/O| F[\"Goroutine per task\\n(scheduler handles blocking)\"]\n E -->|CPU| G[\"select {} loop\\n(controlled yielding)\"]For most apps, use goroutines everywhere. For the 5% of performance-critical code, choose based on your scheduler profile.
\n" }, { "id": "tag:ashwingopalsamy.in,2025-05-18:books/software-architecture-hard-parts", "url": "https://ashwingopalsamy.in/library/", "title": "Software Architecture: The Hard Parts", "content_text": "", "date_published": "2025-05-18T00:00:00.000Z", "tags": [ "books" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "https://ashwingopalsamy.in/library/notes/review-your-own-pr-first/", "url": "https://ashwingopalsamy.in/library/notes/review-your-own-pr-first/", "title": "Review Your Own PR First", "content_text": "The PRs that merge cleanly are the ones authors already self-reviewed. A practical checklist before you ask.", "date_published": "2025-01-15T00:00:00.000Z", "tags": [ "notes" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ], "content_html": "Like most developers, I’ve been on both sides of Pull Requests. What I’ve noticed is that the best PRs, the ones that get merged smoothly with minimal back-and-forth, are where the author has already done a thorough self-review.
\nsequenceDiagram\n participant Author\n participant Reviewer\n Author->>Reviewer: Push PR for review\n Reviewer->>Author: 12 comments (typos, dead code, naming)\n Author->>Author: Fix trivial issues\n Author->>Reviewer: Push fixes\n Reviewer->>Author: 5 more comments\n Author->>Author: Fix again\n Author->>Reviewer: Push fixes\n Note over Author,Reviewer: 3+ round trips before merge
Clean up obvious issues yourself so reviewers focus on architecture and design.
\nReading your own diff catches patterns that don’t jump out when you’re writing.
\nA polished PR signals respect for your colleagues’ time.
\nOpen the Files changed tab and read every line as the reviewer.
\nFollow conventional-commit style. Each commit should represent one logical change.
\nAdd inline comments for non-obvious decisions.
\nRun them locally. Check coverage for success and failure paths.
\nRun your formatter and linter before requesting review.
\nsequenceDiagram\n participant Author\n participant Self as Self-Review\n participant Reviewer\n Author->>Self: Read own diff as reviewer\n Self->>Author: Catch 12 trivial issues locally\n Author->>Author: Fix naming, dead code, edge cases\n Author->>Reviewer: Push clean PR\n Reviewer->>Author: 1 substantive design comment\n Author->>Author: Address feedback\n Author->>Reviewer: Push final fix\n Note over Author,Reviewer: 1 round trip to merge
graph TD\n Start[\"Open your PR diff\"] --> A{\"Diff readable?\\nClear naming?\"}\n A -->|Yes| B{\"Commit messages\\nclear and atomic?\"}\n A -->|No| A1[\"Fix naming\"] --> A\n B -->|Yes| C{\"Tests pass?\\nCoverage adequate?\"}\n B -->|No| B1[\"Rewrite commits\"] --> B\n C -->|Yes| D{\"Docs updated?\\nPR description clear?\"}\n C -->|No| C1[\"Add tests\"] --> C\n D -->|Yes| E{\"Linting clean?\"}\n D -->|No| D1[\"Update docs\"] --> D\n E -->|Yes| F[\"Ready for review\"]\n E -->|No| E1[\"Run linter\"] --> EThe simplest habit that pays the biggest dividends: before clicking “Request Review”, open the Files changed tab and read every line as if a colleague wrote it.
\n" }, { "id": "https://ashwingopalsamy.in/library/notes/go-generics-comparable-constraint/", "url": "https://ashwingopalsamy.in/library/notes/go-generics-comparable-constraint/", "title": "The comparable Constraint in Go Generics", "content_text": "What 'incomparable types in type set' means and how Go's comparable constraint shapes generic maps and sets.", "date_published": "2024-12-25T00:00:00.000Z", "tags": [ "notes" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ], "content_html": "While working on a generic function in Go, I once encountered this error: ‘incomparable types in type set’.
\nIt led me to dig deeper into the comparable constraint. With this post, I’ll walk you through what comparable is, why it’s useful, and how you can leverage it for cleaner, type-safe Go code.
comparable is a constraint that ensures a type supports equality comparisons (== and !=).
In Go, only certain types are inherently comparable: primitive types like int, float64 and string, but exclude types like slices, maps, and functions.
type Array[T comparable] struct {\n data []T\n}\n\nfunc (a *Array[T]) Contains(value T) bool {\n for _, v := range a.data {\n if v == value {\n return true\n }\n }\n return false\n}graph TD\n A[\"any\\n(all types)\"]\n B[\"comparable\\n(supports == and !=)\"]\n C[\"constraints.Ordered\\n(supports < > <= >=)\"]\n A --> B\n B --> C
any is simply an alias for interface{}. While functionally identical, any better aligns with the intentions of generics and improves readability.
func PrintValues[T any](values []T) {\n for _, v := range values {\n fmt.Println(v)\n }\n}func RemoveDuplicates[T comparable](input []T) []T {\n seen := make(map[T]bool)\n result := []T{}\n for _, v := range input {\n if !seen[v] {\n seen[v] = true\n result = append(result, v)\n }\n }\n return result\n}graph LR\n subgraph \"Using any (unsafe)\"\n A1[\"func Contains\\n[T any]\"] --> B1[\"Pass []int\\nas T\"]\n B1 --> C1[\"Runtime Panic\\n== on slice\"]\n end\n subgraph \"Using comparable (safe)\"\n A2[\"func Contains\\n[T comparable]\"] --> B2[\"Pass []int\\nas T\"]\n B2 --> C2[\"Compile Error\\n[]int not comparable\"]\n end
The real value of comparable is catching errors at compile time instead of letting them slip into production.
When we first start with Go, the main function seems almost too simple. But before main even begins, the Go runtime orchestrates careful initialization of all imported packages, runs their init functions and ensures everything is in the right order.
sequenceDiagram\n participant OS\n participant Runtime\n participant Packages\n participant main\n\n OS->>Runtime: Execute binary\n Runtime->>Runtime: Bootstrap (scheduler, GC, memory)\n Runtime->>Packages: Init packages in dependency order\n Packages->>Packages: Run init() functions\n Packages-->>Runtime: All packages initialized\n Runtime->>main: Call main()\n main->>main: Main goroutine runs\n main-->>OS: os.Exit or return
Go initializes packages in dependency order, not import order. Leaf packages initialize first.
\ngraph TD\n main[\"main\\n(init last)\"]\n A[\"Package A\"]\n B[\"Package B\"]\n C[\"Package C\"]\n main --> A\n main --> B\n A --> C
Init order: C -> A -> B -> main.
\nYou can have multiple init functions. They run in order they appear. Go initializes packages in the order of their dependencies.
\n\nUse
\nsync.Oncewhen you need lazy or guarded initialization of shared resources. It’s safer than relying oninit()ordering.
os.Exit() terminates the program immediately. No deferred functions run.
func main() {\n if err := doSomethingRisky(); err != nil {\n cleanup()\n os.Exit(1)\n }\n}The main function runs in a special goroutine. If main returns, the entire program exits – even if other goroutines are still working. Use sync.WaitGroup to wait for background goroutines.
When I first started learning Go, I was intrigued by its approach to memory management. Go handles memory in a way that’s both efficient and safe, but it can be a bit of a black box if you don’t peek under the hood.
\ngraph TD\n subgraph STACK[\"Goroutine Stack\"]\n S1[\"Local variables\"]\n S2[\"Function parameters\"]\n S3[\"Return addresses\"]\n end\n subgraph HEAP[\"Shared Heap\"]\n H1[\"Escaped variables\"]\n H2[\"Pointers returned\\nfrom functions\"]\n H3[\"Closure captures\"]\n end\n EA{{\"Escape Analysis\\n(compile time)\"}}\n EA -- \"does not escape\" --> STACK\n EA -- \"escapes to heap\" --> HEAPIn Go, when you pass variables like integer, string, or boolean to a function, they are passed by value. A copy is made.
\nfunc increment(num int) {\n num++\n}\n\nfunc main() {\n n := 21\n increment(n)\n fmt.Println(n) // 21\n}To modify the original variable inside a function, pass a pointer.
\nfunc incrementPointer(num *int) {\n (*num)++\n}\n\nfunc main() {\n n := 42\n incrementPointer(&n)\n fmt.Println(n) // 43\n}Escape analysis determines whether variables need to live beyond their function scope.
\nflowchart TD\n A[\"Variable declared\"] --> B{\"Returned as\\npointer?\"}\n B -- Yes --> HEAP[\"Allocate on Heap\"]\n B -- No --> C{\"Captured by\\nclosure?\"}\n C -- Yes --> HEAP\n C -- No --> D{\"Assigned to\\ninterface?\"}\n D -- Yes --> HEAP\n D -- No --> E{\"Too large\\nfor stack?\"}\n E -- Yes --> HEAP\n E -- No --> STACK[\"Allocate on Stack\"]Run go build -gcflags '-m' on any Go file to see escape analysis decisions.
func main() {\n var wg sync.WaitGroup\n counter := 0\n counterPtr := &counter\n for i := 0; i < 1000; i++ {\n wg.Add(1)\n go func() {\n *counterPtr++\n wg.Done()\n }()\n }\n wg.Wait()\n fmt.Println(\"Counter:\", *counterPtr)\n}This has a data race. Fix with a mutex:
\nvar mu sync.Mutex\ngo func() {\n mu.Lock()\n *counterPtr++\n mu.Unlock()\n wg.Done()\n}()go test -race to detect data racesGit is the backbone of every software project. Working in FinTech systems, I’ve learned that Git isn’t just a tool – it’s a shared language and a safety net.
\n\n\nIn FinTech and regulated environments, every change must be auditable and traceable. Clean Git practices are not just about developer productivity – they are a compliance requirement.
\n
An atomic commit focuses on one thing – fixing a bug, adding a feature, or refactoring.
\nGood: feat: add endpoint for retrieving user account balances\nBad: misc: fix bugs and add features
<type>(<scope>): <subject>\n<BLANK LINE>\n<body (optional)>\n\nThe Conventional Commits Specification formalizes this format. It pairs well with commitlint and enables automatic changelog generation.
\n
graph LR\n A[\"feat(parser): add bitmap validation\"]\n A --> B[\"<b>type</b><br/>feat\"]\n A --> C[\"<b>scope</b><br/>parser\"]\n A --> D[\"<b>description</b><br/>add bitmap validation\"]
<JIRA-ticket-ID>-<type>-<short-description>Examples: JIRA-5678-fix-transaction-timeout, JIRA-1234-feature-add-batch-processing
git checkout JIRA-5678-fix-transaction-timeout\ngit pull --rebase origin main\n\nRebasing rewrites commit hashes, so it should only be used on local or feature branches. The payoff is a linear history that reads like a narrative.
\n
gitGraph\n commit id: \"init\"\n commit id: \"v1.0\"\n branch JIRA-5678-fix-timeout\n commit id: \"add retry logic\"\n commit id: \"handle edge case\"\n commit id: \"add tests\"\n checkout main\n commit id: \"hotfix: logging\"\n checkout JIRA-5678-fix-timeout\n merge main id: \"rebase onto main\" type: HIGHLIGHT\n checkout main\n merge JIRA-5678-fix-timeout id: \"squash merge\" type: HIGHLIGHT\n commit id: \"v1.1\"
[JIRA-ticket-ID] <Type>: <Short Description>
Examples:
\n[JIRA-5678] Fix: Handle transaction timeout edge cases[JIRA-1234] Feature: Add bulk processing for transactionsAnswer three questions: What changed? Why? Does it introduce risks?
\nLarge PRs are hard to review and prone to mistakes. A schema migration should be its own PR.
\nRead your diff as if a colleague wrote it before requesting review.
\ngraph LR\n A[\"Branch Created\"] --> B[\"Commits\"]\n B --> C[\"Self-Review\"]\n C --> D[\"PR Opened\"]\n D --> E[\"CI Passes\"]\n E --> F[\"Code Review\"]\n F --> G[\"Approved\"]\n G --> H[\"Squash Merge\"]\n H --> I[\"Branch Deleted\"]
In highly critical FinTech systems, precision isn’t optional. Clean commits, structured branches, and clear PRs are safeguards for the stability of the systems we build.
\n" }, { "id": "https://ashwingopalsamy.in/library/notes/go-constants-beyond-basics/", "url": "https://ashwingopalsamy.in/library/notes/go-constants-beyond-basics/", "title": "Go Constants Beyond the Basics", "content_text": "Go constants are fixed values with surprising flexibility: typed constants, iota, and compile-time tricks that matter.", "date_published": "2024-11-13T00:00:00.000Z", "tags": [ "notes" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ], "content_html": "When I first got into Go, I thought constants were simple and limited – just fixed values, nothing fancy. But as I delved deeper, I found they’re quite versatile. Yes, they’re fixed values, but Go handles them in ways that are both flexible and efficient. Let’s see what that means with some practical examples.
\nIn Go, constants are often untyped until you actually use them. They have a default kind but can be assigned to variables of different types, as long as the value fits. This makes them adaptable in a way that’s unusual for a statically typed language.
\nHere’s how that looks:
\nconst x = 10\n\nvar i int = x\nvar f float64 = x\nvar b byte = xgraph TD\n A[\"const x = 5\\n(untyped)\"] --> B[\"used as int\"]\n A --> C[\"used as float64\"]\n A --> D[\"used as byte\"]\n B --> E[\"int\"]\n C --> F[\"float64\"]\n D --> G[\"byte\"]
A bit analogous to Schrodinger’s paradox, x can be an int, a float64, or even a byte until you assign it. This temporary flexibility lets x work smoothly with different types in your code. No need for casting, which keeps things neat.
You can even mix constants of different types in expressions and Go will figure out the best type for the result:
\nconst a = 1.5\nconst b = 2\n\nconst result = a * b // result is float64Since a is a floating-point number, Go promotes the whole expression to float64. So you don’t have to worry about losing precision – Go handles it. But be careful: if you try to assign result to an int, you’ll get an error. Go doesn’t allow implicit conversions that might lose data.
Go doesn’t have a preprocessor like some other languages, but you can use constants in if statements to include or exclude code at compile time.
const debug = false\n\nfunc main() {\n if debug {\n fmt.Println(\"Debugging enabled\")\n }\n}When debug is false, the compiler knows the if condition will never be true and might leave out the code inside the block. This can make your final binary smaller.
One powerful feature of Go’s constants is that they support very large numbers. Untyped numeric constants in Go have “infinite” precision, limited only by memory and the compiler.
\nconst bigNum = 1e1000 // This is a valid constantEven though bigNum is way bigger than any built-in numeric type like float64 or int, Go lets you define it as a constant. You can do calculations with these large numbers at compile time:
const (\n a = 1e20\n b = 1e30\n c = a * b // c is 1e50\n)If you’ve been using Go, you’ve probably seen iota for creating enumerated constants.
const (\n _ = iota\n KB = 1 << (10 * iota)\n MB\n GB\n TB\n)graph LR\n A[\"iota=0\"] --> B[\"1<<0 = 1\\n(Read)\"]\n C[\"iota=1\"] --> D[\"1<<1 = 2\\n(Write)\"]\n E[\"iota=2\"] --> F[\"1<<2 = 4\\n(Execute)\"]\n B --> G[\"Read | Write = 3\"]\n D --> G
While Go’s constants are flexible, there are some things they can’t do.
\nConstants don’t have a memory address at runtime. So you can’t take the address of a constant or use a pointer to it.
\nconst x = 10\nvar p = &x // Error: cannot take the address of xOnly certain built-in functions can be used in constant expressions, like len, cap, real, imag, and complex.
const str = \"hello\"\nconst length = len(str) // This works\nconst pow = math.Pow(2, 3) // Error: math.Pow cannot be used in constant expressionsI’ve been exploring Go’s UTF-8 support and was curious about how well it handles non-Latin scripts in code.
\nGo source files are UTF-8 encoded by default. You can use Unicode characters in variable names and function names. Chinese characters work fine:
\npackage main\n\nimport \"fmt\"\n\nfunc main() {\n 消息 := \"Hello, World!\"\n fmt.Println(消息)\n}I tried Tamil, my mother tongue:
\npackage main\n\nimport \"fmt\"\n\nfunc main() {\n எண்ணிக்கை := 42\n fmt.Println(\"Value:\", எண்ணிக்கை)\n}But the compiler throws errors:
\n./prog.go:6:11: invalid character U+0BCD '்' in identifierTamil is an abugida. Consonant-vowel sequences are written as units with combining marks. Go’s spec allows Unicode letters in identifiers but excludes combining marks (categories Mn, Mc, Me).
graph LR\n A[\"Tamil syllable\"] --> B[\"Base consonant\\n(Lo: valid)\"]\n A --> C[\"Vowel sign\\n(Mc: continuation only)\"]\n B --> D[\"Visually incomplete\\nalone\"]\n C --> D
Chinese characters are classified under “Letter, Other” (Lo) – standalone symbols. Tamil requires combining marks, which Go’s spec explicitly excludes.
\n\n" }, { "id": "tag:ashwingopalsamy.in,2024-07-20:watch/avatar-the-last-airbender", "url": "https://ashwingopalsamy.in/library/", "title": "Avatar: The Last Airbender", "content_text": "", "date_published": "2024-07-20T00:00:00.000Z", "tags": [ "watch" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "tag:ashwingopalsamy.in,2024-06-10:books/learning-go", "url": "https://ashwingopalsamy.in/library/", "title": "Learning Go", "content_text": "", "date_published": "2024-06-10T00:00:00.000Z", "tags": [ "books" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "tag:ashwingopalsamy.in,2024-05-01:watch/chotta-bheem", "url": "https://ashwingopalsamy.in/library/", "title": "Chotta Bheem", "content_text": "", "date_published": "2024-05-01T00:00:00.000Z", "tags": [ "watch" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "tag:ashwingopalsamy.in,2024-03-10:watch/suits", "url": "https://ashwingopalsamy.in/library/", "title": "Suits", "content_text": "", "date_published": "2024-03-10T00:00:00.000Z", "tags": [ "watch" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "tag:ashwingopalsamy.in,2024-01-20:watch/the-social-network", "url": "https://ashwingopalsamy.in/library/", "title": "The Social Network", "content_text": "", "date_published": "2024-01-20T00:00:00.000Z", "tags": [ "watch" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "tag:ashwingopalsamy.in,2023-10-14:watch/bojack-horseman", "url": "https://ashwingopalsamy.in/library/", "title": "BoJack Horseman", "content_text": "", "date_published": "2023-10-14T00:00:00.000Z", "tags": [ "watch" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "tag:ashwingopalsamy.in,2023-08-14:watch/breaking-bad", "url": "https://ashwingopalsamy.in/library/", "title": "Breaking Bad", "content_text": "", "date_published": "2023-08-14T00:00:00.000Z", "tags": [ "watch" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "tag:ashwingopalsamy.in,2023-06-08:watch/never-have-i-ever", "url": "https://ashwingopalsamy.in/library/", "title": "Never Have I Ever", "content_text": "", "date_published": "2023-06-08T00:00:00.000Z", "tags": [ "watch" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "tag:ashwingopalsamy.in,2023-02-12:watch/ben-10", "url": "https://ashwingopalsamy.in/library/", "title": "Ben 10", "content_text": "", "date_published": "2023-02-12T00:00:00.000Z", "tags": [ "watch" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "tag:ashwingopalsamy.in,2022-09-30:watch/vikings", "url": "https://ashwingopalsamy.in/library/", "title": "Vikings", "content_text": "", "date_published": "2022-09-30T00:00:00.000Z", "tags": [ "watch" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "tag:ashwingopalsamy.in,2021-12-03:watch/money-heist", "url": "https://ashwingopalsamy.in/library/", "title": "Money Heist", "content_text": "", "date_published": "2021-12-03T00:00:00.000Z", "tags": [ "watch" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "tag:ashwingopalsamy.in,2020-08-22:watch/mr-robot", "url": "https://ashwingopalsamy.in/library/", "title": "Mr. Robot", "content_text": "", "date_published": "2020-08-22T00:00:00.000Z", "tags": [ "watch" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "tag:ashwingopalsamy.in,2020-06-05:watch/13-reasons-why", "url": "https://ashwingopalsamy.in/library/", "title": "13 Reasons Why", "content_text": "", "date_published": "2020-06-05T00:00:00.000Z", "tags": [ "watch" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "tag:ashwingopalsamy.in,2020-05-01:watch/silicon-valley", "url": "https://ashwingopalsamy.in/library/", "title": "Silicon Valley", "content_text": "", "date_published": "2020-05-01T00:00:00.000Z", "tags": [ "watch" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "tag:ashwingopalsamy.in,2019-06-03:watch/chernobyl", "url": "https://ashwingopalsamy.in/library/", "title": "Chernobyl", "content_text": "", "date_published": "2019-06-03T00:00:00.000Z", "tags": [ "watch" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] }, { "id": "tag:ashwingopalsamy.in,2019-05-20:watch/game-of-thrones", "url": "https://ashwingopalsamy.in/library/", "title": "Game of Thrones", "content_text": "", "date_published": "2019-05-20T00:00:00.000Z", "tags": [ "watch" ], "authors": [ { "name": "Ashwin Gopalsamy", "url": "https://ashwingopalsamy.in/" } ] } ] }Go’s creators primarily aimed for consistent string handling through UTF-8 support. They didn’t necessarily intend for native-language coding in identifiers requiring combining marks.
\n