Forem: Joy Biswas

Why You Should Use panic Instead of log.Fatal for Cleanup

Joy Biswas — Wed, 26 Nov 2025 04:51:14 +0000

When writing code in Go we often run into errors that are critical. These are errors that mean our application cannot continue running. To handle these we usually look at two options. We can use panic or we can use log.Fatal.

They both stop the application but they do it in very different ways. The main difference is how they treat the defer function.

The Problem with Fatal

When you use log.Fatal the application stops immediately. It calls a system function called os.Exit(1). This is a hard stop. The program does not look back and it does not run any cleanup code.

Let us look at a standard example. Imagine we are connecting to a database in our main function. We want to make sure the database connection closes when the app stops.

package main

import (
    "fmt"
    "log"
)

func main() {
    fmt.Println("1. Opening Database Connection...")

    // We schedule this to run when the function exits
    defer fmt.Println("Clean up: Closing Database Connection.")

    // Something bad happens here
    log.Fatal("CRITICAL ERROR: System failure!")
}

Output:

1. Opening Database Connection...
2025/11/26 10:00:00 CRITICAL ERROR: System failure!
exit status 1

Notice what is missing? The line "Clean up: Closing Database Connection" never printed. The defer function was ignored. If this was a real application the database connection might remain open on the server side until it times out because we never sent the close signal.

Why Panic is Different

Now let us look at panic. When a program panics it begins to shut down but it does not stop immediately. It starts "unwinding" the stack. This means it goes back up through the functions you called.

Crucially, panic executes any deferred functions it finds along the way.

Here is the same example using panic:

package main

import (
    "fmt"
)

func main() {
    fmt.Println("1. Opening Database Connection...")

    // We schedule this to run when the function exits
    defer fmt.Println("Clean up: Closing Database Connection.")

    // Something bad happens here
    panic("CRITICAL ERROR: System failure!")
}

Output:

1. Opening Database Connection...
Clean up: Closing Database Connection.
panic: CRITICAL ERROR: System failure!

[stack trace...]

The Logic: Why Use Panic?

You should use panic instead of log.Fatal when you have critical resources to manage.

In our example we initialized our application and opened a main database connection. The connection was successful. But then another error occurred later in the code.

If we use log.Fatal the app just dies. The database connection is never explicitly closed.

If we use panic the application understands that it needs to crash but it is polite about it. It pauses to run the defer function. This allows us to strictly close the database connection. Once the cleanup is done the application finally shuts down and prints the error message.

Summary

log.Fatal: Stops the app instantly. It skips defer functions. Use this only if you have no cleanup to do.
panic: Stops the normal flow but runs defer functions first. Use this when you need to ensure connections, files, or resources are closed properly before the program exits.

Go's New WaitGroup.Go

Joy Biswas — Sun, 02 Nov 2025 05:44:52 +0000

Go 1.25+ added a new method to the sync package that removes common boilerplate: the WaitGroup.Go() method. If you've used wg.Add(1), go func(), and defer wg.Done() hundreds of times, this one's for you.

The old way

Here's how we launch concurrent goroutines:

package main

import (
    "fmt"
    "sync"
)

func main() {
    var wg sync.WaitGroup
    list1 := []int{10, 20, 30, 40}
    list2 := []int{1, 10, 20, 30, 40}

    l1 := []int{-1, 4, 5, 6}
    l2 := []int{4, 5, 6}

    wg.Add(1)
    go func() {
        defer wg.Done()
        solution(list2, list1)
    }()

    wg.Add(1)
    go func() {
        defer wg.Done()
        solution(l2, l1)
    }()

    wg.Wait()
}

func solution(x, y []int) {
    var uniqueIdx int
    for _, num1 := range x {
        uniqueIdx ^= num1
    }
    for _, num2 := range y {
        uniqueIdx ^= num2
    }
    fmt.Println(uniqueIdx)
}

This works fine. But look at the steps: increment the counter manually, wrap everything in an anonymous function, remember to defer the done call. For every single goroutine.

The new way

Now we can write:

package main

import (
    "fmt"
    "sync"
)

func main() {
    var wg sync.WaitGroup
    list1 := []int{10, 20, 30, 40}
    list2 := []int{1, 10, 20, 30, 40}

    l1 := []int{-1, 4, 5, 6}
    l2 := []int{4, 5, 6}

    wg.Go(func() {
        solution(list1, list2)
    })
    wg.Go(func() {
        solution(l2, l1)
    })

    wg.Wait()
}

func solution(x, y []int) {
    var uniqueIdx int
    for _, num1 := range x {
        uniqueIdx ^= num1
    }
    for _, num2 := range y {
        uniqueIdx ^= num2
    }
    fmt.Println(uniqueIdx)
}

