A Java reader brings habits from packages, classes, records, interfaces, exceptions, annotations, streams, and long-lived APIs. That helps with contracts, visibility, and maintainable names, but the Musi page asks a narrower question: what contract should this lists, slices, maps, and pipelines example make visible?
var prices = List.of(450, 120, 80);
var firstPrice = prices.get(0);let prices := [450, 120, 80];
let firstPrice := prices.[0];
firstPrice;Reading Collections, Streams, and Pipelines from Java
On the Musi side, Musi collection examples keep indexing, field access, and pipelines explicit so a reader can see where each value comes from. Read the shared example through Java eyes: keep the useful instinct, then let Musi name shape, behavior, absence, and outside work in separate places.
False friend
Do not import lazy iterators, stream chains, table conventions, or pointer arithmetic unless the Musi example needs that behavior. For a Java reader, the trap is reading Musi class as a nominal object type with constructors and fields; Musi class is a behavior contract supplied by instances; records and data model object shape.
When this pays off
Use this shape for prices, stops, animals, files, and other small batches where each step has a name. The Java instinct still helps here: Keep the Java habit of naming APIs for future readers.