the0 v1.1.0 - The Polyglot Update

We just tagged v1.1.0. This one's been brewing since before v1.0.0 even shipped. The numbers:

294 files changed. 36,827 lines added. 4,502 lines deleted.

That's right - we actually added code this time. Shocking, I know.

And yes, I say "we" because this release was a collaboration. Me and Claude. The AI. We pair programmed the entire thing.

The Pitch

Here's the thing about algo trading: everyone has opinions about languages.

The Rust people will tell you memory safety matters when you're managing positions. The Haskell folks will explain how pure functions prevent side effects that blow up your account. The C++ crowd will flex about latency. The Python tribe will just ship something while everyone else is still arguing about type systems.

They're all right. They're all wrong. The only thing that actually matters is: can you deploy your bot and trust it to run?

v1.1.0 answers that question for 7 languages.

The Claude Sessions

I should be honest about how this release got built. It wasn't me grinding away solo at 2am (okay, some of it was). Most of it was me and Claude Code working through actual architectural decisions together.

The first question was fundamental: how do we support 7 languages without the runtime becoming a mess? We had to understand which services would change and how compiled languages would differ from interpreted ones.

Turns out compiled languages are actually simpler. No dependency vendoring. No virtual environments. Just a binary that runs. But we needed a standard contract: every bot receives BOT_ID and BOT_CONFIG as environment variables, and writes results to result.json. That's it. Same interface whether you're writing Haskell or Python.

The Input abstraction fell out naturally from there. parse(), metric(), success(), error() - these aren't language features, they're domain concepts. Reading config, emitting metrics, reporting results. The implementation varies by language but the domain stays constant.

This is what Claude Code actually enabled: thinking about the domain without getting bogged down in technology details. I could focus on "what should a trading bot communicate to the platform?" while Claude handled "how does Haskell read environment variables?" across 7 different ecosystems simultaneously.

The technology serves the domain. Not the other way around.

What Got Added

7 Language SDKs

Every SDK follows the same pattern:

• parse() - Read bot ID and config from environment
• metric(type, data) - Emit metrics to the dashboard
• success(message) / error(message) - Report execution results
• log(message) - Structured logging

Same interface, different languages. Write your bot in whatever makes you productive.

Here's what an SMA crossover bot looks like in C#:

using The0;

var input = Input.Parse();
var config = input.Config;

// Fetch prices and calculate SMAs
var prices = await FetchPrices(config.Symbol);
var shortSma = prices.TakeLast(config.ShortPeriod).Average();
var longSma = prices.TakeLast(config.LongPeriod).Average();

// Emit metrics for the dashboard
input.Metric("price", new { symbol = config.Symbol, value = prices.Last() });
input.Metric("sma", new { short_sma = shortSma, long_sma = longSma });

// Detect crossover
if (shortSma > longSma) {
    input.Metric("signal", new { type = "BUY" });
}

input.Success("SMA analysis complete");

And the same thing in C++:

#include <the0.h>

int main() {
    auto input = the0::Input::parse();
    auto config = input.config();

    // Fetch and calculate
    auto prices = fetch_prices(config["symbol"]);
    double short_sma = calculate_sma(prices, config["short_period"]);
    double long_sma = calculate_sma(prices, config["long_period"]);

    // Emit metrics
    input.metric("sma", {{"short_sma", short_sma}, {"long_sma", long_sma}});

    if (short_sma > long_sma) {
        input.metric("signal", {{"type", "BUY"}});
    }

    return input.success("Analysis complete");
}

Check out the quick start guides for all 7 languages.

Custom Frontends

Here's a dirty secret: the default dashboard is generic. It has to be. It doesn't know what your strategy does or what metrics matter to you.

The inspiration came from Datadog. Did you know you can generate those gloriously complex Datadog dashboards with just... JSON? I spent a fun afternoon at work vibe coding a metrics dashboard - saved three hours of manually dragging widgets around the GUI. Programmatic dashboards are underrated.

the0 takes that idea further. Instead of JSON, you get React. Full component control. Real interactivity. Not just "here's a chart with these values" but "here's a trading interface that does exactly what my strategy needs."

import { useMetrics, useEvents } from '@the0/react';

export default function MyDashboard() {
  const metrics = useMetrics();
  const { price, signal, sma } = metrics;

  return (
    <div>
      <h1>{price?.symbol}: ${price?.value}</h1>
      <Signal type={signal?.type} />
      <SMAChart short={sma?.short_sma} long={sma?.long_sma} />
    </div>
  );
}

Your bot emits metrics. Your frontend visualizes them. The React SDK handles all the plumbing.

