Stop Hardcoding Everything

The first version of v-star was basically me seeing how much I could abuse Go's concurrency to make a spreadsheet user's life miserable. All raw speed. 1M policies, 300ms, boom. I thought I had it figured out.

But here's the thing: raw speed is easy. Architecture is the hard part.

v0.7.0 is where I stopped treating this like a script and started treating it like a framework. The big move? Interfaces.

The "Stop Hardcoding" Pivot

I realized I was trapped. If I wanted a different interest rate model, I had to rip out the guts of the simulator. Who does that? I did.

So I killed the concrete dependencies. Now we have PathGenerator, ContingencyCalculator, and MortalityTable as interfaces.

Until now, it was just Geometric Brownian Motion for path generation. Cool, but GBM just drifts. Real interest rates don't do that — they mean-revert. Enter the Vasicek Model. Because I'm using a PathGenerator interface, I just plugged in a Vasicek generator and suddenly the simulation actually makes sense for real-world financial engineering. It's not just a feature, it's what makes the tool useful.

Same for the ContingencyCalculator. I stopped doing just present values and started doing actual actuarial science — whole life, term insurance, deferred annuities, net single premiums. If it's a life-contingent cash flow, v-star can probably calculate it without me rewriting the core engine.

One interface change unlocked all of that. That's the power of programming to interfaces instead of concrete types.

The Unix Way

v-star was always CLI-first, but v0.7.0 makes it composable. I added StreamCensusFromReader. The engine doesn't care if your data is in a file, an HTTP body, or some buffer in memory. It just wants an io.Reader.

You can literally curl a CSV and pipe it straight into the engine:

curl -s https://api.provider.com/census | ./v-star read --stdin --benchmark

And if you want the fastest possible I/O, there's the mmap path. 10M rows in 0.80 seconds. Zero-copy parsing. As fast as the OS can read the disk.

The HTTP API

The biggest grown-up move in this version is the server. v-star is now a REST API. You don't need Go to use it. Call it from Python, R, or even Excel via HTTP.

Need a Monte Carlo risk report with VaR 95% and CTE 99%? Hit the /montecarlo endpoint. Industry-standard risk metrics delivered as JSON in milliseconds. Same engine, wrapped in a way that makes it accessible to the rest of your stack.

The Flex (Benchmarks)

Because I can't help myself:

• PV Calculation: 380 million calls per second
• Parallel Valuation: 272 million policies per second
• Monte Carlo: 3.7 million paths per second

Combine that speed with the new interfaces and you're not running a simulation. You're running a professional-grade actuarial lab on your laptop.

The Boring Stuff That Matters

Parallel Monte Carlo — each worker gets its own RNG so they aren't fighting over a lock. More cores = faster simulation.

Version injection via ldflags — no more hardcoding the version in main.go like a caveman. It's a tiny change, but it's the "I actually know how to build Go tools" flex.

What's Next

The foundation is finally not made of cardboard. Custom mortality tables from real CSV files. Variance reduction with antithetic variates. Stepped and increasing benefits. The fun stuff.

Repo is at github.com/lubasinkal/v-star. Go build it, or don't. I don't care.