Re:Pros and Cons of Nim
by rlp on Thursday May 28, 2020 @06:09AM
(#23335549)
I'm a big fan of Nim, but I really wish it supported cyclic type declarations in separate files and out-of-order functions without forward declarations. As it is, I'm constantly structuring things around those limitations. Big projects often end up squeezed into a single huge file (or a few huge files).
[ Parent
| on HN ]
You can re-order functions by using the {.experimental: "codeReordering".} pragma now.
consider `include` instead of `import` if you want to break things down to smaller files.
Also, I'm with Araq on this one -- in my experience, every time I reached for a cyclic-cross-file-type-declaration, there was a much simpler acyclic solution I found later.
Include doesn't work for cyclic types, they need to be in the same "type" block. I do not agree with Araq's stance here, there are often cases when closely-related types need to reference each other, and it's not always convenient to put them in the same file. That's why you see the "types.nim" file in larger Nim projects -- no one has a good solution and just shoves them all together. And, if you use types.nim, you no longer have proper visibility control, since fields cannot be private and there is no package-level visibility. Most languages understand this, C/C++/Rust all allow at least the ability to forward declare a type (and Rust allows cyclic, out-of-order types).
Re:Pros and Cons of Nim
by rishav_sharan on Thursday May 28, 2020 @06:59AM
(#23335873)
yes please!
I had forgotten how irritating creating header like declaration files were till I tried Nim.