[tastyminerals]

With all due respect, Nim is a great language performance wise however I fail to see how is it different from D. Many advertised features have been present in D for a long time.

Syntax wise Nim it is a step back. It's hard to read and understand while any C/C++ dev will have next to no effort reading through D code. And of course while D is C ABI compliant it interoperates with C++ well too.

I seriously doubt that Nim or any other language in this regard has better metaprogramming than D.

Nim might have a speed overhead in certain tasks but that depends on a benchmark. Besides, does Nim have anything similar to NumPy which is actually faster? D does.

[pietroppeter]

* For a full comparison of features D vs Nim see [0], or a more succint selection of items by Nim's creator [1]; these also contains some remarks about metaprogramming and C/C++ interoperability.

* syntax-wise you could also argue that is a step forward: it embraces Python syntax and it would be easy to read and understand for all Python devs.

* Nim does have a "faster NumPy" by the same author of the article: [2]

[0]: https://github.com/timotheecour/D_vs_nim [1]: https://forum.nim-lang.org/t/1779#11098 [2]: https://mratsim.github.io/Arraymancer/index.html

[tastyminerals]

Thanks. So here are the points for D according to the table. Very few breaking changes because language is pretty mature. Not sure if Nim is as stable but just this one fact is enough for me personally.

D has slices, ranges and lazy evaluation which is a joy when you do data number crunching. Nim does not have them.

Also no mention of dpp in a table is surprising tbo.

D PRs take time mostly because they go through a rigorous community review. And by that I mean your PR does need to hit the quality bar. Which is only good and does not make a language a sandbox of community features like C++. See the PR for macros in D and why it didn't happen. Another reason is the lack of people of course.

[matthiaswh]

The table is out of date. Nim is post 1.0[1] now and stable, and has few breaking changes.

[1] https://nim-lang.org/blog/2019/09/23/version-100-released.ht...

[dmix]

> it embraces Python syntax

Nim looks most like Pascal syntax to me, with a bit of Python

[tastyminerals]

I read through Arraymancer readme and the rationale and got very mixed feelings about the project and its purpose. It's everything and nothing at the same time. NumPy like syntax and functionality, sklearn algorithms and look, deep learning too, here is and example and some screens which we borrowed from Scipy. Seriously? Sorry if that might be too judgemental but it sounds and looks amateurish. And I thought of benchmarking it against D mir... Also, the name... And this is what I feel about Nim in general, rushed and undercooked.

[entha_saava]

[0] is a great comparison, are there other comparisons of this kind?

[logicchains]

>I seriously doubt that Nim or any other language in this regard has better metaprogramming than D.

D's macros work through string interpolation. There are certainly people who find the Nim approach of generating a typed AST to be preferable.

[tokai]

> Syntax wise Nim it is a step back. It's hard to read and understand

This reads like satire to me. You shouldn't claim your feelings as objective truth.

[hellofunk]

I agree that it is strange that, in all of the discussions surrounding relatively modern languages, and new technologies, while nim and rust and many others frequently get mentioned, so rarely it seems that anyone talks about D. Wonder why that is? I’m genuinely curious.

[hippyhippo]

Because D is effectively dead/has lost its momentum completely?

If you look at the development surrounding D, the stdlib got its allocator module around 5 years back IIRC in experimental. It is still not stable. Same for many other modules. Due to lack of resources not much work is being poured into the stdlib. Same for developer tooling, some people have created ide tools and stuff, however they are not AST based and so most of the things that should work don't work. Yet, instead of pouring resources into these issues, the resources are poured into developing 3 compilers dmd, gcc based d, and llvm based d.

Also, the readability issue posted by the op are subjective. To me, and many others, Nim is much much more readable and elegant than C/D/C++/Rust.

Also regarding OP's >Many advertised features have been present in D for a long time.

Nim has macros and many features are based on or around macros, whereas D will never get macros. IIRC D uses reflection based stuff?

> I seriously doubt that Nim or any other language in this regard has better metaprogramming than D.

Well, you are wrong (Unless you like reflection more than macros). Nim, haxe, etc. languages have very powerful AST based macros.

[tastyminerals]

Are you the same person who attacked ppl on D forum. The nickname is familiar and the style ;)

Chill. All languages have dusty corners and given the amount of ppl D has it's obvious that not all things are fixed in time but they were and they will, history already proved it. Besides, complaining is easier right?

[hippyhippo]

> Are you the same person who attacked ppl on D forum

Nope. I am the person who asked about dlang VS plugin and new ds module recently. I don't remember attacking anybody.

> All languages have dusty corners and given the amount of ppl D has it's obvious that not all things are fixed in time but they were and they will, history already proved it.

