www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D vs nim

reply Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
Nim looks very promising.
Is there any comprehensive comparison against D somewhere (if possible
recent) ?
Apr 10 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Friday, 10 April 2015 at 18:42:20 UTC, Timothee Cour wrote:
 Nim looks very promising.
 Is there any comprehensive comparison against D somewhere (if 
 possible
 recent) ?
The only things I've read about nim have been on the D forums - it seems the wikipedia article is even being considered for deletion due to not being noteworthy. So I think you might have trouble finding any comparisons. P.S., the example on the language's frontpage is cool! http://nim-lang.org/ Why should I be excited? Nim is the only language that leverages automated proof technology to perform a disjoint check for your parallel code. Working on disjoint data means no locking is required and yet data races are impossible: parallel: var i = 0 while i <= a.high: spawn f(a[i]) spawn f(a[i+1]) # ERROR: cannot prove a[i] is disjoint from a[i+1] # BUT: replace 'i += 1' with 'i += 2' and the code compiles! i += 1
Apr 10 2015
parent reply "bachmeier" <no spam.com> writes:
On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote:
 The only things I've read about nim have been on the D forums - 
 it seems the wikipedia article is even being considered for 
 deletion due to not being noteworthy. So I think you might have 
 trouble finding any comparisons.
Read the comments sections on other languages on Reddit programming and you'll see their spam all over the place. I've never used Nim (and don't plan to because I've been turned off by their constant spamming of comment threads on Reddit) but the numerous comments I've seen repeatedly indicate that Nim is not yet ready for real use.
Apr 10 2015
next sibling parent reply Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
I think people interested in D should take a closer look at nim and judge
for yourself ; http://nim-lang.org/tut1.html is a good starting point (docs
in general are very well written).

I went through their tutorials and here are some first impressions:

