DEV Community: Ashwin Gopalsamy

How Internet works?

Ashwin Gopalsamy — Fri, 07 Nov 2025 03:43:26 +0000

🌐 How the Internet actually works

1. Local Devices

Phones, tablets, and laptops connect to the internet through Wi-Fi, broadband, or mobile data. These create the entry point for communication.

2. Internet Service Provider (ISP)

The ISP’s network (cell towers or broadband routers) assigns your device an IP address and routes your data.

ISPs act as your gateway to the wider internet.

3. DNS (Domain Name System)

When you enter a website (like www.google.com), your device first performs a DNS lookup to translate the domain name into an IP address (like 142.250.190.14).

4. IXP (Internet Exchange Point)

ISPs don’t directly connect to every network. They pass traffic through IXPs, where multiple ISPs and large networks exchange data.

5. BGP & Autonomous Systems

The Border Gateway Protocol (BGP) connects independent networks called Autonomous Systems (AS) — the internet’s “routing map.”

This system decides how data travels across the globe through the most efficient or available path.

6. Servers & Data Centers

Your request eventually reaches a server (or cluster of servers) hosting the target website or service.

These servers process your request and send back a response (like a web page, video, or API data).

7. CDN Nodes (Content Delivery Networks)

To speed things up, CDNs store cached content (like images or videos) in servers closer to your location — often inside or near ISP networks.

8. Return Path

The response travels back through the same or similar route — from server → BGP → IXP → ISP → your device — and your browser/app displays the result.

🧩 In Short:

Device → ISP → DNS → IXP → BGP/AS Backbone → Server/CDN → back to Device

Each layer plays a distinct role:

DNS finds where to go
ISP + IXP + BGP decide how to get there
Servers/CDNs deliver what you asked for

Graphemes in Go

Ashwin Gopalsamy — Sun, 10 Aug 2025 03:40:00 +0000

I once ran into this problem of differentiating runes, bytes and graphemes while handling names in Tamil and emoji in a Go web app: a string that looked short wasn’t, and reversing it produced gibberish. The culprit wasn’t Go being flawed, it was me making assumptions about what “a character” means.

Let’s map the territory precisely:

1. Bytes. The raw material Go calls a string

Go represents strings as immutable UTF-8 byte sequences.

What we see isn’t what Go handles under the hood.

s := "வணக்கம்"
fmt.Println(len(s)) // 21

The length is 21 bytes not visible symbols. Every Tamil character can span 3 bytes. Even simple-looking emojis stretch across multiple bytes.

2. Runes. Unicode code points

