A C# reader brings habits from nullable flow analysis, records, LINQ, async tasks, extension methods, interfaces, namespaces, and attributes. That helps with domain code through named APIs and tooling feedback, but the Musi page asks a narrower question: what contract should this field-shaped data example make visible?
public interface IShow<T> {
string Show(T value);
}let Show [T] := class {
let show (value : T) : String;
};
export instance Show[Int] {
let show (value : Int) : String := "number";
};Reading Records, Classes, and Objects from C#
On the Musi side, Musi records and data variants describe stored shape. Behavior belongs in functions or classes/instances, not inside an object by default. Read the shared example through C# eyes: keep the useful instinct, then let Musi name shape, behavior, absence, and outside work in separate places.
False friend
Do not read class as object shape. If the page is about a pet, invoice, room, or vehicle, start with fields or variants. For a C# reader, the trap is mapping Musi classes to object classes or service containers; Musi class is a typeclass-style behavior contract, not a CLR class with fields, constructors, and inheritance.
When this pays off
Use records when names like owner, age, amount, or route are the point of the value. The C# instinct still helps here: Keep the C# habit of making api shape readable at the call site.