www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D vs Rust

reply nbro <blah gfail.com> writes:
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.

Apart from this, what are the real advantages of D over Rust? 
They seem to be similar languages in what they want to achieve. 
Rust seems to be younger and the syntax seems to be slightly 
different from the C-like syntax. I am not such concerned or 
interested with the syntax advantages of a language over the 
other, but more about in general what one does better than the 
other. Overall, which one has a better design and a more 
promising future? Which one is more performant, in which 
situations? If you could answer all these questions it would be 
nice. I'm still deciding which one to learn and invest my time 
on, but I would like to have also your more experienced and 
expert opinion.
Jan 28
next sibling parent cym13 <cpicard openmailbox.org> writes:
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.

 Apart from this, what are the real advantages of D over Rust? 
 They seem to be similar languages in what they want to achieve. 
 Rust seems to be younger and the syntax seems to be slightly 
 different from the C-like syntax. I am not such concerned or 
 interested with the syntax advantages of a language over the 
 other, but more about in general what one does better than the 
 other. Overall, which one has a better design and a more 
 promising future? Which one is more performant, in which 
 situations? If you could answer all these questions it would be 
 nice. I'm still deciding which one to learn and invest my time 
 on, but I would like to have also your more experienced and 
 expert opinion.
I don't really think they are similar in what they want to achieve. Rust wanted to achieve a zero-cost memory-safe model. It almost did. I said almost because the cost is on the programmer's side: you have to go out of your way and learn new mechanics to use it. It may be a good thing to use but it is clear that it needs you to develop new skills. D on the other side wanted to be better than C++ but in the same way: if you like C++-style programming you'll be able to transfer those skills in D. If you like functionnal programming you can program in D. If you like java-style programming you can program in D. If you like C programming... well, you get the point. Of course there are things that will be different but porting a program from C doesn't imply rethinking the program: it's mostly some symbol substitutions. You won't have that with Rust. The other point is that metaprogramming is way better in D than in Rust. Maybe Rust will eventually get better at it, but right now D is the best IMHO. The last point is harder to explain... There is a D style, and that style is truely beautiful. I don't think it can really be explained, it has to be discovered, but no matter how much I try to learn something else I always find myself drown back to D. Just my two cents :-)
Jan 28
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 28 January 2016 at 22:30:51 UTC, nbro wrote:
 [snip]
Long discussion from last year: http://forum.dlang.org/thread/ckjukjfkgrguhfhkdhhj forum.dlang.org
Jan 28
prev sibling next sibling parent lobo <swamplobo gmail.com> writes:
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.

 Apart from this, what are the real advantages of D over Rust? 
 They seem to be similar languages in what they want to achieve. 
 Rust seems to be younger and the syntax seems to be slightly 
 different from the C-like syntax. I am not such concerned or 
 interested with the syntax advantages of a language over the 
 other, but more about in general what one does better than the 
 other. Overall, which one has a better design and a more 
 promising future? Which one is more performant, in which 
 situations? If you could answer all these questions it would be 
 nice. I'm still deciding which one to learn and invest my time 
 on, but I would like to have also your more experienced and 
 expert opinion.
Learn both. You will be a better programmer for it and will be in a position to make up your own mind which one *you* prefer. I come from a heavy C/C++/Java/Python background and for me productivity is paramount. Syntax is very important because it has an impact on my productivity. I find Rust syntax really annoying. Little things in D like UFCS and optional parens make a huge difference. Big things like D templates and compile time reflection power is so easy to tap into and use that it drives Rust into the ground. For me memory safety is not a problem. Yes it bites occasionally, but never enough that its worth giving up productivity everywhere else. bye, lobo
Jan 28
prev sibling next sibling parent reply Ola Foaheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 28 January 2016 at 22:30:51 UTC, nbro wrote:
 other. Overall, which one has a better design and a more 
 promising future?