string → []rune( gives you code points, but still not what a human perceives.

rs := []rune(s)
fmt.Println(len(rs)) // 7

Here it’s 7 runes, but some Tamil graphemes (like “க்”) combine two runes: க + ்.

3. Grapheme clusters the units users actually see

Go’s standard library stops at runes. To work with visible characters, you need a grapheme-aware library, like github.com/rivo/uniseg.

for gr := uniseg.NewGraphemes(s); gr.Next(); {
    fmt.Printf("%q\n", gr.Str())
}

That outputs what a human reads “வ”, “ண”, “க்”, “க”, “ம்”, and even “❤️” as a single unit.

Why this matters

If your app deals with names, chats, or any multilingual text indexing by bytes will break things. Counting runes helps, but can still split what you intend as one unit. Grapheme-aware operations align with what users actually expect.

Real bugs I’ve seen: Tamil names chopped mid-character, emoji reactions breaking because only one code point was taken.

To put it simply

Task	Approach
Count code points	`utf8.RuneCountInString(s)`
Count visible units	Grapheme iteration (`uniseg`)
Reverse text	Parse into graphemes, reverse slice, join
Slice safely	Only use `s[i:j]` on grapheme boundaries

Think about what you intend to manipulate: the raw bytes, the code points, or what a user actually reads on screen and choose the right level.

[Boost]

Ashwin Gopalsamy — Fri, 13 Dec 2024 15:10:12 +0000

A Peek Behind Go’s Entry Point - From Initialization to Exit

Ashwin Gopalsamy ・ Dec 13 '24

#go #beginners #programming

A Peek Behind Go’s Entry Point - From Initialization to Exit

Ashwin Gopalsamy — Fri, 13 Dec 2024 15:10:02 +0000

When we first start with Go, the main function seems almost too simple. A single entry point, a straightforward go run main.go and voila - our program isup and running.

But as we dug deeper, I realized there’s a subtle, well-thought-out process churning behind the curtain. Before main even begins, the Go runtime orchestrates a careful initialization of all imported packages, runs their init functions and ensures that everything’s in the right order - no messy surprises allowed.

The way Go arranges has neat details to it, that I think every Go developer should be aware of, as this influences how we structure our code, handle shared resources and even communicate errors back to the system.

Let’s explore some common scenarios and questions that highlight what’s really going on before and after main kicks into gear.

Before main: Orderly Initialization and the Role of init

Picture this: you’ve got multiple packages, each with their own init functions. Maybe one of them configures a database connection, another sets up some logging defaults and a third initializes a lambda worker & the fourth initializing an SQS queue listener.

By the time main runs, you want everything ready - no half-initialized states or last-minute surprises.

Example: Multiple Packages and init Order

// db.go
package db

import "fmt"

func init() {
    fmt.Println("db: connecting to the database...")
    // Imagine a real connection here
}

// cache.go
package cache

import "fmt"

func init() {
    fmt.Println("cache: warming up the cache...")
    // Imagine setting up a cache here
}

// main.go
package main

import (
    _ "app/db"   // blank import for side effects
    _ "app/cache"
    "fmt"
)

func main() {
    fmt.Println("main: starting main logic now!")
}

When you run this program, you’ll see:

db: connecting to the database...
cache: warming up the cache...
main: starting main logic now!

The database initializes first (since mainimports db), then the cache and finally main prints its message. Go guarantees that all imported packages are initialized before mainruns. This dependency-driven order is key. If cache depended on db, you’d be sure db finished its setup before cache’s init ran.

Ensuring a Specific Initialization Order

Now, what if you absolutely need dbinitialized before cache, or vice versa? The natural approach is to ensure cache depends on db or is imported after db in main. Go initializes packages in the order of their dependencies, not the order of imports listed in main.go. A trick that we use is a blank import: _ "path/to/package" - to force initialization of a particular package. But I wouldn’t rely on blank imports as a primary method; it can make dependencies less clear and lead to maintenance headaches.

Instead, consider structuring packages so their initialization order emerges naturally from their dependencies. If that’s not possible, maybe the initialization logic shouldn’t rely on strict sequencing at compile time. You could, for instance, have cache check if db is ready at runtime, using a sync.Once or a similar pattern.

Avoiding Circular Dependencies

Circular dependencies at the initialization level are a big no-no in Go. If package A imports B and B tries to import A, you’ve just created a circular dependency. Go will refuse to compile, saving you from a world of confusing runtime issues. This might feel strict, but trust me, it’s better to find these problems early rather than debugging weird initialization states at runtime.

Dealing with Shared Resources and sync.Once

Imagine a scenario where packages A and B both depend on a shared resource - maybe a configuration file or a global settings object. Both have initfunctions and both try to initialize that resource. How do you ensure the resource is only initialized once?

A common solution is to place the shared resource initialization behind a sync.Once call. This ensures that the initialization code runs exactly one time, even if multiple packages trigger it.

Example: Ensuring Single Initialization

// config.go
package config

import (
    "fmt"
    "sync"
)

var (
    once      sync.Once
    someValue string
)

func init() {
    once.Do(func() {
        fmt.Println("config: initializing shared resource...")
        someValue = "initialized"
    })
}

func Value() string {
    return someValue
}

Now, no matter how many packages import config, the initialization of someValuehappens only once. If package A and B both rely on config.Value(), they’ll both see a properly initialized value.

Multiple init Functions in a Single File or Package

You can have multiple init functions in the same file and they’ll run in the order they appear. Across multiple files in the same package, Go runs init functions in a consistent, but not strictly defined order. The compiler might process files in alphabetical order, but you shouldn’t rely on that. If your code depends on a specific sequence of init functions within the same package, that’s often a sign to refactor. Keep init logic minimal and avoid tight coupling.

Legitimate Uses vs. Anti-Patterns

init functions are best used for simple setup: registering database drivers, initializing command-line flags or setting up a logger. Complex logic, long-running I/O or code that might panic without good reason are better handled elsewhere.

As a rule of thumb, if you find yourself writing a lot of logic in init, you might consider making that logic explicit in main.

Exiting with Grace and Understanding os.Exit()

Go’s main doesn’t return a value. If you want to signal an error to the outside world, os.Exit() is your friend. But keep in mind: calling os.Exit() terminates the program immediately. No deferred functions run, no panic stack traces print.

Example: Cleanup Before Exit

package main

import (
    "fmt"
    "os"
)

func main() {
    if err := doSomethingRisky(); err != nil {
        fmt.Println("Error occurred, performing cleanup...")
        cleanup()       // Make sure to clean up before calling os.Exit
        os.Exit(1)
    }
    fmt.Println("Everything went fine!")
}

func doSomethingRisky() error {
    // Pretend something failed
    return fmt.Errorf("something bad happened")
}

func cleanup() {
    // Close files, databases, flush buffers, etc.
    fmt.Println("Cleanup done!")
}

If you skip the cleanup call and jump straight to os.Exit(1), you lose the chance to clean up resources gracefully.

Other Ways to End a Program

You can also end a program through a panic. A panic that’s not recovered by recover() in a deferred function will crash the program and print a stack trace. This is handy for debugging but not ideal for normal error signaling. Unlike os.Exit(), a panic gives deferred functions a chance to run before the program ends, which can help with cleanup, but it also might look less tidy to end-users or scripts expecting a clean exit code.

Signals (like SIGINT from Cmd+C) can also terminate the program. If you’re a soldier, you can catch signals and handle them gracefully.

Runtime, Concurrency and the main Goroutine

Initialization happens before any goroutines are launched, ensuring no race conditions at startup. Once main begins, however, you can spin up as many goroutines as you like.

It’s important to note that main function in itself runs in a special “main goroutine” started by the Go runtime. If main returns, the entire program exits - even if other goroutines are still doing work.

This is a common gotcha: just because you started background goroutines doesn’t mean they keep the program alive. Once main finishes, everything shuts down.

package main

import (
    "fmt"
    "time"
)

func main() {
    go func() {
        time.Sleep(2 * time.Second)
        fmt.Println("Goroutine finished its job!")
    }()

    // If we simply return here, the main goroutine finishes,
    // and the program exits immediately, never printing the above message.

    time.Sleep(3 * time.Second)
    fmt.Println("Main is done, exiting now!")
}

In this example, the goroutine prints its message only because main waits 3 seconds before ending. If main ended sooner, the program would terminate before the goroutine completed. The runtime doesn’t “wait around” for other goroutines when main exits. If your logic demands waiting for certain tasks to complete, consider using synchronization primitives like WaitGroup or channels to signal when background work is done.

What if a Panic Occurs During Initialization?

If a panic happens during init, the whole program terminates. No main, no recovery opportunity. You’ll see a panic message that can help you debug. This is one reason why I try to keep my init functions simple, predictable and free of complex logic that might blow up unexpectedly.

Wrapping It Up

By the time main runs, Go has already done a ton of invisible legwork: it’s initialized all your packages, run every init function and checked that there are no nasty circular dependencies lurking around. Understanding this process gives you more control and confidence in your application’s startup sequence.

When something goes wrong, you know how to exit cleanly and what happens to deferred functions. When your code grows more complex, you know how to enforce initialization order without resorting to hacks. And if concurrency comes into play, you know that the race conditions start after init runs, not before.

For me, these insights made Go’s seemingly simple main function feel like the tip of an elegant iceberg. If you have your own tricks, pitfalls you’ve stumbled into, or questions about these internals, I’d love to hear them.

After all, we’re all still learning - and that’s half the fun of being a Go developer.

Thanks for reading! May the code be with you :)

