Forem: Yash-007

LynkBin: AI-Powered Bookmark Manager

Yash-007 — Sat, 20 Dec 2025 21:45:51 +0000

I save a lot of good content. LinkedIn posts, X threads, Reddit insights.
but when I actually need them… they’re gone.

Bookmarks became a black hole.

so I started building LynkBin

a simple place to dump everything you save and actually find it later.

what it does:

one hub for saved posts + personal notes
AI auto organizes stuff (categories, tags, short descriptions based on the content)
smart filters so you don’t have to scroll forever
save in seconds via Dashboard or Telegram bot **

the goal isn’t to save more content. it’s to make saved content useful again.

I’m actively adding more features including support for more platforms like Instagram, YouTube, and will also work on browser extension to save things even faster.

I'm open to ideas on what would make this useful and super easy for you to use.

Go Concurrency: Goroutines, Channels and WaitGroups

Yash-007 — Tue, 12 Aug 2025 21:21:34 +0000

In Go, we can make our program do more than one thing at the same time. This is called concurrency, and it’s a great way to get things done faster.

we'll walk through goroutines, channels, and WaitGroups with simple examples you can try yourself.

What is concurrency?

imagine you’re making dinner. while the pasta is boiling, you start cutting vegetables for the salad. you’re doing both at once so the food is ready sooner.

that’s how concurrency works in a program. you run different tasks side by side instead of waiting for each one to finish before starting the next.

Goroutines: Your Lightweight Workers

A goroutine is like hiring an extra worker for your program. it's incredibly cheap to create (we can have thousands of them) and they all work together.

simple example: without Goroutines

func main() {
    cookPasta()     // takes 10 minutes
    makeSalad()     // takes 5 minutes
    bakeBread()     // takes 15 minutes
    // Total time: 30 minutes
}

with Goroutines

func main() {
    go cookPasta()     // start cooking pasta in background
    go makeSalad()     // start making salad in background
    go bakeBread()     // start baking bread in background

    time.Sleep(16 * time.Minute) // Wait for everything to finish
    // Total time: 16 minutes (everything runs together!)
}

the go keyword is like saying "hey, start doing this task in the background while I continue with other things."

The Problem: How Do We Know When Work is Done?

here's the issue with the restaurant example above. how do we know when all the chefs are done? we used time.Sleep() which is like guessing how long it will take. that's not reliable.

Solution 1: WaitGroups (The Team Counter)

A WaitGroup is like a counter that keeps track of how many workers are still busy.

func main() {
    var wg sync.WaitGroup  // create a counter

    wg.Add(1)  // "I'm starting 1 worker"
    go func() {
        defer wg.Done()  // "this worker is finished"
        cookPasta()
    }()

    wg.Add(1)  // "I'm starting another worker"
    go func() {
        defer wg.Done()  // "this worker is finished"
        makeSalad()
    }()

    wg.Wait()  // "wait until all workers are done"
    fmt.Println("all food is ready")
}

When to use WaitGroups:

you have a fixed number of tasks
you just want to wait for everything to finish
you don't need results back from the workers

Solution 2: Channels (The Communication System)

Channels are like walkie-talkies that let your goroutines talk to each other. they can send messages, data, or even just signals saying "I'm done"

basic Channel example

func main() {
    messages := make(chan string)  // create a walkie-talkie

    // Worker sends a message
    go func() {
        time.Sleep(2 * time.Second)
        messages <- "Pizza is ready!"  // send message through channel
    }()

    // main goroutine receives the message
    msg := <-messages  // wait for and receive message
    fmt.Println(msg)   // pints: "Pizza is ready!"
}

Using Channels for Completion Signals

func cookWithChannels() {
    done := make(chan bool)  // create a "done" signal channel

    go func() {
        cookPasta()
        done <- true  // send "finished" signal
    }()

    go func() {
        makeSalad()
        done <- true  // send "finished" signal
    }()

    // wait for both tasks to finish
    <-done  // wait for first task
    <-done  // wait for second task

    fmt.Println("both tasks completed!")
}

Real World Example: Processing Multiple Files

let's say you want to process 100 files. here's how you'd do it:

Without Concurrency (Slow)

func processFiles(files []string) {
    for _, file := range files {
        processFile(file)  // process one file at a time
    }
    // If each file takes 1 second, 100 files = 100 seconds
}

With Goroutines and WaitGroups (Fast)

