3 ms·
Couldn't edit my post, but forgot to mention my main pain points with Nim have been: - its module system, especially not being able to have mutually recursive
by khaledh 3y ago
Couldn't edit my post, but forgot to mention my main pain points with Nim have been:
- its module system, especially not being able to have mutually recursive imports (there has been a 7 year old proposal[1])
- order-sensitive declarations of procs (i.e. can't use a proc defined further down in the file unless you add a forward reference to it). For the latter there's an experimental pragma[2], but it doesn't work a lot of times once you introduce mutually recursive calls
- object variants requiring declaration of a separate enum instead of allowing inline declaration of the variant cases, and a close issue[3] with not being able to define the same field names under different variant cases.
[1] https://github.com/nim-lang/rfcs/issues/6 https://github.com/nim-lang/rfcs/issues/6
[2] https://nim-lang.org/docs/manual_experimental.html#code-reordering https://nim-lang.org/docs/manual_experimental.html#code-reor...
[3] https://github.com/nim-lang/RFCs/issues/19 https://github.com/nim-lang/RFCs/issues/19
- elcritch 3y agoYou might like Patty. It makes case types more ergonomic: https://github.com/andreaferretti/patty https://github.com/andreaferretti/patty
- khaledh 3y agoNeat! Thanks for sharing. This might come in handy, although the constraint of unique field names across variant cases is still there.
- elcritch 3y agoYah it's annoying, but I just rename one. Beff331 made a lib that uses tuples and avoids the naming issue: https://github.com/beef331/fungus https://github.com/beef331/fungus
- auxym 3y agoIf I recall correctly, lazy symbol resolution, which would allow both circular module imports and order-independent procs, was initially on the roadmap for 2.0. Currently, it was moved to a stretch goal for 2.2. https://github.com/nim-lang/RFCs/issues/503 https://github.com/nim-lang/RFCs/issues/503