My Social Links: LinkedIn | GitHub | 𝕏 (formerly Twitter) | Substack | Dev.to

For more content, please consider following. See ya!

[Boost]

Ashwin Gopalsamy — Fri, 06 Dec 2024 16:40:25 +0000

A Tiny, Dependency-Free UUID Checker for Go!

Ashwin Gopalsamy ・ Dec 6 '24

#go #uuid #opensource

A Tiny, Dependency-Free UUID Checker for Go!

Ashwin Gopalsamy — Fri, 06 Dec 2024 16:40:07 +0000

As like few folks, at times, when I deal with UUIDs in Go, I rarely needed a big, feature-packed library - just a lean way to confirm something basic, like, “Yes, that string is definitely a UUID.” Sometimes, I’d also want to check if it was a UUIDv7 and maybe peek at its embedded ‘timestamp’.

Nothing major, just a quiet helper in the background.

And what?

That’s why I built uuidcheck. It’s not a complex stuff, just a handful of meaningful functions that stick to Go’s standard library. No external dependencies at all.

Only the baby steps?

I didn’t stop at making it small. I wrote clear Go-doc style documentation so you can read about each function right in pkg.go.dev; no guesswork needed. Every corner of the logic got a unit test, pushing coverage to 100%. It wasn’t hard, given the library’s size, but it’s nice to know everything’s solid. If a weird edge case comes up, I can trust the tests already have my back. Even if something slipped my mind, I would love your ‘good first contribution’ to the library.

Do you need to care?

To be honest, most projects don’t need a daily UUID validation routine or a quick timestamp extraction from UUIDv7 strings. But when you do, uuidcheck might save you from writing the same checks over and over. It’s small, neat, and does the job without weighing you down.

So, if you ever find yourself thinking, “I just need to confirm this is a real UUID, nothing else.” Remember github.com/ashwingopalsamy/uuidcheck.

It’s there to help, staying out of your way, and giving you that tiny bit of confidence where it matters.

Thanks for reading! May the code be with you :)

My Social Links: LinkedIn | GitHub | 𝕏 (formerly Twitter) | Substack | Dev.to

For more content, please consider subscribing. See ya!

Git -> GitHub -> GPG Key (Windows)

Ashwin Gopalsamy — Sun, 01 Dec 2024 13:26:04 +0000

If you're a beginner to Git or just starting to tinker with GitHub and GPG, you're probably here because you want to get that super-cute green "Verified" label next to your commits. The one that makes your contributions look professional and trusted. But, like most of us, you might have run into a few snags while setting up GPG keys on Windows. Don’t worry—you're not alone!

In this guide, I'll walk you through the entire process of setting up GPG for signing your GitHub commits on Windows. Plus, I’ll show you how I fixed a few tricky issues along the way. So, grab your coffee, and let's dive into it.

Step 1: Install Git Bash

Before we get into the GPG configuration, let's talk about Git Bash. Git Bash is a terminal emulator that comes with Git for Windows. If you haven’t installed it yet, do yourself a favor and install it. You can get it from the official Git website. Git Bash is much more user-friendly for these kinds of setups, and it plays better with Unix-based commands that you’ll need for GPG (like export).

Using Git Bash throughout this process will save you from some headaches, especially when working with environment variables. Trust me, you’ll thank me later.

Once you've installed Git Bash, open it up. Now, you're ready to go!

Step 2: Install GPG4Win (and GPG)

To get started with GPG, you’ll need to install GPG4Win, which is the suite that includes everything you need to generate your keys. You can download it from here.

After installation, make sure GPG is accessible by running the following command in Git Bash:

gpg --version

This should return the version number of GPG if it’s properly installed. If you get an error, go back to the installation and make sure it went smoothly.

Step 3: Generate a GPG Key

Next, let’s generate your GPG key. This is the key that will be used to sign your Git commits.

Run the following command in Git Bash to create your GPG key:

   gpg --full-generate-key

Choose the default options (RSA and RSA, key size 4096, etc.), and when asked for your name and email, use the same email that you have registered with GitHub.

You should see something like this:

   Real name: Your Name
   Email address: your-email@example.com

Important: Make sure the email you enter matches the one on your GitHub account. If it doesn't, GitHub won’t be able to associate your commits with your account.

Once the key is generated, list your keys to find the key ID:

   gpg --list-secret-keys --keyid-format LONG

This will output a long string with your key ID. It should look something like this:

   sec   rsa4096/XXXXXXXXXXXXXXXX 2024-12-01 [SC] [expires: 2027-12-01]
         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   uid                 [ultimate] Your Name <your-email@example.com>
   ssb   rsa4096/XXXXXXXXXXXXXXXX 2024-12-01 [E] [expires: 2027-12-01]

Copy your key ID from the rsa4096/XXXXXXXXXXXXXXXX part. You'll need it for later.

Step 4: Add Your GPG Key to Git

Now that your GPG key is ready, let's tell Git to use it for signing commits. First, export the public key to add it to GitHub:

gpg --armor --export your-email@example.com

This will print your public GPG key in ASCII format. Copy the entire output (starting with -----BEGIN PGP PUBLIC KEY BLOCK----- and ending with -----END PGP PUBLIC KEY BLOCK-----).

Next, add this key to GitHub:

Go to your GitHub account and navigate to Settings > SSH and GPG Keys > New GPG Key.
Paste your public key into the box and save it.

Step 5: Configure Git to Use Your GPG Key

Let’s tell Git to use your GPG key when signing commits. Run the following command in Git Bash:

git config --global user.signingkey your-key-id

Replace your-key-id with the GPG key ID you copied earlier.

Then, configure Git to automatically sign your commits by default:

git config --global commit.gpgSign true

This ensures that every commit you make will be signed automatically.

Step 6: Test Your Setup

You’re almost there! Now, let’s test if everything is working properly. Try making a commit in any of your repositories:

Make a small change to a file and commit it:

   git commit -m "Test commit"

Push the commit to GitHub:

   git push

Check GitHub. If everything is set up correctly, you should now see the "Verified" label next to your commit on GitHub!

Common Issues & Fixes

