6 ms·

I would have liked to hear more about what exactly made D so great -- reading through it it's kind of vague. He mentions generics and finally getting LLVM suppo

I would have liked to hear more about what exactly made D so great -- reading through it it's kind of vague. He mentions generics and finally getting LLVM support working as a target, and being able to use D at a high and low-level but I don't see anything here that's groundbreaking. Could someone who uses D Hate to be that guy, but if you could compare it with rust that would be double A++ good... I know the targets are somewhat different but I find that I can write high level rust and low level rust. Also, I get the feeling that you could very easily have used Go for the same purposes (D was around long before Go IIRC so maybe it was just not being present).

sargun 8y ago
One of the nice aspects of D is that it interfaces with C++ really nicely. I'm not overly familiar with how Rust handles this, as the last time I tried to glue together Rust and C++ was more than a year ago, and the tooling was in evolution. From Go / CGo, it can be pretty scary to interface with native C++ code, and it requires lots of annoying boilerplate.
- WalterBright 8y ago
  "C++ has a very complex ABI, and the Rust ABI is not frozen. However, both C++ and Rust support functions that use the C ABI. Therefore, interoperability between C++ and Rust involves writing things in such a way that C++ sees Rust code as C code and Rust sees C++ code as C code." https://hsivonen.fi/modern-cpp-in-rust/ https://hsivonen.fi/modern-cpp-in-rust/
  - hardwaresofton 8y ago
    Context: this poster is likely Walter Bright the creator and first implementer of D lang itself. Cool to know you also read that article about C++ in rust (I personally read a little bit then left because trying to interface with C++ from rust wasn't a problem I had), but I guess it's obvious that you would.
    - WalterBright 8y ago
      > is likely Probably 100%
- arunc 8y ago
  I've written wrappers for C++ libraries to work with D and it's _very_ easy. To work with C++ classes in D, I created factory methods that created/destroyed them with C ABI and used/disposed them respectively. Working with C is even more easier. There is no FFI, etc. Just use Dstep[1] and get going. Or use dpp[2]. [1] https://github.com/jacob-carlborg/dstep https://github.com/jacob-carlborg/dstep [2] https://github.com/atilaneves/dpp https://github.com/atilaneves/dpp
  - WalterBright 8y ago
    Up until quite recently, while the front end of D was written in D, the back end was in C++ (more precisely, C with classes, as it is fairly auld skool). It's now finally pretty much all in D, and I've been piece by piece refactoring it into more idiomatic D.
WalterBright 8y ago
My experience, which of course is anecdotal, is that the advantage is it's easy to change the algorithms and data structures. I've maintained C and C++ code bases for decades, and I've found that the first algorithm I tried has stayed there in the code. It gets tweaked, optimized, refactored, but it's the same algorithm and data structure. With D, when I developed the Warp preprocessor, https://github.com/facebookarchive/warp https://github.com/facebookarchive/warp I continually tried different algorithms & data structures to see which was faster. One reason it's easier is that in C/C++ the . is used for value field access, while -> for pointer field access. In D, . is used for both. So you can easily switch between a value and a pointer to the value by changing little code.
- arunc 8y ago
  > In D, . is used for both This is an absolute pleasure to work with. Turtles (.) all the way down (pointers, values, modules, etc)!
- Mindwipe 8y ago
  Thanks, this was a good explanation of where the likely benefits originate for the use case in the OP!
- sanxiyn 8y ago
  > In D, . is used for both. Yes, this is a great feature. Rust also does this, and I attribute substantial portion of ease of refactoring Rust to this feature.
  - stochastic_monk 8y ago
    Oddly enough, so does Cython.
- torstenvl 8y ago
  That would be nice. I wonder if C would ever consider adding that. Types are tracked by the compiler so it doesn't seem theoretically impossible.
- sdegutis 8y ago
yvdriess 8y ago
D feels much more like a 'sane' C successor, dropped from a parallel dimension where C++ could evolve without caring much about breaking its legacy code running the world. It has a few warts, some D v1 leftovers, but overall feels much more coherent than modern C++; even as the latter has grown much closer to D by piling more on top of its templating system. What I personally found the stand out feature of D to be, is its compile-time template/macro system. D was designed by a compiler builder, and it shows. Its compile-time meta-programming (generics/templates) was built on compiler reflection, whereas C++ did it by abusing template instantiation. I bet every modern C++ programmer that writes his first "if __traits(compiles, S.s1) ..." gets a huge grin on his face, remembering the C++ SNIFAE abuse needed. A crude analogy would be working with Lisp macros after years of C preprocessor hacking. In short, I would recommend D for projects where you want better rapid prototyping and feature turn-around than C++, but the end result needs still to be C-style speed.
- skocznymroczny 8y ago
  I like D, but I'd draw different conclusions. D 1.0 was kind of like a "native C#" for me - a language that combines performance, pointers, direct access and ease of garbage collection, batteries included standard library. I loved it. D 2.0 though, I have more mixed feelings about. It's trying to be a better C++, but in an effort to woo C++ programmers it's slowly becoming C++ itself. D's curse and blessing is that it tries to cover all bases. Safe programming? Kind of supported. OOP programming? Kind of supported. Functional programming? Kind of supported. GC? Kind of supported. No GC? Kind of supported. Everything is supported to some extent, but it takes some effort to learn what exactly is supported in which subset, what language features don't interact well with each other. It's a big boost for expert D programmers, but for less expert ones it's a lot of mental overhead to worry about.
  - arunc 8y ago
    If a function is pure, it is automatically inferred by the compiler and it will be marked for purity (sorry for the lack of words). We don't have to annotate with pure attribute. Also D offers the right balance of functional programming that I can think of. Can you elaborate on what's missing from that point?
nimmer 8y ago
Here's a comparison with Nim. In my experience Nim is one of the fastest both in terms of execution and compile time. https://github.com/timotheecour/D_vs_nim https://github.com/timotheecour/D_vs_nim
- Symmetry 8y ago
  I see a lot of comparisons between unlike languages (Go and Rust for example) but it looks like D and Nim really are competing for the same niche.
  - pjmlp 8y ago
    And C# as well, via AOT compilation and the memory management improvements in 7.x versions.
giancarlostoro 8y ago
D is a work of love by WalterBright and the community. I like to think of D as a true successor to C++ when people compare Go to a C++ alternative. It is between Rust and Go but it doesnt do away with Object Oriented programming or the many paradigmns that exist for different programming approaches. I usually tell people if you can grasp C, C++, C# or Java you are going to understand plenty of Go. Rust has a larger learning curve, Go gains plenty of traction over this simple fact. You hear it often enough "I wanted to learn Rust but Go was simpler to get into" but if those same people gave D a shot they might never look back. D is best understood once you start hacking away at D code because you will appreciate the beauty in D. Different people love different things about it. I love that it is compiled and dont get phased by the optional GC, it doesnt stop Java, C#, or Go from being awesome...
- skocznymroczny 8y ago
  I think the optional part might have a bit to do with it. In Java, C#, Go you are 'stuck' with the garbage collector, so people learned to live with it and usually realized it's not as bad as people claim it to be.
  - giancarlostoro 8y ago
    There's a few other subtle things I like about D too, like the constructor[0] for a class is just this() {} instead of SuperLongClassNameFactoryShopPlaceThing () {} so instead of being redundant with typing, you realize the constructor can just have a much more obvious name such as "this", I know Python has __init__ and the @classmethod decorator for the case where you have to 'overload' the constructor. There's also 'auto' which is similar to 'var' in C#. If you are instantiating a class, why the hell do you need to write it twice, shouldn't the compiler know already the second you invoke the class constructor that your variable will be of that type? So 'auto' is nice too. These are seemingly minor things, but being a programmer who loves programming and programming languages I appreciate language aesthetics / syntatic sugar. Also parallel compilation is my absolute favorite. When I found that compiler flag and used it I was amazed at how fast code compiles with the D compiler. [0]: https://dlang.org/spec/class.html#constructors https://dlang.org/spec/class.html#constructors
p0nce 8y ago
> I would have liked to hear more about what exactly made D so great This WIP article explains very well the USP of D: http://erdani.com/hopl2020-draft.pdf http://erdani.com/hopl2020-draft.pdf (section 3) This article highlight the value of "design-by-introspection" applied to a particular problem space: https://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/ https://blog.thecybershadow.net/2014/03/21/functional-image-... This talk present a concrete example of such: https://www.youtube.com/watch?v=LIb3L4vKZ7U https://www.youtube.com/watch?v=LIb3L4vKZ7U (mind bending stuff) You might not understand what is new about it, but soon your competitors will understand it.
nine_k 8y ago
It would be great if someone knowledgeable compared these contenders for about the same space "close to metal": * Rust; * D; * Ada/Spark; * Zig; using C and C++ as reference points. (I also wonder if ATS-lang is used by anyone in practice; it seems to be targeted approximately at the same space.)
faissaloo 8y ago
Its reflection capabilities are as powerful aa Java if not more so and you can avoid doing so much at runtime using pure functions and templating.

sargun 8y ago

One of the nice aspects of D is that it interfaces with C++ really nicely. I'm not overly familiar with how Rust handles this, as the last time I tried to glue together Rust and C++ was more than a year ago, and the tooling was in evolution. From Go / CGo, it can be pretty scary to interface with native C++ code, and it requires lots of annoying boilerplate.

WalterBright 8y ago
"C++ has a very complex ABI, and the Rust ABI is not frozen. However, both C++ and Rust support functions that use the C ABI. Therefore, interoperability between C++ and Rust involves writing things in such a way that C++ sees Rust code as C code and Rust sees C++ code as C code." https://hsivonen.fi/modern-cpp-in-rust/ https://hsivonen.fi/modern-cpp-in-rust/
- hardwaresofton 8y ago
  Context: this poster is likely Walter Bright the creator and first implementer of D lang itself. Cool to know you also read that article about C++ in rust (I personally read a little bit then left because trying to interface with C++ from rust wasn't a problem I had), but I guess it's obvious that you would.
  - WalterBright 8y ago
    > is likely Probably 100%
arunc 8y ago
I've written wrappers for C++ libraries to work with D and it's _very_ easy. To work with C++ classes in D, I created factory methods that created/destroyed them with C ABI and used/disposed them respectively. Working with C is even more easier. There is no FFI, etc. Just use Dstep[1] and get going. Or use dpp[2]. [1] https://github.com/jacob-carlborg/dstep https://github.com/jacob-carlborg/dstep [2] https://github.com/atilaneves/dpp https://github.com/atilaneves/dpp
- WalterBright 8y ago
  Up until quite recently, while the front end of D was written in D, the back end was in C++ (more precisely, C with classes, as it is fairly auld skool). It's now finally pretty much all in D, and I've been piece by piece refactoring it into more idiomatic D.

WalterBright 8y ago

My experience, which of course is anecdotal, is that the advantage is it's easy to change the algorithms and data structures. I've maintained C and C++ code bases for decades, and I've found that the first algorithm I tried has stayed there in the code. It gets tweaked, optimized, refactored, but it's the same algorithm and data structure. With D, when I developed the Warp preprocessor, https://github.com/facebookarchive/warp https://github.com/facebookarchive/warp I continually tried different algorithms & data structures to see which was faster. One reason it's easier is that in C/C++ the . is used for value field access, while -> for pointer field access. In D, . is used for both. So you can easily switch between a value and a pointer to the value by changing little code.

arunc 8y ago
> In D, . is used for both This is an absolute pleasure to work with. Turtles (.) all the way down (pointers, values, modules, etc)!
Mindwipe 8y ago
Thanks, this was a good explanation of where the likely benefits originate for the use case in the OP!
sanxiyn 8y ago
> In D, . is used for both. Yes, this is a great feature. Rust also does this, and I attribute substantial portion of ease of refactoring Rust to this feature.
- stochastic_monk 8y ago
  Oddly enough, so does Cython.
torstenvl 8y ago
That would be nice. I wonder if C would ever consider adding that. Types are tracked by the compiler so it doesn't seem theoretically impossible.
sdegutis 8y ago

yvdriess 8y ago

D feels much more like a 'sane' C successor, dropped from a parallel dimension where C++ could evolve without caring much about breaking its legacy code running the world. It has a few warts, some D v1 leftovers, but overall feels much more coherent than modern C++; even as the latter has grown much closer to D by piling more on top of its templating system. What I personally found the stand out feature of D to be, is its compile-time template/macro system. D was designed by a compiler builder, and it shows. Its compile-time meta-programming (generics/templates) was built on compiler reflection, whereas C++ did it by abusing template instantiation. I bet every modern C++ programmer that writes his first "if __traits(compiles, S.s1) ..." gets a huge grin on his face, remembering the C++ SNIFAE abuse needed. A crude analogy would be working with Lisp macros after years of C preprocessor hacking. In short, I would recommend D for projects where you want better rapid prototyping and feature turn-around than C++, but the end result needs still to be C-style speed.

skocznymroczny 8y ago
I like D, but I'd draw different conclusions. D 1.0 was kind of like a "native C#" for me - a language that combines performance, pointers, direct access and ease of garbage collection, batteries included standard library. I loved it. D 2.0 though, I have more mixed feelings about. It's trying to be a better C++, but in an effort to woo C++ programmers it's slowly becoming C++ itself. D's curse and blessing is that it tries to cover all bases. Safe programming? Kind of supported. OOP programming? Kind of supported. Functional programming? Kind of supported. GC? Kind of supported. No GC? Kind of supported. Everything is supported to some extent, but it takes some effort to learn what exactly is supported in which subset, what language features don't interact well with each other. It's a big boost for expert D programmers, but for less expert ones it's a lot of mental overhead to worry about.
- arunc 8y ago
  If a function is pure, it is automatically inferred by the compiler and it will be marked for purity (sorry for the lack of words). We don't have to annotate with pure attribute. Also D offers the right balance of functional programming that I can think of. Can you elaborate on what's missing from that point?

nimmer 8y ago

Here's a comparison with Nim. In my experience Nim is one of the fastest both in terms of execution and compile time. https://github.com/timotheecour/D_vs_nim https://github.com/timotheecour/D_vs_nim

Symmetry 8y ago
I see a lot of comparisons between unlike languages (Go and Rust for example) but it looks like D and Nim really are competing for the same niche.
- pjmlp 8y ago
  And C# as well, via AOT compilation and the memory management improvements in 7.x versions.

giancarlostoro 8y ago

D is a work of love by WalterBright and the community. I like to think of D as a true successor to C++ when people compare Go to a C++ alternative. It is between Rust and Go but it doesnt do away with Object Oriented programming or the many paradigmns that exist for different programming approaches. I usually tell people if you can grasp C, C++, C# or Java you are going to understand plenty of Go. Rust has a larger learning curve, Go gains plenty of traction over this simple fact. You hear it often enough "I wanted to learn Rust but Go was simpler to get into" but if those same people gave D a shot they might never look back. D is best understood once you start hacking away at D code because you will appreciate the beauty in D. Different people love different things about it. I love that it is compiled and dont get phased by the optional GC, it doesnt stop Java, C#, or Go from being awesome...

skocznymroczny 8y ago
I think the optional part might have a bit to do with it. In Java, C#, Go you are 'stuck' with the garbage collector, so people learned to live with it and usually realized it's not as bad as people claim it to be.
- giancarlostoro 8y ago
  There's a few other subtle things I like about D too, like the constructor[0] for a class is just this() {} instead of SuperLongClassNameFactoryShopPlaceThing () {} so instead of being redundant with typing, you realize the constructor can just have a much more obvious name such as "this", I know Python has __init__ and the @classmethod decorator for the case where you have to 'overload' the constructor. There's also 'auto' which is similar to 'var' in C#. If you are instantiating a class, why the hell do you need to write it twice, shouldn't the compiler know already the second you invoke the class constructor that your variable will be of that type? So 'auto' is nice too. These are seemingly minor things, but being a programmer who loves programming and programming languages I appreciate language aesthetics / syntatic sugar. Also parallel compilation is my absolute favorite. When I found that compiler flag and used it I was amazed at how fast code compiles with the D compiler. [0]: https://dlang.org/spec/class.html#constructors https://dlang.org/spec/class.html#constructors

p0nce 8y ago

> I would have liked to hear more about what exactly made D so great This WIP article explains very well the USP of D: http://erdani.com/hopl2020-draft.pdf http://erdani.com/hopl2020-draft.pdf (section 3) This article highlight the value of "design-by-introspection" applied to a particular problem space: https://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/ https://blog.thecybershadow.net/2014/03/21/functional-image-... This talk present a concrete example of such: https://www.youtube.com/watch?v=LIb3L4vKZ7U https://www.youtube.com/watch?v=LIb3L4vKZ7U (mind bending stuff) You might not understand what is new about it, but soon your competitors will understand it.

nine_k 8y ago

It would be great if someone knowledgeable compared these contenders for about the same space "close to metal": * Rust; * D; * Ada/Spark; * Zig; using C and C++ as reference points. (I also wonder if ATS-lang is used by anyone in practice; it seems to be targeted approximately at the same space.)

faissaloo 8y ago

Its reflection capabilities are as powerful aa Java if not more so and you can avoid doing so much at runtime using pure functions and templating.