The Go() method handles the counter increment and the Done() call automatically. Three steps become one clean method call.

What it does

The implementation is simple:

// https://github.com/golang/go/blob/master/src/sync/waitgroup.go
func (wg *WaitGroup) Go(f func()) {
    wg.Add(1)
    go func() {
        defer wg.Done()
        f()
    }()
}

It's exactly what we've been writing manually, just packaged properly.

If you're on Go 1.25 or later, start using wg.Go() where it makes sense.

Thanks to Anton Zhiyanov for his excellent Gist of Go: Concurrency guide.

Email Validation and SMTP Handshake With Go

Joy Biswas — Fri, 24 Oct 2025 12:47:29 +0000

I was implementing a signup endpoint for an API where users can register via email. There are many ways to verify an email address. You could use a popular library like go-playground/validator to check if the input is in an email format. However, this doesn't confirm if the email address actually exists or if its domain can receive mail.

If you prefer not to use regex or an external package, Go's standard library offers the net/mail package to validate an email address format.

This approach is generally better than a simple regex validation because mail.ParseAddress parses an address according to the official RFC 5322 specification, which defines the standard for email format.

Basic Format Validation

Let's start by checking if a string has a valid email format.

Example 1: A Well-Formatted but Non-Existent Email

email := "example-user@exampledomain.com"
_, err := mail.ParseAddress(email)
if err != nil {
    log.Panic(err)
}

This code will run without an error. It passes the test because the string contains a local part (example-user), an @ symbol, and a domain (exampledomain.com). The ParseAddress function only cares about the format, not whether the address is real.

Example 2: An Incorrect Format

email := "example-user"
_, err := mail.ParseAddress(email)
if err != nil {
    log.Panic(err)
}

In this case, the program will panic and show the error: mail: missing '@' in address.

Validating the Domain

Format validation is a good first step, but it doesn't prevent users from signing up with an address like test@nonexistent-domain.com. Our next thought might be to check the domain's DNS records.

A common but flawed approach is to look up the host directly.

import "net"

domain := "exampledomain.com"
_, err := net.LookupHost(domain)
if err != nil {
       log.Panic(err)
}

This check for an A or AAAA record is not what we need for email validation. Many people purchase domains exclusively for email services and never set up a website, so they may not have an A record pointing to a web server. Letting users pass verification based on this check is a bad idea.

The correct approach is to check for MX (Mail Exchanger) records. These DNS records specify the mail servers responsible for accepting email on behalf of a domain. If a domain has MX records, it's configured to receive email.

Looking Up MX Records

First, let's get the domain name from the email address and use net.LookupMX to find the MX records for that domain.

email := "contact@gmail.com"
parts := strings.Split(email, "@")
domain := parts[1] // "gmail.com"

mxRecords, err := net.LookupMX(domain)
if err != nil {
    log.Panicf("Failed to look up MX records for %s: %v", domain, err)
}

if len(mxRecords) == 0 {
    log.Fatalf("No MX records found for %s", domain)
}

fmt.Printf("MX Records for %s:\n", domain)
for _, mx := range mxRecords {
    fmt.Printf("  Host: %s, Preference: %d\n", mx.Host, mx.Pref)
}

For a valid address like contact@gmail.com, you'll see a result similar to this, confirming the domain is set up to receive mail:

MX Records for gmail.com:
  Host: gmail-smtp-in.l.google.com., Preference: 5
  Host: alt1.gmail-smtp-in.l.google.com., Preference: 10
  Host: alt2.gmail-smtp-in.l.google.com., Preference: 20
  Host: alt3.gmail-smtp-in.l.google.com., Preference: 30
  Host: alt4.gmail-smtp-in.l.google.com., Preference: 40

If you run the same code on a domain with no MX records, net.LookupMX will return an error, such as lookup joybtw.com: no such host. This tells us the domain is not configured to receive email, and we should reject the address.

The SMTP Handshake to Verify the Mailbox

Now that we know the domain is configured to receive mail, we can go one step further by asking the server if the specific mailbox (e.g., contact@gmail.com) actually exists. We can do this by performing a partial SMTP handshake.

This process involves connecting to the mail server and simulating the first few steps of sending an email, stopping just before transmitting any actual content. The key is the RCPT TO command, where we ask the server if it will accept a message for our target email address. The server's response tells us whether the user likely exists.

Here’s how it works:

Connect to the Mail Server: We connect to the mail server with the highest priority (lowest preference number) on port 25.
Start the Conversation (EHLO): We greet the server to start the conversation.
Specify the Sender (MAIL FROM): We state the sender's address.
Check the Recipient (RCPT TO): We provide the email address to validate.
- A response code starting with 250 means "OK," and the address is likely valid.
- A response code like 550 means the address does not exist.
End the Conversation (QUIT): We properly close the connection without sending an email.