The long term future is "uncertain" for both I think. D depends on two people and Rust depends on Mozilla. C++ has much much wider backing. Rust is very opinionated and you have to figure out for yourself if you want the constraints of linear typing, but the semantics are quite clean. D is closer to C++ style templating and OO, and currently focus on enabling binding to non-template C++ libraries. Rust has more developers behind it. I suggest you read Ali's online book and the online Rust tutorial to get a feel for both.
 Which one is more performant, in which situations?
D allows you to turn off boundschecks, which should make it faster. Currently safe programming in D involves the GC which is much easier, but less performant than Rusts linear typing. There are those that hope for a comparable non-GC solution for D this year, but no concrete description has emerged. Both languages have LLVM backends.
Jan 28
next sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
On Thursday, 28 January 2016 at 23:18:34 UTC, Ola Foaheim Grøstad 
wrote:
 D depends on two people
I disagree with this. Even if Walter Bright and Andrei Alexandrescu both suddenly decided to go join the Amish tomorrow, D would go on. Just because D development is currently *controlled* by two people doesn't mean that no one else is willing or able to replace them, if the need/opportunity arose.
Jan 28
next sibling parent Brad Anderson <eco gnuk.net> writes:
On Thursday, 28 January 2016 at 23:28:04 UTC, tsbockman wrote:
 On Thursday, 28 January 2016 at 23:18:34 UTC, Ola Foaheim 
 Grøstad wrote:
 D depends on two people
I disagree with this. Even if Walter Bright and Andrei Alexandrescu both suddenly decided to go join the Amish tomorrow, D would go on. Just because D development is currently *controlled* by two people doesn't mean that no one else is willing or able to replace them, if the need/opportunity arose.
Yeah, a few years ago D definitely had a Bus Factor of one but Walter (and Andrei) have successfully delegated and opened it up enough that if the worst should happen I think D could still move forward.
Jan 28
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 28 January 2016 at 23:28:04 UTC, tsbockman wrote:
 On Thursday, 28 January 2016 at 23:18:34 UTC, Ola Foaheim 
 Grøstad wrote:
 D depends on two people
I disagree with this. Even if Walter Bright and Andrei Alexandrescu both suddenly decided to go join the Amish tomorrow, D would go on. Just because D development is currently *controlled* by two people doesn't mean that no one else is willing or able to replace them, if the need/opportunity arose.
It is very difficult to predict what keeps online communities together after a crisis, or if they disband gradually, but Rust is just as vulnerable, if not more because of higher complexity. Who knows if Mozilla suddenly have to downsize? Same with Google's Dart. Or Nim. It is much easier to predict longterm if you reach critical mass like C++ and possibly Go.
Jan 28
parent tsbockman <thomas.bockman gmail.com> writes:
On Thursday, 28 January 2016 at 23:43:24 UTC, Ola Fosheim Grøstad 
wrote:
 It is very difficult to predict what keeps online communities 
 together after a crisis, or if they disband gradually, but Rust 
 is just as vulnerable, if not more because of higher 
 complexity. Who knows if Mozilla suddenly have to downsize? 
 Same with Google's Dart. Or Nim.

 It is much easier to predict longterm if you reach critical 
 mass like C++ and possibly Go.
True. That's why I only quoted the "depends on two people" part when I said that I disagree - because I don't disagree with the other part:
 The long term future is "uncertain" for both I think.
Jan 28
prev sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
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.
Jan 28
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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?
Jan 29
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
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.
Jan 29
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Jan 29
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/29/2016 12:26 AM, 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.
That's right. D can link to instantiated templates, and will duplicate the layout. But D will not implement C++ semantics, such as how C++ does overload resolution on templates.
Jan 30
prev sibling parent reply Kagamin <spam here.lot> writes:
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.
Jan 29
parent reply jmh530 <john.michael.hall gmail.com> writes:
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++?
Jan 29
parent Kagamin <spam here.lot> writes:
On Friday, 29 January 2016 at 17:50:04 UTC, jmh530 wrote:
 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++?
