GoMLX from Beginner to Master — Chapter 1: What Is Machine Learning (A Go Engineer's Perspective)

> Serialized book by a senior AI researcher. Next chapter: "Your First Line of GoMLX Code — From Zero Install to a Running Computation Graph in 15 Minutes."

Key points

• The Go engineer's ML dilemma: A backend engineer handling 100M+ daily RPC calls wants anomaly detection beyond hand-written thresholds. Every ML tutorial assumes Python (import torch, pip install, virtualenvs, CUDA version matrices). The book's premise: Go engineers can do ML in Go, and GoMLX makes it production-viable.
• Paradigm shift: Traditional programming = you write rules → program executes. Machine learning = you provide labeled examples → the program infers rules. You become a "trainer of rules" instead of a "writer of rules."
• Why ML: Hand-written rules can't cover combinatorial anomalies (e.g., QPS normal but P99 latency jumps 10ms → 50ms while error rate rises 0.01% → 0.5%). Maintenance cost of rules grows exponentially with system complexity.
• When to use ML (all three must hold): rules are too complex to enumerate; you have many labeled examples; you can tolerate some error rate. If 20 if-else statements get you 95%, just use if-else.

Model, Training, Inference — in Go terms

• Model = architecture (structure you design) + parameters (values learned from data). Scaling y = w*x + b from 2 parameters to 2 million, and one layer to two hundred nested layers, yields deep learning.
• Training = searching the parameter space for minimum prediction error. Brute force works for 2 parameters; gradient descent ("walk downhill by feel") scales to millions. Analogy: it's tuning GOGC, except with 5 million tunable knobs iterated automatically.
• Inference = a plain function with trained parameters baked in. Train once (GPU, hours); infer millions of times (microseconds, often CPU-only).

Flavors of ML

• Supervised learning (book's focus): labeled data → classification (discrete labels) or regression (continuous values). GoMLX's main strength.
• Unsupervised learning: no labels; find structure (clustering, dimensionality reduction, anomaly detection). GoMLX v0.27.3 has limited support here.
• Reinforcement learning: agent + environment + reward signal (AlphaGo). GoMLX ships a working demo: a Hive Go-like game AI running in the browser via WASM (Chapter 15 case study).

Where GoMLX fits in the ecosystem

The author is explicit: Python (PyTorch/JAX + Jupyter + Hugging Face) remains king for research and experimentation. GoMLX targets the production deployment gap instead:

• No bridging pain: embedding PyTorch in Go services means CGo or a separate Python inference process behind gRPC. GoMLX removes that wall — train in GoMLX, or train in PyTorch, export ONNX, and load it for pure-Go inference.
• Zero-dependency deploys: a full DeepFM-style CTR inference service compiles to a ~12–18 MB standalone binary (depends on model/backend) — no Python interpreter, no pip, no CUDA matrix.
• Type-safe ML: tensor shapes become compile-time concepts; shape mismatches (e.g., expecting [batch, 128], passing [batch, 64]) surface at go build, not in production.
• Runs wherever Go runs: servers, edge devices, browsers (WASM).
• Ecosystem positioning: PyTorch and GoMLX are allies, not rivals — experiment in Python, deploy in Go.

How to read the book (15 chapters, four parts)

1. Foundations (Ch. 1–3): mental model, first running code, computation graphs and execution model. 2. Principles (Ch. 4–7): computation graphs as DAGs, JIT compilation and XLA, tensors across host/device memory, automatic differentiation. 3. Modeling (Ch. 8–12): hand-written linear regression, high-level Trainer/Loop/Hooks API, neural networks, CNNs and Attention, full CIFAR-10 project. 4. Mastery (Ch. 13–15): model export (Checkpoint / ONNX / pure-Go binary), data-driven performance profiling, WASM in-browser inference, ONNX loading of Gemma 3 300M, roadmap.

Suggested paths: fast start (Ch. 1→2→3→7→8→9), systematic (all chapters in order, ~2–3 months at 1–2 h/day), or deep-dive (systematic + double-read Ch. 4–7 + rebuild Ch. 12 project + read GoMLX source).

Closing caveats

• ML is not a universal key — don't replace a screwdriver with a power drill.
• Data quality caps model quality; ML bugs (data? architecture? hyperparameters? distribution shift?) are harder to debug than code bugs.
• ML has physical accuracy limits — safety-critical systems need model + redundant sensors + human review, not a lone model.

> The invitation: not to become a Python refugee, not to break up with PyTorch — but to do ML, the Go way, in Go.

Comparison table: traditional programming vs. machine learning

| Dimension | Traditional programming | Machine learning | |---|---|---| | Your job | Write rules | Choose architecture + prepare data | | Program's job | Execute your rules | Infer rules from data | | Output | Computed result | A trained model | | Source of rules | Your brain | Data | | Failure mode | Logic errors | Model learned wrong patterns | | Maintenance cost | Grows with rule count | Drops as data grows |

Training vs. inference

| Dimension | Training | Inference | |---|---|---| | Purpose | Find optimal parameters | Use parameters to predict | | Input | Data + labels | New unlabeled data | | Compute | Heavy (forward + backward) | Light (forward only) | | Hardware | Usually GPU | CPU often suffices | | Frequency | Offline, periodic | Online, per request | | GoMLX role | Full training framework | Exportable to a pure-Go binary |

---

*Author: a senior AI researcher | Ongoing series: "GoMLX from Beginner to Master"*