Important Considerations

While powerful, this method isn't foolproof:

Catch-All Addresses: Some servers are configured with a "catch-all" policy, meaning they accept emails for any address at that domain to prevent spammers from guessing valid addresses. In this case, the RCPT TO check will always succeed, even for non-existent mailboxes.
Security Measures: Mail servers may use security features like greylisting or block automated checks altogether. This can lead to false negatives, where a valid address appears invalid.

Here is the complete code:

Here is a simple, runnable Go program that combines these validation steps.

package main

import (
    "bufio"
    "fmt"
    "log"
    "net"
    "net/mail"
    "strings"
)

func main() {
    email := "contact@gmail.com" // Change this to test other emails

    // Validate Email Format
    _, err := mail.ParseAddress(email)
    if err != nil {
        log.Fatalf("'%s' is not a valid email format: %v", email, err)
    }

    // Extract Domain and Find MX Records
    i := strings.LastIndexByte(email, '@')
    domain := email[i+1:]

    mxRecords, err := net.LookupMX(domain)
    if err != nil {
        log.Fatalf("Could not look up MX records for '%s': %v", domain, err)
    }
    if len(mxRecords) == 0 {
        log.Fatalf("No MX records found for '%s'.", domain)
    }

    // Perform SMTP Handshake
    mxServer := mxRecords[0].Host
    conn, err := net.Dial("tcp", mxServer+":25")
    if err != nil {
        log.Fatalf("Could not connect to SMTP server: %v", err)
    }
    defer conn.Close()

    reader := bufio.NewReader(conn)
    resp, err := reader.ReadString('\n')
    if err != nil {
        log.Fatalf("Could not read from connection: %v", err)
    }
    fmt.Printf("S: %s", resp)

    // EHLO command
    fmt.Fprintf(conn, "EHLO mydomain.com\r\n")
    resp, _ = reader.ReadString('\n')
    fmt.Printf("S: %s", resp)

    // MAIL FROM command
    fmt.Fprintf(conn, "MAIL FROM:<test@mydomain.com>\r\n")
    resp, _ = reader.ReadString('\n')
    fmt.Printf("S: %s", resp)

    // RCPT TO command (The actual check)
    fmt.Fprintf(conn, "RCPT TO:<"+email+">\r\n")
    resp, _ = reader.ReadString('\n')
    fmt.Printf("S: %s", resp)

    // Check the response for the recipient
    if strings.HasPrefix(resp, "250") {
        fmt.Println("Result: Email address is likely valid.")
    } else {
        fmt.Println("Result: Email address is likely invalid.")
    }

    // QUIT
    fmt.Fprintf(conn, "QUIT\r\n")
    resp, _ = reader.ReadString('\n')
    fmt.Printf("S: %s", resp)
}

Note: This code is for educational purposes to demonstrate the concepts of email validation. It is not production-level code. For a real-world application, you would need more robust error handling, connection timeouts, and logic to iterate through multiple MX records if the primary one fails.

Makefile is Awesome, and I Love It

Joy Biswas — Sun, 19 Oct 2025 13:23:28 +0000

Makefile is my go-to tool for every project now. Instead of running long commands inside the repo, I use Makefile. Makefile is super awesome!

For my blog, while building, there were lots of commands I needed to run, like building the binary, running the binary, building the docker image, and re-building the docker image every time I made changes in my code. I had to run many commands.

go build -o blog ./cmd/api/main.go
sudo docker compose up -d
sudo docker compose up --build -d

Sometimes I became so lazy that I pressed the up arrow key lots of times because there were many other commands I had executed.

That’s why I thought I should use Makefile. You just set up the Makefile and run the command make build. Once you set it up, you can see the generated binary. You can easily remember what to run; you don’t have to type the full go build -o blog ./cmd/api/main.go or other project-related commands all the time. It’s just easy and cool.

Example Makefile:

BINARY_NAME = blog
CLI_BINARY_NAME = blog_cli
API_ENTRY = cmd/api/main.go
CLI_ENTRY = cmd/cli/main.go

# Build the main API binary.
build:
    @echo "==> Building API binary: $(BINARY_NAME)"
    @go build -ldflags="-s -w" -o $(BINARY_NAME) $(API_ENTRY)

# Build the command-line interface (CLI) binary.
build-cli:
    @echo "==> Building CLI binary: $(CLI_BINARY_NAME)"
    @go build -ldflags="-s -w" -o $(CLI_BINARY_NAME) $(CLI_ENTRY)

# Run the API application directly.
run:
    @echo "==> Running API from $(API_ENTRY)..."
    @go run $(API_ENTRY)

