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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 

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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
prev sibling next sibling parent Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
Thanks, bearophile.
Jan 31 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
next sibling 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 2016
prev sibling parent reply Eljay <eljay.adobe gmail.com> writes:
I work on a large multi-platform desktop shrink-wrap application. 
  It is a large application, with a code base of over 400,000 
files.  The majority of which is C++, although there is some 
JavaScript in the mix in some of the corners of the UI.  The code 
base is about 30 years old... so you probably can imagine that 
the code has room for improvement.

For an existing project of that size, it makes no sense to try to 
throw it out and start over.  That would be recklessly 
ill-advised.

I was fantasizing:  if the app were to be written today, what 
would be suitable languages?

C++17, is a shoe in, since that corresponds to reality (if looked 
at through a carnival mirror, since the actual code is smeared 
across C++89 - C++98/03 - C++11/14 - C++17 like cities built on 
top the ruins of cities, and its turtles all the way down).

Since I'm a D fanboy, I put D on the list.  And I think these as 

Java, Groovy*, Scala*, Swift.  And maybe, at a stretch, Ada*, 
Clojure*, Kotlin*.

* I've no practical experience in these languages.

A friend of mine said I should add Rust* to the list.  I'm not 
familiar with Rust, so today is my "dive into Rust" day.  That's 
how I got here.  (Hi Walter!  Hi Bearophile!  I've been away for 
a long while.)

In my fantasy, the biggest challenge with a large multi-platform 
application is the tooling and support.

So some of the questions that are meta-language related are...

What are the IDEs like?  People want to have bother-free version 
control, enjoyable debugging experience, works on the target 
platforms, manage very large projects.  C++ has excellent support 
by Visual Studio, and very good support by Xcode.

What do the standard libraries offer?  C++ has a reasonably nice 
standard library.

What off-the-shelf libraries can be leveraged?  C++ has Boost, 
and many others.  A vibrant ecosystem.

Can the language "do the job"?  Part of "doing the job" is 
interoperating with the target platform.  In this fantasy case, 
Win32 with GDI/GDI+ (possibly .NET as a viable alternative), and 
Cocoa.  If that involves writing a C-API bridging layer from 
Language X to Host Platform, that is friction.  A fantasy project 
this size can absorb that kind of friction.

Can we hire 100+ programmers willing to use that language?

Those things are important, even though they are outside the 
domain of the language itself.  Toolchains.  IDEs.  Tool vendor 
stability.  Debugging.  Large project management.  Version 
control.  Suitability.  Community & ecosystem.  Human resources.

Since my love-hate relationship with C++ is well known, in my 
do-over fantasy world, I hope there is a better suited language.

And "make your own language" is not on the table.  I've read 
Aho's dragon book... I've tried that... it is VERY HARD to make 
your own general purpose language, and will consume 10+ years of 
your life.  Bjarne Stroustrup said, "If you do anything useful it 
will haunt you forever after, and if you have a major success you 
get decades of hard manual labor - meaning you have to work on 
the manual."  *hugs* to Walter & Andrei.



That's been tried, turns out maintaining parity that way does not 
work out so well.  Case in point:  check out Office for Windows, 
and Office for Mac.

Step back...

Why am I sharing this on this forum?

I think these meta-language issues need to be thought about to 
help D gain more traction.  In addition to the core language 
issues that Andrei has already discussed in depth, and were 
mentioned again in this thread.

And I really love D.  It speaks to me.  It is the language I wish 
C++ was.  If I could have created a language, I would compare it 
against D as my gold standard.