Okay, so you followed all the steps, but you’re still facing some issues? I’ve been there, and I’ve got you covered with a couple of extra fixes.

Problem 1: "No 'Verified' label?" – Even After Everything Looks Fine

The Issue:

If you’re getting the GPG key to work locally but don’t see the "Verified" label on GitHub, there’s a chance the problem lies in how you're using the terminal.

The Fix:

In Windows, PowerShell can be tricky when it comes to handling environment variables like GPG_TTY, which is necessary for GPG to function properly. The solution is to either set the environment variable correctly in PowerShell or switch to Git Bash.

Here’s what worked for me:

In PowerShell, set the GPG_TTY environment variable with this command:

   $env:GPG_TTY = "COM1"

Alternatively, you can point directly to the gpg.exe executable:

   $env:GPG_TTY = "C:/Program Files (x86)/GnuPG/bin/gpg.exe"

Switch to Git Bash (if you're still facing issues). Git Bash works more naturally with Unix-style commands, including setting environment variables with export. In Git Bash, run:

   export GPG_TTY=$(tty)

This should resolve most issues with signing commits in Git.

Problem 2: GPG Errors on Windows – "No Secret Key"

The Issue:

This error usually means Git can’t find your GPG private key for signing commits.

The Fix:

Check where GPG is installed using:

   where gpg

This should show you the path to your gpg.exe. Make sure it's pointing to the correct version, usually located in C:\Program Files (x86)\GnuPG\bin\gpg.exe.

Configure Git to use the correct GPG version:

If Git is pointing to the wrong GPG version, set it explicitly with:

   git config --global gpg.program "C:/Program Files (x86)/GnuPG/bin/gpg.exe"

Double-check your GPG key with:

   gpg --list-secret-keys --keyid-format LONG

Make sure your key appears. If it doesn’t, you’ll need to import it into your keyring.

Wrapping Up

Setting up GPG on Windows for GitHub commit signing can be a bit tricky, but once you’ve got everything in place, it’s totally worth it to see that “Verified” label next to your commits.

Just remember to use Git Bash to avoid some of the headaches with PowerShell and to set the correct environment variables. If you're running into GPG errors or issues with secret keys, double-check your paths and keys, and you should be good to go!

Happy coding, and enjoy the satisfaction of seeing your verified commits on GitHub! If you have any other issues or tips to share, drop a comment or tweet at me. Let's make this process smoother for everyone.

Git: Set Up Commit Signing with GPG on Mac ✅

Ashwin Gopalsamy — Tue, 19 Nov 2024 06:28:53 +0000

If you've ever tried setting up commit signing with GPG on GitHub and ended up scratching your head, especially on Mac? You're not alone.

You follow the official docs, generate a key, link it to GitHub, and set it up in your local repo, but your commits still show as "Unverified." That’s exactly what happened to me, and here’s how I finally got it working.

Generating Your GPG Key

The first step is generating the GPG key, which is usually pretty straightforward:

Generate the key:

   gpg --full-generate-key

Find your key ID:

   gpg --list-secret-keys --keyid-format LONG

Export the key:

   gpg --armor --export YOUR_KEY_ID > my-gpg-key.asc

Add the key to GitHub: Copy the output from the previous command and go to GitHub Settings > SSH and GPG keys > New GPG key. Paste it in there.

Once this is done, tell Git to use this key for signing commits:

git config --global user.signingkey YOUR_KEY_ID
git config --global commit.gpgSign true

That should take care of the basics. At this point, every commit you make should be signed with your GPG key.

But Is It Working? Check Your Repo’s Config

I thought I was all set until I started seeing "unverified" commits again. Here’s the thing: While you may have set the global config for commit signing, each repository has its own individual config. So, even if your global settings are correct, you still need to check the specific repo configuration.

Run the following to check if commit signing is enabled for your current repo:

git config commit.gpgSign

If the output is true, you're good to go.
If it’s false (or if there’s no output), you need to enable it with:

git config commit.gpgSign true

It’s a small step, but if it's not set, Git won’t sign your commits in that repo, even if you’ve got everything else configured correctly.

Don’t Want to Type Your Passphrase Everytime? Cache It!

If you’re signing commits frequently, typing your GPG passphrase every single time can get old. The good news is, you can cache the passphrase for a certain period, so you don’t have to re-enter it every time you make a commit.

To do this, add these lines to your ~/.gnupg/gpg-agent.conf file:

default-cache-ttl 600
max-cache-ttl 7200

This will cache your passphrase for 10 minutes, and the maximum cache time will be 2 hours. After that, GPG will ask you for your passphrase again.

GPG Not Working? Try Restarting the GPG Agent

Sometimes things can just break for no reason. You might notice that keys stop working, commits aren’t signed, or you see weird errors. When this happens, one thing that tends to help is restarting the GPG agent.

You can do that with:

gpgconf --kill gpg-agent

This command forces the GPG agent to restart the next time you use it. It’s a simple fix but can clear up a lot of problems when things go sideways.

GitHub Desktop Issues: No Passphrase Prompt or "Signing Failed"

If you’re using GitHub Desktop and facing issues with GPG signing (like not getting a passphrase prompt, or encountering the error gpg: signing failed: No such file or directory), the issue might be related to how GitHub Desktop interacts with GPG.

The Problem

GitHub Desktop may not properly launch the passphrase entry dialog for your GPG key, or it might not find the GPG agent. This can result in errors like:

gpg: signing failed: No such file or directory
fatal: failed to write commit object

Solution

Install pinentry-mac: GitHub Desktop often requires the pinentry-mac program for handling the passphrase prompt. Install it using Homebrew:

   brew install pinentry-mac

Configure GPG to Use pinentry-mac: Next, make sure GPG uses the right pinentry program by adding this line to your ~/.gnupg/gpg-agent.conf file:

   echo "pinentry-program $(which pinentry-mac)" >> ~/.gnupg/gpg-agent.conf

Restart the GPG Agent: After updating the configuration, restart the GPG agent to apply the changes:

   gpgconf --kill gpg-agent

Check GPG Version: Ensure you're using GPG version 2+, as older versions don’t support modern features like pinentry-mode loopback:

   gpg --version

If you have an older version, update GPG with:

   brew install gnupg

Once you’ve done this, try again in GitHub Desktop. You should now be prompted for your passphrase, and commits will be signed correctly.

If You’re Still Stuck

If you continue to encounter issues, you might want to try signing a commit directly from the terminal to isolate whether the issue is with GitHub Desktop or your GPG setup:

git commit --amend --no-edit --gpg-sign

If this works but GitHub Desktop still doesn’t, the issue is likely specific to GitHub Desktop's interaction with GPG.

Wrapping Up

Getting GPG commit signing set up on GitHub can be a bit of a pain, especially when things don’t work as expected. But once it’s up and running, it’s a great way to ensure the authenticity of your commits. Here’s a quick checklist to make sure everything’s working:

Check your repo’s commit.gpgSign config: Make sure it’s set to true for your repo with git config commit.gpgSign.
Cache your passphrase: Use gpg-agent to avoid entering your passphrase every time.
Restart the GPG agent: If things go wrong, use gpgconf --kill gpg-agent to reset your keys.
For GitHub Desktop users: Install pinentry-mac and configure GPG to use it to resolve issues with the passphrase prompt and signing failures.

If you’re still running into issues, or if you’ve got a better way of managing GPG with GitHub, leave a comment. I’d love to hear your thoughts!

Thanks for reading. May the code be with you!

Go: Pointers & Memory Management

Ashwin Gopalsamy — Sun, 17 Nov 2024 11:54:41 +0000

TL;DR: Explore Go’s memory handling with pointers, stack and heap allocations, escape analysis and garbage collection with examples

When I first started learning Go, I was intrigued by its approach to memory management, especially when it came to pointers. 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. I want to share some insights into how Go manages memory with pointers, the stack and heap, and concepts like escape analysis and garbage collection. Along the way, we'll look at code examples that illustrate these ideas in practice.

Understanding Stack and Heap Memory

Before diving into pointers in Go, it's helpful to understand how the stack and heap work. These are two areas of memory where variables can be stored, each with its own characteristics.

Stack: This is a region of memory that operates in a last-in, first-out manner. It's fast and efficient, used for storing variables with short-lived scope, like local variables within functions.
Heap: This is a larger pool of memory used for variables that need to live beyond the scope of a function, such as data that's returned from a function and used elsewhere.

In Go, the compiler decides whether to allocate variables on the stack or the heap based on how they're used. This decision-making process is called escape analysis, which we'll explore in more detail later.

Passing by Value: The Default Behavior

In Go, when you pass variables like integer, string, or boolean to a function, they are naturally passed by value. This means a copy of the variable is made, and the function works with that copy. This means, any change made to the variable inside the function will not affect the variable outside its scope.

Here's a simple example:

package main

import "fmt"

func increment(num int) {
    num++
    fmt.Printf("Inside increment(): num = %d, address = %p \n", num, &num)
}

func main() {
    n := 21
    fmt.Printf("Before increment(): n = %d, address = %p \n", n, &n)
    increment(n)
    fmt.Printf("After increment(): n = %d, address = %p \n", n, &n)
}

Output:

Before increment(): n = 21, address = 0xc000012070 
Inside increment(): num = 22, address = 0xc000012078 
After increment(): n = 21, address = 0xc000012070

In this code:

The increment() function receives a copy of n.
The addresses of n in main() and num in increment() are different.
Modifying num inside increment() doesn't affect n in main().

Takeaway: Passing by value is safe and straightforward, but for large data structures, copying may become inefficient.

Introducing Pointers: Passing by Reference

To modify the original variable inside a function, you can pass a pointer to it. A pointer holds the memory address of a variable, allowing functions to access and modify the original data.

Here's how you can use pointers:

package main

import "fmt"

func incrementPointer(num *int) {
    (*num)++
    fmt.Printf("Inside incrementPointer(): num = %d, address = %p \n", *num, num)
}

func main() {
    n := 42
    fmt.Printf("Before incrementPointer(): n = %d, address = %p \n", n, &n)
    incrementPointer(&n)
    fmt.Printf("After incrementPointer(): n = %d, address = %p \n", n, &n)
}

Output:

Before incrementPointer(): n = 42, address = 0xc00009a040 
Inside incrementPointer(): num = 43, address = 0xc00009a040 
After incrementPointer(): n = 43, address = 0xc00009a040

In this example:

We pass the address of n to incrementPointer().
Both main() and incrementPointer() refer to the same memory address.
Modifying num inside incrementPointer() affects n in main().

Takeaway: Using pointers allows functions to modify the original variable, but it introduces considerations about memory allocation.

Memory Allocation with Pointers

When you create a pointer to a variable, Go needs to ensure that the variable lives as long as the pointer does. This often means allocating the variable on the heap rather than the stack.

Consider this function:

func createPointer() *int {
    num := 100
    return &num
}

Here, num is a local variable within createPointer(). If num were stored on the stack, it would be cleaned up once the function returns, leaving a dangling pointer. To prevent this, Go allocates num on the heap so that it remains valid after createPointer() exits.

Dangling Pointers

A dangling pointer occurs when a pointer refers to memory that has already been freed.

Go prevents dangling pointers with its garbage collector, ensuring that memory is not freed while it is still referenced. However, holding onto pointers longer than necessary can lead to increased memory usage or memory leaks in certain scenarios.

Escape Analysis: Deciding Stack vs. Heap Allocation

Escape analysis determines whether variables need to live beyond their function scope. If a variable is returned, stored in a pointer, or captured by a goroutine, it escapes and is allocated on the heap. However, even if a variable doesn’t escape, the compiler might allocate it on the heap for other reasons, such as optimization decisions or stack size limitations.

Example of a Variable Escaping:

package main

import "fmt"

func createSlice() []int {
    data := []int{1, 2, 3}
    return data
}

func main() {
    nums := createSlice()
    fmt.Printf("nums: %v\\n", nums)
}

In this code:

The slice data in createSlice() escapes because it's returned and used in main().
The underlying array of the slice is allocated on the heap.

Understanding Escape Analysis with go build -gcflags '-m'

You can see what Go's compiler decides by using the -gcflags '-m' option:

go build -gcflags '-m' main.go

This will output messages indicating whether variables escape to the heap.

Garbage Collection in Go

Go uses a garbage collector to manage memory allocation and deallocation on the heap. It automatically frees memory that's no longer referenced, helping prevent memory leaks.

Example:

package main

import "fmt"

type Node struct {
    Value int
    Next  *Node
}

func createLinkedList(n int) *Node {
    var head *Node
    for i := 0; i < n; i++ {
        head = &Node{Value: i, Next: head}
    }
    return head
}

func main() {
    list := createLinkedList(1000000)
    fmt.Println("Linked list created")
    // The garbage collector will clean up when 'list' as it was not used
}

In this code:

We create a linked list with 1,000,000 nodes.
Each Node is allocated on the heap because it escapes the scope of createLinkedList().
The garbage collector frees the memory when the list is no longer needed.

Takeaway: Go's garbage collector simplifies memory management but can introduce overhead.

Potential Pitfalls with Pointers

While pointers are powerful, they can lead to issues if not used carefully.

Dangling Pointers (Continued)

Although Go's garbage collector helps prevent dangling pointers, you can still run into problems if you hold onto pointers longer than necessary.

Example:

package main

import (
    "fmt"
    "time"
)

func main() {
    data := createData()
    fmt.Println("Data created")
    time.Sleep(10 * time.Second)
    fmt.Println("Data still in use:", data[0]) // this pointer is not dereferenced yet
}

func createData() *[]int {
    data := make([]int, 1000000)
    return &data
}

In this code:

data is a large slice allocated on the heap.
By keeping a reference to it ([]int), we prevent the garbage collector from freeing the memory.
This can lead to increased memory usage if not managed properly.

Concurrency Issues - Data Race with Pointers

Here's an example where pointers are directly involved:

package main

import (
    "fmt"
    "sync"
)

func main() {
    var wg sync.WaitGroup
    counter := 0
    counterPtr := &counter // Pointer to the counter

    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            *counterPtr++ // Dereference the pointer and increment
            wg.Done()
        }()
    }

    wg.Wait()
    fmt.Println("Counter:", *counterPtr)
}