# Build and run the docker containers.
build-docker: docker-setup
    @echo "==> Starting Docker containers..."
    @sudo $(COMPOSE_CMD) up -d

# Rebuild and run the docker containers.
re-build-docker: docker-setup
    @echo "==> Rebuilding and starting Docker containers..."
    @sudo $(COMPOSE_CMD) up --build -d

# Shut down and remove the docker containers.
docker-down:
    @echo "==> Shutting down Docker containers..."
    @sudo $(COMPOSE_CMD) down

Now you just have to run make build or any other command you like. If you don’t know what command to run, simply run make help, it will list all the available commands in the Makefile.

Once I was working on a project where I used Air for live reloading, TailwindCSS for generating CSS, and Templ for generating user interfaces.

While building, I had to run these three commands:

tailwindcss -i ./styles/input.css -o ./assets/css/output.css --watch --minify
templ generate -path ./cmd/web/templates --watch --open-browser=false
air

You can easily remember air, but the other two commands are a bit long, and I had to press the up arrow key countless times.

Again, Makefile came to the rescue.

Example:

TEMPLATES_DIR = cmd/web/templates
TAILWIND_INPUT = cmd/web/styles/input.css
TAILWIND_OUTPUT = cmd/web/assets/css/output.css

watch-air:
    @echo "==> Starting Air for live reload..."
    @air

watch-templ:
    @echo "==> Watching templ files..."
    @templ generate -path $(TEMPLATES_DIR) --watch --open-browser=false

watch-css:
    @echo "==> Watching CSS files..."
    @tailwindcss -i $(TAILWIND_INPUT) -o $(TAILWIND_OUTPUT) --minify --watch

However, if you try to run the commands like this:

watch:
    @$(MAKE) watch-templ
    @$(MAKE) watch-air
    @$(MAKE) watch-css

This method won’t work because here we are executing three commands sequentially, so the second command waits for the first to finish.

Now we have to run these commands in parallel:

watch:
    @echo "==> Starting live reload with Air, Templ, and Tailwind CSS..."
    @$(MAKE) -j3 watch-air watch-templ watch-css

The make -jN option specifies the maximum number of commands that make can run in parallel.

Just run make watch and you’re good to go. Makefile just makes your development process much easier and more efficient. I hope you use Makefile in your project!

A Docker Trick I Wish I Knew Sooner

Joy Biswas — Thu, 16 Oct 2025 05:04:06 +0000

While building a Docker image recently, I needed to download a file using curl. My first instinct was to install curl in the container, make the request, and move on. But then I discovered Docker has a built-in way to handle this, and it's cleaner.

The Old Way: Installing curl

Here's what I was doing initially:

FROM alpine:latest
WORKDIR /app
RUN apk add --no-cache curl
RUN curl -sS https://example.com/somefile.txt -o /app/somefile.txt

EXPOSE 8080

This works, but it adds unnecessary bloat. You're installing curl just to download a file, increasing your image size and adding an extra dependency you don't really need at runtime.

The Better Way: Using Docker's ADD Instruction

Docker's ADD instruction can fetch remote files directly without requiring curl or wget:

FROM alpine:latest
WORKDIR /app
ADD https://example.com/anotherfile.json /app/anotherfile.json

EXPOSE 8080

Much simpler. No extra packages, no additional layers, and the intent is clearer. ADD pulls the file at build time and places it exactly where you need it.

Why This Matters

Smaller Image Size

Every package you install adds megabytes to your final image. Skipping curl keeps things lean, especially important when you're optimizing for production or working with constrained environments.

Fewer Dependencies

Less tooling means fewer potential security vulnerabilities and a simpler dependency tree. Your container only contains what it actually needs.

Cleaner Dockerfiles

Using built-in instructions makes your Dockerfile more readable and idiomatic. Other developers (or future you) will immediately understand what's happening.

When to Use Each Approach

Use ADD when:

You're downloading a single file from a URL
The file doesn't require authentication
You want to keep your image minimal

Stick with curl or wget when:

You need more control over the download (headers, authentication, retries)
You're fetching multiple files in a complex workflow
You need to process or validate the downloaded content before using it

Have you used ADD for remote files before, or do you have other Docker tricks worth sharing? Let me know in the comments! 😊

My personal blog built with Go and React

Joy Biswas — Thu, 16 Oct 2025 04:44:47 +0000

For quite some time I wanted to change the look of my blog a bit.
Changed a lot in this version. Made the Footer which is now StatusBar like Vim/Neovim style. Also changed the Header and instead of a typical header made a sidebar. Feels good man! 😊
Your feedback is appreciated!

Techstack:
Backend: Go, Gin, Redis, PostgreSQL, Viper
Frontend: React, TailwindCSS

For Markdown rendering used: react-markdown and for syntax highlighting used: highlight.js.
For Markdown editor used: react-md-editor