Support RAII: constructors, destructors and value semantics.
Jan 30
prev sibling next sibling parent Guillaume Piolat <name.lastname gmail.com> writes:
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.
 Apart from this, what are the real advantages of D over Rust?
In my uninformed opinion (I've not used Rust more than "hello world"). For D: - no strong feelings against D syntax, it's rare that people complain about it. Rust syntax is more controversial. This shouldn't matter, but it does. - D "duck-typed" meta-programming could well be more applicable than traits-based meta-programming. Need less names and complexity. - using "unsafe", Rust isn't particularly more memory-safe than the safe D subset. Which by and large native programmers don't even care that much. Top concerns with C++ would be compilation times or build complexity. D kills most memory safety concerns throught bounds check, slices or default initialization. - Rust error handling doesn't strike me as working at scale. We are already seeing "You should not do .unwrap() in a library" advices from Rust experts. Yet .unwrap() seems to creep everywhere which conflates input errors and logical bugs. - D has defaults that let you write ugly code. I think it's a positive. Why should you care about memory safety or immutability for a 50 line program? Cost vs benefit. You can always enforce later, but you don't get your time back. For Rust: - Rust has a simpler resource story. Using it is similar to using modern C++ correctly, hence the appeal for many C++ers who feel at home conceptually. - cargo is a bit friendlier than DUB, and less controversial in its community (which is imho generational, seeing like C++ package managers are even more controversial). Maybe the package manager / build tool is the primary interest of Rust and D over C++. - You can do composed RAII in D but using (GC + linear types) is more complex than using linear types. - D is a large language, not sure how much relatively to Rust. I've heard Rust is complicated too.
Jan 28
prev sibling next sibling parent Saurabh Das <saurabh.das gmail.com> writes:
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/
Jan 28
prev sibling next sibling parent reply qznc <qznc web.de> writes:
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).
Jan 29
parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Jan 29
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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?
Jan 29
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/29/2016 7:39 AM, bearophile wrote:
 [...]
Nice to see you back, bearophile!
Jan 29
next sibling parent JohnCK <j j.com> writes:
On Friday, 29 January 2016 at 18:43:19 UTC, Walter Bright wrote:
 On 1/29/2016 7:39 AM, bearophile wrote:
 [...]
Nice to see you back, bearophile!
I don't why but I thought that Bearophile and Ketmar were the same person. Anyway, is good to see he's coming back. JohnCK.
Jan 29
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Friday, 29 January 2016 at 18:43:19 UTC, Walter Bright wrote:
 On 1/29/2016 7:39 AM, bearophile wrote:
 [...]
Nice to see you back, bearophile!
Having not been around here much myself recently, I didn't even realize he was away, but ... agree :-)
Jan 29
prev sibling parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Friday, 29 January 2016 at 15:39:53 UTC, bearophile wrote:
 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
