[khaledh]

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

[2] https://nim-lang.org/docs/manual_experimental.html#code-reor...

[3] https://github.com/nim-lang/RFCs/issues/19

[elcritch]

You might like Patty. It makes case types more ergonomic: https://github.com/andreaferretti/patty

[khaledh]

Neat! Thanks for sharing. This might come in handy, although the constraint of unique field names across variant cases is still there.

[elcritch]

Yah 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

[auxym]

If 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