Here's the source code

Real-Time Server Monitoring with Go and WebSockets

Joy Biswas — Mon, 06 Oct 2025 16:41:02 +0000

For a long time I wanted to create a project with WebSocket but wasn't getting a good idea. One day I was checking my VPS's resources from htop. Then suddenly an idea popped in my mind: why not use WebSocket and do that remotely in real-time?

The Idea

The concept is simple. Instead of SSHing into my server every time I want to check CPU usage, memory, or disk space, I could build a web dashboard that streams this information live. WebSockets make this perfect because they keep a persistent connection open, pushing updates to the browser without constant polling.

The Tech Stack

As usual, I'm gonna use Go. For such a simple project, I used Go's standard net/http library for the web server, github.com/gorilla/websocket for WebSocket connections, and github.com/shirou/gopsutil to fetch system metrics.

The beauty of this stack is how lightweight it is. No heavy frameworks, no complex setup. Just three dependencies and you're good to go.

Quick note: Yes, tools like Prometheus and Grafana already do this (and better). But where's the fun in that? This project is all about learning how these things work under the hood.

How It Works

The server does two main things. First, it serves a simple HTML page with CSS and JavaScript that connects to the WebSocket endpoint. Second, it collects system stats using gopsutil and pushes them through the WebSocket connection every second or so.

On the backend, gopsutil makes it dead simple to grab CPU percentages, memory usage, disk space, and even network stats. The gorilla/websocket package handles the upgrade from HTTP to WebSocket and manages the connection lifecycle.

The frontend is basic HTML, CSS and JavaScript. When the page loads, it establishes a WebSocket connection and listens for messages. Each message contains JSON data with the current system stats, which gets displayed in real-time on the page.

Why This Project Matters

This might seem like a toy project, but it taught me some valuable concepts. I learned how WebSockets maintain stateful connections, how to handle concurrent clients in Go, and how to gather system metrics programmatically.

Plus, it's actually useful. I can now check my server's health from any browser without needing SSH access. You could extend this to monitor multiple servers, add alerts when resources hit certain thresholds, or even create graphs showing resource usage over time.

Themes

The dashboard comes with five different visual styles to match your preference. Here's what each theme looks like:

I'm not very good at designing UI, so it needs to be fixed a lot. If you're into frontend, feel free to contribute and make it look better.

Getting Started

If you want to try it yourself, here's how:

Clone the repository:

   git clone https://github.com/joybiswas007/res_mon.git
   cd res_mon

Install the dependencies:

   go mod tidy

Run the server:

   go run main.go

Open your browser and go to http://localhost:8080

The code is straightforward, so you can easily modify it to track different metrics or change how often updates are sent.

One More Thing...

Oh, and I took the liberty to write a Dockerfile and docker-compose.yaml file. Was it necessary? Absolutely not. Could you just run go run main.go and call it a day? Yes. Did I spend extra time containerizing a project that literally runs on a single command? Also yes.

Beware of Bots Everywhere

Joy Biswas — Sat, 04 Oct 2025 07:16:47 +0000

Beware of Bots Everywhere

Everyone, watch out for bots. Writing code is important, but it's not enough. When you deploy an app, you must make sure it's secure. For example, secrets like API keys should not leak. There are many stories about the high cost of leaked secret keys on Github.

I check my blog logs every day. From the start, I noticed strange IP addresses. They tried to visit pages that do not exist. Some tried to grab environment variables. Others attempted to run weird commands. This shows why we need to think about security during every deployment.

I host my blog on a VPS. I closed all ports except the ones I need. I also run the blog inside a Docker container for extra safety. These steps help block most threats. Use firewall like UFW to enforce port rules and keep everything updated.

Here are some recent log images I captured. My server handles this kind of activity every day.

Stay vigilant with your setups. Simple habits like log checks and port controls can save you from big problems. Check your own logs today.

Check out my blog's source code here.

How I Stopped Worrying About RAM and Learned to Love Vim

Joy Biswas — Mon, 29 Sep 2025 07:03:56 +0000

That's right, both Vim and Neovim are now a part of my life. I love them both. Today's topic isn't about Vim vs. Neovim, I just wanted to share my experience with you all. I use Vim for all kinds of text editing and Neovim for coding

When It Started

At the end of December 2024 and into early January 2025, I started learning Vim. Before that, Zed had just been released for Linux, so I installed it on my Manjaro device. After trying Zed for a few days, I found it really cool, it used less RAM than VSCode.

Like everyone else, I began my development journey with VSCode. I saw people bragging about Vim and Neovim, and I noticed some developers typing incredibly fast. Seriously, just using the keyboard without ever touching the mouse, they were moving really fast! I was like, I have to learn this, and here I am.