Hi bearophile. Welcome back. I haven't used Ocaml, but was intrigued by it after seeing Yaron Minsky's talks. To what extent can pattern matching, strong types with invariants and other things Ocaml features be implemented idiomatically in D? Eg I know D has invariants, but that seems to be more a debug mode thing, and I am not sure if they are doing the same as what Minsky described in his talk. Bloomberg seem to use it for front end stuff as they open sourced a Javascript back end for the Ocaml compiler (and that's not the only such back end). How productive do you find coding in Ada ?
Jan 30
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Laeeth Isharc:

On Saturday, 30 January 2016 at 16:51:09 UTC, Laeeth Isharc wrote:
 I haven't used Ocaml, but was intrigued by it after seeing 
 Yaron Minsky's talks.  To what extent can pattern matching, 
 strong types with invariants and other things Ocaml features be 
 implemented idiomatically in D?  Eg I know D has invariants, 
 but that seems to be more a debug mode thing, and I am not sure 
 if they are doing the same as what Minsky described in his talk.
Rust allows you to write very OCaML-like code, the main difference is that you need to memory manage manually (and Rust doesn't have a GIL). D Algebraic isn't very good, and the D/Phobos pattern matching is minimal, so to write compiler-like code in D you need a style quite different from the OcaML/F#/SML/Haskell code. On the other hand Rust is less flexible, sometimes even C-like for loops are not handy to do in Rust. The Servo browser and the Rustc compiler are two of the main projects written in Rust, so sometimes Rust looks like a browswer-driven language, and this means Rust developers sometimes seem to not understand or not care that lot of people have other different needs. There are several kinds of code that D allows you to write quite better than Rust (generic application code, script-like code, explorative scientific numerical code (like ndslice), medium-integrity code, metaprogramming, compile-time computations, template-level computations and specializations, higher order template magic, and so on. In general Rust seems a more specialized language).
 How productive do you find coding in Ada ?
In Ada you can be productive if you use it for the purposes it was invented for, but most times you don't write that kind of code. I miss some Ada features, and I've missed the strictness of the Ada compiler that catches lot of bugs, but for most things today I prefer a more modern languages. In Ada you need more time to write the code and make it run, but later you save some debugging time, even compared to D. I like languages that avoid me most common bugs, even if I need more time to write it. To write Ada code you need to remember lot of times, because Ada is a quite large language, but most things are quite logical and straightforward, so learning Ada is just a matter of having elephant's memory, you don't need to be smart. Rust is a much smaller language, but you need to think more about your code, otherwise it will never compile :-) D is more like Python, you don't need lot of memory to use it, and the garbage collector saves you lot of thinking (if you are writing small programs). I think D should relax and keep improving its strengths (like C++ interoperability), fix some of its holes (safety, GC-less programming, fixing its contract-driven programming experience, etc), improve its medium-integrity coding, and keep going on as usual, slowly getting better. The Rust and D niches are sufficiently different, there's minimal overlapping in their purposes and niches. Bye, bearophile
Jan 30
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/30/2016 12:48 PM, bearophile wrote:
 [...]
Thanks for writing this, you make a lot of points I wasn't aware of.
Jan 30
prev sibling next sibling parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
Guillaume Piolat
"- D is a large language, not sure how much relatively to Rust. 
I've heard Rust is complicated too."
and yet, it's easy to get started if you know C.  one can be 
quite quickly productive without having any experience of 
template metaprogramming, CTFE, and the like, and gradually 
absorb language features as you go.  Phobos is pretty readable, 
on the whole.  I agree with bearophile about GC making it easier 
in the beginning.

bearophile:
"I am sometimes able to write working D code almost as quickly as 
Python code"

Yes, indeed - that's my experience too.  I wonder what we could 
do to make this most of the time, if not almost always, and for 
less experienced programmers than you.  It wouldn't be surprising 
to find that the things that tend to get in the way fall in 
certain common categories.  Some people have applied machine 
learning to compilers to study this - that's probably beyond our 
resources for now, but the idea makes sense.  Adam's and others' 
work on error messages might be part of the answer.

Thank you for the colour on OcaML.  What could be done to improve 
Algebraic and pattern matching?  The talk at the London dmeetup 
was quite interesting, but I had the sense that was fairly 
experimental at this stage.

"There are several kinds of code that D allows you to write quite 
better than Rust (generic application code, script-like code, 
explorative scientific numerical code (like ndslice), 
medium-integrity code, metaprogramming, compile-time 
computations, template-level computations and specializations, 
higher order template magic, and so on. "

Should we make more of a feature of this in the intro page.  
Tutorials per category showing the value?  And should the Rosetta 
stone examples (many of which you wrote, as I understand it) be 
more prominently featured?  Maybe even in the code samples on the 
front page too.

"In Ada you can be productive if you use it for the purposes it 
was invented for, but most times you don't write that kind of 
code."
Thank you - yes that's what I figured, and it probably isn't for 
me.  But I wanted to see if I was missing something.

" I like languages that avoid me most common bugs,"
I wonder what the most common bugs and traps are in D.  P0nce's D 
idioms allude to some of them, but that isn't the focus of what 
he writes.

"I think D should relax and keep improving its strengths (like 
C++ interoperability), fix some of its holes (safety, GC-less 
programming, fixing its contract-driven programming experience, 
etc), improve its medium-integrity coding, and keep going on as 
usual, slowly getting better. The Rust and D niches are 
sufficiently different, there's minimal overlapping in their 
purposes and niches."

Yes - I completely agree.  As Peter Thiel says, competition is 
for losers.  Much better to have a monopoly that you have earned 
(and have to keep earning).  I agree with Knuth that language 
reflects thought and people intrinsically think differently (this 
also being shaped by the domain) - he welcomed the prospect of an 
expansion in the number and kinds of language available.

It's funny how the most negative critics in this forum and who 
make diffuse statements about how D has lost the race often don't 
seem to contribute much code to making things better.  Contrast 
with Manu, for example, who whilst spirited is actually through 
actually using the language and reporting concrete difficulties 
is directly driving the completion of some features.

Walter - sorry about that.  I need to get someone to help on that 
front as I have so little time.  Should work now.


Laeeth
Jan 31
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
On Sunday, 31 January 2016 at 15:44:37 UTC, Laeeth Isharc wrote:
 Guillaume Piolat
 "- D is a large language, not sure how much relatively to Rust. 
 I've heard Rust is complicated too."
 and yet, it's easy to get started if you know C.  one can be 
 quite quickly productive without having any experience of 
 template metaprogramming, CTFE, and the like, and gradually 
 absorb language features as you go.  Phobos is pretty readable, 
 on the whole.  I agree with bearophile about GC making it 
 easier in the beginning.

 bearophile:
 "I am sometimes able to write working D code almost as quickly 
 as Python code"

 Yes, indeed - that's my experience too.  I wonder what we could 
 do to make this most of the time, if not almost always, and for 
 less experienced programmers than you.  It wouldn't be 
 surprising to find that the things that tend to get in the way 
 fall in certain common categories.  Some people have applied 
 machine learning to compilers to study this - that's probably 
 beyond our resources for now, but the idea makes sense.  Adam's 
 and others' work on error messages might be part of the answer.

 Thank you for the colour on OcaML.  What could be done to 
 improve Algebraic and pattern matching?  The talk at the London 
 dmeetup was quite interesting, but I had the sense that was 
 fairly experimental at this stage.

 "There are several kinds of code that D allows you to write 
 quite better than Rust (generic application code, script-like 
 code, explorative scientific numerical code (like ndslice), 
 medium-integrity code, metaprogramming, compile-time 
 computations, template-level computations and specializations, 
 higher order template magic, and so on. "

 Should we make more of a feature of this in the intro page.  
 Tutorials per category showing the value?  And should the 
 Rosetta stone examples (many of which you wrote, as I 
 understand it) be more prominently featured?  Maybe even in the 
 code samples on the front page too.

 "In Ada you can be productive if you use it for the purposes it 
 was invented for, but most times you don't write that kind of 
 code."
 Thank you - yes that's what I figured, and it probably isn't 
 for me.  But I wanted to see if I was missing something.

 " I like languages that avoid me most common bugs,"
 I wonder what the most common bugs and traps are in D.  P0nce's 
 D idioms allude to some of them, but that isn't the focus of 
 what he writes.

 "I think D should relax and keep improving its strengths (like 
 C++ interoperability), fix some of its holes (safety, GC-less 
 programming, fixing its contract-driven programming experience, 
 etc), improve its medium-integrity coding, and keep going on as 
 usual, slowly getting better. The Rust and D niches are 
 sufficiently different, there's minimal overlapping in their 
 purposes and niches."

 Yes - I completely agree.  As Peter Thiel says, competition is 
 for losers.  Much better to have a monopoly that you have 
 earned (and have to keep earning).  I agree with Knuth that 
 language reflects thought and people intrinsically think 
 differently (this also being shaped by the domain) - he 
 welcomed the prospect of an expansion in the number and kinds 
 of language available.

 It's funny how the most negative critics in this forum and who 
 make diffuse statements about how D has lost the race often 
 don't seem to contribute much code to making things better.  
 Contrast with Manu, for example, who whilst spirited is 
 actually through actually using the language and reporting 
 concrete difficulties is directly driving the completion of 
 some features.

 Walter - sorry about that.  I need to get someone to help on 
 that front as I have so little time.  Should work now.


 Laeeth
Guillaume Piolat:
What could be done to improve Algebraic and pattern matching?<
The number of developers working on D compiler, D design and Phobos is limited, and D is a large language. So it's better to focus the developing work on fixing and finishing the unfinished parts of D, instead of adding new ways to do the same things. And even if you want new D features, there are more important things to think about, like GC-less coding, C++ interoperability, async/await, and so on.
I wonder what the most common bugs and traps are in D.<
You have to take care of the less common bugs too if you want a reliable language. And currently it's dead-easy to write unsafe code even in safe D functions: int[] foo() pure safe { int[2] a = [10, 20]; auto b = a[]; return b; } void main() {} Now that Rust is showing some "intellectual" competition with C++, Stroustrup is even starting to think about adding some memory safety to C++ (but it's hard for this to become a complete memory safety for C++): https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-cpp-core-guidelines Regarding the code reliability, D is better than C++11, but it can be further improved, as Ada2012/SPARK show. On the other hand, a higher reliability has a cost, and sometimes you don't want to pay it. Every language has to find its balance between many different design goals and desires. Bye, bearophile
Jan 31
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 31 January 2016 at 16:18:21 UTC, bearophile wrote:
 Regarding the code reliability, D is better than C++11
