Nim looks very promising.
Is there any comprehensive comparison against D somewhere (if possible
recent) ?

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

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 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.
>

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.

> 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.

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

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.

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.

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."