> IMO Nim should drop some features (e.g., method),

I'm totally fine with the basic idea of dropping features that are not 
critical, but right now, method is the last thing you want to drop. Mind you, I 
am not particularly wedded to method specifically (and not a huge fan to begin 
with), but you do need a decent runtime polymorphism story in a modern 
language. Much bikeshedding can be had over whether ADTs or OOP are preferable, 
but you need at least **something**.

In the absence of method, Nim really only has object variants and they have two 
major shortcomings:

  * Memory inefficiency, i.e. the memory allocated for any variant is the 
memory allocated for the largest variant.
  * All variants share a single name space, so you end up with something like 
`int_value`, `str_value`, `float_value`, and so forth.



I am not particularly opinionated about what form runtime polymorphism takes 
(I'd be happy with `vtref`, too, at least in principle), but the absence of a 
future-proof and clean mechanism for runtime polymorphism is the #1 reason why 
I find myself using other languages like OCaml or D when I need that, but not 
Nim's specific advantages (mind you, both have their own limitations in areas 
where Nim shines).

> fix broken stuff that was documented but not ready (concept, static[T], 
> regions if they're still there?), and ship a version 1.0.

I agree that a lot of stuff here could be bumped back to a version later than 
1.0. Much of that falls in the "nice to have, but not necessary" category, so 
it could be hidden behind an experimental switch as long as its introduction 
would not require retroactive changes to the language.

> Not, for example, try to develop tooling to compile to JS, amongst other 
> things. Nim can't take on Typescript, and shouldn't try.

I'd say that in that area Nim is competing with ReasonML more than with 
Typescript. The attraction of Nim/ReasonML is that you can have code sharing 
between a JS frontend and a native backend, something that Typescript doesn't 
give you. In the end, I see JS as a backend becoming a more and more common 
language feature to the point that it may become an expected feature of 
high-level languages. It's certainly not something that I'd consider wasted 
effort.

Reply via email to