That's a bold claim. What do you mean by "code reliability"? You get as strong typing as you want with C++. (And no, Laeeth, the fact that Manu has a nice boss that allows him to use an unfinished product in production is not a good reason for other people to do so. Try to be reasonable, just try...)
Jan 31
parent reply Xinok <xinok live.com> writes:
On Sunday, 31 January 2016 at 16:30:47 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 31 January 2016 at 16:18:21 UTC, bearophile wrote:
 Regarding the code reliability, D is better than C++11
That's a bold claim. What do you mean by "code reliability"? You get as strong typing as you want with C++. (And no, Laeeth, the fact that Manu has a nice boss that allows him to use an unfinished product in production is not a good reason for other people to do so. Try to be reasonable, just try...)
He likely means that, in general, D code has fewer bugs than C++11 code. There are numerous reasons for this but I'll just give a few examples: * Certain types of implicit casts are not allowed in D where the original value may be lost, e.g. int to short. * Functions MUST return a value in D or at least throw an error. * D has far less "undefined behavior" than C++. * safe, pure, transitive const/immutable, thread-local by default, etc. This and much more makes D far more "reliable" than C++.
Jan 31
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 31 January 2016 at 18:32:12 UTC, Xinok wrote:
 He likely means that, in general, D code has fewer bugs than 
 C++11 code.