Every example bot in this release comes with a custom frontend. SMA crossover charts, portfolio breakdowns, price alerts with severity indicators - all tailored to what that specific bot actually does.

7 Example Bots

We didn't just ship SDKs. We shipped working bots for each language:

Each one is a complete example: bot code, config schema, custom frontend. Clone it, modify it, deploy it.

Documentation Overhaul

The docs got a complete refresh. We adopted NestJS-style guidelines:

• Prose over bullet points (explain the why before the how)
• Code examples that actually work
• Clear hierarchy (H2 for sections, H3 for subsections)
• Grounded in real code (every example comes from actual example-bots/ or sdk/)

Claude rewrote 28 documentation pages. I'd review, push back on things that didn't sound right, and we'd iterate until it felt right.

New pages added:

• 7 language quick-start guides
• Custom frontends guide
• Platform deployment (Docker Compose + Kubernetes)
• Metrics reference
• Complete CLI command reference

The Kubernetes docs come with a warning though - we haven't tested them in a while. They're marked experimental. If you're brave enough to try, let us know how it goes.

The Haskell Story

I'll be honest. Haskell was the hardest one.

Not because Haskell is hard (it is). But because the Haskell ecosystem has... opinions. Cabal vs Stack. GHC versions. Dependency resolution that makes npm look sane.

We went with GHC 9.6 and Cabal. The SDK is a source dependency pulled via cabal.project:

source-repository-package
    type: git
    location: https://github.com/alexanderwanyoike/the0.git
    tag: v1.1.0
    subdir: sdk/haskell

The example bot is a scheduled type that runs, calculates SMAs, emits metrics, and exits. No infinite loops. No mutable state. Just pure functions computing trading signals.

Is it practical for HFT? No. Is it satisfying to write a trading bot in Haskell? Absolutely.

The C++ Story

C++ was the opposite problem. Not hard to integrate - just verbose.

We went with a header-only SDK. Include the0.h, link against nlohmann/json, and you're good. CMake's FetchContent handles the dependency:

FetchContent_Declare(the0
    GIT_REPOSITORY https://github.com/alexanderwanyoike/the0.git
    GIT_TAG v1.1.0
    SOURCE_SUBDIR sdk/cpp
)

The example bot fetches Yahoo Finance data, calculates SMAs, and emits signals. Modern C++17 with proper RAII. No raw pointers. No memory leaks (probably).

Compile times are... what they are. Blame curl and nlohmann/json. But once it's built, it's fast.

The CLI Updates

The CLI now handles building for compiled languages:

• Rust: Runs cargo build --release
• C++: Runs CMake configure + build
• C#: Runs dotnet publish
• Scala: Runs sbt assembly
• Haskell: Runs cabal build

You compile locally, the CLI packages the binary, uploads it. The platform runs it. Simple.

For interpreted languages (Python, Node), nothing changed. The CLI still vendors dependencies and uploads everything.

By the Numbers

What's Actually Hard

Shipping multi-language support sounds cool. Here's what nobody tells you:

Testing is multiplicative. Every feature needs testing in 7 languages. Every runtime change needs verification across 7 environments. The test matrix is brutal.

Documentation is multiplicative. One typo in the Python docs? Check the other 6 languages. Did you update the CLI example? Did you update it in all 7 quick-starts?

Dependencies are a nightmare. Rust has crates.io. Python has PyPI. Node has npm. C# has NuGet. Scala has Maven (sort of). Haskell has Hackage (sort of). C++ has... pain.

We made a choice: published packages for languages with real package managers (Rust, Python, Node, C#, Scala), git source dependencies for the rest (C++, Haskell).

The Philosophy (Revisited)

v1.0.0 was about subtraction. Removing the bloat. Finding the core.

v1.1.0 is about extension. Same core, more surface area.

the0 is still an execution engine. We still don't do backtesting (do it locally). We still don't have a built-in AI assistant (use Claude Code). We still focus on deploy → run → monitor.

But now you can do that in 7 languages. With custom dashboards. And documentation that doesn't make you want to close the tab.

What's Next

v1.2.0 is already on the whiteboard:

• Runtime refactors (splitting Docker and Kubernetes logic)
• Adding persistent storage support
• Implementing query endpoints for bots
• Improved Kubernetes support (we should probably test those Helm charts)
• Per-bot resource monitoring
• Better log aggregation and search

For now, grab v1.1.0 and try building something in a language you wouldn't normally use for trading. Worst case, you learn something. Best case, you find an edge nobody else is looking for.

The Haskell algo traders are few. Maybe that's the alpha.

Check out the repo, join the Discord, and let us know what language you're deploying in.