RAM Usage

This is how much RAM gets used when I open VSCode, Postman, and Chromium at the same time. The best part is, this is just when I write Go code. If I write JavaScript, the RAM usage in VSCode goes up even more.

See VSCode almost uses 1.3 GB of RAM just when you open it, and when the project grows, the memory usage goes even higher. If you work with JavaScript projects, you'll notice RAM usage increases even more because of all the extra features and extensions running in the background. This is one reason I like using Vim and Neovim for coding, they are much lighter.

The Learning Curve

My first few days were rough. I kept forgetting how to exit, lost files, and fumbled through basic navigation. The modal editing system was a completely different mindset compared to traditional editors. It took a while to get used to switching between normal, insert, and visual modes. I relied heavily on cheat sheets and spent a lot of time on following tutorials. I'm still learning a lot.

Customizing My Setup

Once I got comfortable with the basics, I started tweaking my setup. If you're curious, you can check out my Neovim config file here: joybiswas007/kickstart.nvim. I actually used a fork of the popular kickstart.nvim starter template, which you can find at nvim-lua/kickstart.nvim.

If you want to learn Vim, I highly recommend checking out Learn Vim (the Smart Way). It's a free, beginner-friendly guide that covers everything from the basics to advanced topics and is a great resource for both new and experienced users.

How Vim and Neovim Changed My Workflow

The biggest change? I barely touch the mouse now. Navigating between files, editing text, and running commands all happen from the keyboard. My workflow feels faster and more focused. Macros and registers are game changers for repetitive tasks.

Advice for Beginners

If you’re thinking about trying Vim or Neovim, start small. Learn a few commands at a time and don’t get overwhelmed by all the possibilities. Use cheat sheets and practice regularly. Don’t be afraid to break things, messing up is part of the learning process. And remember, customizing your setup can make the experience a lot more enjoyable.

Conclusion

Looking back, I’m happy I tried Vim and Neovim. They’ve helped me code better and faster. I’m still learning new things, and that keeps it interesting. If you’re unsure about trying them, just go for it, you might end up liking them more than you expect.

Why I Stopped Using go mod download in My Dockerfile

Joy Biswas — Mon, 29 Sep 2025 07:01:47 +0000

Using go mod download inside your Dockerfile can significantly slow down your image build process. Each time you rebuild the image, all Go modules are downloaded again, making the process inefficient, especially during local development when rebuilds are frequent and can take a long time.

While working on the Dockerfile for running my blog inside a Docker container, I encountered this issue firsthand. Every time I made changes and rebuilt the image, Go modules were re-downloaded repeatedly. It quickly became time consuming and frustrating.

Solution

So, how did I solve this? The answer was simple: I used Docker's build cache. After making the changes, the build times were noticeably reduced, and I could clearly see the improvement.

Dockerfile

With caching (fast):

# Set Go proxy to direct (optional)
ENV GOPROXY=direct

# Copy Go mod files and download dependencies
COPY go.mod go.sum ./

# Set cache directories
ENV GOCACHE=/go-cache
ENV GOMODCACHE=/gomod-cache

# Complete other tasks
...

# Build statically linked, optimized binary
RUN --mount=type=cache,target=/gomod-cache --mount=type=cache,target=/go-cache \
    go build -o binary main.go

Without caching (slow):

# Copy Go mod files and download dependencies
COPY go.mod go.sum ./

# Download Go modules
RUN go mod download

# Build the Go binary
RUN go build -o binary main.go

# Complete other tasks
...

go mod download keeps running until it encounters an error or is manually stopped.

You can check out the final Dockerfile here.

Arch Installation Guide

Joy Biswas — Mon, 29 Sep 2025 07:01:11 +0000

This is a minimal guide to install Arch Linux. I used these steps to install Arch Linux on my device. I hope this guide will help you guys. So, let's begin right away!

If you are reading this guide, then I assume you are already booted into Arch and following these steps. I've used nano as a text editor during the installation, but you can use any text editor you like: nano, vim, vi etc.

No.	Topic
1	Pre-installation
2	Verify signature
3	Connect to the internet
4	Update the system clock
5	Partition the disks
6	Format the partitions
7	Mount the file systems
8	Installation
9	Install essential packages
10	Configure the system
11	Chroot
12	Time zone
13	Localization
14	Network configuration
15	Initramfs
16	Root password
17	Post-installation

Pre-installation

Grab the Arch Linux ISO file from their Download page and boot your USB drive with any bootable software you like. I've used Balena Etcher in this tutorial.

Verify signature

It is recommended to verify the image signature before use, especially when downloading from an HTTP mirror, where downloads are generally prone to be intercepted to serve malicious images

gpg --keyserver-options auto-key-retrieve --verify archlinux-version-x86_64.iso.sig

