Onecore.Every view.
We chose Rust so every product view can work from the same changing market state.
The product led the decision
Market information changes continuously. Product views and Trend Hints need the same understanding of that state. We wanted one durable place for those rules, so we chose Rust for the core.
One market model
We organize price movement into nested ranges. That model shapes the way we present markets, track changes, and create Trend Hints. A small difference in how one part interprets a range can become a visible product inconsistency later.
We decided to keep the product’s core rules together in Rust. The same concepts can then carry through the system without being translated into several competing versions. This gives the team one place to review a change and one definition to test.
This is a product decision as much as an engineering one. People should be able to move between views without wondering whether each screen is working from a different idea of the market.
Why Rust fits the work
Explicit state
Rust pushes us to describe who owns data, how it changes, and which states are valid. That pressure is useful when the product depends on connected market events that arrive over time.
Predictable behavior
Rust gives us direct control over memory and concurrent work. We can reason about those choices while designing the system instead of discovering them through changing runtime behavior.
Clear failure paths
The language makes error handling part of ordinary development. That helps us decide what the product should do when information is late, incomplete, or unavailable.
The costs are real
Rust can slow the first pass at an idea. The compiler asks us to resolve decisions that another language might leave for later. Builds take time, some integrations require more work, and new team members face a steeper learning curve.
We still explore product ideas quickly. Once an idea becomes part of the shared market model, we want its assumptions written down and checked. The extra work belongs near the beginning because these rules tend to stay in the product for a long time.
Rust also keeps our hiring choices narrower. We account for that by keeping the product model readable, documenting decisions, and resisting clever abstractions that only one person understands.
Rules that follow from the choice
Keep concepts shared
Boxes, ranges, and Trend Hints should keep the same meaning wherever they appear. New work extends the shared model instead of creating a separate version for each feature.
Measure before claiming
We chose Rust for control and maintainability. Any public claim about speed or scale still needs evidence from the product under real conditions. The language alone is never the proof.
Design for recovery
Tests, monitoring, and review still establish product quality. Rust gives us a clearer way to represent failure, while the team remains responsible for how the product detects and recovers from it.
A choice we can maintain
We chose Rust because it matches the work: connected market state, long-running processes, and product rules that need to stay clear as the system grows.
We will judge the decision by ordinary product behavior: whether views agree, failures are understood, and the team can safely change the shared model. Rust is the foundation we use to do that work.