Well, it was you guys who asked why D is not discussed/used more. I just gave my honest opinion. D's ide tooling is very bad compared to newer languages, even Zig. It's stdlib is not being worked on. Now, what do you expect? Why would people use D? How is creating 3 compilers not a waste of resources when there are 2 important issues that are not being worked on by anybody? Do you think more people/orgs will flock to D because it has 3 compilers even though its tooling is very bad?

> Besides, complaining is easier right?

I don't like how this is posted everywhere somebody points out flaws in something. I am not a compiler developer. I don't have much knowledge about low level stuff. I want to use a programming language for my field of expertise. If the language/ecosystem is not good for that, what do you expect me to do? Do you want me to leave everything aside, set apart 2 years for learning compilers and how its tooling is made. Then leave everything aside for 2 more years, and start contributing to D. Is this what you want me to do?

When you release a project, if you want it to be used by people, it is your responsibility to make sure that it is usable. It is not the customer's responsibility to fix the product.

Look man, I intend no disrespect to anybody. I respect walter and other people. However, what I said is a fact. D/Nim/Crystal etc. have few to no resources for development. It is upto their leads to prioritise things for sustainability. I understand how difficult it is for a project this size. But, you people can't be putting the blame on people like me for not contributing to the project or for saying that the reason why people not use D is because its tooling is nonexistent and its stdlib is dead. AFAIK, many core people also agree that dmd should be deprecated and focus/resources should be put elsewhere.

[tastyminerals]

Ok. But going back to the issue. I live in Munich and know at least two big companies who use D in production and organize meetups. I have yet to see a single company that uses Nim.

[mratsim]

The biggest sponsor of Nim Status:

- https://github.com/status-im?q=&type=&language=nim

It's used by Beamdog for tooling for Neverwinter Enhanced Editions:

- https://github.com/niv/neverwinter.nim

It's used in Academia at the University of Utah and in Germany:

- https://github.com/brentp

- https://github.com/Vindaar

And a couple more: trading, pharma

- https://github.com/nim-lang/Nim/wiki/Companies-using-Nim

[hippyhippo]

Well, mainly Status.im uses Nim, and there is one based in China I think (Some of their employees are regulars in the Nim gitter/irc/discord). Also, there is https://github.com/nim-lang/Nim/wiki/Companies-using-Nim , though I don't know how up to date it is. Anyhow, there is not much jobs for either nim/d/haxe/... So, they are mostly used for personal projects. I wanted to use D however it didn't work out, so onto other languages :(

[cercatrova]

Here's a good overview: https://news.ycombinator.com/item?id=23494490

Basically, D was too little, too late, with a lack of build tools, while Rust, Nim etc are designed from the beginning to have certain features and have easy to use build tools like cargo.

[throwaway_se099]

There is a perception that D has shot its bolt, having been around for quite some time without making a noticeable impact, either by itself or by influencing the mainstream.

[tastyminerals]

It was a developed by too few ppl from the start and by the time it became usable it was way too late

[m4r35n357]

Or, alternatively: Once something _works_ it is no longer interesting . . . ?

[tastyminerals]

Depends on where do you read ;) But tbo D community concentrates around D forum and in majority consists of former C/C++ veterans. Being a younger language Nim lures younger and active members who probably never heard of D anyway.

Historically D never advertised itself enough imho and that is a shame. I blame the lack of proper leadership and management at the start. Its early development progress has been a rocky ride many languages would not survive at all but it did and for me personally it's a testament to its maturity and resilience newer languages still have to prove.

[m4r35n357]

D has a native IDE and working REPL OOTB. They are all jealous!

[beagle3]

> Many advertised features have been present in D for a long time.

They have also been in Nim for a very long time. The initial Nim version was released in 2008, and is comparable to D2 (started 2007) rather than D1 (started 2001). So they are effectively contemporary, and gained a lot of the features at comparable times (and with some cross pollination, I'm sure, although I wasn't there to witness it).

> Syntax wise Nim it is a step back. It's hard to read and understand while any C/C++ dev will have next to no effort reading through D code.

There is no accounting for taste, but Nim syntax is Pythonic; Python is generally regarded as one of the easiest (if not THE easiest) real programming languages to pick up. Both D and Nim get hairy when you use advanced metaprogramming features, but at the surface level -- Nim is likely to be easier to pick up except if your audience is exclusively C/C++ programmers (and maybe even then).

> I seriously doubt that Nim or any other language in this regard has better metaprogramming than D.

You should learn some Lisp then, the mother of all metaprogramming systems :) and also, you should look at Nim, it's not quite Lisp but it goes as far as (and perhaps farther than) Lisp-without-reader-macros. This example[0] embeds a compile time type-checked syntax-checked SQL dialect into Nim.

> Nim might have a speed overhead in certain tasks but that depends on a benchmark. Besides, does Nim have anything similar to NumPy which is actually faster? D does.