Why This Code Fails:

Multiple goroutines dereference and increment the pointer counterPtr without any synchronization.
This leads to a data race because multiple goroutines access and modify the same memory location concurrently without synchronization. The operation *counterPtr++ involves multiple steps (read, increment, write) and is not thread-safe.

Fixing the Data Race:

We can fix this by adding synchronization with a mutex:

package main

import (
    "fmt"
    "sync"
)

func main() {
    var wg sync.WaitGroup
    var mu sync.Mutex
    counter := 0
    counterPtr := &counter // Pointer to the counter

    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            mu.Lock()
            *counterPtr++ // Safely dereference and increment
            mu.Unlock()
            wg.Done()
        }()
    }

    wg.Wait()
    fmt.Println("Counter:", *counterPtr)
}

How This Fix Works:

The mu.Lock() and mu.Unlock() ensure that only one goroutine accesses and modifies the pointer at a time.
This prevents race conditions and ensures the final value of counter is correct.

What does Go's Language Specification say?

It's worth noting that Go's language specification doesn't directly dictate whether variables are allocated on the stack or the heap. These are runtime and compiler implementation details, allowing for flexibility and optimizations that can vary across Go versions or implementations.

This means:

The way memory is managed can change between different versions of Go.
You shouldn't rely on variables being allocated in a specific area of memory.
Focus on writing clear and correct code rather than trying to control memory allocation.

