MO
Mojo Architecture Patterns
Mojo module and struct design patterns for systems-level and ML library development
Details
Language / Topic
MojoCategory
Architecture
Rules
balanced
- Model domain abstractions as `struct` types with explicit trait implementations (`Copyable`, `Stringable`) instead of relying on duck typing.
- Separate hot compute kernels into dedicated `.mojo` files and expose them through a thin `def`-based public API for Python interop compatibility.
- Use `alias` constants and `@parameter` compile-time specialization to generate multiple optimized code paths from a single generic implementation.
- Design library structs around value semantics with `__copyinit__` and `__moveinit__` — avoid shared mutable state between struct instances.
- Use the `owned` / `borrowed` / `inout` argument conventions consistently across a module's API to make ownership flow explicit at every call site.
- Organize a Mojo project as: `src/` for library code, `tests/` for tests, `benchmarks/` for performance measurements, and `examples/` for usage demos.
- Keep Python interop (`Python.import_module`, `PythonObject`) isolated to adapter modules — pure Mojo code should not depend on CPython directly.