I know you don't have a duty to look around for your answer, but you too don't have a duty to say yuck to a project that has been done with a lot of effort.
I am ok with your comment, but maybe go easy on the next project.
> 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.'
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.
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.
The first one most people run into: Nim is roughly as performant as Rust, but it's easier to learn because it's garbage collected. But it's also not garbage collected, if you prefer (with caveats). Want a different flavor of garbage collected? We have three (with caveats)!
thats not a different way of doing same thing, its doing different thing. this not even an argument, if language can provide multiple memory management strategies, in what world is that a bad thing?
and if you somehow confused about choice (of gc), you should stick to default.
also, there is no such thing as "There is Only One Way to Do It" languages. your entire argument is just a circlejerk point.
Is Nim garbage collected? There is no simple answer to that.
When it is garbage collected, how is it garbage collected? There is no simple answer to that.
As stated in my original comment, I prefer languages which are more opinionated than that. Nim is a Swiss Army knife; some people like that, but I prefer choosing a fixed-blade knife to suit my current purpose.
Is C garbage collected? There is no simple answer to that. Link with Boehm (or something similar) and it is. These things are often (with almost any language) aspects of the implementation & deployment, and most mature languages have multiple answers as well. Is Python "compiled"? Well, with Pypy or Cython or etc. it is. (Or maybe it's always at least "compiled" to byte codes run by a slow byte code interpreter.) Etc., etc. I think your standards for "simplicity" or univalence may be, as @SolitudeSF alluded to, unsatisfied by even prog.lang's you like (which you gave no concrete examples of).
he is not trying to sell/convince you to learn gtk. he is warning if you already want to learn it. not everything posted on hn should be a promotion material.
