Re: What do you think about the programming language NIM?
I am Python developer. I am so excited about Nim. I am using it with Nimpy. And i am learning Nim coding now. Excellent programming language. It has bright future. I like so much Nim.
Re: What do you think about the programming language NIM?
@jyelon: A little further comment with respect to the advantages of Nim's owned ref... > I'm surprised everyone is treating owned and unowned refs as if they were > something new. C++ has owned and unowned refs As explained in my previous post, **Nim 's `owned ref`'s are not the same as C++'s `unique_ptr` nor `shared_ptr` but combines the two**: the Nim compiler does data flow analysis just as the C++ compiler does for "unique_ptr"'s to determine when these references go out of scope and can be deallocated. However, Nim's version also has (originally intended to be optional) reference counting as C++'s shared_ptr's do to verify the data flow analysis and that the compiler/programmer are correct, which C++ does not. Thus, Nim's "dangling" ref''s are also better than C++'s `weak_ptr in that in Nim, they can be (maybe optionally eventually) checked that they go out of scope before the owned ref's to which they refer. So in addition to the advantage that these can be (maybe when this is implemented) optional and then zero run-time execution cost, what I didn't mention was that **they also can prevent cyclic data memory leaks, which both C++ 's `shared_ptr` and Swift's automatic reference counting can have**. **In the current implementation, cyclic data causes a crash on attempt to deallocate an `owned ref` which contains a cycle, which is better than an undetected memory leak** **There is a (currently unimplemented) proposed extension in the original Bacon /Dingle paper that uses a recursive "deepDestroy" technique to cause destruction of cyclic data that can be implemented without data races**; this is somewhat costly when there are many deeply nested ref's as they require extra nested destruction passes, but nesting isn't that common or commonly that deep so this should be minimal and only on deallocation. **If a version of this were implemented in Nim, the `newruntime` would work like much the current Garbage Collected Nim** other than needing to have a few owned's and unown's injected into the code in a few places, and as things progress, even some of those could possibly be inferred by the compiler.
Re: What do you think about the programming language NIM?
@jyelon: > I'm surprised everyone is treating owned and unowned refs as if they were > something new. C++ has owned and unowned refs I'm afraid you are far behind the curve here, Nim's owned/dangling ref's aren't like those of C++ at all, see [@Araq's original post on the forum](https://forum.nim-lang.org/t/4743#29588) with follow-up discussion and [another follow-up thread](https://forum.nim-lang.org/t/4976#31173). In short, in his research, @Araq found a paper that describes a way of doing this that is not just pure reference counting but rather more like C++ "unique_ptr" but better as it can optionally verify the correctness with reference counting - it is more like a cross between C++ "unique_ptr" and "shared_ptr" but not the same as either. Since then, we have been working at improving on the work in the original research paper to (hopefully) get something even better than that. > But anybody considering this would have immediately understood the cost > tradeoffs: you pay the performance penalty of maintaining the reference > counts, and you pay the price of doing the extra work to clear out the > unowned refs. In Nim's implementation, reference counts are optional and something that one would turn on for debug/development so as to make sure the compiler/programmer are doing their job properly, then turned of for release in which case there is no reference counters used nor checks made if that option is selected. As to "clearing out unowned ref's", if you are referring to dangling ref's, they are actually just something like C++ "weak_pointer" and thus there is no "clearing out to be done; if checks are turned off and the compiler and programmer are mistaken, then the program may fail by trying to reference a deallocated pointer. As to "clearing out owned ref's when they go out of scope, that is just a simple automatic deallocation just as for any pointer when it is deallocated. Thus, the Nim version of owned/dangling ref's can be zero cost for release/danger mode. When the ownership model fails as when one needs to have the equivalent of multiple owners of the same data, then it is proposed that one would implement an override that would do a deep copy just as one would implement a "Clone" trait in Rust for this case. When one wants to share the same data such as across threads, then one does the overrides to implement reference counted pointers that are basically the same as C++ "shared_ptr", but the need for those should be fairly rare and when required the overhead of their use will likely be much less than other overheads, such as those related to thread context switching.
Re: What do you think about the programming language NIM?
Oh, I had meant to include `{.closure.}`. Oops. Fixed.
A stack (of something) is fundamentally required for general non-linear/tree
cases. TCO can only help your linear cases (partly why I call them "easy").
Good trees have well bounded depth, but yeah, wildly unbalanced ones can cause
trouble for **any** impl, recursive or not. A non-recursive one may minimize
the per-stack entry storage a bit better, though.
Re: What do you think about the programming language NIM?
@cblake:
> Recursion working makes code look much nicer, IMO.
IMO, too. Before coming to Nim, my previous favourite languages were Elm, F#,
and Haskell (in no particular order), so that should tell you what I like.
> Equivalent state machines are often ugly, trickier to get right, and a pain
> point...
Again, agreed. Unfortunately, even if the compiler allowed your desired code,
it currently isn't extended to handle the case, as {.inline.} iterators are
just loops "under the covers", they would have to have re-write rules that
include nested loops (which is close to my desired feature of Tail Call
Optimization- TCO). If the iterators were "first class" ({.closure.}) iterators
then they would be doing proc recursion, which again would require TCO so as
not to build stack. Since Nim doesn't support Tail Call Optimization directly
and C/C++ compilers only **MAY** do it with full optimization turned on (it
isn't guaranteed), if there are any concerns with depth of the call stack, one
will have to write the **UGLY** state machine code!
> the example considered among the more compelling by the Python guys...
I don't think Python has TCO even yet, so depth of tree recursion could be a
problem even with your example snippet, depending on the depth of the Tree.
Re: What do you think about the programming language NIM?
I'm surprised everyone is treating owned and unowned refs as if they were something new. C++ has owned and unowned refs. In C++, they're called "std::unique_ptr" and "dumb pointers." The semantics of the C++ version are almost exactly the same as the semantics of the nim version - the one difference is that in the newruntime, before you release the owned ref, you're required to manually clear out any dangling unowned refs - and it verifies that you have done that. In C++, you're not required to clear out the unowned refs. But, that means that in C++, you can end up with dangling unowned refs. It would actually be very easy to implement the newruntime's semantics in C++, because C++ smart pointers are very flexible. Anybody could have done this at any time. But anybody considering this would have immediately understood the cost tradeoffs: you pay the performance penalty of maintaining the reference counts, and you pay the price of doing the extra work to clear out the unowned refs. In exchange, any code that would have accessed a dangling ref will access a nil pointer instead - which is better, because it's a caught error. I think it's telling that this is not a common thing to do - perhaps this indicates that most programmers don't consider these tradeoffs worthwhile.
Re: What do you think about the programming language NIM?
There are always workarounds since CPUs are little state machines. That should be news to no one. Recursion working makes code look much nicer, IMO. For what it's worth, the example considered among the more compelling by the Python guys back in the Python 2.3 days when they added generators was in-order binary search tree traversal: iterator inorder[T](t: Tree[T]): T = if t: for x in inorder(t.left): yield x yield t.label for x in inorder(t.right): yield x Run which parallels the usual recursive call structure quite well. I think it would be great if the above Nim actually worked. Equivalent state machines are often ugly, trickier to get right, and a pain point (and yeah, usually faster). But "expressive" has always been a main goal of Nim. :-)
Re: What do you think about the programming language NIM?
@cblake: > but I felt your post risked leaving that impression. No, I didn't intend to leave that impression and you make your point. My real point is that iterators are an abstraction to make the basic cases of the use of enumeration over a range or collection of some type easy; I think they will always be limited in use for more complex cases such as recursion and if they did have this capability added, they would then have the danger of causing races. My real point was that there are other ways to implement **the effect of recursive iterators** for those who really need them, with my lazy linear list example showing one of the ways.
Re: What do you think about the programming language NIM?
I do not agree that lazy linear lists are the "main example" of recursion. They may be the _simplest_ example, thusly allow several easy workarounds. I mentioned "trees" right in my comment. Most of the (admittedly subjective) elegance of tree algorithms comes from the way recursive code structure mirrors recursive data structure. `lib/pure/collections/critbits.nim:iterator leaves` shows some ugliness required to workaround there, for example. I agree it may not be a high priority or even in the top 10. I do not think it would be considered a "no real need" extra/extraneous fluff/"feature bloat". I know you didn't say that, exactly, but I felt your post risked leaving that impression.
Re: What do you think about the programming language NIM?
@lscrd, @mratsim, @cblack:
> @mratsim's code may not trigger it, but at least in /devel there seems to be
> a check in semexprs.semOverloadedCallAnalyseEffects that errors out with
> errRecursiveDependencyIteratorX ("recursion is not supported in iterators:
> '$1'"). The error message was even updated just a couple months ago. It is
> not hard to trigger this erroring out with trees that are "run-time switched"
> recursions vs. @mratsim's compile-time switched recursion. I for one would
> love full recursion support in iterators...
The message is correct that "recursion is not supported in iterators: '$1'"; it
can't be supported for iterators because in the general case these are
re-written as simple loops which can't reliably be nested when there is no
proper "escape" logic. @mratsim's example showing it working for accessing
array elements works because that use triggers a different special re-write
rule that doesn't have the same escape logic. The general case is shown
triggering the error message [in this Wandbox
snippet](https://wandbox.org/permlink/9McHwZuENwU04lkA), which if the error
message weren't trigger would run away and stack overflow.
There are a limited number of cases where recursion is actually useful with its
results not easy to obtain other wise, with the main one being lazily deferred
"function" type streams or lazy lists; for these, the lazy deferral breaks the
race. However, these are actually their own iterators so there is no real need
for recursive iterators and rather they are implemented just with closures as
follows:
# rolling your own recursive closure "iterator" stream...
import sugar
type
CIS[T] = ref object # an Co-Inductive Stream (CIS) non-memoizing
head: T
tailf: () -> CIS[T]
iterator items[T](cis: CIS[T]): T {.inline.} =
var ccs = cis
while ccs != nil: yield ccs.head; ccs = ccs.tailf()
proc numsFrom(strt: int): CIS[int] = # we specify the iteration here
if strt > 100: return nil # we can add the escape logic here
CIS[int](head: strt, tailf: () => numsFrom(strt + 1))
for n in 0.numsFrom: # or can add escape logic here
if n > 1000: break else: stdout.write n, " "
Run
as per [this other Wandbox
snippet](https://wandbox.org/permlink/bt6nUKHpdpe8KSIo).
The latter technique is highly recommended as with them it is much easier to
control data races and it can be easily extended for multi-level recursion.
There are some current difficulties implementing this to cross multi-threads
due to the discussed limitations of the single-threaded Garbage Collector, but
there are work arounds (although we a fair amount of boilerplate code).
Re: What do you think about the programming language NIM?
@dom96: > For the time being, Nim v1 will have a GC. We should improve what we have now > instead of jumping ship to this brand new runtime which is a massive risk.. I respect your caution about "newruntime", and of course version 1.0 will still have the current GC options as a fall back. If there were no concern with the current state of multi-threading in Nim or a user doesn't require multi-theading or only very simple "naive" limited multi-threading, the current GC runtime is fine and we should have been at version 1.0 long ago or we are already there as proposed with version 0.20.X alpha/beta. However, @jyelon has expressed the need for a **multi-threaded GC** , which would seem to be the only way to cleanly fix the problems and limitations with current multi-threading, and @Araq has said that "improving what we have now" by implementing a multi-threading GC is much bigger task than the implementation of the current "newruntime" spec. Yes, the jury is out until we can actually try the new spec on practical applications and see how much it affects current packages, but the alternative of "fixing what we have" as to making multi-threading competitive could take years and Nim may well lose the currently developing interest momentum by that time. I have become an owned ref evangelist because I see it quite simply mitigating the huge mess which is the current type system structure built around all the limitations of the current GC and data type definitions, but if it doesn't work out, will become a promoter of whatever way forward we can come up with that fixes these problems in a reasonable amount of time. That said, I tend to favour non-GC solutions as even the best multi-threading GC in the world (perhaps that of Haskell) still has those limitations of undeterministic destruction, garbage collection compression moving memory locations, etc., etc. Besides, depending on GC just makes us an "also-ran" to be compared to such languages as GoLang, D, Crystal, Chapel, etc., etc. and not in the realm of "something unique" as the likes of Rust, Pony, etc., yet when compared to these last offers a much easier to learn and use experience (I think and hope). My personal "back-up plan" if the "newruntime" doesn't work out would be to add some libraries or packages that would replace the "naive" implementations of channels and threadpool so as not to require all the extra boilerplate of creating GC-Safe wrappers in order to use non-"naive" multi-threading, and am actively working on those now while waiting for the "newruntime" to stabilize to the point where I can try it out. I believe that would be the fastest way forward to a stable version 1.0 if the "newruntime" doesn't work out. IMHO, we aren't really anywhere near version 1.0 without doing something about the implementation of multi-threading (for those that need it). Of course, I admit that my use case is just for casual "hobby" projects and not in a production environment so it could well be different for others such as yourself. I love something innovative and unique, and the "newruntime" version of Nim could well be "it".
Re: What do you think about the programming language NIM?
> we believe that for typical use they will be almost as easy to use as GC'ed > references but without GC's downfalls in taking a huge development effort to > reduce memory access wait time latency while supporting multi-threading/Some/ > believe that. Others like myself need to see this in practice.| ---|--- For the time being, Nim v1 will have a GC. We should improve what we have now instead of jumping ship to this brand new runtime which is a massive risk. Anyway, I share @jyelon thoughts and don't want them to feel like everyone in the Nim community has moved on to this new runtime idea, because that isn't the case.
Re: What do you think about the programming language NIM?
@nickjonson: > I’ve found (Nim's) supposed to be faster than Julia... Referring to your opening post, Nim is at least as fast as Julia but not that much faster for well written Julia code other than Julia's wait to pre-compile it's code when it's called the first time. The problem with writing Julia code is one always has to think about and check how it sees the (dynamic) types in order to get this speed; also, I think it's state of development of multi-threading capabilities is in at least as much a state of flux as Nim's (currently). But they are two different use cases: Nim produces stand alone executable code whereas Julia depends on its development environment to run (again at least currently). @jyelon: > the thread-local heaps made it impossible to pass structured data from one > thread to another Not impossible, but a little more boilerplate code is required to accomplish if one doesn't want to allow the system to just deepCopy the data between threads. > I think sharing data structures between threads in garbage collected > languages is more common than you think. Java, definitely. C#, golang. > Anything that runs on the JVM, like scala or kotlin. All pure functional > languages, like haskell... You may as well add F#, too. Yes, all of those named languages now have multi-threaded GC; that is the way memory management has been conventionally done for Virtual Machine types of languages and Haskell now has a multi-threaded GC implementation, too. There are lots of modern languages that don't have GC as in Apple's Swift (using reference counted pointers with automatic destruction, but with flaws), Rust (a kind of safe smart pointer but with reference counting as an option when that doesn't work), and of course C++ (depends on libraries used, but something like Rust without the type safety) and one can still get things done, although you are right that GC makes it fairly easy for lots of types of applications. > I want a garbage collected language. Don't knock Nim's new run time owned ref's until you've tried them: we believe that for typical use they will be almost as easy to use as GC'ed references but without GC's downfalls in taking a huge development effort to reduce memory access wait time latency while supporting multi-threading, high execution time overheads (even worse for multi-threaded versions), and non-deterministic destruction (not knowing exactly when heap memory will be free'ed after the data goes out of scope or even after the reference to the data is manually set to nil). Have you actually tried multi-threading in those other languages to see how easy they are to use for your particular application? Have you actually tried to write something using multi-threading in modern Nim for your application? You'll never know how well they work or don't until you've actually written some Proof Of Concept little micro applications.
Re: What do you think about the programming language NIM?
I think sharing data structures between threads in garbage collected languages is more common than you think. Java, definitely. C#, golang. Anything that runs on the JVM, like scala or kotlin. All pure functional languages, like haskell. Just a few examples.
Re: What do you think about the programming language NIM?
I think only Java has a multithreaded GC. But it's very hard to design and even harder to optimize because the GC will be a contention point. What you could hopefully do is passing ownership of the table between threads with channels. And of course write shared data structure more easily.
Re: What do you think about the programming language NIM?
> However, instead of creating a garbage collector that can handle this That seems to be very hard. You know D-lang had GC support from the beginning, and D-lang has bright devs. Now they try to follow Rust avoiding a GC, see [https://www.reddit.com/r/programming/comments/cdifbu/ownership_and_borrowing_in_d](https://www.reddit.com/r/programming/comments/cdifbu/ownership_and_borrowing_in_d)/ [https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d](https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d)/ Nim has a good GC for single threaded applications, but maybe the newruntime with owned refs will be a even better solution.
Re: What do you think about the programming language NIM?
Back in 2016, I evaluated nim. I thought it was wonderful, and I was particularly impressed with the metaprogramming features. I used to use Common Lisp, and macros were amazing, and I've been waiting for a modern fast language to include them. Kudos. I was about to start using nim, when I noticed a showstopper flaw: the thread-local heaps made it impossible to pass structured data from one thread to another. I made a comment about this in the forum: [https://forum.nim-lang.org/t/2457](https://forum.nim-lang.org/t/2457) At the time, I didn't get much response. But I could see that Araq's quite a visionary, so I assumed he would eventually see the problem and make a garbage collector that allows data structures to be passed between threads. I was half-right: in May 2019, he acknowledged the problem: > I don't think "you cannot easily pass Table[string, string] to a different > thread and locks won't help you" is good enough for Nim in the long run. It's > high time we address this problem. However, instead of creating a garbage collector that can handle this, he created a non-garbage-collected runtime. That's not what I'm looking for, I want a garbage collected language. So, where things stand is: the lack of a garbage collector that supports sharing data structures between threads is still the only showstopper, for me. Aside from that, the language is great. I'm still holding out hope that this limitation will eventually be fixed. I'm patient, I've been checking in periodically since 2016, I'll keep checking in the future.
Re: What do you think about the programming language NIM?
Having curly braces {} and having to type semicolons every time; and more isn't
less readable to me either, but it does add extra unnecessary stuff to type.
Python style indentation(which to me is an upgrade from BASIC syntax which i
have used) makes it faster to write what you are aiming to. But you know that's
just an opinion D:.
Re: What do you think about the programming language NIM?
> Of course Python being taught in schools and universities helps its > popularity, but I don't think at all it's the only or even main reason for > the popularity. The other reason of course is around the time python was introduced the main languages being used were C, C++ and Java (not counting other scripting languages like PHP and Perl that were mainly for web work)… so its no surprise it took off, because everybody really, was just waiting for it. And to be honest I don't find Python that more readable, having a long def start to edge over to the right side of the screen because of all the indentation is certainly no more readable than the same def would be if it had braces inbetween but with all the code on the left side, and the braces on separate lines. Braces to split code never bothered me, however having to put semi-colons at the end of most lines did and certainly never added anything to the readability of C, C++, Java, PHP, Perl... etc, etc
Re: What do you think about the programming language NIM?
> Python, I started to learn Python and found it quite easy to pick up, however > I decided that its growing way to big as a language, too many people are > changing it too much, and for me on Windows it just became another scripting > language, no better than say Perl... and yes Python may be very popular at > the moment and that's mainly because all the schools and university's etc use > it...but we all know that they just follow each other anyway, so just because > they all use it, does not mean its the best language out there. Anybody that > thinks that is a fool. I don't see Python that negatively. The language clearly has its strengths, and personally I find it much more readable compared to Perl (not just now, but already very shortly after moving from Perl to Python). By the way, my perception from using Python professionally for almost 20 years is that schools and universities introduced Python rather slowly, after it was already in wide use. Actually I had expected that Python would find its widespread use in education _much_ earlier. Of course Python being taught in schools and universities helps its popularity, but I don't think at all it's the only or even main reason for the popularity. Regarding the "best language", I think there isn't any best language, only the best compromise for a given use case. :-)
Re: What do you think about the programming language NIM?
I've found Nim just a couple of days ago and i am totally in love with it, i am reading on it on the way to work, at work and then i practice is at home, it's so nice to have a language that is beautiful, really easy to understand just by looking at the code whilst very powerful and performant. I think i will make some tutorial videos on it once i learn it some more.
Re: What do you think about the programming language NIM?
Thanks for your explanation.
Re: What do you think about the programming language NIM?
I like Nim for all the reasons given here... for me personally, comparing with other languages... Python, I started to learn Python and found it quite easy to pick up, however I decided that its growing way to big as a language, too many people are changing it too much, and for me on Windows it just became another scripting language, no better than say Perl... and yes Python may be very popular at the moment and that's mainly because all the schools and university's etc use it...but we all know that they just follow each other anyway, so just because they all use it, does not mean its the best language out there. Anybody that thinks that is a fool. C programming, well ive stated before somewhere, I hate the C language, always have. why would anybody pick the * char to use as a pointer when in nearly every other language it was used for multiply... which meant when you look at C code... you see all these * and its like what a mess, what a complete and utter mess. On windows...Nim is faster than Python and easier than C... reasons enough for me to try it.
Re: What do you think about the programming language NIM?
@mratsim's code may not trigger it, but at least in `/devel` there seems to be
a check in `semexprs.semOverloadedCallAnalyseEffects` that errors out with
`errRecursiveDependencyIteratorX` ("recursion is not supported in iterators:
'$1'"). The error message was even updated just a couple months ago. It is not
hard to trigger this erroring out with trees that are "run-time switched"
recursions vs. @mratsim's compile-time switched recursion. I for one would love
full recursion support in iterators (and so would love to be wrong, if I am).
Re: What do you think about the programming language NIM?
This is Interesting. Thank you. So the documentation is wrong when it says: “Neither inline nor closure iterators can be recursive”. Here: [https://nim-lang.org/docs/manual.html#iterators-and-the-for-statement-first-class-iterators](https://nim-lang.org/docs/manual.html#iterators-and-the-for-statement-first-class-iterators) Or is there something I did not understood?
Re: What do you think about the programming language NIM?
Nim iterators can be recursive, this is my iterator on arbitrarily nested
arrays or sequences to construct tensors.
iterator flatIter*[T](s: openarray[T]): auto {.noSideEffect.}=
## Inline iterator on any-depth seq or array
## Returns values in order
for item in s:
when item is array|seq:
for subitem in flatIter(item):
yield subitem
else:
yield item
Run
Re: What do you think about the programming language NIM?
> Note that Nim iterators correspond to Python generators… I would like, but they are less powerful. Generators can be recursive in Python while iterators cannot. And in Python it’s easy to use a generator without a _for_ loop thanks to the _next_ function. But, despite these limitations, iterators in Nim are very pleasant and easy to use, compared with the way to define them in other languages such as Julia. And, I agree with you, they are amazingly useful.
Re: What do you think about the programming language NIM?
Some people use C++ for speed and Python for rapid prototyping and glue-logic, but combining the two can be tricky. Nim replaces both. It's not quite as fast as C++ (unless you are very careful about memory) and not quite as agile as Python (imo), but when you need both, Nim is great. Note that Nim iterators correspond to Python generators, an amazingly useful feature. Combined with templates, it swamps C++ in agility. And macros take it to a whole nother level.
Re: What do you think about the programming language NIM?
> "performance usually doesn't matter, and if it matters, is not because of the > language, but because of the code written" > > I dont know why you write this statement -- it is obviously wrong, and I am > sure you know that it is wrong. It's not entirely wrong. For _many_ applications, performance doesn't matter. For those applications that do, algorithms typically matter a **lot** more than the choice of programming language. For example, on a sufficiently large list (which probably isn't very large) a custom-written [Bubble Sort](https://en.wikipedia.org/wiki/Bubble_sort#Analysis) in the C language (or Nim, or even assembly) will always lose to Python's built-in `sort`, because [TimSort](https://en.wikipedia.org/wiki/Timsort#Analysis) scales far, far better. Things like this are not that uncommon. This is one reason higher-level languages can outperform hand-coded assembly in some cases: it's easier, and more efficient, to write good, correct algorithms in higher-level languages.
Re: What do you think about the programming language NIM?
Of course it completely depends on the IT field you work on. I have experience working with mastodon apps in big teams with teams of more than 20 developers. In that kind of scenario the performance is the smallest problem you will have to handle. And of course the performance is very important, but in years of experience you see tons of people worried exclusively about execution performance, and there are hundreds of metrics you should have in mind too. Everybody compares languages only based in execution performance when in the business field, development performance usually has a higher value
Re: What do you think about the programming language NIM?
For me performance is everything and any language that is not as fast as hand-tuned C, Fortran or Assembly is a non-starter. And the whole world of High-Performance Computing and Machine Learning is the same. When you train models for hours (or even days or week), a mere 20% speed difference is huge.
Re: What do you think about the programming language NIM?
> performance usually doesn't matter, and if it matters, is not because of the > language, but because of the code written I dont know why you write this statement -- it is obviously wrong, and I am sure you know that it is wrong. Languages like Python, Ruby, LabView, Octave, R, Processing and many more are generally very slow, as long as you cannot just call C libs. Do write a Delaunay triangulation, a RTree search, a dijkstra shortest path search in one of these languages and show me how fast your smart code executes. I came to Nim from Ruby some years ago, was not too unhappy with Ruby, but knowing that your code could be 20 times faster when you create a C routine of it, made me not happy. Maybe what you want to say was that most modern compiled languages like Rust, D, Nim, Crystal are all very close to C, so that benchmarks makes not much sense.
Re: What do you think about the programming language NIM?
Nim is the definitive language for two things (and none of them is performance, because performance usually doesn't matter, and if it matters, is not because of the language, but because of the code written) * Nim's macro system is so powerful that you can do nearly anything you imagine, this makes the language flexible enough to overcome any challenge. * Nim's structure of decoupled backends gives Nim a very high chance of survivavility as it can easily target language-specific platforms (for example the browser by targeting Javascript)
Re: What do you think about the programming language NIM?
I think it's great :) I've modified your post to get rid of that gist you've embedded (a link is enough)
What do you think about the programming language NIM?
While looking for different benchmarks I’ve found It’s supposed to be faster than Julia for many operations, though it doesn’t have so many libraries: [https://gist.github.com/sdwfrost/7c660322c6c33961297a826df4cbc30d](https://gist.github.com/sdwfrost/7c660322c6c33961297a826df4cbc30d) julia_nim_cpp_r_sir.md This gist compares the performance of Julia, Nim, C++ and R - the latter using either [POMP]([http://kingaa.github.io/pomp/)](http://kingaa.github.io/pomp/\)), or [LibBi]([http://libbi.org/](http://libbi.org/)) in a simple simulation of an [SIR]([https://en.wikipedia.org/wiki/Compartmental_models_in_epidemiology#The_SIR_model](https://en.wikipedia.org/wiki/Compartmental_models_in_epidemiology#The_SIR_model)) epidemiological model. In addition to keeping track of susceptibles, infecteds and recovereds, I also store the cumulative number of infections. Time moves in discrete steps, and the algorithm avoids language-specific syntax features to make the comparison as fair as possible, including using the same algorithm for generating binomial random numbers and the same random number generator; the exception are the R versions, POMP uses the standard R Mersenne Twister for the random number generator; I'm not sure what LibBi uses. The algorithm for generating random binomial numbers is only really suitable for small np. Benchmarks were run on a Mac Pro (Late 2013), with 3 Ghz 8-core Intel Xeon E3, 64GB 1866 Mhz RAM, running OSX v 10.11.3 (El Capitan), using Julia v0.6.1, Nim v0.17.3, clang v5.0.0, emscripten v1.37.34, node v8.9.1, and R v3.3.2. ## Nim version ### Native Compile using: This file has been truncated. show original nim.cfg @if asmjs or wasm: d:emscripten @end @if emscripten or asmjs or wasm: o:"index.html" @if not wasm: d:asmjs @end This file has been truncated. show original sir.cpp #include #include #include #include #include #include #include #include #include This file has been truncated. show original There are more than three files. show original
