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
next sibling 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])


     i += 1
Apr 10 2015
next sibling 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 next sibling parent reply 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
next sibling parent reply timotheecour <timothee.cour2 gmail.com> writes:
On Wednesday, 22 April 2015 at 06:03:07 UTC, Timothee Cour wrote:

 On Mon, Apr 13, 2015 at 10:28 AM, Timothee Cour 
 <thelastmammoth gmail.com> wrote:


 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.



I've created a git repo https://github.com/timotheecour/D_vs_nim/ 
with the goal: up to date and objective comparison of features 
between D and nim, and 1:1 map of features, tools, idioms and 
libraries to help D users learn nim and vice versa.
Mar 26 2018
next sibling parent reply Ali <fakeemail example.com> writes:
On Tuesday, 27 March 2018 at 01:19:44 UTC, timotheecour wrote:

 On Wednesday, 22 April 2015 at 06:03:07 UTC, Timothee Cour 
 wrote:

 On Mon, Apr 13, 2015 at 10:28 AM, Timothee Cour 
 <thelastmammoth gmail.com> wrote:


 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.



 I've created a git repo 
 https://github.com/timotheecour/D_vs_nim/ with the goal: up to 
 date and objective comparison of features between D and nim, 
 and 1:1 map of features, tools, idioms and libraries to help D 
 users learn nim and vice versa.


How is RAII available in D? I did a quick search on this forum 
but didnt exactly find what I want

