Top reasons to use D instead of for example Rust, Julia, Go etc :)

On 9/21/20 7:04 AM, Imperatorn wrote:
> Top reasons to use D instead of for example Rust, Julia, Go etc :)

My list, in no particular order:

1. Metaprogramming
2. Using Metaprogramming to generate code
3. Using CTFE to generate Metaprogramming to generate code.

-Steve

On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:
> Top reasons to use D instead of for example Rust, Julia, Go etc :)

From my experience:

# Rust

## Pros

Great introductory material and generally well documented, and shallow learning curve but you need to be prepared to adapt to a different way of doing things. If you do as the documentation says, you will have remarkably few problems.

## Cons (w.r.t D)

Far more difficult and poorly documented integration with C than in D. You can write C code and call it from Rust but just try calling BLAS from Rust - that's a headache, but it's comparatively child's play in D.

Rust doesn't ship with a threading library or parallel for loop in its standard library. In this day and age that's a non-starter for me.

I wonder whether completely shifting your programming style to Rust is worth it when I tend to segfault in D only once or twice every 6 months (if I'm intensively coding D), they are easy fixes (within 5-10 minutes) and usually happen when I've called a C library in an incorrect way.


# Julia

## Pros

Great introductory material and generally well documented. Since it is a dynamic language beginners can lean on the dynamic notation until they understand the typed side. Also great performance and out-of-the-box scientific data structures and algorithms. Its multiple dispatch OOP is very convenient and easy, great collection of programming paradigms and a well designed language. Can call C libraries easily. Easy to write code abuse when you need to because it has embedded compiler and is dynamic but also typed. Very good interpreter.

## Cons (w.r.t D)

Can't distribute proprietary libraries/modules, no dlls so people will see the implementations.

Pointers and references are in their infancy, constants are not really constant, even though it is typed, it has poor support for other things static languages take for granted, e.g. good enums, static, and so forth.

Long compile times for various libraries which can take between 10 seconds to over a minute to compile even simple libraries, and they need to be compiled each time they are loaded. If you are working with libraries, you can suddenly come to a standstill when you have to wait for the function/module to compile.

Even though it's technically a "dynamic" language, I think it's somewhere in between. I'm not sure you can call a language "dynamic" if it has a compiler backend embedded built into it that causes very long all-stops. I feel as if there is a bit of "slight of hand" in that definition, but whatever.

IMO, defaulting to private in a module is the wrong call, but you also you have write export lists a bit like a header file [Gag!].

You have to be careful about how you write code since the compiler can mark things dynamic rather than creating efficient code for it. It requires experience and constant vigilance using the provided tools. Writing an object one way rather than another can have a massivley deliterious effect on performance, and with a drive to "simplify" coding by leaving out type information and so forth, it's something that can easily happen.

Julia is a useful langage but it not a panacea, you have to take extra care to understand why you are using it, because it doesn't easily fall into the usual categories of programming languages.


# Golang
Don't know much about Golang, but I don't tend to take modern static languages with no templates/parametric polymorphism seriously.


# Nim

## Pros

You didn't ask for this but Nim is worth mentioning. Fantastic base language, very easy integration with C, great performance. C/C++/JavaScript backends are an inspired move.

## Cons (w.r.t D)

Very poor documentation, the official book doesn't even begin to touch the usefulness of Ali's "Programming in D".

Poor standard library, for example the threading library doesn't even begin to compare with D's or indeed parallel for loops in D. Currenly in Nim's standard library, the parallel for loop will seriously malfunction in a variety of ways for example, if you are trying to read/write to then same array (in different locations) - apparently there's no current fix for that apart from using another library (which kind of defeats the purpose of a standard library). I found the syntax a little tricky at first, which wasn't helped by the lack of documentation. Module items default to private but not as bad as Julia because you can export with a simple asterix next to the implementation.

On Monday, 21 September 2020 at 18:36:20 UTC, data pulverizer wrote:
> On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:
>> [...]
>
> From my experience:
>
> # Rust
>
> [...]

Great summary! I also actually tried Nim for some time and kind of liked it. But at the end of the day you need more than just nice syntax.

On Monday, 21 September 2020 at 17:20:41 UTC, Steven Schveighoffer wrote:
> On 9/21/20 7:04 AM, Imperatorn wrote:
>> Top reasons to use D instead of for example Rust, Julia, Go etc :)
>
> My list, in no particular order:
>
> 1. Metaprogramming
> 2. Using Metaprogramming to generate code
> 3. Using CTFE to generate Metaprogramming to generate code.
>
> -Steve