Example:

Even if you expect a variable to be allocated on the stack, the compiler might decide to move it to the heap based on its analysis.

package main

func main() {
    var data [1000]int
    // The compiler may choose to allocate 'data' on the heap
    // if it deems it more efficient
}

Takeaway: As the memory allocation details are kinda internal implementation and not part of the Go Language Specification, these information are only general guidelines and not fixed rules which might change at a later date.

Balancing Performance and Memory Usage

When deciding between passing by value or by pointer, we must consider the size of the data and the performance implications.

Passing Large Structs by Value:

type LargeStruct struct {
    Data [10000]int
}

func processValue(ls LargeStruct) {
    // Processing data
}

func main() {
    var ls LargeStruct
    processValue(ls) // Copies the entire struct
}

Passing Large Structs by Pointer:

func processPointer(ls *LargeStruct) {
    // Processing data
}

func main() {
    var ls LargeStruct
    processPointer(&ls) // Passes a pointer, avoids copying
}

Considerations:

Passing by value is safe and straightforward but can be inefficient for large data structures.
Passing by pointer avoids copying but requires careful handling to avoid concurrency issues.

From the field experience:

In early career, a recall a time when I was optimizing a Go application that processed large sets of data. Initially, I passed large structs by value, assuming it would simplify reasoning about the code. However, I happened to notice comparably high memory usage and frequent garbage collection pauses.

After profiling the application using Go's pprof tool in a pair programming with my senior, we found that copying large structs was a bottleneck. We refactored the code to pass pointers instead of values. This reduced memory usage and improved performance significantly.

But the change wasn't without challenges. We had to ensure that our code was thread-safe since multiple goroutines were now accessing shared data. We implemented synchronization using mutexes and carefully reviewed the code for potential race conditions.

Lesson Learned: Very early understanding how Go handles memory allocation can help you write more efficient code, as it's essential to balance performance gains with code safety and maintainability.

Final Thoughts

Go's approach to memory management (like how it does everywhere else) strikes a balance between performance and simplicity. By abstracting away many low-level details, it allows developers to focus on building robust applications without getting bogged down in manual memory management.

Key points to remember:

Passing by value is simple but can be inefficient for large data structures.
Using pointers can improve performance but requires careful handling to avoid issues like data races.
Escape analysis determines whether variables are allocated on the stack or heap, but this is an internal detail.
Garbage collection helps prevent memory leaks but might introduce overhead.
Concurrency requires synchronization when shared data is involved.

By keeping these concepts in mind and using Go's tools to profile and analyze your code, you can write efficient and safe applications.

