Hello the Nims ^^
A friend told me about the language to which he also bought the book and convinced me of the language, however I remain skeptical on certain points.
For my part I think that a known company should use it so that the language is stable over time.
Hello Arrrrrrrrr,
I like the pseudo lol
Indeed, I am slow to stability and see later but I really cross the fingers for this language is successful.
As long the language and the idea is persisting, it will eventually become (almost) everyone favorite.
Look Python for example, or Smalltalk and/or Lisp-families that always be "smart guys" secret weapon.
I'd really like to ask this question: what does popularity have to do with success and future?
Nim has been around for 13 years and is actively developed. It is useful and productive and the community is helpful. Stability releases are being actively worked (v0.19.2) and point releases have been available for a long time.
Reminds me of this article I read yesterday.
Do you think that Nim will have a future ?
Definitely. It is open source and liked by thousands of programmers (most of whom are waiting for it to stabilize and mature). No matter what happens, there will be some people interested in developing Nim.
As I recently posted, Nim's package ecosystem count shows faster yearly percentage growth than almost all other languages. If things go well, Nim will continue to grow - like Python took over 25 years to gradually grow from obscurity to dominance. If things go badly, this growth will fall below other languages so Nim will never leapfrog them, but it will definitely have a future.
How to make this beautiful language more recognized so that they take more importance ?
Nim needs a "killer app". This doesn't necessarily mean a specific app, like Rails was for Ruby - it can be a general pattern, some clear specific thing that Nim does better than its competitors.
My position is that Nim should embrace the niche of being the most libertarian programming language: no restrictive licenses / patents, no mega-corp sugar-daddies, no "dumb it down to reduce programmer replacement costs", no CoCs, highest portability, etc.
But I remain alone in advocating this... So hopefully someone else will come up with a better unique advocacy argument for Nim...
Talking about killer app or general pattern, I think this recent article is interesting:
https://chameth.com/2018/12/09/over-the-top-optimisations-in-nim/
All this without having to switch to another language.
This is the typical use case of any app that succeeds and needs to scale and you can do it all in Nim. And we haven't gotten into macros yet.
Hello the Nims ^^
BTW, did the Nim community ever decide on whether we are Nimers, Nimrods, Nimists, Nimsters, Nimblers, Nimians, Nimberts, or even Nimbertarians? Should we have a vote? ☺
(I used to be one of the original "Pythoneers" - long before it was cool, and long before the "Pythonistas" took over...)
Talking about killer app or general pattern, I think this recent article is interesting: [Over-the-top optimisations with Nim]
I don't know if this gives Nim an advantages over more popular languages, especially Rust.
Doubt anyone would like to prototype with rust - picky, verbose language that demands good understanding. No gc either.
Swift has no gc either but I don't know much more about it.
even lowly shr is still in process of being changed to be more in line with other languages (a good thing IMO)
which completely broke cello :-(
the latest memory management model eliminating GC is huge and excellent!
We will have to see, it may very well alienate the already small pool of Nim users
if much simpler languages such as Elm can automatically turn recursive "procs" into loops, surely Nim could too
It is easy to do TCO for self-recursive function. It is essentially not doable in general, unless one controls the generated assembly (you have to omit a stack frame). This is why Nim relies on GCC and Clang to do it. For comparison, Scala is in the same position, since it lives in the JVM, and in fact Scala only supports TCO for self-recursive functions
A cleaner syntax for Algebraic Data Types... this must also be supported in pattern matching
Not ideal, but this is doable with macros, see patty and gara
currying and the related partial function application
The issue here is not varargs (well, it may be but most functions do not use varargs anyway). The thing is that partial application turns any function into a closure over the partially applied arguments, with the obvious cost. If you really want it, this is again doable with macros, see currying
@andrea:
It is easy to do TCO for self-recursive function. It is essentially not doable in general, unless one controls the generated assembly...
Tail recursion optimization is an interesting topic, do you have any links providing examples on how to do it in Nim?
I wonder ... if Nim were to support labels to mark code positions and some kind of GoTo like statement, maybe tail-recursion could be worked around by them. But I guess this would add potential complications to the language, for you can't just use GoTo to jump in-and-out stack frames wrecklessly. Nevertheless, GoTo has been used to circumvent tail recursions in languages that support the instruction (the debate on the merits and dangers of GoTo have been debated for a long time). But that's a viable (unsafe) alternative to editing the generated Assembly, by jumping to specific position in the code.
do you have any links providing examples on how to do it in Nim?
I am not sure what you are asking. It is an optimization, and as such it should be invisible in frontend (i.e Nim) code. It is the task of a compiler backend to implement it, not something you do by hand. Or maybe I just misunderstood the question?
We will have to see, it may very well alienate the already small pool of Nim users (with the new non-GC memory model)
I think that @Araq is right that it won't affect most users as it just works behind the scenes, just like GC. I really like the idea and hope it turns out that way :)
It is easy to do TCO for self-recursive function. It is essentially not doable in general...
There are ways to do it without eliminating the stack frame by making it a connected series of loops - see below...
Not ideal, but this is doable with macros (ADT;s and pattern matching on them)...
Yes, I assumed as much, but again, it would nice to have the ability built-in.
with the obvious (preformance) cost (of closures). If you really want it, this is again doable with macros, see currying (library)
Yes, I had seen the currying library and know the cost; the question would be whether the cost can be eliminated or optimized away when one calls the function as non-curried with all its arguments? This is lower in the priority list, but one can write some slick code using it, and sometimes one doesn't have to eek out the last CPU machine cycle but having elegant code is more the priority.
That can apply whenever applying FP principles although it doesn't always cost performance: TCO implemented as loops doesn't but makes the code appear to use immutability as in code safety without apparent side effects; ADT's and pattern matching don't have too cost performance but are an elegant way to express variable data structures as we already have with variant objects, just they are kludgy to use; with the right optimizations, this currying and partial function application would only cost when actually used.
I agree with you that losing varargs in order to gain this would hardly be missed as long as an alternate implementation for echo/write/writeLn made these appear to be working with varargs. If syntax changed, no matter how slightly, we would catch some flak for the change. If it were to be done, it would be better before version 1.0. These could be implemented as macros in just turning the arguments into strings by keeping varargs for templates and macros but not for proc or func.
@Tristano:
if Nim were to support labels to mark code positions and some kind of GoTo like statement, maybe tail-recursion could be worked around by them...
Nim has labeled blocks and breaks to blocks which is somewhat of a "goto" and could likely be used.
@jxy:
You could write a macro that does TCO for self-recursive functions, essentially turning it into a while loop. Mutually recursive functions are more difficult to deal with, but is feasible by inlining the procedures and sprinkling a couple of goto's.
Yes, that was what I was thinking, but would like it to be built in so one wouldn't need to add a library.
Yes, I find the documentation amazingly complete until it isn't, with omissions, incomplete descriptions or even outright errors...
Bug reports are welcome but I cannot connect to that anymore. Much effort went into 0.20 to improve the docs.
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.
The docs have 'Edit' buttons.
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.
Can't agree with that, we're still recovering from the immutable concat trees used extensively within Nim's code generator. FP -- much like OO -- can encourage unoptimizable designs.
without as good type inference
Overloading in combination with Hindley-Milner is NP-complete. And indeed I wish F# had good overloading. :P
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: ...
I'm hearing you but Nim is an imperative core plus a macro system. We never claimed anything else -- if I wanted Haskell, I know where to find it.
I'm hearing you but Nim is an imperative core plus a macro system. We never claimed anything else > -- if I wanted Haskell, I know where to find it.
Indeed, going 'full functional' would be terrible, and overloading is great. I'd like Nim to be a viable replacement for C++ and for that I think the current direction is just right.
That said, one thing I wish Nim would take from ML/Haskell/Rust is the algebraic data types. I can't say I find Nim's tagged variants to be an improvement on those. Maybe in Nim 2.0?
Much effort went into 0.20 to improve the docs.
I think all of us greatly appreciate the work that went into this, and need to see if the omissions I noted are still there. I already see that many have been fixed.
The docs have 'Edit' buttons.
I just noticed those and will start to use them.
I wish F# had good overloading. :P
Yes, I guess it's a trade-off overloading versus Hindley-Milner. Your overloading system is beautiful and now that I am used to it, I don't want to give it up at the cost of a few type annotations which are often a good idea for documentation purposes anyway. I'm with you on this. And we still have auto for return value signatures if we want to use it!
I'm hearing you but Nim is an imperative core plus a macro system. We never claimed anything else -- if I wanted Haskell, I know where to find it.
Yes, I know where to find Haskell, too, and I wouldn't want Nim to be like Haskell either, maybe more like F# (without H-M type inference) with mutability versus immutability optional just as we already have by choosing to use let or var bindings...
@bpr:
Indeed, going 'full functional' would be terrible, and overloading is great.
As I replied to Araq above, I agree with you and don't want "full functional", only optional functional.
one thing I wish Nim would take from ML/Haskell/Rust is the algebraic data types.
Yes, that is my point 2. Object variants actually are ADT's but just with too much boilerplate for both declaring them and pattern matching on them. We could use a library of macros to help, but it would be nice to be a part of the language. The nice thing is that it would be an add-on that wouldn't break existing code as in all my suggestions (other than removing varargs if necessary).
Note that I recognize that we may have TCO by the back end compiler, but it isn't guaranteed and may not be in force in debug modes when optimization isn't turned on. Thus we can't write tail called functions knowing that they won't blow the stack for some compiler modes. I would be satisfied with just guaranteed recursion within the same proc, but I think it may be possible to extend to the possibility of some cross proc recursion, although it may take some {.recursive.} pragma notations to do it.
I've been watching nim from the sidelines for a while now and am considering diving (again) in to test the waters especially considering the recent release announcement.
Just to add to the 'killer app' discussion above, I like shashlick's idea above. It is essentially what Julia is trying to do, but nim could be the compiled statically typed option along the same lines, but with a fast compiler, no JIT lag, and decent syntax. It could and should be billed as essentially solving the two language problem.
I'd like to suggest that making nimscript easy to embed and possibly also offering some tooling support for workflows involving prototyping with nimscript and then later converting said code to regular nim. For game programming this could be very attractive for example.
That and removing pain points from GC-less programming in nim, could make it both an attractive very high level and low level language.
Just 2¢ from a friendly lurker.