* nim is already bootstrapped (self-compiles)
* feature set is very rich, many features (semantic and syntax) not found
in D or improving the ones in D, eg hygenic macros,
* many key features of D (static if, type inference, CTFE, UFCS, lambda,
template constraints).
* The syntax seems more orthogonal with fewer bultin constructs and many
generated by library, eg: 'a>b is a hygyenic macro that generates 'b<a';
associative arrays (tables) are in library
* documentation in code uses markdown (less noisy than D's)
 * named parameter arguments
* tooling (nimble package manager ~dub, nimfix ~= gofix; nimgrep ~=
dscanner);
* etc...

less good or tradeoffs:

* C backend instead of (LLVM,gcc or dmd's; but they're working on it
* uses yield-based ranges instead of D-based ranges (maybe simpler to write
but less efficient?)
* forward declarations needed (docs says this may change)
* thread-local GC (no stop the world)
* RAII still experimental it seems
* mutually importing modules seem possible; but doc says: Modules that
depend on each other are possible, but strongly discouraged; it's very
common in D
* mutually recursive types. In Nim these types can only be declared within
a single type section. (Anything else would require arbitrary symbol
lookahead which slows down compilation.)

not sure whether language has those; need to look more in the docs:
* delegates
* template variadic (but has varargs[T])
* not sure whether we can have template parameters which are other than a
type

It would be nice to have a wiki page to describe this further feature by
feature. Many ideas would be great to incorporate in D too btw.

On Fri, Apr 10, 2015 at 2:26 PM, bachmeier via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote:

 The only things I've read about nim have been on the D forums - it seems
 the wikipedia article is even being considered for deletion due to not
 being noteworthy. So I think you might have trouble finding any comparisons.
Read the comments sections on other languages on Reddit programming and you'll see their spam all over the place. I've never used Nim (and don't plan to because I've been turned off by their constant spamming of comment threads on Reddit) but the numerous comments I've seen repeatedly indicate that Nim is not yet ready for real use.
Apr 13 2015
next sibling parent reply "matovitch" <camille.brugel laposte.net> writes:
Sorry if I don't make my point accurately, it's been not so long 
since I started learning English. I often found programming 
language community relates to churchs. I find D to be really 
present on reddit and that’s great because other people can 
discover that wonderful language. But blaming other language for 
doing the same is just plain hypocrite : if it's on top, people 
are interested, it's that simple. That been said I am not 
familiar with nim, but I am really excited about the next 
generation of languages like D and rust. To express my opinion 
about these language and note those are just *opinions*. I think 
D is extraordinary expressive...such a complex language too. From 
a metaprogramming point of view, I am mixed about string mixins, 
the syntax of the 'is' statement (seriously ?), do we need so 
many traits ? Rust opted for type classes over templates 
constraints and ast macros, D had no shame introducing imperative 
programming into the compile time word...it a choice and I kind 
of like even though some might think it's not really pretty. I 
don't like the GC much and I think I wouldn't missed the features 
it allowed, but that won't say I am very grateful about the 
recent improvements (I think it's Martin Nowak to thanks). I 
don't like associative arrays built-in, those are no trivial data 
structure and should be available in phobos. About Phobos, it's 
clearly a big win compare to Rust standard library...for now 
(only...I hope), ranges are plain awesome, algorithm is good. 
Modules, distinction between struct and class, ref and others 
storage classes well that's beyond word : awesome ! Unittests : 
thats political. ;) Foreach is good but why adding an index is 
restricted to built-in arrays and I know about ennumerate, that's 
not the question. Why auto ref arguments taking function should 
be templates (I understand there is a method duplication but that 
is so weird especially not coherent with auto ref *returning 
function) ? I have noticed something about D, sometimes some 
stuff might seems weird at first but often when you dig about it, 
you discover there is a really well thought design choice behind 
it. I don't now rust that much, but I have to admit it looks much 
prettier and a bit less expressive/powerful but again it's D I am 
comparing it to. The two are a great improvement on C++ I get my 
pittance with since four month now, that feels good. A bad think 
about those languages though is that they can also make you kinda 
hate your job sometimes. ;) Well anyway, thanks to all the people 
involved in the design of such heavy machineries as compilers, I 
hope I get more time and experience to help some day (I am more 
in applied maths, so I think I will try to get on this side).

btw : I think D should get rid off un-bracketed if statement, 
programming is not about sparing the number of lines...but that’s 
again a matter of taste.
Apr 13 2015
parent reply "Jadbox" <jadit2 gmail.com> writes:
 btw : I think D should get rid off un-bracketed if statement, 
 program king is not about sparing the number of lines...but 
 that’s again a matter of taste.
I'm that guy on the other side of the fence. I view unbracked IFs as an essential part of concise code readability. Brackets are the symbolization of a block of logic, meaning multiple steps of logic. Being forced to express "this is a block of code" for just a single statement after an IF seems bloaty and hurts scanning through code. I also feel reducing line numbers is something to strive for as long as no readability is sacrifices.
Apr 13 2015
next sibling parent "extrawurst" <stephan extrawurst.org> writes:
On Tuesday, 14 April 2015 at 06:31:08 UTC, Jadbox wrote:
 btw : I think D should get rid off un-bracketed if statement, 
 program king is not about sparing the number of lines...but 
 that’s again a matter of taste.
I'm that guy on the other side of the fence. I view unbracked IFs as an essential part of concise code readability. Brackets are the symbolization of a block of logic, meaning multiple steps of logic. Being forced to express "this is a block of code" for just a single statement after an IF seems bloaty and hurts scanning through code. I also feel reducing line numbers is something to strive for as long as no readability is sacrifices.
+1
Apr 14 2015
prev sibling next sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Tuesday, 14 April 2015 at 06:31:08 UTC, Jadbox wrote:
 btw : I think D should get rid off un-bracketed if statement, 
 program king is not about sparing the number of lines...but 
 that’s again a matter of taste.
I'm that guy on the other side of the fence. I view unbracked IFs as an essential part of concise code readability. Brackets are the symbolization of a block of logic, meaning multiple steps of logic. Being forced to express "this is a block of code" for just a single statement after an IF seems bloaty and hurts scanning through code. I also feel reducing line numbers is something to strive for as long as no readability is sacrifices.
+1. I personally think that whenever you use unbracketed if the statement should be on the same line as the if - but that should be checked by configurable style-checkers, not by the compiler. I also don't like the idea of introducing these kinds of breaking changes when the language is supposed to be stable. Enforcing some best practices from the beginning of the language is beneficial, since I can be sure all code written in that language uses these best practices. But if such best practices are introduced when the language claims to be stable, forcing me to go all over my project to make sure it complies to it, and then forking some of the dependencies' repositories so I can do the same with them(only this time it's code that I'm unfamiliar with) - I'll seriously consider if migrating my project to a more stable language might actually be less work in the long run, considering that more breaking changes like this might be introduced in the future.
Apr 14 2015
parent "matovitch" <camille.brugel laposte.net> writes:
On Tuesday, 14 April 2015 at 10:09:15 UTC, Idan Arye wrote:
 On Tuesday, 14 April 2015 at 06:31:08 UTC, Jadbox wrote:
 btw : I think D should get rid off un-bracketed if statement, 
 program king is not about sparing the number of lines...but 
 that’s again a matter of taste.
I'm that guy on the other side of the fence. I view unbracked IFs as an essential part of concise code readability. Brackets are the symbolization of a block of logic, meaning multiple steps of logic. Being forced to express "this is a block of code" for just a single statement after an IF seems bloaty and hurts scanning through code. I also feel reducing line numbers is something to strive for as long as no readability is sacrifices.
+1. I personally think that whenever you use unbracketed if the statement should be on the same line as the if - but that should be checked by configurable style-checkers, not by the compiler. I also don't like the idea of introducing these kinds of breaking changes when the language is supposed to be stable. Enforcing some best practices from the beginning of the language is beneficial, since I can be sure all code written in that language uses these best practices. But if such best practices are introduced when the language claims to be stable, forcing me to go all over my project to make sure it complies to it, and then forking some of the dependencies' repositories so I can do the same with them(only this time it's code that I'm unfamiliar with) - I'll seriously consider if migrating my project to a more stable language might actually be less work in the long run, considering that more breaking changes like this might be introduced in the future.
Please I wouldn't like to divert this thread into a bracketed/un-bracked flame war...In fact I mostly don't care. In fact if people like it thats probably the good choice, I just like to got only one way to do it *syntax-wise*. But please talk about feature, I regret my '.btw:' section.
Apr 14 2015
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 14 April 2015 at 06:31:08 UTC, Jadbox wrote:
 btw : I think D should get rid off un-bracketed if statement, 
 program king is not about sparing the number of lines...but 
 that’s again a matter of taste.
I'm that guy on the other side of the fence. I view unbracked IFs as an essential part of concise code readability. Brackets are the symbolization of a block of logic, meaning multiple steps of logic. Being forced to express "this is a block of code" for just a single statement after an IF seems bloaty and hurts scanning through code. I also feel reducing line numbers is something to strive for as long as no readability is sacrifices.
I think Apple would disagree (CVE-ID CVE-2014-1266).
Apr 14 2015
prev sibling next sibling parent reply "Messenger" <dont shoot.me> writes:
On Friday, 10 April 2015 at 21:26:35 UTC, bachmeier wrote:
 On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote:
 The only things I've read about nim have been on the D forums 
 - it seems the wikipedia article is even being considered for 
 deletion due to not being noteworthy. So I think you might 
 have trouble finding any comparisons.
Read the comments sections on other languages on Reddit programming and you'll see their spam all over the place. I've never used Nim (and don't plan to because I've been turned off by their constant spamming of comment threads on Reddit) but the numerous comments I've seen repeatedly indicate that Nim is not yet ready for real use.
To be fair, a vocal minority says the same of D. Accusations of linkbombing are commonplace, as is the notion that the D forums are "nice except for the constant go-bashing", claims that there is an organized secret cabal (naturally led by AA and WB) directing people over IRC to upvote everything D regardless of content, etc. Once the seed of doubt is there suddenly everyone saying anything positive about D is probably/maybe/possibly just part of the mob. On Monday, 13 April 2015 at 17:28:14 UTC, Timothee Cour wrote: [...]
 * feature set is very rich, many features (semantic and syntax) 
 not found
 in D or improving the ones in D, eg hygenic macros,
I really like how younger languages can afford to take ideas and find inspiration in eachother. Everyone is better off having mindsets along the lines of "that's awesome, how can we do better" as opposed to "Simpsons did it, you just stole that from XYZ."
Apr 14 2015
parent reply "bachmeier" <no spam.net> writes:
On Tuesday, 14 April 2015 at 10:48:48 UTC, Messenger wrote:
 To be fair, a vocal minority says the same of D. Accusations of 
 linkbombing are commonplace, as is the notion that the D forums 
 are "nice except for the constant go-bashing", claims that 
 there is an organized secret cabal (naturally led by AA and WB) 
 directing people over IRC to upvote everything D regardless of 
 content, etc. Once the seed of doubt is there suddenly everyone 
 saying anything positive about D is probably/maybe/possibly 
 just part of the mob.
The problem with Nim is different. They'll go into the comments section of a completely unrelated post, write something favorable about Nim, then they'll all upvote it so it stays there. That signals to me that they know they can't generate interest based on the merits of the language.
Apr 14 2015
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2015-04-14 at 12:47 +0000, bachmeier via Digitalmars-d wrote:
 On Tuesday, 14 April 2015 at 10:48:48 UTC, Messenger wrote:
 To be fair, a vocal minority says the same of D. Accusations of=20
 linkbombing are commonplace, as is the notion that the D forums=20
 are "nice except for the constant go-bashing", claims that=20
 there is an organized secret cabal (naturally led by AA and WB)=20
 directing people over IRC to upvote everything D regardless of=20
 content, etc. Once the seed of doubt is there suddenly everyone=20
 saying anything positive about D is probably/maybe/possibly=20
 just part of the mob.
=20 The problem with Nim is different. They'll go into the comments=20 section of a completely unrelated post, write something favorable=20 about Nim, then they'll all upvote it so it stays there. That=20 signals to me that they know they can't generate interest based=20 on the merits of the language.
That is a very strong claim about ethically bad behaviour, I hope you have evidence to substantiate it. Even if true, that sort of behaviour is just "gaming the system", I am sure it happens in Java, C, C++, etc. circles, it is all part of guerilla marketing undertaken by anyone with anything to market. I like the Nim concept and approach, but there is an annoying attitude towards certain types of obvious bug. My current bugbear (!) is that the installer will not install, due to what seems like a blindingly obvious problem, but they will not fix the issue because "just use it in place". Grr=E2=80=A6 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 20 2015
parent "bearophile" <bearophileHUGS lycos.com> writes:
Russel Winder:

 it is all part of
 guerilla marketing undertaken by anyone with anything to market.
It's still not a correct behavour, regardless how many do it. Bye, bearophile
Apr 20 2015
prev sibling next sibling parent Parke via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, Apr 20, 2015 at 2:21 AM, Russel Winder via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 I like the Nim concept and approach, but there is an annoying attitude
 towards certain types of obvious bug. My current bugbear (!) is that
 the installer will not install, due to what seems like a blindingly
 obvious problem, but they will not fix the issue because "just use it
 in place". Grr…
Nim includes an install.sh script. It worked for me. According to the Nim docs ( http://nim-lang.org/download.html ) "There are other ways to install Nim (like using the install.sh script), but these tend to cause more problems." I am not sure what these unspecified problems are. I used Nim only briefly, so perhaps there problems are lurking and I just did not encounter them. -Parke
Apr 20 2015
prev sibling next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2015-04-20 at 13:05 -0700, Parke via Digitalmars-d wrote:
=20
[=E2=80=A6]
 Nim includes an install.sh script.  It worked for me.
install.sh calls koch, both of these are created by running build.sh. Running koch builds the executable for installation which requires extra compilations one critical part of which does not happen. So the built system is fine but the installable version will not build.
 According to the Nim docs ( http://nim-lang.org/download.html ) "There
 are other ways to install Nim (like using the install.sh script), but
 these tend to cause more problems."  I am not sure what these
 unspecified problems are.  I used Nim only briefly, so perhaps there
 problems are lurking and I just did not encounter them.
The Nim developers seem disinterested in fixing things for early adopters, which is sad. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.winder ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder
Apr 21 2015
parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 21 April 2015 at 08:29:11 UTC, Russel Winder wrote:
 On Mon, 2015-04-20 at 13:05 -0700, Parke via Digitalmars-d 
 wrote:
 
[…]
 Nim includes an install.sh script.  It worked for me.
install.sh calls koch, both of these are created by running build.sh. Running koch builds the executable for installation which requires extra compilations one critical part of which does not happen. So the built system is fine but the installable version will not build.
 According to the Nim docs ( http://nim-lang.org/download.html 
 ) "There
 are other ways to install Nim (like using the install.sh 
 script), but
 these tend to cause more problems."  I am not sure what these
 unspecified problems are.  I used Nim only briefly, so perhaps 
 there
 problems are lurking and I just did not encounter them.
The Nim developers seem disinterested in fixing things for early adopters, which is sad.
Neither is it a good strategy. How are they supposed to build up a user base (and get input), if they don't care for potential users, especially now that they are going on about how great the language is.
Apr 21 2015
prev sibling next sibling parent Parke via Digitalmars-d <digitalmars-d puremagic.com> writes:
 On Mon, 2015-04-20 at 13:05 -0700, Parke via Digitalmars-d wrote:
 Nim includes an install.sh script.  It worked for me.
On Tue, Apr 21, 2015 at 1:28 AM, Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> wrote:
 install.sh calls koch, both of these are created by running build.sh.

 Running koch builds the executable for installation which requires extra
 compilations one critical part of which does not happen. So the built
 system is fine but the installable version will not build.
How should I modify the following script to encounter the problems of which you speak? ---- unzip -q nim-0.10.2.zip cd nim-0.10.2 sh build.sh > /dev/null sh install.sh ../install_dir cd ../install_dir echo 'echo "Hello, Nim world!"' > hello.nim nim/bin/nim c hello.nim echo ./hello ---- When I run the script on my Ubuntu system, I get the following: $ sh -x nim_test.sh + unzip -q nim-0.10.2.zip + cd nim-0.10.2 + sh build.sh + sh install.sh ../install_dir Nim build detected copying files... installation successful + cd ../install_dir + echo echo "Hello, Nim world!" + nim/bin/nim c hello.nim config/nim.cfg(45, 2) Hint: added path: '/home/bake/.babel/pkgs/' [Path] config/nim.cfg(46, 2) Hint: added path: '/home/bake/.nimble/pkgs/' [Path] Hint: used config file '/usr/local/bake/tmp/install_dir/nim/config/nim.cfg' [Conf] Hint: system [Processing] Hint: hello [Processing] CC: hello CC: system [Linking] Hint: operation successful (8753 lines compiled; 1.230 sec total; 14.148MB) [SuccessX] + echo + ./hello Hello, Nim world!
Apr 21 2015
prev sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2015-04-21 at 09:42 -0700, Parke via Digitalmars-d wrote:
=20
[=E2=80=A6]
 How should I modify the following script to encounter the problems of
 which you speak?
=20
 ----
=20
 unzip -q nim-0.10.2.zip
I think the issue here is that this is the "release" from a while back, whereas I am trying to build from master/HEAD of the Git repository. I hypothesize that the problem with building libzip occurred after 10.2.
 cd nim-0.10.2
 sh build.sh > /dev/null
 sh install.sh ../install_dir
=20
 cd ../install_dir
 echo 'echo "Hello, Nim world!"' > hello.nim
 nim/bin/nim c hello.nim
 echo
 ./hello
=20
 ----
=20
 When I run the script on my Ubuntu system, I get the following:
=20
 $ sh -x nim_test.sh
 + unzip -q nim-0.10.2.zip
 + cd nim-0.10.2
 + sh build.sh
 + sh install.sh ../install_dir
 Nim build detected
 copying files...
 installation successful
 + cd ../install_dir
 + echo echo "Hello, Nim world!"
 + nim/bin/nim c hello.nim
 config/nim.cfg(45, 2) Hint: added path: '/home/bake/.babel/pkgs/' [Path]
 config/nim.cfg(46, 2) Hint: added path: '/home/bake/.nimble/pkgs/' [Path]
 Hint: used config file
 '/usr/local/bake/tmp/install_dir/nim/config/nim.cfg' [Conf]
 Hint: system [Processing]
 Hint: hello [Processing]
 CC: hello
 CC: system
 [Linking]
 Hint: operation successful (8753 lines compiled; 1.230 sec total;
 14.148MB) [SuccessX]
 + echo
=20
 + ./hello
 Hello, Nim world!
--=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.winder ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder
Apr 22 2015
prev sibling parent "Chris" <wendlec tcd.ie> writes:
On Monday, 13 April 2015 at 17:28:14 UTC, Timothee Cour wrote:
 I think people interested in D should take a closer look at nim 
 and judge
 for yourself ; http://nim-lang.org/tut1.html is a good starting 
 point (docs
 in general are very well written).

 I went through their tutorials and here are some first 
 impressions:

 * nim is already bootstrapped (self-compiles)
 * feature set is very rich, many features (semantic and syntax) 
 not found
 in D or improving the ones in D, eg hygenic macros,
 * many key features of D (static if, type inference, CTFE, 
 UFCS, lambda,
 template constraints).
 * The syntax seems more orthogonal with fewer bultin constructs 
 and many
 generated by library, eg: 'a>b is a hygyenic macro that 
 generates 'b<a';
 associative arrays (tables) are in library
 * documentation in code uses markdown (less noisy than D's)
  * named parameter arguments
 * tooling (nimble package manager ~dub, nimfix ~= gofix; 
 nimgrep ~=
 dscanner);
 * etc...

 less good or tradeoffs:

 * C backend instead of (LLVM,gcc or dmd's; but they're working 
 on it
 * uses yield-based ranges instead of D-based ranges (maybe 
 simpler to write
 but less efficient?)
 * forward declarations needed (docs says this may change)
 * thread-local GC (no stop the world)
 * RAII still experimental it seems
 * mutually importing modules seem possible; but doc says: 
 Modules that
 depend on each other are possible, but strongly discouraged; 
 it's very
 common in D
 * mutually recursive types. In Nim these types can only be 
 declared within
 a single type section. (Anything else would require arbitrary 
 symbol
 lookahead which slows down compilation.)

 not sure whether language has those; need to look more in the 
 docs:
 * delegates
 * template variadic (but has varargs[T])
 * not sure whether we can have template parameters which are 
 other than a
 type

 It would be nice to have a wiki page to describe this further 
 feature by
 feature. Many ideas would be great to incorporate in D too btw.

 On Fri, Apr 10, 2015 at 2:26 PM, bachmeier via Digitalmars-d <
 digitalmars-d puremagic.com> wrote:

 On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote:

 The only things I've read about nim have been on the D forums 
 - it seems
 the wikipedia article is even being considered for deletion 
 due to not
 being noteworthy. So I think you might have trouble finding 
 any comparisons.
Read the comments sections on other languages on Reddit programming and you'll see their spam all over the place. I've never used Nim (and don't plan to because I've been turned off by their constant spamming of comment threads on Reddit) but the numerous comments I've seen repeatedly indicate that Nim is not yet ready for real use.
I have to say, Nim sounds very interesting and promising. I don't know how easy it is to integrate C/C++ code, but they have a foreign function interface: http://nim-lang.org/manual.html#foreign-function-interface
Apr 20 2015
prev sibling parent Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, Apr 13, 2015 at 10:28 AM, Timothee Cour <thelastmammoth gmail.com>
wrote:

 I think people interested in D should take a closer look at nim and judge
 for yourself ; http://nim-lang.org/tut1.html is a good starting point
 (docs in general are very well written).

 I went through their tutorials and here are some first impressions:

 * nim is already bootstrapped (self-compiles)
 * feature set is very rich, many features (semantic and syntax) not found
 in D or improving the ones in D, eg hygenic macros,
 * many key features of D (static if, type inference, CTFE, UFCS, lambda,
 template constraints).
 * The syntax seems more orthogonal with fewer bultin constructs and many
 generated by library, eg: 'a>b is a hygyenic macro that generates 'b<a';
 associative arrays (tables) are in library
 * documentation in code uses markdown (less noisy than D's)
  * named parameter arguments
 * tooling (nimble package manager ~dub, nimfix ~= gofix; nimgrep ~=
 dscanner);
 * etc...

 less good or tradeoffs:

 * C backend instead of (LLVM,gcc or dmd's; but they're working on it
 * uses yield-based ranges instead of D-based ranges (maybe simpler to
 write but less efficient?)
Other issues with that: this provides a less flexibility (eg infinite ranges, bidirectional ranges etc)
 * forward declarations needed (docs says this may change)
 * thread-local GC (no stop the world)
 * RAII still experimental it seems
 * mutually importing modules seem possible; but doc says: Modules that
 depend on each other are possible, but strongly discouraged; it's very
 common in D
 * mutually recursive types. In Nim these types can only be declared within
 a single type section. (Anything else would require arbitrary symbol
 lookahead which slows down compilation.)

 not sure whether language has those; need to look more in the docs:
 * delegates
Actually they do have delegates (just not mentioned in the tutorial)
 * template variadic (but has varargs[T])
 * not sure whether we can have template parameters which are other than a
 type
 It would be nice to have a wiki page to describe this further feature by
 feature. Many ideas would be great to incorporate in D too btw.

 On Fri, Apr 10, 2015 at 2:26 PM, bachmeier via Digitalmars-d <
 digitalmars-d puremagic.com> wrote:

 On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote:

 The only things I've read about nim have been on the D forums - it seems
 the wikipedia article is even being considered for deletion due to not
 being noteworthy. So I think you might have trouble finding any comparisons.
Read the comments sections on other languages on Reddit programming and you'll see their spam all over the place. I've never used Nim (and don't plan to because I've been turned off by their constant spamming of comment threads on Reddit) but the numerous comments I've seen repeatedly indicate that Nim is not yet ready for real use.
I would like to refocus this thread on feature set and how it compares to D, not on flame wars about brackets or language marketing issues.
Apr 21 2015