Programming on Prateek Sharma

The Go Programming Language

Tue, 01 Sep 2026 00:00:00 +0000

TODO: Add review / notes once read.

Give callers two error types, one extending the other

Fri, 28 Aug 2026 00:00:00 +0000

In the WazirX Java connector I split errors into two:

WazirxClientException — the caller made a mistake the caller can fix: a bad side value, a missing required field. Thrown before a request is even sent.
WazirxApiException — something went wrong once the request left the process: a network failure, a non-2xx response.

WazirxClientException extends WazirxApiException. That one line is the whole design. A caller who only cares “did this work?” catches the parent. A caller who wants to retry network failures but fail fast on their own bad input catches both separately. Nobody is forced into a giant catch (Exception e) that swallows bugs, and nobody has to try/catch five specific types at every call site.

Two-sided membership needs one lock, not two

Thu, 27 Aug 2026 00:00:00 +0000

Goroomlib models a relationship that points both ways: a Room holds a map of its users, and each User holds a list of the rooms it’s in. That redundancy is deliberate — both lookups need to be O(1) — but it’s also the whole bug surface.

The first version

AddUserToRoom did the obvious thing:

func (s *RoomService) AddUserToRoom(roomName string, user *User) {
    room := s.rooms[roomName]

    room.mu.Lock()
    room.users[user.ID] = user
    room.mu.Unlock()

    user.mu.Lock()
    user.joinedRooms = append(user.joinedRooms, roomName)
    user.mu.Unlock()
}

Each side is individually locked, so go vet and the race detector on a simple test are both happy. But there’s a window between the two critical sections where the room says “user is here” and the user says “I’m not in that room.” Anything that reads both — say, a disconnect handler that walks user.joinedRooms to remove the user from each — can run in that window and leak the membership.

Generic returns can be the right call for a library you maintain alone

Wed, 26 Aug 2026 00:00:00 +0000

The standard advice for a client library is: give callers typed responses. client.Ticker(...) (*Ticker, error), not (any, error). I went the other way in my WazirX Go connector and I still think it was right for that library.

The upstream API’s response shapes move around — objects that become arrays, fields that appear and vanish across endpoints. With ~25 endpoints and one maintainer (me, in spare hours), typed structs would mean 25 things to keep in sync with an API I don’t control and can’t see changes to until they ship. The generic return pushed that cost to the call site, where the caller already knows which two fields they want and can assert for them.

Endpoint maps over hand-rolled methods

Tue, 25 Aug 2026 00:00:00 +0000

I’ve now written two client libraries for the same exchange API — one in Go , one in Java — and the thing I’d keep from both is the same: don’t write a method per endpoint. Describe the endpoints as data and dispatch through one function.

The shape of the problem

The API has roughly two dozen endpoints. They differ in four ways:

HTTP verb (GET, POST, DELETE)
path
whether the request must be signed
the response body

Everything else — building query params, adding a signature, choosing the verb handler, parsing the response — is identical. Writing a hand-rolled method per endpoint means writing that identical body 25 times, and then maintaining 25 copies of it when the signing scheme or the base URL handling changes.

Goroomlib

Sun, 23 Aug 2026 00:00:00 +0000

Across the poker platforms I’ve worked on at Adda52 and Mind Sports League, one shape kept showing up: users joining a table, leaving it, sending messages to everyone at it, and the server keeping track of who’s where. Every time I touched a new real-time feature, I ended up rewriting the same User and Room bookkeeping from scratch. I wanted to pull that pattern out once, get it right, and stop reimplementing it.

WazirX Go Connector

Sun, 23 Aug 2026 00:00:00 +0000

WazirX is one of India’s largest crypto exchanges, and while its REST API is well documented, it doesn’t ship an official Go client. I wanted to poke at their API for a side project and didn’t want to hand-roll request signing and endpoint plumbing every time, so I built wazirx-connector-go and open-sourced it once it was in decent shape.

Avoiding ~25 near-identical methods