I found a comment for Walter (saying it was recently added 
https://forum.dlang.org/post/p1pa01$kc8$1 digitalmars.com)

What was the added feature that now enables RAII in D
Mar 27 2018
parent reply Timothee Cour <thelastmammoth gmail.com> writes:
that comment was regarding -betterC
RAII (with structs) has been available in D for a while, eg:

```d
struct A{
  ~this(){...}
}

void fun(){
  A a; // when a goes out of scope, will call dtor deterministically
}
```


On Tue, Mar 27, 2018 at 4:15 PM, Ali via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Tuesday, 27 March 2018 at 01:19:44 UTC, timotheecour wrote:

 On Wednesday, 22 April 2015 at 06:03:07 UTC, Timothee Cour wrote:

 On Mon, Apr 13, 2015 at 10:28 AM, Timothee Cour
 <thelastmammoth gmail.com> wrote:


 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.




 I've created a git repo https://github.com/timotheecour/D_vs_nim/ with the
 goal: up to date and objective comparison of features between D and nim, and
 1:1 map of features, tools, idioms and libraries to help D users learn nim
 and vice versa.



 How is RAII available in D? I did a quick search on this forum but didnt
 exactly find what I want

 I found a comment for Walter (saying it was recently added
 https://forum.dlang.org/post/p1pa01$kc8$1 digitalmars.com)

 What was the added feature that now enables RAII in D
Mar 27 2018
next sibling parent reply Arun Chandrasekaran <aruncxy gmail.com> writes:
On Tuesday, 27 March 2018 at 23:23:10 UTC, Timothee Cour wrote:

 that comment was regarding -betterC
 RAII (with structs) has been available in D for a while, eg:

 ```d
 struct A{
   ~this(){...}
 }

 void fun(){
   A a; // when a goes out of scope, will call dtor 
 deterministically
 }
 ```


 On Tue, Mar 27, 2018 at 4:15 PM, Ali via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:

 On Tuesday, 27 March 2018 at 01:19:44 UTC, timotheecour wrote:

 [...]



 How is RAII available in D? I did a quick search on this forum 
 but didnt exactly find what I want

 I found a comment for Walter (saying it was recently added 
 https://forum.dlang.org/post/p1pa01$kc8$1 digitalmars.com)

 What was the added feature that now enables RAII in D




This is deterministic destruction and not RAII. Resource is never 
*acquired* here. Lack of default constructors for struct in D 
makes it impossible to achieve the RAII as in C++.
Mar 28 2018
parent Ali <fakeemail example.com> writes:
On Thursday, 29 March 2018 at 03:57:05 UTC, Arun Chandrasekaran 
wrote:

 On Tuesday, 27 March 2018 at 23:23:10 UTC, Timothee Cour wrote:



 This is deterministic destruction and not RAII. Resource is 
 never *acquired* here. Lack of default constructors for struct 
 in D makes it impossible to achieve the RAII as in C++.


So what else is missing for D to achieve RAII as in C++ ?
And is deterministic destruction only available for structs, what 
about classes
Mar 29 2018
prev sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 28/03/18 02:23, Timothee Cour wrote:

 that comment was regarding -betterC
 RAII (with structs) has been available in D for a while, eg:
 
 ```d
 struct A{
    ~this(){...}
 }
 
 void fun(){
    A a; // when a goes out of scope, will call dtor deterministically
 }
 ```
 


Not so long as destructors don't reliably run.

$ dmd --version
DMD64 D Compiler v2.079.0
Copyright (C) 1999-2018 by The D Language Foundation, All Rights 
Reserved written by Walter Bright

$ cat test.d
import std.stdio;

struct A {
     int a;

     this(int a) {
         this.a = a;

         writefln("A(%s) constructed", a);
     }

     ~this() {
         writefln("A(%s) destructed", a);
     }
}

struct B {
     A a;

     this(int val) {
         a = A(val);
         throw new Exception("Constructor failed");
     }
}

void main() {
     try {
         auto a = A(1);
         auto b = B(2);
     } catch(Exception ex) {
         writefln("Caught: %s", ex.msg);
     }
}

$ rdmd test.d
A(1) constructed
A(2) constructed
A(1) destructed
Caught: Constructor failed

https://issues.dlang.org/show_bug.cgi?id=14246
Mar 29 2018
parent reply Maksim Fomin <mxfm protonmail.com> writes:
On Thursday, 29 March 2018 at 09:45:04 UTC, Shachar Shemesh wrote:

 Not so long as destructors don't reliably run.

 $ rdmd test.d
 A(1) constructed
 A(2) constructed
 A(1) destructed
 Caught: Constructor failed

 https://issues.dlang.org/show_bug.cgi?id=14246


Good catch. This is a variant of bug reported 5 years ago. The 
funny part of this bug is that the fix was reverted ... because 
of excessive code breakage.

I like D pretty much and wish to use it in serious code, but I 
cannot tolerate such sort of things.
Mar 29 2018
parent Shachar Shemesh <shachar weka.io> writes:
On 29/03/18 14:03, Maksim Fomin wrote:

 On Thursday, 29 March 2018 at 09:45:04 UTC, Shachar Shemesh wrote:

 Not so long as destructors don't reliably run.

 $ rdmd test.d
 A(1) constructed
 A(2) constructed
 A(1) destructed
 Caught: Constructor failed

 https://issues.dlang.org/show_bug.cgi?id=14246


 
 Good catch. This is a variant of bug reported 5 years ago. The funny 
 part of this bug is that the fix was reverted ... because of excessive 
 code breakage.
 
 I like D pretty much and wish to use it in serious code, but I cannot 
 tolerate such sort of things.


I don't think the fix was reverted because fixing the bug breaks code. I 
think the fix was reverted because *it* broke code.

The fix made way too many assumptions that were simply not universally 
true. For example, it would not work with structs with  disable init or 
 disable this().

So, yes, the way D is built it is not easy to properly fix it. That does 
not mean it shouldn't be fixed.

Shachar
Mar 29 2018
prev sibling parent John Belmonte <john neggie.net> writes:
On Tuesday, 27 March 2018 at 01:19:44 UTC, timotheecour wrote:

 I've created a git repo 
 https://github.com/timotheecour/D_vs_nim/ with the goal: up to 
 date and objective comparison of features between D and nim, 
 and 1:1 map of features, tools, idioms and libraries to help D 
 users learn nim and vice versa.


I just recently came across Andrei's comparison of D, Rust, and 
Go [1].  I'd love to see that updated and hear his take on Nim.

I don't have experience with Nim yet, but from what I've read it 
seems to match D's 10x "easier to interface with C and C++".  
Other possible 10x items are the GC, macro system, and the 
development community being able to focus their resources at a 
higher level (no linker, competing compilers, headaches targeting 
arm64, etc. etc.).

[1] 
https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why
Apr 19 2018
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 22 April 2015 at 06:03:07 UTC, Timothee Cour wrote:

 [snip]

 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.


In the comparison you made
https://github.com/timotheecour/D_vs_nim/
you say the CTFE engine for nim is a register VM. Stefan Koch's 
new CTFE is a bytecode interpreter. Is there an advantage of one 
over the other?
Mar 27 2018
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 28/03/2018 1:02 AM, jmh530 wrote:

 On Wednesday, 22 April 2015 at 06:03:07 UTC, Timothee Cour wrote:

 [snip]

 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.


 
 In the comparison you made
 https://github.com/timotheecour/D_vs_nim/
 you say the CTFE engine for nim is a register VM. Stefan Koch's new CTFE 
 is a bytecode interpreter. Is there an advantage of one over the other?


All application VM's use bytecode interpreters at some point in its layers.

Register versus stack VM's don't make too much of a difference.

newCTFE appears to be stack, just like .net CLR, JVM and Lua.
Mar 27 2018
prev sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Tuesday, 27 March 2018 at 12:02:37 UTC, jmh530 wrote:

 On Wednesday, 22 April 2015 at 06:03:07 UTC, Timothee Cour 
 wrote:

 [snip]

 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.


 In the comparison you made
 https://github.com/timotheecour/D_vs_nim/
 you say the CTFE engine for nim is a register VM. Stefan Koch's 
 new CTFE is a bytecode interpreter. Is there an advantage of 
 one over the other?


newCTFE can have different backends, tough the current default is 
a register based vm with a limited number of regs (16384).
Mar 27 2018
prev sibling parent David J Kordsmeier <dkords gmail.com> 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.


This is a fair set of critiques as far as the spamming goes.  The 
NIM project founder is sort of a one person show in development 
and promotion.  I wouldn't say it is not ready for real 
(commercial) use without being objective, as you have to really 
characterize what those requirements are.  If one considers 
commercial criteria to be something like: toolchain quality, IDE 
support, documentation, platform support, sustainable community, 
fair licensing terms, significant technical merits, actual 
adoption in the enterprise or research community, and commercial 
support available.  I'd agree that if your graded NIM across 
these criteria, it doesn't score high.  What impresses me about 
it are the technical merits, platform support, and its toolchain.

Disclosure, I did actually use NIM before posting.  I wrote a 
module called huenim which handles basic Philips HUE 
communication.  I found the experience to be a mixed bag.  I was 
impressed that the project lead of NIM was available to help me 
in my struggles around UPnP.  But there just is not enough great 
documentation with sample code, at the level I like when I am 
picking up a new language.  The syntax bothers me, but that's 
just my own issue with too many years of Java and C.  Another 
thing that really impressed me was how easy it was to bootstrap 
the language on an ARM device, particularly AARCH64.  The total 
runtime size is small as well.  Would I use it for my company?  
Yes.  Is there risk in doing this?  Yes.  Hard to recruit NIM 
coders.  Hard to know what is the long term sustainability of the 
NIM community and project as a whole.

I still would say that on the ready for "real" commercial use, D 
would get a much higher grade on more categories.
May 03 2018
prev sibling parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote:

 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:


I believe Rust's rayon [1] can do this too...

[1] https://github.com/rayon-rs/rayon
Apr 19 2018
parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2018-04-19 at 16:50 +0000, Per Nordl=C3=B6w via Digitalmars-d wrote=
:

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

 P.S., the example on the language's frontpage is cool!
=20
 http://nim-lang.org/
=20
 Why should I be excited?
 Nim is the only language that leverages automated proof=20
 technology to perform a disjoint check for your parallel code.=20
 Working on disjoint data means no locking is required and yet=20
 data races are impossible:


=20
 I believe Rust's rayon [1] can do this too...
=20
 [1] https://github.com/rayon-rs/rayon


Has anyone got Pony on their list of interesting languages?

--=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
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Apr 20 2018
next sibling parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Friday, 20 April 2018 at 11:07:30 UTC, Russel Winder wrote:

 On Thu, 2018-04-19 at 16:50 +0000, Per Nordlöw via 
 Digitalmars-d wrote:

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

 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:


 
 I believe Rust's rayon [1] can do this too...
 
 [1] https://github.com/rayon-rs/rayon


 Has anyone got Pony on their list of interesting languages?


Yep, I have. To bad about no curly braces, though.
Apr 20 2018
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 20 April 2018 at 11:07:30 UTC, Russel Winder wrote:

 Has anyone got Pony on their list of interesting languages?


I had spent some time looking over the reference capabilities 
[1], but I'm not sure I have the time to actually program in the 
language. The isolated type seemed like the most interesting 
take-away. I think someone on the D forums had been trying to get 
something similar.

[1] 
https://tutorial.ponylang.org/capabilities/reference-capabilities.html
Apr 20 2018
parent reply Rel <relmail rambler.ru> writes:
As for me, I find the Nim programming language interesting. 
However I dislike syntax a bit, in some cases Python+Pascal 
syntax style of Nim looks very ugly in my opinion. Also I 
strongly against relying on C compiler for code generation, 
knowing how slow it can be. Obviously it was easy for them to use 
C as a pure-text backend, but I think these days LLVM should be 
used instead.
Apr 25 2018
parent reply Rel <relmail rambler.ru> writes:
In case you guys like to take a quick look at new emerging,
but somewhat unknown systems programming languages:
* https://www.red-lang.org/ (own handwritten backend)
* https://crystal-lang.org/ (llvm-based backend)
* https://ziglang.org/ (llvm-based backend)
* http://nitlanguage.org/ (c-based backend?)
* https://www.xojo.com/ (llvm-based backend)
Apr 25 2018
parent reply Mark <smarksc gmail.com> writes:
On Wednesday, 25 April 2018 at 14:18:07 UTC, Rel wrote:

 In case you guys like to take a quick look at new emerging,
 but somewhat unknown systems programming languages:
 * https://www.red-lang.org/ (own handwritten backend)
 * https://crystal-lang.org/ (llvm-based backend)
 * https://ziglang.org/ (llvm-based backend)
 * http://nitlanguage.org/ (c-based backend?)
 * https://www.xojo.com/ (llvm-based backend)


Funnily, none of these languages have a "static if" construct, 
nor do Rust, Swift and Nim. Not one that I could find, anyway.
May 03 2018
next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote:

 Funnily, none of these languages have a "static if" construct, 
 nor do Rust, Swift and Nim. Not one that I could find, anyway.


What qualifies under "static if"? Because Rust, Swift and Nim do 
have conditional compilation.
https://doc.rust-lang.org/book/first-edition/conditional-compilation.html
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Lang
age/Statements.html (conditional compilation blocks)
https://nim-lang.org/docs/manual.html#statements-and-expressions-when-statement
May 03 2018
parent reply Mark <smarksc gmail.com> writes:
On Thursday, 3 May 2018 at 20:57:16 UTC, Dennis wrote:

 On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote:

 Funnily, none of these languages have a "static if" construct, 
 nor do Rust, Swift and Nim. Not one that I could find, anyway.


 What qualifies under "static if"? Because Rust, Swift and Nim 
 do have conditional compilation.
 https://doc.rust-lang.org/book/first-edition/conditional-compilation.html
 https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Lang
age/Statements.html (conditional compilation blocks)
 https://nim-lang.org/docs/manual.html#statements-and-expressions-when-statement


Fair enough. I should have written "static if + CTFE".
May 03 2018
parent reply Timothee Cour <thelastmammoth gmail.com> writes:
nim supports static if (`when`) + CTFE. A simple google search or searching
would've revealed that.

On Thu, May 3, 2018 at 3:20 PM Mark via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Thursday, 3 May 2018 at 20:57:16 UTC, Dennis wrote:

 On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote:

 Funnily, none of these languages have a "static if" construct,
 nor do Rust, Swift and Nim. Not one that I could find, anyway.


 What qualifies under "static if"? Because Rust, Swift and Nim
 do have conditional compilation.




https://doc.rust-lang.org/book/first-edition/conditional-compilation.html




https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html
(conditional compilation blocks)




https://nim-lang.org/docs/manual.html#statements-and-expressions-when-statement


 Fair enough. I should have written "static if + CTFE".





 May 03 2018



  parent reply Mark <smarksc gmail.com>  writes:


On Thursday, 3 May 2018 at 23:09:34 UTC, Timothee Cour wrote:

 nim supports static if (`when`) + CTFE. A simple google search 
 or searching
 would've revealed that.

 On Thu, May 3, 2018 at 3:20 PM Mark via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:


 On Thursday, 3 May 2018 at 20:57:16 UTC, Dennis wrote:

 On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote:

 Funnily, none of these languages have a "static if" 
 construct, nor do Rust, Swift and Nim. Not one that I could 
 find, anyway.


 What qualifies under "static if"? Because Rust, Swift and 
 Nim do have conditional compilation.




 https://doc.rust-lang.org/book/first-edition/conditional-compilation.html




 https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Lang
age/Statements.html (conditional compilation blocks)




 https://nim-lang.org/docs/manual.html#statements-and-expressions-when-statement


 Fair enough. I should have written "static if + CTFE".




The little information on the official site describes `when` more 
like #ifdef in C than an actual static if. I also went over a few 
dozens of modules in the standard library and the statement seems 
to be rarely used, and when it does it's usually in an #ifdef-ish 
context (like platform specific code).

Perhaps Nim's support for conditional compilation is as powerful 
as D's is, but you can see why my impression is currently to the 
contrary.



 May 04 2018



  parent  Timothee Cour <thelastmammoth gmail.com>  writes:


i think the explanation in
https://nim-lang.org/docs/manual.html#statements-and-expressions-when-statement
is pretty clear. In any case you can see for yourself:
nim c -r main.nim
```nim
proc fun(a:int):auto=a*a

   when fun(1)==1: echo "ok1"
   when fun(2)==2: echo "ok2"
```
prints ok1


On Fri, May 4, 2018 at 9:40 AM Mark via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Thursday, 3 May 2018 at 23:09:34 UTC, Timothee Cour wrote:

 nim supports static if (`when`) + CTFE. A simple google search
 or searching
 would've revealed that.

 On Thu, May 3, 2018 at 3:20 PM Mark via Digitalmars-d <
 digitalmars-d puremagic.com> wrote:


 On Thursday, 3 May 2018 at 20:57:16 UTC, Dennis wrote:

 On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote:

 Funnily, none of these languages have a "static if"
 construct, nor do Rust, Swift and Nim. Not one that I could
 find, anyway.


 What qualifies under "static if"? Because Rust, Swift and
 Nim do have conditional compilation.








https://doc.rust-lang.org/book/first-edition/conditional-compilation.html








https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html
(conditional compilation blocks)








https://nim-lang.org/docs/manual.html#statements-and-expressions-when-statement

 Fair enough. I should have written "static if + CTFE".







 The little information on the official site describes `when` more
 like #ifdef in C than an actual static if. I also went over a few
 dozens of modules in the standard library and the statement seems
 to be rarely used, and when it does it's usually in an #ifdef-ish
 context (like platform specific code).



 Perhaps Nim's support for conditional compilation is as powerful
 as D's is, but you can see why my impression is currently to the
 contrary.





 May 04 2018



prev sibling next sibling parent  Andrew Kelley <superjoe30 gmail.com>  writes:


On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote:

 On Wednesday, 25 April 2018 at 14:18:07 UTC, Rel wrote:

 In case you guys like to take a quick look at new emerging,
 but somewhat unknown systems programming languages:
 * https://www.red-lang.org/ (own handwritten backend)
 * https://crystal-lang.org/ (llvm-based backend)
 * https://ziglang.org/ (llvm-based backend)
 * http://nitlanguage.org/ (c-based backend?)
 * https://www.xojo.com/ (llvm-based backend)


 Funnily, none of these languages have a "static if" construct, 
 nor do Rust, Swift and Nim. Not one that I could find, anyway.


Zig has implicit static if:

test "static if" {
     if (false) {
          compileError("this is never analyzed");
     }
}

$ zig test test.zig
Test 1/1 static if...OK

test "static if" {
     if (true) {
          compileError("this is analyzed");
     }
}

$ zig test test.zig
test.zig:3:9: error: this is analyzed
          compileError("this is analyzed");
         ^



 May 08 2018



prev sibling  parent reply Rel <relmail rambler.ru>  writes:


On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote:

 Funnily, none of these languages have a "static if" construct, 
 nor do Rust, Swift and Nim. Not one that I could find, anyway.


So what's a big deal in having 'static if' construct? Most of the
new programming languages that compiles to native code like Nim,
Crystal, Rust, Red and etc have good enough meta-programming
support anyways.



 May 13 2018



  parent  aliak <something something.com>  writes:


On Monday, 14 May 2018 at 06:14:02 UTC, Rel wrote:

 On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote:

 Funnily, none of these languages have a "static if" construct, 
 nor do Rust, Swift and Nim. Not one that I could find, anyway.


 So what's a big deal in having 'static if' construct? Most of 
 the
 new programming languages that compiles to native code like Nim,
 Crystal, Rust, Red and etc have good enough meta-programming
 support anyways.



I recommend this talk to show what static if (among other static 
introspection tools) enables.

https://www.youtube.com/watch?v=29h6jGtZD-U

Cheers



 May 13 2018



prev sibling  parent reply helxi <brucewayneshit 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) ?


Nim is way more expressive than D afaik. Consider the following 
imaginary function:

proc fn[A : int | float; N; B : seq[A] | DoublyLinkedList[A] | 
array[N, A] | set[A]](x: B) : int =
     return x.len() + 10

This function takes an argument of type B, which is can be either 
a vector or forward-list or array of (array's length is N, which 
can be of any numeric type) or a set of A. A can be either int or 
float only.

Emulating those inline constraints in D would be cumbersome.



 Apr 13 2018



  parent  Timothee Cour <thelastmammoth gmail.com>  writes:


 helxi I invite you to contribute PR's to
https://github.com/timotheecour/D_vs_nim/ where I discuss feature
parity and how to translate concepts from D to nim wherever it makes
sense


On Fri, Apr 13, 2018 at 4:12 PM, helxi via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 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) ?



 Nim is way more expressive than D afaik. Consider the following imaginary
 function:

 proc fn[A : int | float; N; B : seq[A] | DoublyLinkedList[A] | array[N, A] |
 set[A]](x: B) : int =
     return x.len() + 10

 This function takes an argument of type B, which is can be either a vector
 or forward-list or array of (array's length is N, which can be of any
 numeric type) or a set of A. A can be either int or float only.

 Emulating those inline constraints in D would be cumbersome.





 Apr 13 2018