Alternatively, from an existing Arch Linux installation run:

pacman-key -v archlinux-version-x86_64.iso.sig

Connect to the internet

Ensure your network interface is listed and enabled, for example with ip-link(8)

ip link

Verify the connection with ping

ping archlinux.org

Or make sure your device is connected to the Internet with Ethernet Cable.

Update the system clock

Use timedatectl(1) to ensure the system clock is accurate:

timedatectl set-ntp true

To check the service status, use:

timedatectl status

Partition the disks

Use cfdisk to partition the disk. We'll be using cfdisk in this guide. It's super easy to partition the disks with cfdisk. Seriously! Try it once.

Format the partitions

As you are done making partitions, now let's format them to make them usable.

mkfs.ext4 /dev/root_partition
mkfs.fat -F32 /dev/efi_system_partition

If you created an EFI system partition, format it to FAT32 using mkfs.fat(8).

mkswap /dev/swap_partition

Mount the file systems

mount /dev/root_partition /mnt

Now let's create some directory inside the /mnt partition to mount the efi system.

mkdir -p /mnt/boot/efi
mkdir /mnt/home

And now mount the EFI system:

mount /dev/sda1 /mnt/boot/efi

If you created a swap volume, enable it with swapon(8):

swapon /dev/swap_partition

Select the mirrors

Packages to be installed must be downloaded from mirror servers, which are defined in /etc/pacman.d/mirrorlist. On the live system, after connecting to the internet, reflector updates the mirror list by choosing 20 most recently synchronized HTTPS mirrors and sorting them by download rate.

The higher a mirror is placed in the list, the more priority it is given when downloading a package. You may want to inspect the file to see if it is satisfactory. If it is not, edit the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account.

This file will later be copied to the new system by pacstrap, so it is worth getting right.

Install essential packages

Use the pacstrap(8) script to install the base package, Linux kernel and firmware for common hardware:

pacstrap /mnt base linux linux-firmware vim nano linux-headers base-devel

Tip:
You can substitute linux for a kernel package of your choice, or you could omit it entirely when installing in a container.

You could omit the installation of the firmware package when installing in a virtual machine or container.

The base package does not include all tools from the live installation, so installing other packages may be necessary for a fully functional base system. In particular, consider installing:

Configure the system

Generate an fstab file (use -U or -L to define by UUID or labels, respectively):

genfstab -U /mnt >> /mnt/etc/fstab

Check the resulting /mnt/etc/fstab file, and edit it in case of errors.

Chroot

Change root into the new system:

arch-chroot /mnt

Now let's install some necessary packages which we need to complete the install process

pacman -S grub efibootmgr efivar networkmanager intel-ucode amd-ucode

if you device is support Intel microcode then install intel-ucode or if you device support AMD micorcode then install amd-ucode.

Time zone

Set the time zone:

ln -sf /usr/share/zoneinfo/Region/City /etc/localtime

Change the Region & City according to your location.

ln -sf /usr/share/zoneinfo/Asia/Dhaka /etc/localtime

Or check all the available regions

cd /usr/share/zoneinfo && ls

Select the one you need.

Run hwclock(8) to generate /etc/adjtime:

hwclock --systohc

Localization

Create the locale.conf(5) file, and set the LANG variable accordingly:

nano /etc/locale.conf

Enter the followings in locale.conf file

LANG=en_US.UTF-8

Edit /etc/locale.gen and uncomment en_US.UTF-8 UTF-8 and other needed locales. Generate the locales by running:

locale-gen

Network configuration

Create the hostname file:

nano /etc/hostname

Edit /etc/hostname and add this line:

myhostname

Alternatively, Using hostnamectl(1):

hostnamectl set-hostname myhostname

Some software may however still read /etc/hosts directly. To prevent them from potentially breaking or delaying operation, configure the hosts(5) file:

nano /etc/hosts

127.0.0.1   localhost
::1     localhost
127.0.1.1   myhostname

Complete the network configuration for the newly installed environment. That may include installing suitable network management software.

Initramfs

Creating a new initramfs is usually not required, because mkinitcpio is run automatically during the kernel package installation.

For LVM, system encryption, or RAID, modify mkinitcpio.conf(5) and regenerate the initramfs image:

mkinitcpio -P

Root password

Set the root password:

passwd

Install GRUB bootloader

Install GRUB in the EFI directory:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB

Generate the GRUB configuration file:

grub-mkconfig -o /boot/grub/grub.cfg

Enable NetworkManager

systemctl enable NetworkManager

Exit chroot

exit

Unmount

Unmount all partitions:

umount -R /mnt

Optionally, use fuser to identify any busy partitions before unmounting.

Reboot

reboot

If you see the login screen, congratulations—you've successfully installed Arch Linux!

