A C++ reader brings habits from RAII, overload sets, templates, references, optional values, exceptions, and object hierarchies. That helps with ownership stories, value categories, and compile-time abstractions, but the Musi page asks a narrower question: what contract should this fresh values and mutation example make visible?
auto queue_depth = 0;
queue_depth += 1;
const auto visible_depth = queue_depth;let queueDepth := mut 0;
queueDepth := queueDepth + 1;
let visibleDepth := queueDepth;
visibleDepth;Reading Variables and Mutation from C++17
On the Musi side, Musi makes mutation explicit with mut and assignment; ordinary let names read as stable facts. Read the shared example through C++17 eyes: keep the useful instinct, then let Musi name shape, behavior, absence, and outside work in separate places.
False friend
Do not translate every rebinding habit into mutation. A new receipt, label, or counter snapshot can be a fresh name. For a C++ reader, the trap is turning every Musi value into a class-shaped design; Musi class is closer to a concept or trait than a C++ class; records/data store shape, instances satisfy behavior.
When this pays off
Use mutation when the domain really changes over time, such as queue depth or a buffer cursor. The C++17 instinct still helps here: Keep the C++ habit of asking which operation is generic and which value owns shape.