Which is a questionable claim. If we are going to compare we have to compare performance vs proficiency vs risk of making mistake vs tooling vs X factors. You certainly can write very high risk code in both C++ and D trying to get the highest possible performance.
 * Certain types of implicit casts are not allowed in D where 
 the original value may be lost, e.g. int to short.
Except D has modular arithmetics for integers and a very heavy handed cast operator. In my own C++ code I use a cast function that asserts value ranges in debug builds. So no, I am not accepting this.
 * Functions MUST return a value in D or at least throw an error.
?
 * D has far less "undefined behavior" than C++.
And static analysis tooling that reports on some of it, but I have never actually experienced any problems related to "undefined behaviour" in my own code.
 * safe, pure, transitive const/immutable, thread-local by 
 default, etc.
Thread local globals may or may not cause bugs. Depends on what you expect, but it is primarily a syntax issue. Pure does not effect reliability. Transitive const may offer some better reliability, except in the situations where you can't use it because you need head const. Which is what I usually need...
 This and much more makes D far more "reliable" than C++.
No, it does not make D anything in particular. It is just a claim. Having a GC makes D more reliable, but we can make a similar list for D without GC vs C++, or C++ with a boehm collector and static analyzers vs D. The problem is most C++ projects are not suitable for a GC. I only know of one FOSS project that use a GC with C++: Inkscape.
Jan 31
prev sibling next sibling parent Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
Thanks, bearophile.
Jan 31
prev sibling parent reply xenon325 <anm programmer.net> writes:
On Sunday, 31 January 2016 at 16:18:21 UTC, bearophile wrote:
 And currently it's dead-easy to write unsafe code even in  safe 
 D functions:

 int[] foo() pure  safe {
     int[2] a = [10, 20];
     auto b = a[];
     return b;
 }
 void main() {}
