4 ms·

its true that leadership does nothing and development is stuck, but even in this state nim is probably enough for most people. > how much frustration you will

its true that leadership does nothing and development is stuck, but even in this state nim is probably enough for most people. > 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

lqdev 4y ago
> unless you limittest generics, most people wont even encounter this. 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 https://github.com/liquidev/pan [2]: https://github.com/liquidev/aglet https://github.com/liquidev/aglet
- elcritch 4y ago
  I've run into the "cannot instantiate 'V'" somewhat regularly. Generally it means the compiler doesn't have enough info and defaults to trying to use `V` as a concrete type. 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.
carterza 4y ago
I'm not sure there is one - but I guess a language where you're not constantly dealing with horrible error message, an under-specified and broken implementation and a shitty stdlib - might be better, even if it doesn't have some of the nicer frills of Nim.

lqdev 4y ago

> unless you limittest generics, most people wont even encounter this. 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 https://github.com/liquidev/pan [2]: https://github.com/liquidev/aglet https://github.com/liquidev/aglet

elcritch 4y ago
I've run into the "cannot instantiate 'V'" somewhat regularly. Generally it means the compiler doesn't have enough info and defaults to trying to use `V` as a concrete type. 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.

carterza 4y ago

I'm not sure there is one - but I guess a language where you're not constantly dealing with horrible error message, an under-specified and broken implementation and a shitty stdlib - might be better, even if it doesn't have some of the nicer frills of Nim.