The exchange exposes close to two dozen endpoints — tickers, order book depth, order placement, withdrawals, sub-account transfers, and so on. Writing a hand-rolled method for each one would have meant the same boilerplate repeated two dozen times: build params, sign if needed, pick GET/POST/DELETE, hit the URL, parse the response.

WazirX Java Connector

Sun, 23 Aug 2026 00:00:00 +0000

After building the Go connector for WazirX, I wanted the same thing on the JVM — but WazirX doesn’t publish an official Java client at all, REST or WebSocket. The REST half was a fairly direct port of what I’d already learned building the Go client. The WebSocket half turned out to be its own project.

Letting callers choose their failure granularity

For errors, I didn’t want every caller forced into one giant catch-all exception, but I also didn’t want to force a try/catch at every single call site. I split errors into two, with one extending the other:

Audio Cloning

Mon, 23 Jun 2025 00:00:00 +0000

This is an extension of the Video Translator tool that generates cloned audio for short subtitles, improving the quality of the dubbed output. It uses OpenVoice and MeloTTS to clone the original speaker’s voice.

Challenges

Library compatibility. The libraries weren’t functional on Python 3.12, which I was using — they worked on 3.10. So the TTS stage couldn’t live in the same script as the rest of the pipeline.
Short subtitles. The libraries needed a longer sample to clone a voice well, and very short lines (hello, hi, bye) errored out.

What I changed in the fork

openvoice/se_extractor.py had a check that discarded audio segments shorter than 1.5 seconds. Words like hello fall under that. I relaxed the check to allow segments down to ~0.5 seconds, and added a skip for lines too short to process.
Added melo-tts to requirements.txt (the docs mention it but don’t pin it).
Added a driver script that points at a video-translator output folder and runs cloning across every generated audio file.
Patched the library to run on CPU for Apple M1.

The fork is at github.com/pratts/OpenVoice ; test1.py runs the cloning over the translator’s output.

Video Translator

Mon, 23 Jun 2025 00:00:00 +0000

I always wanted to watch Japanese anime and other foreign-language films in English without living in the subtitles. During a break I decided to see how far open-source models could get me, and built a script that:

Extracts the background audio from the video.
Transcribes it to a subtitle file in the original language.
Translates each subtitle to English.
Converts the translated subtitles to audio.
Merges the translated audio with the background track.
Muxes the final audio back into the video.

I wanted to lean on open-source tooling and minimize paid services:

Patched OpenVoice for short-clip cloning and CPU inference

Fri, 20 Jun 2025 00:00:00 +0000

While building the Audio Cloning stage of my video-translator pipeline, I hit two blockers in OpenVoice :

openvoice/se_extractor.py discarded audio segments shorter than 1.5 seconds, which meant short subtitle lines (hello, hi, bye) couldn’t be cloned at all. I relaxed the threshold to ~0.5 seconds and added an explicit skip for lines too short to process.
The library assumed a CUDA GPU. I patched it to run on CPU so it worked on Apple M1.

The changes live in my fork at github.com/pratts/OpenVoice . They were scoped to my use case and haven’t been proposed upstream.

TTS Study Assistant

Mon, 15 Jan 2024 00:00:00 +0000

The TTS Study Assistant lets you select text on any webpage, save it as a note, hear it read aloud, and summarize it with AI for review. It’s a Chrome extension (Manifest V3), a Go/Fiber backend, and a React admin panel.

Architecture

Backend (Go) — Fiber for HTTP, PostgreSQL via GORM, JWT auth, OpenAI for summarization, deployed on Railway in a Docker container.
Frontend (React + TypeScript) — Vite build, React Query + Context for state, deployed on Vercel.
Extension — Manifest V3 service worker, Chrome Storage API for local state, Chrome TTS API for playback, content scripts for text selection.

Decisions worth noting

Source-based token lifetimes

Web sessions and extension sessions have very different UX expectations, so the access-token lifetime depends on where the request comes from: