A Lua reader brings habits from tables, metatables, nil, coroutines, embedding, modules, and small runtime boundaries. That helps with simple data and host/runtime edges without much ceremony, but the Musi page asks a narrower question: what contract should this module and package boundaries example make visible?
local option = require("option")
local default_gate = option.some(1)let option := import "@std/option";
export let defaultGate : option.Option[Int] := option.someOf[Int](1);Reading Modules, Imports, and Exports from Lua
On the Musi side, Musi imports bring named module values into scope, so package boundaries stay visible where code uses them. Read the shared example through Lua eyes: keep the useful instinct, then let Musi name shape, behavior, absence, and outside work in separate places.
False friend
Do not rebuild a source-language global namespace, header include pile, or barrel file when one import names the owner. For a Lua reader, the trap is letting table shape, missing fields, and behavior conventions blur together; Musi class is not a metatable pattern; records/data hold table-like shape, classes/instances name promised behavior.
When this pays off
Use modules when billing, routing, text, option, runtime, or encoding code has an owner worth naming. The Lua instinct still helps here: Keep the Lua habit of using small names and simple values.