Doesn't http://wiki.dlang.org/DIP25 fix this ?
Jan 31
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
xenon325:

 Doesn't http://wiki.dlang.org/DIP25 fix this ?
I think DIP25 is designed to be only a partial solution, it's not a complete memory safety story. Bye, bearophile
Feb 01
prev sibling parent Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Monday, 1 February 2016 at 07:13:32 UTC, xenon325 wrote:
 On Sunday, 31 January 2016 at 16:18:21 UTC, bearophile wrote:
 And currently it's dead-easy to write unsafe code even in 
  safe D functions:

 int[] foo() pure  safe {
     int[2] a = [10, 20];
     auto b = a[];
     return b;
 }
 void main() {}
Doesn't http://wiki.dlang.org/DIP25 fix this ?
No, it only works for `ref`.
Feb 01
prev sibling next sibling parent Chris Wright <dhasenan gmail.com> writes:
On Sun, 31 Jan 2016 15:44:37 +0000, Laeeth Isharc wrote:
 bearophile:
 "I am sometimes able to write working D code almost as quickly as Python
 code"
 
 Yes, indeed - that's my experience too.  I wonder what we could do to
 make this most of the time, if not almost always, and for less
 experienced programmers than you.
Google's internal recommendations used to be: use Python when your project is going to stay small, use Java or C++ otherwise. Their recent recommendations are the same, but with the note that projects do not stay small. I feel like D catches up in productivity (purely from a language and tools standpoint, not from a library standpoint) within the first hundred lines of code. The only things I use python for these days are its REPL (which is a pretty nice calculator) and pretty-printing JSON.
Jan 31
prev sibling parent Joakim <dlang joakim.fea.st> writes:
On Sunday, 31 January 2016 at 15:44:37 UTC, Laeeth Isharc wrote:
 Walter - sorry about that.  I need to get someone to help on 
 that front as I have so little time.  Should work now.
Still happening, had three email replies returned this weekend.
Jan 31
prev sibling parent reply gour <gour atmarama.com> writes:
On Saturday, 30 January 2016 at 20:48:01 UTC, bearophile wrote:

Hello bearophile,

 In Ada you can be productive if you use it for the purposes it 
 was invented for, but most times you don't write that kind of 
 code.

 I miss some Ada features, and I've missed the strictness of the 
 Ada compiler that catches lot of bugs, but for most things 
 today I prefer a more modern languages.