func processFilesConcurrently(files []string) {
    var wg sync.WaitGroup

    for _, file := range files {
        wg.Add(1)
        go func(fileName string) {
            defer wg.Done()
            processFile(fileName)
        }(file)
    }

    wg.Wait()  // wait for all files to be processed
    // with 10 CPU cores, 100 files might take only 10 seconds
}

With Goroutines and Channels (Getting Results Back)

func processFilesWithResults(files []string) {
    results := make(chan string, len(files))  // buffered channel

    // start workers
    for _, file := range files {
        go func(fileName string) {
            result := processFile(fileName)
            results <- result  // send result back
        }(file)
    }

    // Collect results
    for i := 0; i < len(files); i++ {
        result := <-results
        fmt.Println("Got result:", result)
    }
}

When to Use What?

use Goroutines when:

you want to do multiple things at the same time
tasks are independent of each other
you want to improve performance

use WaitGroups when:

you have a known number of workers
you just need to wait for everything to finish
you don't need results or communication

use Channels when:

workers need to send data back
you need coordination between goroutines
you want to control the flow of work

Simple Worker Pool Pattern

func workerPool(jobs []string, numWorkers int) {
    jobChan := make(chan string)

    // start workers
    var wg sync.WaitGroup
    for i := 0; i < numWorkers; i++ {
        wg.Add(1)
        go func(workerID int) {
            defer wg.Done()
            for job := range jobChan {  // keep taking jobs until channel closes
                fmt.Printf("Worker %d processing %s\n", workerID, job)
                // do actual work here
                time.Sleep(1 * time.Second)
            }
        }(i)
    }

    // send jobs
    go func() {
        for _, job := range jobs {
            jobChan <- job
        }
        close(jobChan)  // signal no more jobs
    }()

    wg.Wait()  // wait for all workers to finish
    fmt.Println("all jobs completed!")
}

Goroutines are cheap and easy.
WaitGroups are perfect for "fire and forget" scenarios
Channels are great when you need communication or results

REST vs gRPC – When to Use What

Yash-007 — Sat, 26 Jul 2025 21:37:55 +0000

Most of us start building APIs with REST. It’s easy, works well in browsers and is simple to test using tools like postman or curl. you send some JSON, get a response that’s it.

But recently I came across gRPC. At first, it seemed complicated. but once I understood the basics, it started to make sense. This post is just a quick summary of what I learned not a deep dive, just something simple to help others get started.

First, What is RPC?

before understanding gRPC, let’s look at RPC (Remote Procedure Call).

RPC is when one program calls a function that runs on another machine, like it’s calling a local function. You don’t worry about the network or HTTP stuff just call a method, pass some data, and get back a result.

It’s like saying:

“Run this function somewhere else and send me the result.”

that makes it a good fit for when services need to talk to each other often.

gRPC is an RPC framework

REST – Easy, Familiar, Works Everywhere

REST is the most common way to build APIs. It uses HTTP/1.1 and sends data using JSON. JSON is text-based, easy to read, and works with browsers, mobile apps, and tools.

Why REST is popular:

easy to read and write
simple to test (Postman, curl, browser)
great for frontend-backend connections
If your API is going to be used by web or mobile apps. REST is the obvious choice.

gRPC – Some Setup, But Super Fast

gRPC is a better choice when your own backend services need to talk to each other like microservices or internal APIs.

Instead of JSON, gRPC uses a smaller binary format called protobuf. it also uses HTTP/2, which allows faster, multiple connections and streaming.

It made backend communication really fast and clean and used a lot by companies with big systems, where many services need to talk to each other quickly.

How Does gRPC Work?

Step 1: write a .proto file

syntax = "proto3";

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

Step 2: Generate code

You run a command to generate client and server code from the proto file.

Step 3: Use that code

Server code (in Go):

func (s *MyGreeterServer) SayHello(ctx context.Context, req *pb.HelloRequest) (*pb.HelloReply, error) {
  return &pb.HelloReply{Message: "Hello " + req.Name}, nil
}

Client code:

conn, _ := grpc.Dial("localhost:50051", grpc.WithInsecure())
client := pb.NewGreeterClient(conn)

res, _ := client.SayHello(context.Background(), &pb.HelloRequest{Name: "Yash"})
fmt.Println(res.Message) // "Hello Yash"

You call a function like normal, and gRPC handles everything behind the scenes.

When to Use What?