I hope this exploration of Go's memory management with pointers will be helpful. Whether you're just starting with Go or looking to deepen your understanding, experimenting with code and observing how the compiler and runtime behave is a great way to learn.

Feel free to share your experiences or any questions you might have — I'm always keen to discuss, learn and write more about Go!

Bonus Content - Direct Pointer Support

You know? Pointers can be directly created for certain datatypes and cannot, for some. This short table covers them.

Type	Supports Direct Pointer Creation?	Example
Structs	✅ Yes	`p := &Person{Name: "Alice", Age: 30}`
Arrays	✅ Yes	`arrPtr := &[3]int{1, 2, 3}`
Slices	❌ No (indirect via variable)	`slice := []int{1, 2, 3}; slicePtr := &slice`
Maps	❌ No (indirect via variable)	`m := map[string]int{}; mPtr := &m`
Channels	❌ No (indirect via variable)	`ch := make(chan int); chPtr := &ch`
Basic Types	❌ No (requires a variable)	`val := 42; p := &val`
time.Time (Struct)	✅ Yes	`t := &time.Time{}`
Custom Structs	✅ Yes	`point := &Point{X: 1, Y: 2}`
Interface Types	✅ Yes (but rarely needed)	`var iface interface{} = "hello"; ifacePtr := &iface`
time.Duration (Alias of int64)	❌ No	`duration := time.Duration(5); p := &duration`

Please let me know in the comments if you like this; I'll try adding such bonus contents to my articles moving forward.

Thanks for reading! For more content, please consider following.

May the code be with you :)

Installing Go on Windows 11 in One Command

Ashwin Gopalsamy — Thu, 14 Nov 2024 18:10:43 +0000

Installing Go on Windows 11 in One Command

If you’re setting up Go on Windows 11, it doesn’t get simpler than this:

winget install GoLang.Go

This single command handles everything: downloading, installing, and configuring Go on your system. No manual work, no fiddling with settings—it’s exactly what you need to get started.

Screenshot:

A Few Quick Tips

Run as Admin: Make sure your terminal or PowerShell is opened as an administrator. Without it, Winget won’t complete the install.
Verify Installation: Once it’s done, type go version in the terminal to confirm Go is installed and ready to use. If it doesn’t show up, you might need to manually adjust your PATH (though Winget typically handles this for you).

Wrap-Up

With Go installed in just one line, you’re all set to start coding. Whether you’re building microservices, exploring concurrency with Goroutines, or just testing out a new language, Go’s simplicity will get you up and running fast. Give it a try, and let the code do the talking. Happy coding!

Git Practices for Critical Production-grade Codebases

Ashwin Gopalsamy — Thu, 14 Nov 2024 05:38:20 +0000

TL;DR: Master Git with best practices for commits, branches, and PRs in production-grade systems. Learn to keep codebases clean, traceable, and reliable using tools like Commitlint.

Git is the backbone of every software project. Whether you're debugging a critical issue, implementing a feature, or deploying to production, Git holds the story of your project’s evolution. But that story can get messy if we don’t follow some structure. Trust me, I’ve seen (and written) my share of cryptic commit messages and tangled branches, and it never ends well.

Working in highly critical, production-grade FinTech systems, I’ve learned that Git workflows are more than just a convenience—they’re a lifeline. Clean commits, branches, and pull requests (PRs) don’t just make life easier; they protect the stability of the systems we build, ensuring traceability and reducing risk in environments where the stakes couldn’t be higher.

Here’s a guide to Git best practices that I aim to follow (or at least aspire to), with tools to help you enforce these practices without adding too much overhead.

Commits: The Backbone of Your Codebase

Your commit history is like a logbook. It should tell you exactly what happened and why, in a way that’s easy to follow. In production-grade systems, this clarity isn’t optional—it’s critical.

1. Write Atomic Commits

An atomic commit focuses on one thing—fixing a bug, adding a feature, or refactoring code. This ensures every commit is clear, self-contained, and easy to understand. It also makes debugging and rollbacks safer.

Example:

Good:

   feat: add endpoint for user account details
   fix: handle timeout in transaction service

Bad:

   misc: fix bugs and add features

When I’m in a hurry, it’s tempting to lump everything into one commit, but I always regret it later when debugging becomes a nightmare.

2. Use Descriptive Commit Messages

Your commit message should explain what changed and, if needed, why. Following a consistent format helps everyone on the team (including your future self) understand what’s going on.

Structure:

<type>(<scope>): <subject>
<BLANK LINE>
<body (optional)>

Examples:

fix(auth): resolve token expiration issues in login
feat(api): add batch endpoint for transaction summaries

These messages don’t just help during reviews—they’re lifesavers when digging through logs or debugging an issue six months down the line.

3. Automate Commit Linting

No matter how disciplined we are, it’s easy to slip up. That’s where Commitlint comes in. It’s a lightweight tool that ensures your commit messages follow a defined convention, like Conventional Commits.

Tools for Commitlint:

Commitlint by Conventional Changelog

This is one of the most popular Commitlint tools. It’s simple, extensible, and works seamlessly with Husky to enforce commit message rules during pre-commit or pre-push hooks.
Commitlint for Conventional Commits

Written in Golang, this lightweight Commitlint tool is fast and easy to set up for smaller teams or those already using Go. It’s perfect if you prefer tools that feel native to your tech stack. My personal favorite.
Conventional Commits Specification

A useful guide to the conventions enforced by these tools.

Setting up Commitlint is straightforward, and the long-term benefits—clear commit messages, consistent history—are well worth the effort.

Branches: Organized and Traceable

In highly critical systems, branch organization is non-negotiable. It’s not just about avoiding confusion—it’s about making sure work can be traced back to its purpose, especially in microservices architectures where each service lives in its own repository.

1. Follow a Consistent Naming Convention

A good branch name starts with the task or issue identifier, making it easy to see what the branch is for. I always use this format:

Format:

<JIRA-ticket-ID>-<type>-<short-description>

Examples:

JIRA-5678-fix-transaction-timeout
JIRA-1234-feature-add-batch-processing

This convention has saved me—and my team—countless hours when tracking work across multiple repositories.