Username: root

Password: YourRootPassword

Post-installation

A new installation only includes the root account. It is best to create an unprivileged user account for daily use.

Create a new user:

useradd --create-home myuser
passwd myuser

Add the user to common groups:

usermod -aG wheel,users,power,storage myuser

Enable sudo access for your user:

nano /etc/sudoers

Uncomment the following line:

%wheel ALL=(ALL) ALL

Install GUI

Xorg (Display Server)

Install Xorg:

pacman -S xorg

Install some basic fonts:

pacman -S ttf-dejavu ttf-droid ttf-font-awesome otf-font-awesome ttf-lato ttf-liberation ttf-opensans ttf-ubuntu-font-family

Edit FreeType configuration:

nano /etc/profile.d/freetype2.sh

Uncomment this line:

export FREETYPE_PROPERTIES="truetype:interpreter-version=40"

KDE Desktop Environment

Install KDE and SDDM (Display Manager):

pacman -S sddm plasma

(Optional) Install all KDE applications:

pacman -S kde-applications

Enable and start the display manager:

systemctl enable sddm.service
systemctl start sddm.service

And you're done! Enjoy your Arch Linux setup.

Here is the Official Arch Linux Install Guide.

The Effect of AI on Me

Joy Biswas — Mon, 29 Sep 2025 07:00:26 +0000

I don't know why, but when I try to learn frontend development, I don't find it as exciting as backend or Linux related topics. I understand React, but my real struggle is UI design, I'm just not good at it. With backend projects, I can read documentation, follow tutorials, and build things. But design? Remember that meme about backend developers who can't center a div? That's me.

My AI Experiment

While building the dashboard with React and TailwindCSS for this blog, I hit a wall with design. So I thought: Let's try AI! What followed was 2-3 days of frustration.

My first prompt: "Create a React login component." The result? A stark white screen with basic inputs, zero creativity. I refined my request, but the AI kept producing similar uninspired designs. And you can also guess what happened with the other components and how many times I had to re-run the prompt to redesign the dashboard. That's when I realized: AI needs precise prompting, and even then, its creativity is limited.

The Dependency Trap

What started as a helper became a crutch. I began using AI (ChatGPT, Gemini, Copilot) for everything:

Simple text changes I could make in seconds
Basic layout fixes
Errors I could've solved with a quick Google search

The scary part? The more I used AI for trivial tasks, the harder it became to think independently. Like slow poison, reliance crept in:

Immediate solutions felt convenient
My problem-solving muscles weakened
I grew impatient with manual work

Lessons Learned

AI is a tool, not a replacement

It can't replicate human creativity in design
The prompt matters

"Make a beautiful login page" ≠ effective instruction
Overuse harms growth

If you delegate thinking, you stop learning

Those 2-3 days taught me: Use AI to enhance skills, not avoid developing them.

Forem: Joy Biswas

Why You Should Use panic Instead of log.Fatal for Cleanup

The Problem with Fatal

Why Panic is Different

The Logic: Why Use Panic?

Summary

Go's New WaitGroup.Go

The old way

The new way

What it does

Email Validation and SMTP Handshake With Go

Basic Format Validation

Validating the Domain

Looking Up MX Records

The SMTP Handshake to Verify the Mailbox

Important Considerations

Here is the complete code:

Makefile is Awesome, and I Love It

A Docker Trick I Wish I Knew Sooner

The Old Way: Installing curl

The Better Way: Using Docker's ADD Instruction

Why This Matters

Smaller Image Size

Fewer Dependencies

Cleaner Dockerfiles

When to Use Each Approach

My personal blog built with Go and React

Real-Time Server Monitoring with Go and WebSockets

The Idea

The Tech Stack

How It Works

Why This Project Matters

Themes

Getting Started

One More Thing...

Beware of Bots Everywhere

Beware of Bots Everywhere

How I Stopped Worrying About RAM and Learned to Love Vim

When It Started

RAM Usage

The Learning Curve

Customizing My Setup

How Vim and Neovim Changed My Workflow

Advice for Beginners

Conclusion

Why I Stopped Using go mod download in My Dockerfile

Solution

Dockerfile

Arch Installation Guide

Table of Contents

ToC

Pre-installation

Verify signature

Connect to the internet

Update the system clock

Partition the disks

Format the partitions

Mount the file systems

Select the mirrors

Install essential packages

Configure the system

Chroot

Time zone

Localization

Network configuration

Initramfs

Root password

Install GRUB bootloader

Enable NetworkManager

Exit chroot

Unmount

Reboot

Post-installation

Install GUI

Xorg (Display Server)

KDE Desktop Environment

The Effect of AI on Me

My AI Experiment

The Dependency Trap

Lessons Learned