Yes, Nim has ArrayMancer (by mratsim, who wrote this raytracer as well) which is considerably faster than Numpy and also natively supports CUDA and OpenCL, IIRC, even though it's still younger so it's not as complete as Numpy. But Nim also has Nimpy which lets you mix Python and Nim with the least friction (and generates one executable that works, and works equally well and quickly, with whatever Python you happen to use at runtime - Py27, Py36, Py37, Py38 - not familiar with anything else that does). There was also NimBorg which provided similar mixing with Lua, but it seems to be abandoned now for lack of interest.

> And of course while D is C ABI compliant it interoperates with C++ well too.

Nim is source level as well as ABI level compliant with C, C++ and Objective C (you can use C++ exceptions and objects natively, no need for an "extern C" wrapper; same with Objective C). And also natively compatible with Javascript (though obviously not in the same compilation unit ...) . D is under appreciated, for sure, but Nim is definitely not lesser, and it's about as old.

[0] https://juancarlospaco.github.io/nim-gatabase

[tastyminerals]

Thank you for the detailed answer. It clears things up.

[mratsim]

> Syntax wise Nim it is a step back. It's hard to read and understand while any C/C++ dev will have next to no effort reading through D code. And of course while D is C ABI compliant it interoperates with C++ well too.

On the other hand, people coming from Python, Ruby, Pascal, Ada will appreciate the minimal amount of sigils.

> I seriously doubt that Nim or any other language in this regard has better metaprogramming than D.

Can you write an Embedded DSL + compiler running at compile-time in D

- https://github.com/numforge/laser/tree/master/laser/lux_comp...

Can you write a cryptographic library with hex conversion to big integer and modular arithmetic running at compile-time in D?

- https://github.com/mratsim/constantine/blob/master/constanti...

Can you generate a state machine that lowers down to optimized computed gotos with no dynamic allocation suitable for multithreading runtimes and embedded devices and able to display the actual graph at compiletime?

- https://github.com/mratsim/Synthesis

Can you describe x86 opcodes in a declarative way for a JIT assembler and do all the rex/modrm/sib computation at compile-time?

- https://github.com/mratsim/photon-jit/blob/master/photon_jit...

And the same thing for an emulator?

- https://github.com/mratsim/glyph/blob/master/glyph/snes/opco...

Can you implement async as a library?

Can you emulate classes with ADTs to solve the expression problem, avoid cache misses and multithreading problem due to OOP and the double indirection due to the visitor pattern?

- https://github.com/mratsim/trace-of-radiance/blob/master/tra...

> Nim might have a speed overhead in certain tasks but that depends on a benchmark. Besides, does Nim have anything similar to NumPy which is actually faster? D does.

It does:

- https://github.com/mratsim/Arraymancer

With CPU, OpenCL and Cuda backends (in differing state of maturity)

and it's being used for data analysis for example ancestry prediction:

- http://home.chpc.utah.edu/~u6000771/somalier-ancestry.html

You can even run a neural network and see its training live:

- https://github.com/Vindaar/NeuralNetworkLiveDemo

AFAIK D doesn't have any plotting library while Nim has plot.ly integration and a ggplot2 port in pure Nim:

- https://github.com/brentp/nim-plotly

- https://github.com/Vindaar/ggplotnim

And lastly nim can easily call Python:

- https://github.com/yglukhov/nimpy

or be called from Python:

- https://github.com/Pebaz/nimporter

[tastyminerals]

Also, all good points. Appreciate that.

[moonchild]

I suspect d's metaprogramming is not as good as nim's (haven't used the latter), though it's better than metaprogramming of every language I've used without macros.

That said, it can do all of the metaprogramming-related tasks you mention.

[mratsim]

Are you aware of D libraries in that vein? I'm especially interested in the first 2, since those are something I'm actively working on at the moment.

[moonchild]

I don't know of any DSLs, but the stdlib arbitrary precision integer library works just fine at compile time:

  enum x = BigInt("0xffffffffffffffffffffffffffffffff") % 2;
  writeln(x);

('enum' means 'make this value a compile-time constant; error if you can't')

[Sir_Substance]

I gave quite a few statically-compilable language a try a few years back before settling on nim as my "fat binary" language of choice.

D was a contender, but ultimately the reason I dropped it was I was unable to compile a hello world on my laptop. Now, that machine is not fast, but it is actually pretty new, it's a very low end 2017 dell machine, and it turned out that bootstrapping a D environment requires a midspec machine or it literally cannot complete.

I donno man, D seems to have a "last 5%" problem. It looks good on the surface, but as you start looking into it you discover that the bootstrap tools are fat as hell, the core library has a weird split in GC styles, the doc is inconsistent. Everything you do in D is 5% harder than it needs to be, nothing is buttery smooth. Overall, all those 5% multiply together to make it a 20-30% worse experience overall, although I couldn't point at any one thing and say "that is what has killed D".