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.
@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+
@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://fo
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
@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
>
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
diffe
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
@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 w
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 structu
@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
@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 t
> 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 prac
@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
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.
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.
> 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_bo
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 notic
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. Bu
> 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 counti
> 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 v
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.
Thanks for your explanation.
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
@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 a
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-sta
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:
> 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, itera
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
> "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, perfor
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
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
> 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
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
I think it's great :)
I've modified your post to get rid of that gist you've embedded (a link is
enough)
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_
35 matches
Mail list logo