I look at the history of RemObjects, and how they had a 
distributed object technology... but to support it they had to 
become a language vendor (of Oxygene, their version of Delphi, 
which is Apple/Wirth's Object Pascal), and then had to create 
their Elements compiler, and extend it to support multiple target 
platforms, and then extend it more to support multiple languages 

they've jumped into the IDE game.  It is interesting to note that 
where they started and how they got to where they are is an 
interesting journey of necessity.
Sep 03 2017
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 09/03/2017 11:26 AM, Eljay wrote:


 I put D on the list.


Been there, done that. Decision makers rationalize any other choice 
pretty easily:

- Python is 20 times slower: "We don't need speed."

- Python has a global lock: "We will start RESTful separate processes."

- Python's memory foot print is huge: "We will use less processes and 
use coroutines."

- Python does not provide static type-checking: "We will use pylint." 
People submit code that are broken: "They should use pylint."

- Similar other items where Python is inferior: "We'll deal with those 
when they become issues."

- Python is better on this one item: "Great! We choose Python."


 Hi Walter!


He's still hanging around... ;)


 Hi Bearophile!


I'm afraid bearophile has moved to greener pastures. I've run into 
bearophile on Reddit on Rust-related threads. He uses a different name 
there.


 Can we hire 100+ programmers willing to use that language?


D companies are known to interview in e.g. C++ but tell the candidates 
that they will be coding in D.

Ali
Sep 03 2017
next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 3 September 2017 at 19:40:27 UTC, Ali Çehreli wrote:

 Decision makers rationalize any other choice pretty easily:


There is a useful method in the book "Thinking Fast and Slow" to 
try to be rational about a choice.

1/ Before looking the different solitions, make a list of 
relevant criterion for the problem at hand, and associate 
weights. For example I need to choose a language, let's choose 
Platform Support (weight 5), Familiarity (weight 4) and Speed 
(weight 2).

2/ Rate each alternatives alongside the choosen criterion.
For example D gets 3/5 in Platform Support, 4/4 in Familiarity 
and 1/2 in Speed.
That makes 3 + 5 + 1 = 9 points.

3/ And then _without further thinking_ choose the one with the 
most point.

In the book the example used was with hiring, but I suspect it 
applies to many type of decisions instead.

This method is supposed to outperform intuitive reasoning for 
hiring. In particular overcome some biases. However biases still 
find a way in the choice of criterions.
Sep 03 2017
prev sibling next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Sunday, 3 September 2017 at 19:40:27 UTC, Ali Çehreli wrote:

 Hi Bearophile!


 I'm afraid bearophile has moved to greener pastures. I've run 
 into bearophile on Reddit on Rust-related threads. He uses a 
 different name there.


*sigh*
Sep 03 2017
prev sibling parent reply Eljay <eljay.adobe gmail.com> writes:
On Sunday, 3 September 2017 at 19:40:27 UTC, Ali Çehreli wrote:

 Been there, done that. Decision makers rationalize any other 
 choice pretty easily:


In my fantasy, I'd be the decision maker.  ;-)

In reality, along all my career, usually the decision as to the 
language used was made usually by (non-engineer) management, or 
sometimes by the principle developer by fiat.

And merits of the language was but one of many factors, but I 
think the foremost factor was whichever language the decision 
maker was familiar with, or enamored with.  (In your example, 
hence... PYTHON!  I actually like Python, but I've only used it 
for scripting purposes.  Less than 1 kLOC.)

Often times in the projects I have been on, that decision maker 
has long since moved on to different projects or left the company.

And the language decision is nigh impossible to change.  Except...

On my current project, the original language was Object Pascal.  
At some point in the early 90s, the Object Pascal code was 
mechanically transformed into C++89 code.

Even though that was a very long time ago, there are still Object 
Pascal idioms present in the code.  Which are not idiomatic C++.

Semi-ironically, Object Pascal is still around, and has it's own 
following.  Although now referred to as Delphi or Oxygene or 
Freescal.  They're all Object Pascal.

Regarding the project language choice, the one thing I have found 
consistent from all my projects is:  picking a locked-down 
proprietary language is invariably a bad decision.  Languages 
like PowerBuilder Powerscript or Forte Tool or Meditech Magic or 
PickOS PickBASIC.

My apologies to devs that enjoy Powerscript or Tool or Magic or 
PickBASIC.  I'm not saying that those languages cannot be 
enjoyable.  The nature of proprietary languages make the projects 
tied to them at their mercy.

Whereas with D, if I don't like dmd, I can use gcd, or ldc.  Or 
if D doesn't support my favorite platform -- obviously Amiga OS, 
the one best OS ever made -- I could in theory do the work to 
leverage D as a front end to my toolchain.

Hmmm, maybe that doesn't make sense.  Sorry if I didn't express 
myself clearly.
Sep 04 2017
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 09/04/2017 08:13 AM, Eljay wrote:


 the original language was Object Pascal.


Just a random connection: Bastiaan Veelo's DConf presentation was about 
parsing Extended Pascal.

   http://dconf.org/2017/talks/veelo.html


 Sorry if I didn't express myself clearly.


I agree that D rocks! :p

Ali
Sep 05 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
BTW, your email server is rejecting my emails to you!
Jan 30 2016
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 2016
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 2016