January 29, 2016
On Thursday, 28 January 2016 at 22:30:51 UTC, nbro wrote:
> I have loved C++ when I first started learning it a pair of years ago (then I stopped for some time for some work reasons), and quite recently I have discovered D, which seems apparently a better language from the design point of view, especially in supporting OO design and modularisation, maybe I am just wrong since I know just a little of D so far, but I really had some problems just in setting up a simple OO project, i.e. importing classes, there are .h and .cpp files, etc, which only make everything confusing and make you learn stupid things instead of being productive. D also seems to have a cleaner syntax in general. C++ is becoming more and more a mess because they keep introducing new functionalities to make C++ compete with new languages, and I'm starting hating it. Languages should not just be powerful but simple enough to be productive.
>
> [...]

This article on Quora is illuminating: https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Andrei-Alexandrescu

The Reddit thread from which I had come across the above article: https://www.reddit.com/r/programming/comments/3sa6lf/d_has_no_vision_go_is_out_of_its_depth_rust/

January 29, 2016
Am 29.01.2016 um 00:18 schrieb Ola Foaheim Grøstad:
> D is closer to C++ style templating and OO, and currently focus
> on enabling binding to non-template C++ libraries.

Small correction: Should be "binding to template based C++ libraries" - non-template libraries have worked more or less for a while now.

January 29, 2016
On Friday, 29 January 2016 at 07:01:07 UTC, Sönke Ludwig wrote:
> Am 29.01.2016 um 00:18 schrieb Ola Foaheim Grøstad:
>> D is closer to C++ style templating and OO, and currently focus
>> on enabling binding to non-template C++ libraries.
>
> Small correction: Should be "binding to template based C++ libraries" - non-template libraries have worked more or less for a while now.

I was thinking of Walter's work on supporting C++ exceptions as completing the effort to bind to non-templated libraries; exceptions being the "return value" for failure.

Is there an effort to support templated libraries? They are often fully inlined and header-only?

January 29, 2016
On Friday, 29 January 2016 at 08:23:38 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 29 January 2016 at 07:01:07 UTC, Sönke Ludwig wrote:
>> Am 29.01.2016 um 00:18 schrieb Ola Foaheim Grøstad:
>>> D is closer to C++ style templating and OO, and currently focus
>>> on enabling binding to non-template C++ libraries.
>>
>> Small correction: Should be "binding to template based C++ libraries" - non-template libraries have worked more or less for a while now.
>
> I was thinking of Walter's work on supporting C++ exceptions as completing the effort to bind to non-templated libraries; exceptions being the "return value" for failure.
>
> Is there an effort to support templated libraries? They are often fully inlined and header-only?

It depends what you mean by templated. I believe the interoperability work is for the results of instantiated templates, not on the templates themselves.
January 29, 2016
On Friday, 29 January 2016 at 08:26:01 UTC, John Colvin wrote:
> It depends what you mean by templated. I believe the interoperability work is for the results of instantiated templates, not on the templates themselves.

Hmm, not sure how important that is. At least in my C++ class templates most member functions tend to be inline, so they shouldn't end up in an object file.

January 29, 2016
On Thursday, 28 January 2016 at 22:30:51 UTC, nbro wrote:
> Apart from [syntax], what are the real advantages of D over Rust?

D is a broader language and is applicable in more situations.

In many cases you don't care and don't want to care about memory management. Use D and its garbage collector and be done with it. Rust forces you to think about memory management all the time, because it type checks life times. If you hit some performance wall during development, then Ds toolbox allows you to work around the GC in specific places. So, convenience first and performance where necessary. No premature optimization.

If you need more programmers, D is easier to learn, due to its syntax. Simple C, Java and even C++ programs can be very directly ported to D. For example, the D compiler frontend was converted from C++ to D algorithmically. This does not work with Rust, where the type checker will complain a lot.

D is more mature than Rust at the moment. Less backwards incompatible changes. More reliability and stability.

D has three different backends with different strengths. With dmd you have really fast compilation, which is great for development. With the LLVM and GCC backends you get better performance for release builds. With GCC you can compile for many architectures (although you might need to port the runtime).
January 29, 2016
On Friday, 29 January 2016 at 07:01:07 UTC, Sönke Ludwig wrote:
> Small correction: Should be "binding to template based C++ libraries" - non-template libraries have worked more or less for a while now.

Actually less. Without RAII you can't bind any realistic C++ library like Qt.
January 29, 2016
qznc:

On Friday, 29 January 2016 at 09:00:52 UTC, qznc wrote:
> D is a broader language and is applicable in more situations.
> In many cases you don't care and don't want to care about memory management.

Learning to manage memory in Rust takes lot of time and practice, it's a bit painful. I am sometimes able to write working D code almost as quickly as Python code, but writing similar code in Rust takes me much more time.

So I think for both small script-like programs, and general application code (where code safety is not the most important thing), D wins over Rust.

D is also more flexible (higher order templates, better CTFE, unrestricted UFCS, etc), and you can port Python or C code to D faster than to Rust.

So I think Rust targets a smaller number of coding purposes compared to D. Rust could also replace the code you want to write in OcaML, like compiler-like programs (thanks to Rust enums and pattern matching).

Safety and correctness of the code are very important for me. Regarding safety & correctness I think there's this ordering:

Rust > D > C++14 > C

If you talk about correctness you think about Ada too. Rust code seems usually more succinct compared to Ada code. Ada is more mature and it has lot of small features missing from Rust/D, that help make the code more correct (like integer subsets, static invariants, stronger typing for array indexing, SPARK annotations to manage global mutables safely, and so on). I don't know if such safety features will be added to Rust, I am dubious.

In the C/Ada world you have language subsets like MISRA/SPARK that people use in high integrity system. I think Rust still lacks something like that.

Bye,
bearophile
January 29, 2016
On Friday, 29 January 2016 at 12:05:08 UTC, Kagamin wrote:
>
> Actually less. Without RAII you can't bind any realistic C++ library like Qt.

My understanding is that D has a lot of options for behavior similar to RAII, but it does not have the full capability. What would be the most important thing for D to change to improve the experience of binding to C++?
January 29, 2016
On Friday, 29 January 2016 at 15:39:53 UTC, bearophile wrote:
> D is also more flexible (higher order templates, better CTFE, unrestricted UFCS, etc), and you can port Python or C code to D faster than to Rust.
>
> So I think Rust targets a smaller number of coding purposes compared to D.

Which purposes and why?