2. Keep Branches Short-Lived

The longer a branch stays open, the more likely it is to diverge from the base branch. I aim to merge branches into main or develop frequently, keeping integration smooth and reducing conflicts.

3. Rebase for a Clean History

Rebasing instead of merging keeps your branch history linear, which is much easier to follow during debugging or reviews.

Example Workflow:

git checkout JIRA-5678-fix-transaction-timeout
git pull --rebase origin main

Rebasing has saved me from so many messy histories, but I’m always careful not to rebase shared branches like main.

Pull Requests: The Gateway to Collaboration

Pull requests are where collaboration happens. In highly critical systems, they also serve as an essential checkpoint to catch mistakes before they make it to production.

1. Use Clear and Structured PR Titles

A PR title should be concise but informative. I use this format to keep things consistent and easily traceable:

Format:

[JIRA-ticket-ID] <Type>: <Short Description>

Examples:

[JIRA-5678] Fix: Handle transaction timeout edge cases
[JIRA-1234] Feature: Add bulk processing for transactions

2. Write Descriptive PR Descriptions

A good PR description provides enough context to help reviewers understand what’s changing and why. I try to answer three key questions:

What changed?
Why was this change made?
Does it introduce any risks or side effects?

Example:

### What
Added a batch endpoint for processing transaction summaries.

### Why
This improves efficiency for bulk transaction reconciliation.

### Impact
- Adds a new API endpoint.
- No breaking changes.
- Includes unit and integration tests.

3. Keep PRs Small and Focused

Large PRs are overwhelming to review and prone to mistakes. I aim to keep PRs focused on a single feature, bug, or task to make reviews faster and more effective.

4. Use Checklists and Labels

Checklists ensure that every step is complete before merging:

[ ] Unit tests added
[ ] Integration tests verified
[ ] Documentation updated

Labels like feature, fix, or hotfix also help prioritize reviews.

Why These Practices Matter

In highly critical, production-grade FinTech systems, precision isn’t optional. I’ve seen how poor Git practices can snowball into major issues—long debugging sessions, delayed releases, or even customer-facing outages. Clean commits, structured branches, and clear PRs aren’t just best practices—they’re safeguards for the stability and trustworthiness of the systems we build.

By following these practices:

Debugging in production becomes faster and more efficient.
Collaboration is smoother because everything is easy to trace.
Compliance and audits are simpler, with clear histories and well-documented changes.

If you’ve got your own favorite tools or Git horror stories, let’s swap notes. The best practices we share today could save someone a lot of time (and stress) tomorrow.

Glad you like it. May the code be with you. <3

The Ultimate Hack to Simplify Ctrl and Cmd Shortcuts Between Windows and Mac

Ashwin Gopalsamy — Wed, 13 Nov 2024 17:55:07 +0000

If you’ve ever sat down at a Windows machine after a long day on your Mac—or vice versa—you know the struggle. Your fingers instinctively hit the wrong key. You meant to copy, but instead, you’ve opened the Start menu. Or worse, you killed a process in the terminal. The Ctrl vs Cmd chaos is real, and as someone who hops between platforms daily, I know how frustrating it can be.

For developers, where every keystroke counts, this constant back-and-forth isn’t just annoying—it’s exhausting. But here’s the good news: there’s a fix, and it’s surprisingly simple. All you need is Microsoft’s PowerToys, a free, open-source tool that can tweak your Windows keyboard to match your Mac instincts.

The Ctrl vs Cmd Struggle Is Universal

If you’re a Mac-first developer like me, switching to a Windows keyboard feels like betrayal. You instinctively go for Cmd+C to copy, only to realize that it’s actually Ctrl+C. And if you’re coming from Windows, reaching for the Ctrl key on a Mac often results in frustrated clicks and a string of internal curses.

The problem isn’t just remembering which key does what; it’s rewiring your brain every time you switch systems. And as developers, we rely on muscle memory for productivity. Breaking that flow slows us down.

PowerToys to the Rescue

Here’s where PowerToys comes in. It’s an open-source utility from Microsoft that’s a lifesaver for anyone who wants to customize their Windows experience. Among its many features, Keyboard Manager lets you remap keys to make them work the way you want.

For me, that meant swapping Ctrl and the Alt key on my Windows keyboard so that it behaves more like my Mac. No more second-guessing every shortcut.

Setting It Up

Here’s how to get started:

Download PowerToys

Grab it from GitHub or directly from the Microsoft Store. It’s easy to install and lightweight.
Enable Keyboard Manager

Open PowerToys, go to the Keyboard Manager tab, and toggle it on.
Remap Keys
- Click on Remap a Key.
- Choose the Alt key as the original key and set it to act as Ctrl (Windows’ equivalent of Cmd).
- You can also remap the Ctrl key to act as Alt if you want full symmetry.
Test It

Open your IDE or favorite apps and try common shortcuts like copy, paste, and undo. You’ll notice how natural it feels almost instantly.

Screenshot

Why This Is a Game-Changer

This simple tweak eliminates one of the biggest pain points of switching platforms. Instead of wasting mental energy remembering different key placements, your keyboard works with you. For me, it’s been a small but meaningful change—one that helps me stay in the zone when coding, debugging, or even writing documentation.

Bonus Productivity Tips

While you’re exploring PowerToys, check out these other features that can make your life easier:

FancyZones: Perfect for arranging multiple windows when you’re working across terminals, browsers, and IDEs.
PowerRename: Quickly rename batches of files without leaving Explorer.
File Explorer Preview: View .md, .json, or other developer-centric file types directly in Explorer.

The Joy of a Seamless Workflow

After making this change, I stopped thinking about which key to press and started focusing on my work. It’s funny how something so small can make such a big difference. If you’re juggling Windows and Mac and tired of playing “Ctrl or Cmd roulette,” give this a shot.

Over to You

Have you tried PowerToys, or do you have your own hacks for handling multi-platform keyboard challenges? Share your tips—I’d love to hear them!

If you have found value with this post, please support me with a like or comment. Your 3 seconds means a lifetime to me.

Happy coding (and less key taming)!