If your service talks to browsers or mobile apps → REST is easier.

If your services talk to each other a lot → gRPC is faster and uses less data.

for example, a frontend app calling your API → REST.
two backend services sending data to each other all day → gRPC.

Reflection in Go — When You Need to Work with the Unknown

Yash-007 — Fri, 25 Jul 2025 20:22:05 +0000

Go is a statically typed language, which means you usually know the type of every variable at compile time. but sometimes you don’t especially when working with interface{} and that’s when reflection becomes useful.

The reflect package in Go allows your program to inspect and even modify types and values at runtime.

reflect.TypeOf and reflect.ValueOf

These two are the entry points for using reflection in Go:

TypeOf() gives the static type.
ValueOf() gives the runtime value.

x := 3.14

t := reflect.TypeOf(x)   // float64
v := reflect.ValueOf(x)  // 3.14

fmt.Println("Type:", t)
fmt.Println("Kind:", t.Kind()) // float64

Reading Struct Fields at Runtime

Reflection lets you loop through struct fields dynamically:

type User struct {
    Name string `json:"name"`
    Age  int    `json:"age"`
}

u := User{"Yash", 30}
v := reflect.ValueOf(u)
t := reflect.TypeOf(u)

for i := 0; i < v.NumField(); i++ {
    field := t.Field(i)
    fmt.Println("Field:", field.Name)
    fmt.Println("Value:", v.Field(i))
    fmt.Println("Tag:", field.Tag.Get("json"))
}

This is exactly what libraries like encoding/json or gorm do under the hood read struct fields and tags at runtime to decide how to handle data.

Modifying a Value Using Reflection

If you want to update a variable through reflection, you need to pass a pointer:

x := 3.4
v := reflect.ValueOf(&x) // pass pointer
v.Elem().SetFloat(7.1)

fmt.Println(x) // 7.1

Trying to modify a non-pointer value will result in a panic.

Dynamically Calling Methods

You can even call methods by their name:

type MyType struct{}

func (m MyType) SayHello(name string) {
    fmt.Println("Hello", name)
}

v := reflect.ValueOf(MyType{})
method := v.MethodByName("SayHello")
method.Call([]reflect.Value{reflect.ValueOf("Yash")}) // Output: Hello Yash

Reflection is heavily used in the Go ecosystem. some common examples:

encoding/json for marshaling and unmarshaling structs
GORM (ORM library) to map Go structs to database tables
Validation libraries (like go playground/validator)
Logging tools, serialization frameworks, CLI parsers, etc.

End:

Reflection is powerful, but:

It’s slower than regular code
You lose compile time type safety
It can make code harder to understand
So use it only when you really need dynamic behavior.

A Subtle Memory Leak in Go You Might Miss

Yash-007 — Thu, 24 Jul 2025 13:36:54 +0000

When we think of memory leaks, we usually imagine something obvious like forgetting to close a file or a goroutine running forever. But in Go, memory leaks can be much more subtle.

One such case comes from how slices work under the hood.

How slices actually work:

A slice in Go is not the actual data. It’s just a small structure that contains:

a pointer to the underlying array
a length
a capacity

so when you reslice a slice, you're not making a new copy. You're just creating another view over the same underlying array.

The problem: memory being held unnecessarily:

Let’s say you’re reading a large file into memory and want to extract only the first group of digits from it. You might write a function like this:

var digitRegexp = regexp.MustCompile("[0-9]+")

func FindDigits(filename string) []byte {
    b, _ := ioutil.ReadFile(filename)
    return digitRegexp.Find(b)
}

At first glance, this looks fine. It reads the file, finds the first digit sequence, and returns it.

But here’s the issue: the returned slice still points to the original array that contains the entire file. So even though you’re only using a few bytes, the garbage collector can’t release the rest of the file from memory because it’s still being referenced by the slice.

This can easily lead to memory being held longer than necessary.

The fix: copy what you need:

To prevent this, you can simply copy the slice that you actually care about into a new one. That way, the rest of the file is no longer referenced and can be cleaned up.

func CopyDigits(filename string) []byte {
    b, _ := ioutil.ReadFile(filename)
    b = digitRegexp.Find(b)
    c := make([]byte, len(b))
    copy(c, b)
    return c
}

This way, only the required bytes are kept in memory, and the rest of the file can be garbage collected.

This is a small detail that’s easy to overlook, but it can have a big impact especially in long running programs or memory heavy operations.