True, this is so nice to have. I would also say unittesting built in is a really powerful concept.

On Monday, 21 September 2020 at 18:36:20 UTC, data pulverizer wrote:
> On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:
Well explained. Thanks for your comments. Well, i would like to add a little more in the con section of Nim. Module management in Nim is really annoying. In D, i can import anything from any module at anywhere. But in Nim, circular module dependency is a hell. And yes, you are right in the case of Ali's book vs Nim docs. Ali's book is the only thing which brought me to D.

-Vinod Chandran

On Monday, 21 September 2020 at 18:36:20 UTC, data pulverizer wrote:
> Poor standard library, for example the threading library doesn't even begin to compare with D's or indeed parallel for loops in D. Currenly in Nim's standard library, the parallel for loop will seriously malfunction in a variety of ways for example, if you are trying to read/write to then same array (in different locations) -

Well we map '||' to the OpenPM standard which works well enough for most of the industry. Could have picked a more credible example about how bad our stdlib is.

On Monday, 21 September 2020 at 20:59:30 UTC, Araq wrote:
> On Monday, 21 September 2020 at 18:36:20 UTC, data pulverizer wrote:
>> Poor standard library, for example the threading library doesn't even begin to compare with D's or indeed parallel for loops in D. Currenly in Nim's standard library, the parallel for loop will seriously malfunction in a variety of ways for example, if you are trying to read/write to then same array (in different locations) -
>
> Well we map '||' to the OpenPM standard which works well enough for most of the industry. Could have picked a more credible example about how bad our stdlib is.

This comment is linked to this query in the Nim forums: https://forum.nim-lang.org/t/6317. D, Chapel, and Julia are able to carry out this calculation between their base and standard libraries.

I would have liked to include Nim in a benchmark I was doing for an article with the other three languages actually discussed the Nim forums: https://forum.nim-lang.org/t/6443#39740 but one of the requirements I set for the article is that only the standard libraries and base language could be used.

**As I said, I think Nim is a fantastic language**, but as a data scientist, there are certain things I expect from standard libraries in modern languages. One of them is being able to easily write and run code like the example threaded kernel matrix calculation using either elements from the base or standard library. That is pretty basic to me.

On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:
> Top reasons to use D instead of for example Rust, Julia, Go etc :)

My personal favourites to use D

1. Sane language (modules, dot operator, UFCS, etc niceties)
2. Uniform dot operator for member access - makes writing algorithms seamless. No need to worry about pointer vs reference/value. This is so underrated!!
3. Compile-time introspection for humans
4. Readable std lib
5. Truly multi-paradigm
6. Default thread local

On Monday, 21 September 2020 at 20:59:30 UTC, Araq wrote:
> On Monday, 21 September 2020 at 18:36:20 UTC, data pulverizer wrote:
>> Poor standard library, for example the threading library doesn't even begin to compare with D's or indeed parallel for loops in D. Currenly in Nim's standard library, the parallel for loop will seriously malfunction in a variety of ways for example, if you are trying to read/write to then same array (in different locations) -
>
> Well we map '||' to the OpenPM standard which works well enough for most of the industry. Could have picked a more credible example about how bad our stdlib is.

Nim is great, it just needs time to grow