> Finally, yes, Nim still has many sharp edges, immature spots, and a not > really complete set of "batteries" (libs) plus the docs and tools situation > is, pardon me, miserable (and IMO one of the major barriers for better > uptake). But then, Nim is a) a small project without millions of $, and b) > not yet 1.0. > > Freezing the language for some time and fixing compiler bugs, refactoring, > maturing I think would be good for Nim. > > Fully agreed. Nim urgently needs to stop being ever moving and to become > stable and reliable (also as in "works as expected").
I, too, have been anxiously awaiting 1.0 but OTOH I'm also glad we don't yet have it else it would be hard to introduce some of the fixes/improvements without breaking changes. For instance, even lowly shr is still in process of being changed to be more in line with other languages (a good thing IMO) and the latest memory management model eliminating GC is **huge and excellent**! As well, this experimental "Concepts" idea needs to be pursued or abandoned. > The probably biggest problem I see is documentation. It seems to cover most > areas but it doesn't really or only superficially. I end up looking at the > source and experimenting way more often than I like. Yes, I find the documentation amazingly complete until it isn't, with omissions, incomplete descriptions or even outright errors... Of course, it's quite understandable given the language's state of flux. One thing that might help would be having it served in some sort of wiki format where readers can immediately attach comments/corrections that just appear as a flag when hidden but reveal can be toggled with a click, so that readers can easily supply instant feedback; I'm sure it has happened many times to all of us that we have noted a required change but have lost it by the time we go to file an issue or PR. These flags could be reviewed by documentation maintainers and applied or rejected. **TLDR;** As to what others have said about what would make Nim stand out among all the other available languages, could that be if it fully supported a functional paradym at least to about the level F# does although not necessarily identical would make it much more functional than most "competing" languages and would make it even more appealing, since FP is the old/new "thing"? It already has a syntax almost as concise as that of F# although without as good type inference. For my use, Nim has become one of my favourite languages along with F# and Haskell. Notice something there? Yes, the other languages are (mostly) pure functional languages. Care to guess what I'm going to say next? Yes, I wish Nim was just a little more functional. The abilities of the other languages I most covet are as follows, from very important and easily doable to the more difficult to even impossible: 1\. Guaranteed Tail Call Optimization (TCO):. While @Araq has said Nim has this through the back end C/C++ compiler, it is an optional optimization and not guaranteed, also not available for all alternate backends such as JavaScript; if much simpler languages such as Elm can automatically turn recursive "procs" into loops, surely Nim could too and then it would be guaranteed for all backends. F# actually doesn't do function recursion at all unless the rec keyword qualifier is used on the function, but then it guarantees TCO even across mutually recursive functions grouped together. 2\. A cleaner syntax for Algebraic Data Types than the current boilerplate required for object variants - again, Elm(like)'s "type Node a = EmptyNode | Leaf a | Branch (ref (Node a)) (ref (Node a)) a" is about as concise as it gets even if we have to add "as object" to turn it into the same as an object variants, then "type Tree a = ref Node" is all that's required to have a tree structure with possible left and right branches. ( The different [T] versus a declaration of generics isn't important). So being able to declare "type Node[T] = EmptyNode | Leaf[T] | Branch[ref Node[T], ref Node[T], T)" would be fine. Actually, this is perhaps already possible in Nim with re-write rules or a term re-writing macro, but it would certainly make it much easier to use ADT's and should be available in the standard library. Of course, this must also be supported in pattern matching on the enum "Constructors" to be of maximum usefulness. 3\. Other important things from Functional Programming that Nim doesn't offer are currying and the related partial function application. These would be difficult to add to Nim due to Nim supporting varargs -.all the languages I know that have varargs don't support currying and partial function application, but let's examine it: these are implemented as an optional extra end parameter that is an array of some type. It might be considered that F#'s printf function is such a thing unless you consider the format string and the parameters used to fill its "holes" as a unit, in which case it is just a function that takes a single string as argument with the format string and it's parameters just the application of a function to deliver that string parameter. However, if we try to consider varargs the same way and because it is always the (optional) last parameter, function composition and "piping" will never really work out. Nim's culture is along the lines of OOP where the first parameter is the one that gets applied for method call syntax where F# and to some extent Haskell put the container parameter last so it can be applied after the parameters pertaining to the container have already been applied. Perhaps this could be solved with some sort of re-write rules/macros but it seems complex what to do with varargs would seem to be an obstacle - I suppose Nim people aren't willing to give up varargs even though their main use is in procs such as echo that could use an idea like F#'s printf? I suppose it isn't essential but must people love F#'s "piping" operators and find partial functional application sometimes useful; meanwhile, Nim has method call syntax chaining which (kind of) serves the same purpose. Note that only eliminating varargs and thus the required changes to library procs would be breakiing changes with the others able to be added even after 1.0.
