> how much frustration you will encounter fighting the compiler and broken / under-specified language features and semantics might be a turn-off.
unless you limittest generics, most people wont even encounter this.
> My advice would be to look elsewhere.
that would imply that there is a better alternative
I don't think my totally normal usage of generics for type safety could be called "stretching the limits." My usage of generics includes using a parameter [V] for OpenGL meshes to introduce type safety with the vertex type. I'm pretty sure that's perfectly normal?
Recently one of my friends tried compiling my project - pan[1] on Windows, and for whatever reason - it doesn't work! stating that it "cannot instantiate 'V'", whatever that means. I've had this error annoy me many times before, but I have no clue what triggers it or how to reproduce it reliably. Call this a 'stable implementation.'
[1]: https://github.com/liquidev/pan [2]: https://github.com/liquidev/aglet
Generally it's not usually an issue with Nim's generics itself, but rather bad error message. Definitely an area for improvement IMHO. Though having used a fair bit of C++ templates over the years, I still find the Nim errors much more tractable after a bit of experience.
There _are_ a few broken limits of Nim's generics, but they are things pushing the type system to a limit.