For quite some time I was looking at Ada as potential language to write multi-platform desktop application, but, being the big language which requires lot of time and energy to invest into learning/mastering it, I, somehow, feel reluctant seeing that there is practically no open-source community around Ada, no truly open-source compile -- what would happen if AdaCore would simply pull the plug since I do not believe there are enough people capable to maintain/develop FSF GNAT, so I'd appreciate if you can write few words about Ada vs D hoping that the latter it one you are recommending for new (gui) projects? I simply hope that D can provide me with most/all the features I'd expect from the language like Ada, but but even more modern features, more choices when it comes to developing GUI desktop app, more compiler choices, better tooling and, of course, much bigger community of open-source enthusiasts. Sincerely, Gour
Mar 13
parent reply bearophile <bearophileHUGS lycos.com> writes:
gour:

 For quite some time I was looking at Ada as potential language 
 to write multi-platform desktop application, but, being the big 
 language which requires lot of time and energy to invest into 
 learning/mastering it, I, somehow, feel reluctant seeing that 
 there is practically no open-source community around Ada, no 
 truly open-source compile -- what would happen if AdaCore would 
 simply pull the plug since I do not believe there are enough
 people capable to maintain/develop FSF GNAT, so I'd appreciate 
 if you can write few words about Ada vs D hoping that the 
 latter it one you are recommending for new (gui) projects?

 I simply hope that D can provide me with most/all the features 
 I'd expect from the language like Ada, but but even more modern 
 features, more choices when it comes to developing GUI desktop 
 app, more compiler choices, better tooling and, of course, much 
 bigger community of open-source enthusiasts.
Ada language has several nice features worth stealing (I'd like both D and Rust to add constrained values, static preconditions, ranged subtypes, and annotations to control access to global variables), and if you're writing a train control system, a space probe/satellite, a military machine control, a hardware-constrained device that needs to be very reliable (like a medical machine working inside the body) then using Ada/SPARK could be reasonable. But for an average multi-platform desktop application Ada is not a good idea. The main problem is not the language itself (that is very verbose, but that's not a show-stopper), but the tooling (very scarce, and very pricey, very few compilers, very few IDEs, etc), the community (small), and the libraries (not many). A sufficiently rich and sufficiently determined group of programmers could probably write a regular desktop application in Ada, but you're walking uphill for not enough reason. Sometimes worse is better because it's actually overall better. There is a recent thread about Ada on Reddit, but unfortunately the best comment in that page has being deleted... :-) https://www.reddit.com/r/programming/comments/49y7sc/11_myths_about_ada/ Bye, bearophile
Mar 14
parent =?utf-8?B?U2HFoWEgSmFuacWha2E=?= <gour atmarama.com> writes:
bearophile <bearophileHUGS lycos.com> writes:


Hello bearophile,

and thank you very much for your insightful reply!

 But for an average multi-platform desktop application Ada is not a
 good idea. The main problem is not the language itself (that is very
 verbose, but that's not a show-stopper), but the tooling (very scarce,
 and very pricey, very few compilers, very few IDEs, etc), the
 community (small), and the libraries (not many). A sufficiently rich
 and sufficiently determined group of programmers could probably write
 a regular desktop application in Ada, but you're walking uphill for
 not enough reason. Sometimes worse is better because it's actually
 overall better.
Very useful info and I've arrived to the same conclusion.
 There is a recent thread about Ada on Reddit, but unfortunately the
 best comment in that page has being deleted... :-)
I was reading it several times and possibly noticed it, but now it does not matter since I consider myself as D user. ;) Sincerely, Gour -- Bewildered by the modes of material nature, the ignorant fully engage themselves in material activities and become attached. But the wise should not unsettle them, although these duties are inferior due to the performers' lack of knowledge.
Mar 15
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
BTW, your email server is rejecting my emails to you!
Jan 30
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 31/01/16 6:00 PM, Walter Bright wrote:
 BTW, your email server is rejecting my emails to you!
Worse case scenario for Laeeth contact via LinkedIn.
Jan 30
prev sibling parent Dsby <dushibaiyu yahoo.com> writes:
On Thursday, 28 January 2016 at 22:30:51 UTC, nbro wrote:
 [...]
I retransmission this post in rust's user-forum. It is url: https://users.rust-lang.org/t/rust-vs-dlang-i-want-more-experienced/4472 there have more point.
Jan 30