I think Nim favors structured programming which is just objects/structs and free-standing procs that work on them.
Basically there is no "methods" only attached to an object type like in OOP. So you would organize your code like C code, which is the most popular language with structure programming bias, except that you have: * overloading so no need to prefix with my type like `my_type_add`, `my_type_mul` * operator overloading so just reuse the `+` * stronger typing * closures * * * Concepts documentation is in experimental: [https://nim-lang.org/docs/manual_experimental.html#concepts](https://nim-lang.org/docs/manual_experimental.html#concepts) * * * In terms of files, in general Nim code is structured with a common type file, and then procs for each type are in a separate file unless everything can be put together in a single file of reasonable length. The common type file is due to Nim not supporting recursive imports. This causes difficulties when we want a type to have private field, but need to export it from the common type file for it's own basic proc. But that's solvable in the future and private field is a technical solution to a social problem. In Nim we trust users to understand that "With great power comes great responsibility".
