www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C++17

reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
Just a thought:

1. D needs capable compiler programmers.

2. Converting C++ programmers is a good recruitment strategy.

3. C++ programmers are very concerned about memory management 
features.

4. When C++17 is released, current C++ programmers will go "I was 
ready to leave C++, but I will give it a second chance now that 
it has all these new interesting features". So 2017-2018 is a bad 
period for converting C++ programmers.

It seems to me that a competitive production-ready solution that 
satisfies the current crop of C++ programmers has to be 
implemented within 6 months. When C++17 is perceived as being 
near release the psychology will be "I will wait for C++17 before 
looking at other languages".

Would it be possible to make a fully compatible 
unique_ptr/shared_ptr solution that acts as the default memory 
management scheme in D within 6 months?

If not, what is the strategy behind focusing on interfacing with 
C++? (Evaluated in relation to the C++17 release.)
Jan 26
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 26 January 2016 at 09:16:47 UTC, Ola Fosheim Grøstad 
wrote:
 Would it be possible to make a fully compatible 
 unique_ptr/shared_ptr solution that acts as the default memory 
 management scheme in D within 6 months?
No that would be stupid to make that the default as it is unsafe. Now if one want to use that, D is very capable of doing it already. Just won't make it the default (like it is not the default in C++ either). People that don't switch because of this aren't going to swicth if it is added as it's already in.
Jan 26
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 09:33:22 UTC, deadalnix wrote:
 No that would be stupid to make that the default as it is 
 unsafe.
When would you estimate that D could have a production ready default memory managment solution (without GC)? When people look at a language they don't ask themselves what is possible, but what the main features are and how convenient it looks. So from a (C/C++) marketing point of view it is better to send the message "excellent memory management with optional GC" than "GC backed memory with optional..."
Jan 26
parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 26 January 2016 at 10:39:03 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 26 January 2016 at 09:33:22 UTC, deadalnix wrote:
 No that would be stupid to make that the default as it is 
 unsafe.
When would you estimate that D could have a production ready default memory managment solution (without GC)?
Now, D can do the exact same as C++ .
 When people look at a language they don't ask themselves what 
 is possible, but what the main features are and how convenient 
 it looks.
It is in the standard lib, as it is for C++.
 So from a (C/C++) marketing point of view it is better to send 
 the message "excellent memory management with optional GC" than 
 "GC backed memory with optional..."
That's dumb from an engineering point of view.
Jan 26
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 15:51:22 UTC, deadalnix wrote:
 On Tuesday, 26 January 2016 at 10:39:03 UTC, Ola Fosheim 
 Grøstad wrote:
 On Tuesday, 26 January 2016 at 09:33:22 UTC, deadalnix wrote:
 No that would be stupid to make that the default as it is 
 unsafe.
When would you estimate that D could have a production ready default memory managment solution (without GC)?
Now, D can do the exact same as C++ .
Not really, but that was not the question. So let me repeat: When would you estimate that D will have a production ready default memory management solution (without GC).
Jan 26
parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 26 January 2016 at 15:59:37 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 26 January 2016 at 15:51:22 UTC, deadalnix wrote:
 On Tuesday, 26 January 2016 at 10:39:03 UTC, Ola Fosheim 
 Grøstad wrote:
 On Tuesday, 26 January 2016 at 09:33:22 UTC, deadalnix wrote:
 No that would be stupid to make that the default as it is 
 unsafe.
When would you estimate that D could have a production ready default memory managment solution (without GC)?
Now, D can do the exact same as C++ .
Not really, but that was not the question. So let me repeat: When would you estimate that D will have a production ready default memory management solution (without GC).
I don't think it is desirable. I do think we should focus on having GC.malloc/GC.free have the same level of perfs than malloc/free, which is very doable. Now as to when, well, I'm waiting for your PR.
Jan 26
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 18:57:45 UTC, deadalnix wrote:
 I don't think it is desirable. I do think we should focus on 
 having GC.malloc/GC.free have the same level of perfs than 
 malloc/free, which is very doable.
Does this mean that you have given up on D getting an ownership mechanism?
 Now as to when, well, I'm waiting for your PR.
Not sure what you mean?
Jan 26
parent reply rsw0x <anonymous anonymous.com> writes:
On Tuesday, 26 January 2016 at 19:02:54 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 26 January 2016 at 18:57:45 UTC, deadalnix wrote:
 I don't think it is desirable. I do think we should focus on 
 having GC.malloc/GC.free have the same level of perfs than 
 malloc/free, which is very doable.
Does this mean that you have given up on D getting an ownership mechanism?
There doesn't seem to be much work towards this and it doesn't appear to be a high priority issue. Things like catching C++ exceptions seem to be far higher up on the priority list than a defined memory model or ownership mechanics. I see C++17 and think of why I should keep using D when C++ is aping a lot of its best features.
Jan 26
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 19:07:03 UTC, rsw0x wrote:
 I see C++17 and think of why I should keep using D when C++ is 
 aping a lot of its best features.
Yes... and Rust is also maturing... So.
Jan 26
prev sibling next sibling parent reply bachmeier <no spam.com> writes:
On Tuesday, 26 January 2016 at 19:07:03 UTC, rsw0x wrote:

 I see C++17 and think of why I should keep using D when C++ is 
 aping a lot of its best features.
You and 99.9% of other C++ programmers. D is not going to gain anything from efforts to recruit C++ programmers because they are, in spite of claims to the contrary, very happy with the language. The productive path is to provide a good alternative that keeps them from touching C++ in the first place.
Jan 26
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 19:33:04 UTC, bachmeier wrote:
 You and 99.9% of other C++ programmers. D is not going to gain 
 anything from efforts to recruit C++ programmers because they 
 are, in spite of claims to the contrary, very happy with the 
 language.
That's not actually true. Many C++ programmer express a dislike for how the the syntax has developed over time, all the weird corner-cases, the obfuscated meta programming mechanisms and unpredictable implicitness when trying to do more advanced typing. Just getting the right constructor to fire can be a challenge. The general C++ semantics are good enough, but the language has to many weird aspects to it that is "beyond repair" and that makes C++ programming time consuming.
Jan 26
parent reply bachmeier <no spam.com> writes:
On Tuesday, 26 January 2016 at 20:25:34 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 26 January 2016 at 19:33:04 UTC, bachmeier wrote:
 That's not actually true. Many C++ programmer express a dislike 
 for how the the syntax has developed over time, all the weird 
 corner-cases, the obfuscated meta programming mechanisms and 
 unpredictable implicitness when trying to do more advanced 
 typing. Just getting the right constructor to fire can be a 
 challenge.

 The general C++ semantics are good enough, but the language has 
 to many weird aspects to it that is "beyond repair" and that 
 makes C++ programming time consuming.
The problem is that "C++ programmers" is not a random sample. It's a group that was willing to push through the pain of old C++ and read books by Scott Meyers and learn template metaprogramming. The willingness to endure that torture weeded out all but the very best matches. Now there are improvements with C++11, C++14, and C++17, so *that group* getting a *much improved language* has no incentive to switch. Everyone else is already using another language. "With C++xx, there's little benefit to switching" is a very common sentiment among current C++ programmers. And it's probably true. On the other hand, with a few exceptions, it's hard to see someone choosing to learn C++ rather than D. Making a push for those developers will be more productive.
Jan 26
next sibling parent bachmeier <no spam.com> writes:
On Tuesday, 26 January 2016 at 21:01:53 UTC, bachmeier wrote:

 "With C++xx, there's little benefit to switching" is a very 
 common sentiment among current C++ programmers. And it's 
 probably true. On the other hand, with a few exceptions, it's 
 hard to see someone choosing to learn C++ rather than D. Making 
 a push for those developers will be more productive.
Also, I see the competition for new programmers on a daily basis. Rcpp, which allows one to embed C++ code inside an R program, is the most popular dependency of R packages. D is unable to compete in that space because of the lack of proper DLL support for Windows and no such support for Mac. I will never be convinced that D wouldn't be preferred by data scientists. But that's not happening because of D's current limitations.
Jan 26
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 21:01:53 UTC, bachmeier wrote:
 out all but the very best matches. Now there are improvements 
 with C++11, C++14, and C++17, so *that group* getting a *much 
 improved language* has no incentive to switch. Everyone else is 
 already using another language.
Even if that was true, it still means that there are THOUSANDS of ex-C++ programmers that would use a C++ like language if it provided comparable semantics. In my experience C++14 is mostly ok if you avoid advanced programming mechanisms, but if you want to achieve a specific set of abstractions you end up wasting a lot time on getting around the corner cases, like avoiding situations where the compiler cannot deduce what to do (instantiation conflicts).
Jan 26
prev sibling next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 26 January 2016 at 21:01:53 UTC, bachmeier wrote:
 "With C++xx, there's little benefit to switching" is a very 
 common sentiment among current C++ programmers. And it's 
 probably true.
It's not true. After failing to convince my coworkers to use D, I wondered about this. I actually thought, myself, that C++14 is good enough and nearly like writing D. I was wrong. I've recently spent about 2 or 3 months writing C++14 at work. I ended up complaining a lot. Most of the time because I'd written a bug that wouldn't have happened in D. The rest was usually due to something supposedly simple taking an inordinate amount of work. And the compile times... I never used to think they were _that_ important. I do now. I actually think slower when writing C++, which means I work slower. It sounds obvious, but I only really felt it recently. The penny really dropped when I wrote D again for the 1st time after weeks and weeks of C++14. It was night and day. Suddenly my thoughts started getting to converted to code all that faster, with fewer bugs to distract and annoy me. Don't get me wrong: I vastly prefer C++14 to C++98 or plain C. But even modern C++ needs this: https://en.wikipedia.org/wiki/Erase%E2%80%93remove_idiom Which is, quite frankly, ridiculous. Do you know how you split a string in C++? You install boost, that's how. Atila
Jan 26
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Jan 27, 2016 at 12:16:58AM +0000, Atila Neves via Digitalmars-d wrote:
 On Tuesday, 26 January 2016 at 21:01:53 UTC, bachmeier wrote:
"With C++xx, there's little benefit to switching" is a very common
sentiment among current C++ programmers. And it's probably true.
It's not true. After failing to convince my coworkers to use D, I wondered about this. I actually thought, myself, that C++14 is good enough and nearly like writing D. I was wrong. I've recently spent about 2 or 3 months writing C++14 at work. I ended up complaining a lot. Most of the time because I'd written a bug that wouldn't have happened in D. The rest was usually due to something supposedly simple taking an inordinate amount of work.
This reminds me of the time when I wanted to make a "trivial" change to an old C++ project of mine. This was after I had become acquianted with D, and gotten used to built-in AA's. I noticed that C++14 finally officially had hashtables in the standard library (which is worth a rant in itself -- who has ever heard of a modern programming language that has no standard hashtable implementation until how many decades after?!), and was eager to finally try it out in my code. It would be a simple task, I thought; simply plop in the new standard hashtable at a strategic point in the code to serve as a cache, and performance should improve. Right? Right?? Many hours later, I was tearing my hair out trying to resolve stupid issues like: 1) You cannot instantitate a hashtable template without also specifying a hash function. WAT?! No built-in hash function??! Well, yes there is, except... 2) The standard hashtables have no standard hash function for structs. You have to write your own. WAT??! 3) After you have a hash function, you have to create the hashtable with an explicitly-attached hash function -- it's not a template parameter, it has to be a function object passed to the hashtable's ctor. Which means passing around the hash function everywhere all over the code, wherever there's the need to create a hashtable. Arghh... I'm pretty sure with a "little" more effort I could have made it work... but seriously, that was several *hours* compared to the 2 seconds it takes in D to add an AA to your code. You people who think there's still enough reasons to stick to C++ crack me up. Do you have any idea what on earth you're talking about?! [...]
 The penny really dropped when I wrote D again for the 1st time after
 weeks and weeks of C++14. It was night and day. Suddenly my thoughts
 started getting to converted to code all that faster, with fewer bugs
 to distract and annoy me.
Exactly!!!! If that project of mine had been in D, it would have taken me at the most 5-10 mins to code, test, and debug the new code change. With C++, it took several hours and it still hasn't gotten off the ground yet. This isn't some isolated incident or unfortunate coincidence either. C++ is full of convoluted idioms and needlessly complex paraphrases to shoehorn modern programming techniques onto a decrepit and dying ancient core. Make one mistake and you're faced with either a memory leak, an untraceable pointer bug, an off-by-1 bug, or some other kind of nasty, hard-to-debug problem. Oh, right, we're not supposed to touch malloc/free or new/delete anymore, we're supposed to wrap those in "safe" library abstractions. And we're not supposed to used naked pointers anymore, it should be one of those fancy black magic pointer wrappers that do ref-counting or some such. Ergo, convoluted idioms and needlessly complex paraphrasis for what, conceptually, ought to have been a straightforward 5 lines of code, that comes out in C++ as 50+ lines or more.
 Don't get me wrong: I vastly prefer C++14 to C++98 or plain C. But
 even modern C++ needs this:
 
 https://en.wikipedia.org/wiki/Erase%E2%80%93remove_idiom
 
 Which is, quite frankly, ridiculous. Do you know how you split a
 string in C++? You install boost, that's how.
[...] The fact that boost is required to write anything non-trivial in C++ without reinventing the square wheel or pulling all your hair out, is a sign that something has deeply gone wrong with the language. Yet its proponents continue to stab themselves with knives and revel in the pain, since C++ is, after all, still superior, especially over that pathetic failure called D. "I can't write D code in the same painful, bug-prone, productivity-killing way as I write C++ code, so D sux!" I suppose it's too much of a sacrifice for C++ coders to write code in less painful, more bug-free, and more productive ways. After all, what about the job security??! (And lest you think I'm just a rambling lunatic, here's another ex-C++ coder who sees it the same way: http://bartoszmilewski.com/2013/09/19/edward-chands/ ) T -- If you compete with slaves, you become a slave. -- Norbert Wiener
Jan 26
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2016 4:45 PM, H. S. Teoh via Digitalmars-d wrote:
 http://bartoszmilewski.com/2013/09/19/edward-chands/ )
"And you know a new feature is badly designed if Scott Meyers has a talk about it."
Jan 26
prev sibling next sibling parent =?UTF-8?Q?Tobias=20M=C3=BCller?= <troplin bluewin.ch> writes:
H. S. Teoh via Digitalmars-d <digitalmars-d puremagic.com> wrote:
 This reminds me of the time when I wanted to make a "trivial" change to
 an old C++ project of mine. This was after I had become acquianted with
 D, and gotten used to built-in AA's. I noticed that C++14 finally
 officially had hashtables in the standard library (which is worth a rant
 in itself -- who has ever heard of a modern programming language that
 has no standard hashtable implementation until how many decades
 after?!), and was eager to finally try it out in my code.  It would be a
 simple task, I thought; simply plop in the new standard hashtable at a
 strategic point in the code to serve as a cache, and performance should
 improve. Right? Right??
 
 Many hours later, I was tearing my hair out trying to resolve stupid
 issues like:
 
 1) You cannot instantitate a hashtable template without also specifying
    a hash function. WAT?! No built-in hash function??! Well, yes there
    is, except...
Wrong. There's std::hash<T>. It's a struct, not a function though.
 2) The standard hashtables have no standard hash function for structs.
    You have to write your own.  WAT??!
Usually, you just specialize std::hash<T> for your type. How often do you write custom structs/classes (it's the same in C++) to be used _by value_ as key in a hash table anyway?
 3) After you have a hash function, you have to create the hashtable with
    an explicitly-attached hash function
Wrong.
 -- it's not a template parameter,
Wrong again. It is a template parameter and it defaults to std::hash<T>.
    it has to be a function object passed to the hashtable's
    ctor.
With default argument std::hash<T>().
    Which means passing around the hash function everywhere all
    over the code, wherever there's the need to create a hashtable.
Wrong. You just specialize std::hash<T> and be done.
    Arghh...
Yes.
 I'm pretty sure with a "little" more effort I could have made it work...
 but seriously, that was several *hours* compared to the 2 seconds it
 takes in D to add an AA to your code.
 
 You people who think there's still enough reasons to stick to C++ crack
 me up.  Do you have any idea what on earth you're talking about?!
Well apparently you don't. Tobi
Jan 26
prev sibling parent reply =?UTF-8?Q?Tobias=20M=C3=BCller?= <troplin bluewin.ch> writes:
H. S. Teoh via Digitalmars-d <digitalmars-d puremagic.com> wrote:
 [long rant]
If you want to attract new programmers you should stop constantly bashing other programming languages on the public forums. This is one thing that Rust got right. Tobi
Jan 27
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 08:08:30 UTC, Tobias Müller 
wrote:
 H. S. Teoh via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:
 [long rant]
If you want to attract new programmers you should stop constantly bashing other programming languages on the public forums. This is one thing that Rust got right.
Well, C++ hash tables are ok. It is the result of a C++ library philosophy, which one may or may not agree with. The point of this thread was to argue that D needs to attract C/C++ programmers and might be better off selecting semantics that attract them. There is something to be said about timeliness for doing so. Autumn 2016 seems to be the perfect time to market D to C++ programmers, but the first thing they will ask for is no-GC memory handling, and "malloc" + DIY will just result in a big big yawn. If 8 weekend programmers can replace 1 full time programmer and D needs 5 more full time programmers to compete (with C++, Rust and Swift), then D needs 40 weekend programmers to compete. It takes a focused _strategy_ to get into the hearts of C/C++ programmers. It's not going to happen on it's own.
Jan 27
parent reply rsw0x <anonymous anonymous.com> writes:
On Wednesday, 27 January 2016 at 08:56:09 UTC, Ola Fosheim 
Grøstad wrote:
 On Wednesday, 27 January 2016 at 08:08:30 UTC, Tobias Müller 
 wrote:
 H. S. Teoh via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:
 [long rant]
If you want to attract new programmers you should stop constantly bashing other programming languages on the public forums. This is one thing that Rust got right.
Well, C++ hash tables are ok. It is the result of a C++ library philosophy, which one may or may not agree with. The point of this thread was to argue that D needs to attract C/C++ programmers and might be better off selecting semantics that attract them. There is something to be said about timeliness for doing so. Autumn 2016 seems to be the perfect time to market D to C++ programmers, but the first thing they will ask for is no-GC memory handling, and "malloc" + DIY will just result in a big big yawn. If 8 weekend programmers can replace 1 full time programmer and D needs 5 more full time programmers to compete (with C++, Rust and Swift), then D needs 40 weekend programmers to compete. It takes a focused _strategy_ to get into the hearts of C/C++ programmers. It's not going to happen on it's own.
The response from the D community seems to be an overwhelming "It's fine as is" when it's obviously not. Which is making me question sinking more time into D if there actually is no cohesive plan to make D an actual C++ competitor rather than a toy language as it currently stands.
Jan 27
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:
 The response from the D community seems to be an overwhelming 
 "It's fine as is" when it's obviously not. Which is making me 
 question sinking more time into D if there actually is no 
 cohesive plan to make D an actual C++ competitor rather than a 
 toy language as it currently stands.
I found it very interesting that Bjarne Stroustrup basically admitted in his presentation of GSL that the progress of Rust has forced C++ to change faster. And there is no doubt that Apple is putting its money behind Swift, planning for a major upgrade (Swift 3)... As far as I can tell there is a horse race between C++, Rust and perhaps also Swift that will affect what programmers expect from system level programming languages in the coming years. So "It's fine as is" isn't really an option.
Jan 27
prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:
 toy language
What is with everyone using inane hyperbole in this thread? Is everyone trying to one up each other? D is a toy language? Really? Tell that to Sociomantic and AdRoll, I'm sure they use D right next to brainfuck, right?
Jan 27
next sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Wednesday, 27 January 2016 at 15:37:39 UTC, Jack Stouffer 
wrote:
 On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:
 toy language
What is with everyone using inane hyperbole in this thread? Is everyone trying to one up each other? D is a toy language? Really? Tell that to Sociomantic and AdRoll, I'm sure they use D right next to brainfuck, right?
PureScript is used by SlamData, a multi-million dollar company. I still consider PureScript a toy language.
Jan 27
next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 27 January 2016 at 16:12:49 UTC, rsw0x wrote:
 PureScript is used by SlamData, a multi-million dollar company.
 I still consider PureScript a toy language.
Purescript, Typescript, etc. are not languages, they're glorified preprocessors.
Jan 27
prev sibling parent Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Wednesday, 27 January 2016 at 16:12:49 UTC, rsw0x wrote:
 On Wednesday, 27 January 2016 at 15:37:39 UTC, Jack Stouffer 
 wrote:
 On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:
 toy language
What is with everyone using inane hyperbole in this thread? Is everyone trying to one up each other? D is a toy language? Really? Tell that to Sociomantic and AdRoll, I'm sure they use D right next to brainfuck, right?
PureScript is used by SlamData, a multi-million dollar company. I still consider PureScript a toy language.
Do you have a better definition than that of wiki ? It seems to me one can create reliable, maintainable computer programs in a production environment in D, that it is hardly limited in terms of not having a full range of programming constructs, and that library support is not a serious problem for a bigger project because the cost of writing bindings or wrapping things is one-off. https://en.wikipedia.org/wiki/Toy_programming_language A toy language is a computer programming language that lacks the requirements to create reliable, maintainable computer programs in a production environment.[citation needed] Which programs to categorize as toy languages is difficult, however.[citation needed] Languages such as Brainfuck and Whitespace are both considered esoteric programming languages.[citation needed] They are Turing complete,[citation needed] which means they are able to compute any computable function.[citation needed] Logo is an example of a toy language.[citation needed] Its goal was originally to create a math land where children could play with words and sentences.[citation needed] For a long time, the GNU Compiler Collection was shipped with a toy programming language called Treelang[citation needed] which was essentially C without the advanced features such as pointers, arrays, and records.[citation needed] Limitations Though a toy language may be mathematically complete, it is usually limited in one or several ways. It may not support a full range of programming constructs or concepts. It may lack a full set of support libraries considered to be required for creating production-quality programs. Uses The main use of a toy language is in computer languages research. Some uses are as frameworks for researching new programming constructs or as a prototype for new language concepts or paradigms. Other notable uses are as a learning or demonstration tool, e.g. in universities, for programming constructs and techniques not available in mainstream languages and as an exercise in building a language from scratch.
Jan 27
prev sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Wednesday, 27 January 2016 at 15:37:39 UTC, Jack Stouffer 
wrote:
 D is a toy language? Really? Tell that to Sociomantic and 
 AdRoll, I'm sure they use D right next to brainfuck, right?
brainfuck... Recently as an experiment I was going through to decide on the minimum instructions needed for a chip; Perhaps processor design would have them listed, but I came around 6-7 different instructions. With these instructions in combination you can do/build everything else. I'm also reminded of playing the TIS-100 game not too long ago, which was a 'chip' designed with 10 instructions and you had to program the chips in parallel to get stuff done. This includes everything from multiplication and division, to sorting and array access. It's amazing what you can do with so very little if you approach it right.
Jan 27
prev sibling next sibling parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:
 On Wednesday, 27 January 2016 at 08:56:09 UTC, Ola Fosheim 
 Grøstad wrote:
 On Wednesday, 27 January 2016 at 08:08:30 UTC, Tobias Müller 
 wrote:
 H. S. Teoh via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:
 [long rant]
If you want to attract new programmers you should stop constantly bashing other programming languages on the public forums. This is one thing that Rust got right.
Well, C++ hash tables are ok. It is the result of a C++ library philosophy, which one may or may not agree with. The point of this thread was to argue that D needs to attract C/C++ programmers and might be better off selecting semantics that attract them. There is something to be said about timeliness for doing so. Autumn 2016 seems to be the perfect time to market D to C++ programmers, but the first thing they will ask for is no-GC memory handling, and "malloc" + DIY will just result in a big big yawn. If 8 weekend programmers can replace 1 full time programmer and D needs 5 more full time programmers to compete (with C++, Rust and Swift), then D needs 40 weekend programmers to compete. It takes a focused _strategy_ to get into the hearts of C/C++ programmers. It's not going to happen on it's own.
The response from the D community seems to be an overwhelming "It's fine as is" when it's obviously not. Which is making me question sinking more time into D if there actually is no cohesive plan to make D an actual C++ competitor rather than a toy language as it currently stands.
Grumbling is great, up to a point. Talented and discerning people who don't see a way to fix problems are going to grumble. Change takes time, and one tends to overestimate what can be accomplished in shorter periods of time, and underestimate what's possible over longer periods. Since I've been here (one or two years) we've seen some very substantial improvements - the web site, the documentation, C++ integration, D being usable on ARM/Android, just to name a few. But the power is in your hands too. Perhaps the D Foundation and corporate sponsorship will change the resource question in time. But it's a different situation from being in a vast corporation where one has no control and nobody will listen to you. Ilya saw that D needed better numerical primitives and he wrote ndslice. John Colvin saw that D needed a focal point for numerical and scientific computing and he took charge of that - nobody appointed him. There isn't so much benefit to having a coherent top-down plan when you can neither force people to work on things, nor pay them to do so. That's not how open-source works, and it's more governed by the principle of catallaxy discussed by Hayek than it is some kind of corporate project. The advantage of not having a top down plan is that decisions can be shaped by local knowledge from peoples' practical experience of the kinds of problems they need to solve. If you want to change the GC etc, telling other people they ought to look at that will be much less effective than picking some aspect of the problem to work on. For example, the sociomantic GC was released - I wonder what the blockers are for this to be ported in part or whole to D. If one doesn't have time to work on the whole thing, one can at least start creating a focal point for a white paper and then let others add to it and refine it.
Jan 27
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 27 January 2016 at 16:40:11 UTC, Laeeth Isharc 
wrote:
 and it's more governed by the principle of catallaxy discussed 
 by Hayek
Principle of spontaneous order might be appropriate.
Jan 27
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Wednesday, 27 January 2016 at 17:11:18 UTC, jmh530 wrote:
 On Wednesday, 27 January 2016 at 16:40:11 UTC, Laeeth Isharc 
 wrote:
 and it's more governed by the principle of catallaxy discussed 
 by Hayek
Principle of spontaneous order might be appropriate.
One and the same. https://en.wikipedia.org/wiki/Catallactics Note this bit especially - Hayek's suggested Greek construction would be rendered καταλλαξία) from the Greek verb katallasso (καταλλάσσω) which meant not only "to exchange" but also "to admit in the community" and "to change from enemy into friend." https://en.wikipedia.org/wiki/Catallactics Catallactics is a theory of the way the free market system reaches exchange ratios and prices. It aims to analyse all actions based on monetary calculation and trace the formation of prices back to the point where an agent makes his or her choices. It explains prices as they are, rather than as they "should" be. The laws of catallactics are not value judgments, but aim to be exact, objective and of universal validity. It was first used extensively by the Austrian School economist Ludwig von Mises.[citation needed] Catallactics is a praxeological theory, the term catallaxy being used by Friedrich Hayek to describe "the order brought about by the mutual adjustment of many individual economies in a market."[1] Hayek was dissatisfied with the usage of the word "economy" because its Greek root, which translates as "household management", implies that economic agents in a market economy possess shared goals. He derived the word "Catallaxy" (Hayek's suggested Greek construction would be rendered καταλλαξία) from the Greek verb katallasso (καταλλάσσω) which meant not only "to exchange" but also "to admit in the community" and "to change from enemy into friend."[2] According to Mises (Human Action, page 3) and Hayek[3] it was Richard Whately who coined the term "catallactics". Whately's Introductory Lectures on Political Economy (1831) reads:[4] It is with a view to put you on your guard against prejudices thus created, (and you will meet probably with many instances of persons influenced by them,) that I have stated my objections to the name of Political-Economy. It is now, I conceive, too late to think of changing it. A. Smith, indeed, has designated his work a treatise on the "Wealth of Nations;" but this supplies a name only for the subject-matter, not for the science itself. The name I should have preferred as the most descriptive, and on the whole least objectionable, is that of CATALLACTICS, or the "Science of Exchanges."
Jan 27
parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 27 January 2016 at 21:58:06 UTC, Laeeth Isharc 
wrote:
 One and the same.

 [snip]
I disagree. Your point was that open source is bottom-up and not top-down. That's more like spontaneous order https://en.wikipedia.org/wiki/Spontaneous_order It's a specific idea within the broader set of ideas in economics. Praxeology is Mises' term for the science of human action. In his view, the science of human action is broad, encompassing many fields. He refers to one of those fields Catallactics, which is the theory of exchange. For all intents and purposes, when you hear Catallactics, you could replace it with Economics and you'd be fine (price theory might be even more accurate). Perhaps the main difference is that Catallactics theoretically covers all exchange, but even Economics these days covers many types of non-monetary exchange. To me, it makes as much sense to say that open source is governed by the principles of catallaxy as it does to say that it's governed by the principles of economics. What specific meaning is conveyed by saying that? Too broad.
Jan 27
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:
 The response from the D community seems to be an overwhelming 
 "It's fine as is" when it's obviously not. Which is making me 
 question sinking more time into D if there actually is no 
 cohesive plan to make D an actual C++ competitor rather than a 
 toy language as it currently stands.
I can't take any of this seriously as long as ConcernedDev1950 do not provide any PR.
Jan 27
parent reply rsw0x <anonymous anonymous.com> writes:
On Wednesday, 27 January 2016 at 20:31:33 UTC, deadalnix wrote:
 On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:
 The response from the D community seems to be an overwhelming 
 "It's fine as is" when it's obviously not. Which is making me 
 question sinking more time into D if there actually is no 
 cohesive plan to make D an actual C++ competitor rather than a 
 toy language as it currently stands.
I can't take any of this seriously as long as ConcernedDev1950 do not provide any PR.
ConcernedDev1950 will go use a language that doesn't require them to write the standard library.
Jan 27
parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 27 January 2016 at 20:51:43 UTC, rsw0x wrote:
 On Wednesday, 27 January 2016 at 20:31:33 UTC, deadalnix wrote:
 On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:
 The response from the D community seems to be an overwhelming 
 "It's fine as is" when it's obviously not. Which is making me 
 question sinking more time into D if there actually is no 
 cohesive plan to make D an actual C++ competitor rather than 
 a toy language as it currently stands.
I can't take any of this seriously as long as ConcernedDev1950 do not provide any PR.
ConcernedDev1950 will go use a language that doesn't require them to write the standard library.
Apparently no, they come here and cry and get nothing done.
Jan 27
next sibling parent Chris Wright <dhasenan gmail.com> writes:
On Wed, 27 Jan 2016 22:18:49 +0000, deadalnix wrote:

 On Wednesday, 27 January 2016 at 20:51:43 UTC, rsw0x wrote:
 On Wednesday, 27 January 2016 at 20:31:33 UTC, deadalnix wrote:
 On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:
 The response from the D community seems to be an overwhelming "It's
 fine as is" when it's obviously not. Which is making me question
 sinking more time into D if there actually is no cohesive plan to
 make D an actual C++ competitor rather than a toy language as it
 currently stands.
I can't take any of this seriously as long as ConcernedDev1950 do not provide any PR.
ConcernedDev1950 will go use a language that doesn't require them to write the standard library.
Apparently no, they come here and cry and get nothing done.
I just want to do my own thing. When I try doing it in D, I often have to work on three or four dependencies as well. Sometimes it's a good tradeoff -- D occasionally has something no other language I'm willing to use has. Most of the time it's not. That's not crying; it's practicality.
Jan 27
prev sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Wednesday, 27 January 2016 at 22:18:49 UTC, deadalnix wrote:
 On Wednesday, 27 January 2016 at 20:51:43 UTC, rsw0x wrote:
 On Wednesday, 27 January 2016 at 20:31:33 UTC, deadalnix wrote:
 On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:
 The response from the D community seems to be an 
 overwhelming "It's fine as is" when it's obviously not. 
 Which is making me question sinking more time into D if 
 there actually is no cohesive plan to make D an actual C++ 
 competitor rather than a toy language as it currently stands.
I can't take any of this seriously as long as ConcernedDev1950 do not provide any PR.
ConcernedDev1950 will go use a language that doesn't require them to write the standard library.
Apparently no, they come here and cry and get nothing done.
Yes, how dare people see D marketed as a non-alpha language then realize the language is actually still in an alpha-state.
Jan 27
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 28 January 2016 at 00:46:00 UTC, rsw0x wrote:

 Yes, how dare people see D marketed as a non-alpha language 
 then realize the language is actually still in an alpha-state.
It's not in an alpha state. It's a grassroots language. There's no other way to describe it. Being community driven, it moves in the direction and at the pace that the community drives it. There's no large team, no governing body, no committee to drive development. Everyone using it needs to accept that any particular personal peeve they have with the language are only going to get changed in one of two ways: there's enough momentum behind it to cause it to percolate up to the top of the priority list for the core developers, or if you do it yourself. That's what it boils down to. It's unreasonable to lambast the core developers as wanting to do nothing to improve the language. There are only so many hours in the day. Walter and Andrei care very much about this language. So do many others who are working to make it better, focusing on the areas that fit within their needs and their abilities. That's why it has come along as far as it has. Debate about which issues should take priority are certainly needed, but these threads that degenerate into bashing the core developers, or calling D a "toy" language, serve no purpose other than to waste bandwidth and make it difficult to discuss what really matters.
Jan 27
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jan 28, 2016 at 02:59:38AM +0000, Mike Parker via Digitalmars-d wrote:
 On Thursday, 28 January 2016 at 00:46:00 UTC, rsw0x wrote:
 
Yes, how dare people see D marketed as a non-alpha language then
realize the language is actually still in an alpha-state.
It's not in an alpha state. It's a grassroots language. There's no other way to describe it. Being community driven, it moves in the direction and at the pace that the community drives it. There's no large team, no governing body, no committee to drive development. Everyone using it needs to accept that any particular personal peeve they have with the language are only going to get changed in one of two ways: there's enough momentum behind it to cause it to percolate up to the top of the priority list for the core developers, or if you do it yourself. That's what it boils down to. It's unreasonable to lambast the core developers as wanting to do nothing to improve the language. There are only so many hours in the day. Walter and Andrei care very much about this language. So do many others who are working to make it better, focusing on the areas that fit within their needs and their abilities. That's why it has come along as far as it has. Debate about which issues should take priority are certainly needed, but these threads that degenerate into bashing the core developers, or calling D a "toy" language, serve no purpose other than to waste bandwidth and make it difficult to discuss what really matters.
+1, the voice of reason. T -- Debian GNU/Linux: Cray on your desktop.
Jan 27
prev sibling next sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Thursday, 28 January 2016 at 02:59:38 UTC, Mike Parker wrote:
 There's no large team, no governing body, no committee to drive 
 development. Everyone using it needs to accept that any 
 particular personal peeve they have with the language are only 
 going to get changed in one of two ways: there's enough 
 momentum behind it to cause it to percolate up to the top of 
 the priority list for the core developers, or if you do it 
 yourself. That's what it boils down to.
You know, this reminds me when i worked in a software company for a short while. I found it utterly aggravating. There was code i could work on and fix and do, but the whole structure of it required a number of things, including getting permission to work on it. You couldn't just work on it and get it working, you had to go through a series of steps to get approval to work on it. QA were a separate set of testers (who in my experience weren't coders so couldn't even get their tests to work), a database list of bugs and requests, and you didn't necessarily get any option of working on at all. Often i felt like i was sitting on my hands when it could have taken me 15 minutes to just fix the damn thing. I'm not saying a committee or governing body is bad, but when it's too large (or tries to be) then it becomes it's own bottleneck taking 100x longer than needed. My own preference for coding is 1) Get it to work, 2) Optimize, 3) Beautify it.
Jan 27
prev sibling parent Ola Foaheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 28 January 2016 at 02:59:38 UTC, Mike Parker wrote:
 On Thursday, 28 January 2016 at 00:46:00 UTC, rsw0x wrote:

 Yes, how dare people see D marketed as a non-alpha language 
 then realize the language is actually still in an alpha-state.
It's not in an alpha state. It's a grassroots language. There's no other way to describe it. Being community driven, it moves in the direction and at the pace that the community drives it.
That's not actually true, Walter ultimately decides everything. Lisp might have been grassroot, but only because it is 100% library driven. Leading to Common Lisp, Common Music etc...
 There's no large team, no governing body, no committee to drive 
 development. Everyone using it needs to accept that any 
 particular personal peeve they have with the language are only 
 going to get changed in one of two ways: there's enough 
 momentum behind it to cause it to percolate up to the top of 
 the priority list for the core developers, or if you do it 
 yourself. That's what it boils down to.
The point of this thread is that D would benefit from cutting the scope of no-gc management to deliver on time and gain momentum and build a larger team. It is about strategy. Telling people "DIY" or "submit PR" is off topic. That is not a viable strategy that can make D converge towards completion in a timely manner.
 Debate about which issues should take priority are certainly 
 needed, but these threads that degenerate into bashing the core 
 developers, or calling D a "toy" language, serve no purpose 
 other than to waste bandwidth and make it difficult to discuss 
 what really matters.
People read too much into "toy language". Many toy languages are better and more advanced than non-toy languages. They are just not designed and developed in a manner that lead to completion and often lack a formal specification. Some might argue that without a specfication you don't even have a language, you have an experimental prototype that could lead to a specified language. If it is impossible to implement a fully compatible D compiler without studying DMD it basically means that nobody knows what the D language is.
Jan 27
prev sibling parent reply bachmeier <no spam.com> writes:
On Wednesday, 27 January 2016 at 08:08:30 UTC, Tobias Müller 
wrote:

 If you want to attract new programmers you should stop 
 constantly bashing other programming languages on the public 
 forums.

 This is one thing that Rust got right.

 Tobi
I know I should just let this go, because time is valuable, but anyway... All language comparisons involve "bashing" other languages. Otherwise there is no answer when someone asks "Why language X rather than language Y?" Forget about random posters on a forum. Let's go to the Rust homepage, click the link https://github.com/ctjhoa/rust-learning and then click on Why Rust? http://www.oreilly.com/programming/free/files/why-rust.pdf That's not a random forum post. It's a document promoting Rust, linked on the Rust homepage, and produced by O'Reilly. Here are a few quotes: "It’s difficult to write secure code. It’s common for security exploits to leverage bugs in the way C and C++ programs handle memory, and it has been so at least since the Morris virus, the first Internet virus to be carefully analyzed, took advantage of a buffer overflow bug to propagate itself from one machine to the next in 1988." "It’s very difficult to write multithreaded code, which is the only way to exploit the abilities of modern machines. Each new generation of hardware brings us, instead of faster processors, more of them; now even midrange mobile devices have multiple cores. Taking advantage of this entails writing multithreaded code, but even experienced programmers approach that task with caution: concurrency introduces broad new classes of bugs, and can make ordinary bugs much harder to reproduce." "In allowing an array reference to affect the behavior of a subsequent return statement, my C compiler is fully standards-compliant. An “undefined” operation doesn’t just produce an unspecified result: it is allowed to cause the program to do anything at all." And ironically, in this very thread, a C++ programmer has called D a toy language.
Jan 27
next sibling parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Wednesday, 27 January 2016 at 15:14:07 UTC, bachmeier wrote:
 All language comparisons involve "bashing" other languages. 
 Otherwise there is no answer when someone asks "Why language X 
 rather than language Y?"
Sometimes it's just one language feature (or lack of it) that makes (or breaks) the decision to use it. If you step back and consider a starting point from which all discussions must eventually flow, that starting point is most likely C (I doubt assembly language is considered since it's too low level). So invariably there MUST be comparison and bashing between languages. Truthfully I'll happily bash C, it has a horrible memory management model that requires way too careful of management. But that doesn't mean it's a bad language, in many cases it's still a very very fine language, especially for writing code for PIC chips and the like.
 http://www.oreilly.com/programming/free/files/why-rust.pdf

 That's not a random forum post. It's a document promoting Rust, 
 linked on the Rust homepage, and produced by O'Reilly. Here are 
 a few quotes:

 <snip>
All of the quotes seem well thought out, and truthful. If Rust provides a good way to deal with and take advantage of the features, then they will probably get a wider audience.
 And ironically, in this very thread, a C++ programmer has 
 called D a toy language.
Toy language? I recall BASIC was considered a beginners language back in the day, and yet so much code is written with it. True since the language was more fully implemented on DOS with Qbasic and later Visual Basic; But as long as you can get the work done then I wouldn't see a problem
Jan 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 16:48:24 UTC, Era Scarecrow 
wrote:
  Toy language? I recall BASIC was considered a beginners 
 language back in the day, and yet so much code is written with 
 it. True since the language was more fully implemented on DOS 
 with Qbasic and later Visual Basic; But as long as you can get 
 the work done then I wouldn't see a problem
BASIC was polished and shipped with literally every single home computer in the 80s. Primitive yes, but widely used. Much more so than D. It did exactly what it was supposed to do and didn't have any incomplete features.
Jan 27
parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Wednesday, 27 January 2016 at 17:50:09 UTC, Ola Fosheim 
Grøstad wrote:
 BASIC was polished and shipped with literally every single home 
 computer in the 80s. Primitive yes, but widely used. Much more 
 so than D. It did exactly what it was supposed to do and didn't 
 have any incomplete features.
Well i'd say it had incomplete features, having goto/gosub and global variables; Although it worked it bred spaghetti code like crazy. I'm sure BASIC would have had more features if they could have fit them into the ROM; But like the TCC (Tiny C Compiler) they first added what was most important and added additional features afterwards until they couldn't fit anything else while shaving every byte they could along the way. Curiously i wrote a de-tokenizer a year or something ago and some of the features bled through a bit quite obviously; All math and number storage being done with a 6 byte BCD packed format (that I'm told is also used in calculators) while the line numbers were unsigned shorts (probably for sorting reasons). It had the interesting effect of having to convert the 16bit line number using division while printing the program out, and then just outputting the numbers for everything else with a quick conversion from BCD to string. But BASIC shined most when there was so little memory. It wasn't uncommon to have only 4k for available RAM; And you could write short yet useful programs in 4k.
Jan 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 19:42:46 UTC, Era Scarecrow 
wrote:
  Well i'd say it had incomplete features, having goto/gosub and 
 global variables; Although it worked it bred spaghetti code 
 like crazy.
Not incomplete features, just a very very very bad feature set. :-) I added my own BASIC instructions on the C64 when I was in my late teens. You had a section at address $C000 where you could put 4K of machine language without interfering with BASIC. I believe I added some commands for sound. Of course, there were also expansion cartridges that would give you extra commands and so on. BASIC was also the CLI, so it took the role as a primitive version of Bash on Unix.
  I'm sure BASIC would have had more features if they could have 
 fit them into the ROM;
I believe Microsoft made adaptions for each machine. The BASIC dialect could be quite different. Didn't matter too much, the hardware was different too ;-). Computer magazines had an enormous amount of listings of BASIC programs you could punch in. "Continued in next issue". :-D
 But BASIC shined most when there was so little memory. It 
 wasn't uncommon to have only 4k for available RAM; And you 
 could write short yet useful programs in 4k.
Yes, VIC20 had 3.5K left for BASIC.
Jan 28
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
https://www.reddit.com/r/cpp/comments/41uflq/bjarne_stroustrup_doing_an_ama/

Mentions D.
Jan 29
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 29 January 2016 at 10:43:08 UTC, Ola Fosheim Grøstad 
wrote:
 https://www.reddit.com/r/cpp/comments/41uflq/bjarne_stroustrup_doing_an_ama/

 Mentions D.
Since it is in danish, let me quickly translate the informative sections: Bjarne Stroustrup (translated from danish): The safety rules is part of the more extensive guidelines (https://github.com/isocpp/CppCoreGuidelines ) and supported by a small library (https://github.com/microsoft/gsl ) . We have "annotations" which can be used to neutralize the rules (as an "unsafe" annotation). We minimize their usage. Our goal is 100% safety and I assume that we will get as close to that goals as any language that can work directly with hardware. We already have 100% resource safety, and that is better than languages like Java and C#. I think all languages will become better in these areas.» On garbage collection: Bjarne Stroustrup (translated from danish): Yes, programming language creators and researchers have always been fascinated by garbage collection. I think that is a mistake: GC is not general - it cannot deal with non-memory resources - and is not ideal - it introduces a central facility in (otherwise) distributed systems. The good solution is to not produce garbage: http://www.stroustrup.com/resource-model.pdf . RAII is central in my ideas about programming. He also acknowledges scandinavian contributions to programming languages, the OO languages Simula and Beta.
Jan 29
parent bitwise <bitwise.pvt gmail.com> writes:
On Friday, 29 January 2016 at 11:08:41 UTC, Ola Fosheim Grøstad 
wrote:
 On garbage collection:

 Bjarne Stroustrup (translated from danish): Yes, programming 
 language creators and researchers have always been fascinated 
 by garbage collection. I think that is a mistake: GC is not 
 general - it cannot deal with non-memory resources - and is not 
 ideal - it introduces a central facility in (otherwise) 
 distributed systems. The good solution is to not produce 
 garbage: http://www.stroustrup.com/resource-model.pdf . RAII is 
 central in my ideas about programming.
+ucent.max Non-memory resource management. I really hope something gets figured out with lifetimes this year. Bit
Jan 29
prev sibling next sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Wednesday, 27 January 2016 at 15:14:07 UTC, bachmeier wrote:
 And ironically, in this very thread, a C++ programmer has 
 called D a toy language.
C++ programmer
No. I've been using D since 2012 and have ported two large personal academic codebases to it. Ignoring the issues D has or pretending they don't exist isn't helping D. Rust had explosive adoption despite targeting the same exact niche as D, there is **not** a lack of developers that want an alternative to C++. The entire point of this thread is what is D doing to keep up with Rust and C++17, the answer seems to be... not much. Maybe the developers around here haven't bothered to check C++17 features recently I guess.
Jan 27
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 17:20:37 UTC, rsw0x wrote:
 Rust had explosive adoption despite targeting the same exact 
 niche as D, there is **not** a lack of developers that want an 
 alternative to C++.
Indeed, and why do Rust have so many contributors to the essential infrastructure? Because they attract C/C++/academic developers that are capable and inclined to contribute to the essential infrastructure. I don't really see how attracting "scripty" programmers will significantly affect the number of contributors to compiler + tooling. I also don't think the current contributors contributing more will make a significant change.
Jan 27
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 15:14:07 UTC, bachmeier wrote:
 And ironically, in this very thread, a C++ programmer has 
 called D a toy language.
D is incomplete, unfinished, unspecified and unstable. C++14 is an ISO standard and has several independent implementations that are polished and stable compiler releases. That makes D a toy language and C++ an industry standard. Not very difficult to grok, I would think.
Jan 27
next sibling parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Wednesday, 27 January 2016 at 18:09:50 UTC, Ola Fosheim 
Grøstad wrote:
 On Wednesday, 27 January 2016 at 15:14:07 UTC, bachmeier wrote:
 And ironically, in this very thread, a C++ programmer has 
 called D a toy language.
D is incomplete, unfinished, unspecified and unstable. C++14 is an ISO standard and has several independent implementations that are polished and stable compiler releases. That makes D a toy language and C++ an industry standard. Not very difficult to grok, I would think.
It make its immature but come on, it's not a toy.
Jan 27
parent reply rsw0x <anonymous anonymous.com> writes:
On Wednesday, 27 January 2016 at 19:21:11 UTC, Abdulhaq wrote:
 On Wednesday, 27 January 2016 at 18:09:50 UTC, Ola Fosheim 
 Grøstad wrote:
 On Wednesday, 27 January 2016 at 15:14:07 UTC, bachmeier wrote:
 And ironically, in this very thread, a C++ programmer has 
 called D a toy language.
D is incomplete, unfinished, unspecified and unstable. C++14 is an ISO standard and has several independent implementations that are polished and stable compiler releases. That makes D a toy language and C++ an industry standard. Not very difficult to grok, I would think.
It make its immature but come on, it's not a toy.
Fits fairly well under Eric S. Raymond's toy language definition, actually.
Jan 27
parent Chris Wright <dhasenan gmail.com> writes:
On Wed, 27 Jan 2016 19:25:49 +0000, rsw0x wrote:

 On Wednesday, 27 January 2016 at 19:21:11 UTC, Abdulhaq wrote:
 On Wednesday, 27 January 2016 at 18:09:50 UTC, Ola Fosheim Grøstad
 wrote:
 On Wednesday, 27 January 2016 at 15:14:07 UTC, bachmeier wrote:
 And ironically, in this very thread, a C++ programmer has called D a
 toy language.
D is incomplete, unfinished, unspecified and unstable. C++14 is an ISO standard and has several independent implementations that are polished and stable compiler releases. That makes D a toy language and C++ an industry standard. Not very difficult to grok, I would think.
It make its immature but come on, it's not a toy.
Fits fairly well under Eric S. Raymond's toy language definition, actually.
I've seen almost nothing produced by Eric S Raymond besides a hypertext version of the INTERCAL spec and _The Cathedral and the Bazaar_. Oh, and some random conspiracy theorist on IRC making outrageous claims and ESR accepting them as absolute truth without a second thought. So I'm not sure why I should prioritize his definitions. More to the point, people here are using different definitions, which results in a profound lack of communication that looks like an argument with content but isn't. D is quite unlike languages intended and marketed as toys, such as GolfScript, Befunge, and Whitespace; or personal projects intended mostly as an exercise for the designer. Compared to them, D is a much better choice for use in production code. D is also somewhat unlike languages such as C++ and Java, which have reliable implementations, are well specified, and change at a pace that a Fortune 500 company can keep up with. Of the two, D's heart is in the C++/Java camp: it's intended for serious use, has features to make that feasible, and has a reliable core of features that work. However, it's not close enough -- not well versioned enough, doesn't have sufficiently stable tools -- for it to be generally wise to bet your company on it. D as a programming language is unlikely to stabilize any time soon. The release structure doesn't support it. The language spec is a living document rather than being versioned. This is useful for keeping everyone compatible with the newest features (you do it or nobody can use your library) but is bad for keeping your company's code working over the course of years without people having to update it to the latest language features. Companies typically stick to one version for quite some time, but in D's case, this means cutting off a number of third-party libraries. The tooling has improved over time. Five years ago, dsss was newfangled; now dub has consumed all. dfix and dfmt have only come up recently, and there's talk of including them in the standard distribution. And this is related, but it's not about the language as such: the library situation is improving, but slowly. In 2008 dsource.org hosted probably fifty projects. Eight years later, code.dlang.org indexes 650 packages. There are database adapters for a scant handful of databases. There are no Google or Amazon API clients. There are many missing things. *That* makes it hard to use D in production, even if the tooling and stability were there.
Jan 27
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 27 January 2016 at 18:09:50 UTC, Ola Fosheim 
Grøstad wrote:
 That makes D a toy language and C++ an industry standard.

 Not very difficult to grok, I would think.
Sure, but... https://www.youtube.com/watch?v=7FYTc55nGEI
Jan 27
prev sibling next sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Wednesday, 27 January 2016 at 00:16:58 UTC, Atila Neves wrote:
 I've recently spent about 2 or 3 months writing C++14 at work. 
 I ended up complaining a lot. Most of the time because I'd 
 written a bug that wouldn't have happened in D. The rest was 
 usually due to something supposedly simple taking an inordinate 
 amount of work.
The deepest I've personally gone into C++ was when writing a quicksort and other sort functions. The whole thing fell spectacularly apart for something that was tiny and obscure and looked correct. It was quite a pain.
 The penny really dropped when I wrote D again for the 1st time 
 after weeks and weeks of C++14. It was night and day. Suddenly 
 my thoughts started getting to converted to code all that 
 faster, with fewer bugs to distract and annoy me.
 Do you know how you split a string in C++? You install boost, 
 that's how.
Heh, considering strings are still based on C's implementation which null terminated, mostly due to memory constraints that the original computers had (64k, OR LESS of memory), EVERY byte was precious. I'm not sure how Boost would deal with splitting a string, but I can think of a way that would do the job (well two ways if you want one that doesn't mutate the original data). I personally think C++ should probably be abandoned for a better language since it's insistence on backwards compatibility chains it to some very bad design decisions; And it's horrid syntax *Yuck!* which has kept me from using it for over two decades; Not to mention the STL looks confusing and only makes some sense after a good video tutorial where the basics of the principles were explained. Good code and API's shouldn't need a lot of explaining to get them to work. Good design shouldn't need a lot of fiddling to get it to work in a way that logically makes sense.
Jan 26
prev sibling parent bachmeier <no spam.net> writes:
On Wednesday, 27 January 2016 at 00:16:58 UTC, Atila Neves wrote:
 On Tuesday, 26 January 2016 at 21:01:53 UTC, bachmeier wrote:
 "With C++xx, there's little benefit to switching" is a very 
 common sentiment among current C++ programmers. And it's 
 probably true.
It's not true. After failing to convince my coworkers to use D, I wondered about this. I actually thought, myself, that C++14 is good enough and nearly like writing D. I was wrong.
I definitely agree with you that D is the better choice for us. And I haven't talked to a random sample of thousands of C++ programmers, so I may be wrong. But my impression is that the C++ programmers of today are the modern version of the early programmers that refused to touch FORTRAN because they weren't about to use a compiler. They won't give up on a language in which they are so heavily invested, one which most of the world avoids, to use a language designed to be used by humans. For those of us that just want to get work done, D is a great choice, but we moved on from or never even started with C++.
Jan 26
prev sibling parent rsw0x <anonymous anonymous.com> writes:
On Tuesday, 26 January 2016 at 21:01:53 UTC, bachmeier wrote:
 "With C++xx, there's little benefit to switching" is a very 
 common sentiment among current C++ programmers. And it's 
 probably true. On the other hand, with a few exceptions, it's 
 hard to see someone choosing to learn C++ rather than D. Making 
 a push for those developers will be more productive.
If this was true, then Rust wouldn't have seen explosive popularity, as it targets the same niche as C++ does(except with a safety-oriented aspect.) crates.io has 21 million package downloads recorded, does dub has similar statistics we can compare it to?
Jan 26
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Tuesday, 26 January 2016 at 19:07:03 UTC, rsw0x wrote:
 I see C++17 and think of why I should keep using D when C++ is 
 aping a lot of its best features.
The real victory isn't, "Everyone carries our flag," it's "Everyone adopts our good ideas."
Jan 26
parent deadalnix <deadalnix gmail.com> writes:
On Tuesday, 26 January 2016 at 19:51:22 UTC, Joseph Rushton 
Wakeling wrote:
 On Tuesday, 26 January 2016 at 19:07:03 UTC, rsw0x wrote:
 I see C++17 and think of why I should keep using D when C++ is 
 aping a lot of its best features.
The real victory isn't, "Everyone carries our flag," it's "Everyone adopts our good ideas."
They invented it all as well.
Jan 26
prev sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Tuesday, 26 January 2016 at 18:57:45 UTC, deadalnix wrote:
 On Tuesday, 26 January 2016 at 15:59:37 UTC, Ola Fosheim 
 Grøstad wrote:
 On Tuesday, 26 January 2016 at 15:51:22 UTC, deadalnix wrote:
 On Tuesday, 26 January 2016 at 10:39:03 UTC, Ola Fosheim 
 Grøstad wrote:
 On Tuesday, 26 January 2016 at 09:33:22 UTC, deadalnix wrote:
 No that would be stupid to make that the default as it is 
 unsafe.
When would you estimate that D could have a production ready default memory managment solution (without GC)?
Now, D can do the exact same as C++ .
Not really, but that was not the question. So let me repeat: When would you estimate that D will have a production ready default memory management solution (without GC).
I don't think it is desirable. I do think we should focus on having GC.malloc/GC.free have the same level of perfs than malloc/free, which is very doable. Now as to when, well, I'm waiting for your PR.
They will never have the performance of e.g, jemalloc. re: GC in D, GC in D is a pipedream, if it wasn't, why is it still so horrible? Everyone keeps dancing around the fact that if the GC wasn't horrible, nobody would work around it. The fact that the GC has to be worked around is proof enough that the GC has failed.
Jan 26
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 26 January 2016 at 19:04:33 UTC, rsw0x wrote:
 Now as to when, well, I'm waiting for your PR.
They will never have the performance of e.g, jemalloc.
In fact I will. The design of SDC's GC is based on jemalloc after extensive discussion with Jason Evan. He is considering backporting part of the work in jemalloc. Namely, the only major additional work that need to be done is to write one uint per page on "large" allocations (namely 16kb - 192kb) in order to be able to detect internal pointers. Considering these aren't that common to boot, this is not expected to impact perfs significantly. On the other hand, D's type system can be leveraged to reduce lock contention on the GC (and not lock at all on thread local allocs). Really, there is a lot to be done here and I'm reluctant to push for more language things while what we have is far from top notch.
Jan 26
parent reply rsw0x <anonymous anonymous.com> writes:
On Tuesday, 26 January 2016 at 20:05:16 UTC, deadalnix wrote:
 On the other hand, D's type system can be leveraged to reduce 
 lock contention on the GC (and not lock at all on thread local 
 allocs).
There's no such thing in D. shared int* i = new int(5); int* l = new int(5); these call the same exact functions with the same exact typeid.
Jan 26
next sibling parent deadalnix <deadalnix gmail.com> writes:
On Tuesday, 26 January 2016 at 20:22:19 UTC, rsw0x wrote:
 On Tuesday, 26 January 2016 at 20:05:16 UTC, deadalnix wrote:
 On the other hand, D's type system can be leveraged to reduce 
 lock contention on the GC (and not lock at all on thread local 
 allocs).
There's no such thing in D. shared int* i = new int(5); int* l = new int(5); these call the same exact functions with the same exact typeid.
It doesn't have to. This is no secret that the current implementation is shit.
Jan 26
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Tue, 26 Jan 2016 20:22:19 +0000, rsw0x wrote:

 On Tuesday, 26 January 2016 at 20:05:16 UTC, deadalnix wrote:
 On the other hand, D's type system can be leveraged to reduce lock
 contention on the GC (and not lock at all on thread local allocs).
There's no such thing in D. shared int* i = new int(5); int* l = new int(5); these call the same exact functions with the same exact typeid.
Which means that the checks regarding shared are performed at compile time and not at runtime. That's perfectly valid. The type system is also mostly expressed at compile time -- there's no runtime check inserted at the start of each method ensuring that each of its class-based parameters is in fact of the required type. That's not a problem.
Jan 26
parent rsw0x <anonymous anonymous.com> writes:
On Tuesday, 26 January 2016 at 20:43:06 UTC, Chris Wright wrote:
 On Tue, 26 Jan 2016 20:22:19 +0000, rsw0x wrote:

 On Tuesday, 26 January 2016 at 20:05:16 UTC, deadalnix wrote:
 On the other hand, D's type system can be leveraged to reduce 
 lock contention on the GC (and not lock at all on thread 
 local allocs).
There's no such thing in D. shared int* i = new int(5); int* l = new int(5); these call the same exact functions with the same exact typeid.
Which means that the checks regarding shared are performed at compile time and not at runtime. That's perfectly valid. The type system is also mostly expressed at compile time -- there's no runtime check inserted at the start of each method ensuring that each of its class-based parameters is in fact of the required type. That's not a problem.
Yes, and what he said is not currently possible in D because there's no way to know if an allocation is shared or not implying that the language *does* need changes.
Jan 26
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Tue, 26 Jan 2016 19:04:33 +0000, rsw0x wrote:
 GC in D is a pipedream, if it wasn't, why is it still so horrible?
 Everyone keeps dancing around the fact that if the GC wasn't horrible,
 nobody would work around it.
Rather, if everyone believed the GC was awesome in all circumstances, nobody would work around it. It could be awesome in all circumstances, but if people believe otherwise, they'll try working around it. It could be generally awesome but bad for a certain use case, in which case people who need to support that use case will need to work around it. In this case, I think it's a marketing issue, not a technical one. D's being marketed as an alternative to C++, and existing C++ users tend to believe that any garbage collector is too slow to be usable.
Jan 26
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 20:40:50 UTC, Chris Wright wrote:
 In this case, I think it's a marketing issue, not a technical 
 one. D's being marketed as an alternative to C++, and existing 
 C++ users tend to believe that any garbage collector is too 
 slow to be usable.
Yes, I've noticed how some C++ programmers on reddit and other places say things like "I looked at the website for language X, but when I saw they mentioned using a GC I lost all interest".
Jan 26
parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 26 January 2016 at 20:49:33 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 26 January 2016 at 20:40:50 UTC, Chris Wright wrote:
 In this case, I think it's a marketing issue, not a technical 
 one. D's being marketed as an alternative to C++, and existing 
 C++ users tend to believe that any garbage collector is too 
 slow to be usable.
Yes, I've noticed how some C++ programmers on reddit and other places say things like "I looked at the website for language X, but when I saw they mentioned using a GC I lost all interest".
These are looking for a reason not to use X. They were never potential users.
Jan 26
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 22:36:34 UTC, deadalnix wrote:
 On Tuesday, 26 January 2016 at 20:49:33 UTC, Ola Fosheim 
 Grøstad wrote:
 Yes, I've noticed how some C++ programmers on reddit and other 
 places say things like "I looked at the website for language 
 X, but when I saw they mentioned using a GC I lost all 
 interest".
These are looking for a reason not to use X. They were never potential users.
Actually, I don't think so. They have just been disappointed by other languages with a GC and have dismissed GC as a viable solution for their type of programming (like DSP). I think being a non-GC programmer is a part of an _identity_ they take pride in. You might say that is akin to audiophiles, sometimes it makes sense, sometimes not?
Jan 26
prev sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Tuesday, 26 January 2016 at 20:40:50 UTC, Chris Wright wrote:
 On Tue, 26 Jan 2016 19:04:33 +0000, rsw0x wrote:
 GC in D is a pipedream, if it wasn't, why is it still so 
 horrible? Everyone keeps dancing around the fact that if the 
 GC wasn't horrible, nobody would work around it.
Rather, if everyone believed the GC was awesome in all circumstances, nobody would work around it. It could be awesome in all circumstances, but if people believe otherwise, they'll try working around it. It could be generally awesome but bad for a certain use case, in which case people who need to support that use case will need to work around it. In this case, I think it's a marketing issue, not a technical one. D's being marketed as an alternative to C++, and existing C++ users tend to believe that any garbage collector is too slow to be usable.
In any case where you attempt to write code in D that is equal in performance to C++, you must avoid the GC. Either stop advertising D as an alternative to C++ or do something about this, because as it stands it's dishonest to say that D achieves the same performance as C++ when hiding the asterisk that is "when you abandon 90% of the standard library and much of the core language itself while jumping through hoops"
Jan 26
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 21:15:07 UTC, rsw0x wrote:
 In any case where you attempt to write code in D that is equal 
 in performance to C++, you must avoid the GC.
Yes, I don't see why anyone should have to link in the GC if they don't want to use it.
Jan 26
parent reply Igor <Vladamir.I google.com> writes:
On Tuesday, 26 January 2016 at 21:21:53 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 26 January 2016 at 21:15:07 UTC, rsw0x wrote:
 In any case where you attempt to write code in D that is equal 
 in performance to C++, you must avoid the GC.
Yes, I don't see why anyone should have to link in the GC if they don't want to use it.
I think the leaders are in over their heads. They have no real vision or plan to make D the language it can be. They are satisfied with their niche in the programming world. They need a Steve Jobs type of person to make this stuff happen. Someone that understands what has to be done, in what order, and how to make it happen. What D lacks is organizational structure! It's akin to a bunch of kids programming in their bedrooms cobbling together stuff and being ecstatic that it works(for them at least). D is basically stagnate(bug fixes and piddly stuff don't count), which is pretty sad considering it looks to be a one of the best languages on the planet. If I said this stuff in North Korea I'd be hung!
Jan 26
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 21:50:58 UTC, Igor wrote:
 I think the leaders are in over their heads. They have no real 
 vision or plan to make D the language it can be. They are 
 satisfied with their niche in the programming world.
The vision statement says this: «Safety is a primary concern of all work, especially work involving early memory reclamation (below). Our main challenge for H1 2016 is to create a combination of language and library support for safe reference counting. We would also hopefully support ownership patterns such as uniqueness with borrowing.» And this: «"No GC" is a primary concern going forward for the standard library and client code. We need good language+library support and robust idioms to follow for good no-GC code.» These are very weak statements, and there are no estimates. So what does it mean? Planning in H1, design in H2, implementation after that and production ready in 2-10 years? If so, why put it in H1? What is the ETA? :-/
 If I said this stuff in North Korea I'd be hung!
There is quite a bit of whipping and screaming around here, but I have yet to see a hanging.
Jan 26
prev sibling next sibling parent tsbockman <thomas.bockman gmail.com> writes:
On Tuesday, 26 January 2016 at 21:50:58 UTC, Igor wrote:
 D is basically stagnate(bug fixes and piddly stuff don't
 count), which is pretty sad considering it looks to be a
 one of the best languages on the planet.
From this statement, I'm guessing that you started using D *very* recently. While there are certainly some major problems with D that need to be addressed, the idea that it is "stagnant" is ridiculous. Go download a version of DMD from a few years ago, and see how far you get with compiling any major, modern D project: http://downloads.dlang.org/releases/2012/ D has made *massive* strides forward in the last few years, and from what I see the pace of development has not slowed significantly. The real problem is simply that D2 is an extremely ambitious project, and it will take a further huge investment of developer resources to bring it to something resembling completion.
Jan 26
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Tuesday, 26 January 2016 at 21:50:58 UTC, Igor wrote:
 What D lacks is organizational structure! It's akin to a bunch 
 of kids programming in their bedrooms cobbling together stuff 
 and being ecstatic that it works(for them at least).
I'm going to chalk this up to lack of experience in volunteer based software projects.
 D is  basically stagnate(bug fixes and piddly stuff don't 
 count), which is pretty sad considering it looks to be a one of 
 the best languages on the planet.
This is absolutely ridiculous, I'm sorry, there's no other way to describe this. The sheer number of new language features, removals of bad ideas, and new library features makes C++ growth look glacial in comparison. I literally know of no other language than Python that has as quick a turnaround on new ideas than D has.
Jan 26
next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Wed, 27 Jan 2016 05:28:56 +0000, Jack Stouffer wrote:

 The sheer number of new language features, removals of bad ideas,
 and new library features makes C++ growth look glacial in comparison. I
 literally know of no other language than Python that has as quick a
 turnaround on new ideas than D has.
I think the general trend is to create a new language rather than evolve an existing one. It's easier to market.
Jan 26
parent Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 27 January 2016 at 05:41:18 UTC, Chris Wright wrote:
 I think the general trend is to create a new language rather 
 than evolve an existing one. It's easier to market.
I have to disagree with you there. The number of new languages per year that hit more than, let's say, 10,000 continuous users is quite small; in most years it's zero.
Jan 26
prev sibling parent reply Igor <Vladamir.I google.com> writes:
On Wednesday, 27 January 2016 at 05:28:56 UTC, Jack Stouffer 
wrote:
 On Tuesday, 26 January 2016 at 21:50:58 UTC, Igor wrote:
 What D lacks is organizational structure! It's akin to a bunch 
 of kids programming in their bedrooms cobbling together stuff 
 and being ecstatic that it works(for them at least).
I'm going to chalk this up to lack of experience in volunteer based software projects.
 D is  basically stagnate(bug fixes and piddly stuff don't 
 count), which is pretty sad considering it looks to be a one 
 of the best languages on the planet.
This is absolutely ridiculous, I'm sorry, there's no other way to describe this. The sheer number of new language features, removals of bad ideas, and new library features makes C++ growth look glacial in comparison. I literally know of no other language than Python that has as quick a turnaround on new ideas than D has.
Um, 1. I'm not comparing it to C++. 2. Compared to the explosion that D1 had several years ago and all the libraries that were create and all the work, D is relatively stagnate. Just because stuff is still happening doesn't mean anything. D has lost a lot of momentum in the Phobos\Tango mess and many of the eager programmers in D seemed to have moved on to greener pastures. It's been over 15 years since D's incarnation and one would expect it to be much much further along? "C was originally developed by Dennis Ritchie between 1969 and 1973". Within 10 years C as pretty much the defacto standard. Maybe D needs to create it's own OS built on an OOP foundation without all the pitfalls of modern windows, OSX and Linux? Maybe that will put it on the map.
Jan 27
next sibling parent Wilson <sdfdsfsdfsd sdasd.com> writes:
On Wednesday, 27 January 2016 at 22:32:33 UTC, Igor wrote:
 Maybe D needs to create it's own OS built on an OOP foundation 
 without all the pitfalls of modern windows, OSX and Linux? 
 Maybe that will put it on the map.
...I can't tell if you're being sarcastic or not...
Jan 27
prev sibling next sibling parent tsbockman <thomas.bockman gmail.com> writes:
On Wednesday, 27 January 2016 at 22:32:33 UTC, Igor wrote:
 Um,

 1. I'm not comparing it to C++.

 2. Compared to the explosion that D1 had several years ago and 
 all the libraries that were create and all the work, D is 
 relatively stagnate. Just because stuff is still happening 
 doesn't mean anything.
Then you're discussing a different topic than most everyone else in this thread. This thread began as a discussion of the language itself, not the D ecosystem as a whole. The explicit point of comparison is C++ (check the title and the O.P.). Of course, this forum goes off topic all the time, so I'm not saying there's necessarily anything wrong with changing the subject - I'm just pointing out why people were confused about your point.
Jan 27
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 27 January 2016 at 22:32:33 UTC, Igor wrote:

 2. Compared to the explosion that D1 had several years ago and 
 all the libraries that were create and all the work, D is 
 relatively stagnate. Just because stuff is still happening 
 doesn't mean anything.

 D has lost a lot of momentum in the Phobos\Tango mess and many 
 of the eager programmers in D seemed to have moved on to 
 greener pastures. It's been over 15 years since D's incarnation 
 and one would expect it to be much much further along?
Not even close. I've been following and using D since 2003 and maintaining Derelict since 2004. I was there through the Phobos/Tango divide and the transition to D2. I can tell you anecdotally that things are running on quite a larger scale now than at any other point during that time. More libraries to choose from, more newsgroup traffic, more new people asking questions, more downloads of the compiler (as per the charts Andrei periodically posts), and more across the board. D is much further along than it used to be.
Jan 27
parent Ola Foaheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 28 January 2016 at 02:46:05 UTC, Mike Parker wrote:
 Phobos/Tango divide and the transition to D2. I can tell you 
 anecdotally that things are running on quite a larger scale now 
 than at any other point during that time. More libraries to 
 choose from, more newsgroup traffic, more new people asking 
 questions, more downloads of the compiler (as per the charts 
 Andrei periodically posts), and more across the board. D is 
 much further along than it used to be.
A fair section of the hardcore C/C++ developers have been lost to C++ and Rust. An influx of non hardcore developers does not lead to increased momentum regarding compiler and tooling, but will most likely lead to a increased resistance to breaking changes. The measures of growth from search engines shows a loss of interest and stagnation. As far as I can tell the hardcore developers who once viewed D as an upcoming star they dabbled with in anticipation if what will come increasingly view as a something of the past. I believe these trends can turn around with the right strategy. With no clear strategy I predict that D will: 1. Loose attention of hardcore developers because of incompleteness. 2. Loose non hardcore developers to high level languages with better tooling and improving compilers/infrastructure. So clearly, delivering on time matters.
Jan 27
prev sibling next sibling parent reply Mathias Lang via Digitalmars-d <digitalmars-d puremagic.com> writes:
2016-01-26 22:15 GMT+01:00 rsw0x via Digitalmars-d <
digitalmars-d puremagic.com>:

 In any case where you attempt to write code in D that is equal in
 performance to C++, you must avoid the GC.
No. There are many places when performances could be optimized. The GC surely can be improved, but avoid it is no silver bullet, and I even doubt it has the most time spend / speedup ratio. And that's only taking speed into account. There are many more factor to take into account. Consistency / reliability should be the prime focus. Because I keep getting compiler bugs, almost on a weekly basis.
Jan 26
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 21:49:16 UTC, Mathias Lang wrote:
 2016-01-26 22:15 GMT+01:00 rsw0x via Digitalmars-d < 
 digitalmars-d puremagic.com>:

 In any case where you attempt to write code in D that is equal 
 in performance to C++, you must avoid the GC.
No. There are many places when performances could be optimized. The GC surely can be improved, but avoid it is no silver bullet, and I even doubt it has the most time spend / speedup ratio.
It is a silver bullet if you have: 1. latency requirements 2. memory consumption requirements 3. interfacing FFI requirements ...
Jan 26
parent rsw0x <anonymous anonymous.com> writes:
On Tuesday, 26 January 2016 at 21:52:32 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 26 January 2016 at 21:49:16 UTC, Mathias Lang wrote:
 2016-01-26 22:15 GMT+01:00 rsw0x via Digitalmars-d < 
 digitalmars-d puremagic.com>:

 In any case where you attempt to write code in D that is 
 equal in performance to C++, you must avoid the GC.
No. There are many places when performances could be optimized. The GC surely can be improved, but avoid it is no silver bullet, and I even doubt it has the most time spend / speedup ratio.
It is a silver bullet if you have: 1. latency requirements 2. memory consumption requirements 3. interfacing FFI requirements ...
4. multithreaded allocations because the entire thing is wrapped in a mutex
Jan 26
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Tue, 26 Jan 2016 21:15:07 +0000, rsw0x wrote:

 On Tuesday, 26 January 2016 at 20:40:50 UTC, Chris Wright wrote:
 On Tue, 26 Jan 2016 19:04:33 +0000, rsw0x wrote:
 GC in D is a pipedream, if it wasn't, why is it still so horrible?
 Everyone keeps dancing around the fact that if the GC wasn't horrible,
 nobody would work around it.
Rather, if everyone believed the GC was awesome in all circumstances, nobody would work around it. It could be awesome in all circumstances, but if people believe otherwise, they'll try working around it. It could be generally awesome but bad for a certain use case, in which case people who need to support that use case will need to work around it. In this case, I think it's a marketing issue, not a technical one. D's being marketed as an alternative to C++, and existing C++ users tend to believe that any garbage collector is too slow to be usable.
In any case where you attempt to write code in D that is equal in performance to C++, you must avoid the GC.
Over on d.learn there was a post by H.S. Teoh today about how a struct deserializer she wrote used techniques that absolutely require a GC in order to work without leaking memory everywhere. The version of the code without this technique was an order of magnitude slower. You could probably implement something in C++ that had similar performance, but you'd be writing a custom string type with reference counting, and it would be terribly annoying to use. But the huge reason that it's a marketing problem rather than a technical one is that I doubt most people care enough about performance most of the time to need to avoid garbage collection. The success of Unity3D shows that you can write games in garbage collected languages, and those have at least moderate latency requirements. If you're doing real-time programming, you do need to be very careful about the GC. If your entire application is real-time, then you can't use a GC at all. If portions of it have lower latency requirements, which, I'm told, is common, you can use nogc in strategic places, call GC.disable and GC.enable where appropriate, and enjoy the best of both worlds. A bit of digging suggests that real-time programs have troubles with malloc being too slow or having unpredictable latency, and there are a few specialized allocators for real-time systems. So this isn't so much a problem with GC in particular; it's more of a problem with general- purpose allocators.
Jan 26
parent reply rsw0x <anonymous anonymous.com> writes:
On Wednesday, 27 January 2016 at 05:32:04 UTC, Chris Wright wrote:
 On Tue, 26 Jan 2016 21:15:07 +0000, rsw0x wrote:

 On Tuesday, 26 January 2016 at 20:40:50 UTC, Chris Wright 
 wrote:
 On Tue, 26 Jan 2016 19:04:33 +0000, rsw0x wrote:
 GC in D is a pipedream, if it wasn't, why is it still so 
 horrible? Everyone keeps dancing around the fact that if the 
 GC wasn't horrible, nobody would work around it.
Rather, if everyone believed the GC was awesome in all circumstances, nobody would work around it. It could be awesome in all circumstances, but if people believe otherwise, they'll try working around it. It could be generally awesome but bad for a certain use case, in which case people who need to support that use case will need to work around it. In this case, I think it's a marketing issue, not a technical one. D's being marketed as an alternative to C++, and existing C++ users tend to believe that any garbage collector is too slow to be usable.
In any case where you attempt to write code in D that is equal in performance to C++, you must avoid the GC.
Over on d.learn there was a post by H.S. Teoh today about how a struct deserializer she wrote used techniques that absolutely require a GC in order to work without leaking memory everywhere. The version of the code without this technique was an order of magnitude slower. You could probably implement something in C++ that had similar performance, but you'd be writing a custom string type with reference counting, and it would be terribly annoying to use.
As I haven't reviewed the code, I'll leave no comment.
 But the huge reason that it's a marketing problem rather than a 
 technical one is that I doubt most people care enough about 
 performance most of the time to need to avoid garbage 
 collection. The success of Unity3D shows that you can write 
 games in garbage collected languages, and those have at least 
 moderate latency requirements.
Unity3D engine is written in C++, moot point. It's also well known in gaming communities for being incredibly underperforming. There's no "AAA" games written in Unity, just indie games and phone games. Hilariously enough, if you google "What major games have been made with Unity?" The first result(for me, anyways) was a reddit thread https://www.reddit.com/r/gamedev/comments/2qigo0/why_arent_more_aaa_games_developed_with_unity/ Top response "It's super easy to get from 0% to 90% in Unity but really hard to get from 90% to 100%.* The garbage collector is a major culprit in this."
 If you're doing real-time programming, you do need to be very 
 careful about the GC. If your entire application is real-time, 
 then you can't use a GC at all. If portions of it have lower 
 latency requirements, which, I'm told, is common, you can use 
  nogc in strategic places, call GC.disable and GC.enable where 
 appropriate, and enjoy the best of both worlds.
Except the GC has leaked into the entire language. Here's a fun idea, let's play "things that definitely should be usable in nogc but are unusable in nogc" all core.thread.* functions are unusable in nogc for some dumb reason mutexes, semaphores, condition variables et cetera are classes; I have an in-house library that essentially wraps pthread primitives in structs. I have no way to use exceptions in nogc outside of massive hacks, I have to resort to C error handling. I have to manually create my own functors to be able to capture variables by value in lambdas so that they're usable in nogc. How C++98. Alias template parameters are again massive hidden abusers of the GC. Data structures? Haha. Nothing. Logging? Time to create your own fprintf wrapper and wonder why you're not just using C directly. This is just a tiny sample of my experience using nogc.
 A bit of digging suggests that real-time programs have troubles 
 with malloc being too slow or having unpredictable latency, and 
 there are a few specialized allocators for real-time systems.
This is almost entirely applicable only to hard real-time. Note that hard real-time is a tiny minority of most real-time problems; it's almost always a variant of soft real-time.
 So this isn't so much a problem with GC in particular; it's 
 more of a problem with general- purpose allocators.
Yes, you allocate outside of the real-time parts and reuse memory in pools/buffers. This is completely against the grain of having a standard library that relies on a GC, the massive majority of Phobos(and hell, a lot of the runtime and language itself) is completely unusable in nogc code. The major problem with having a GC that it lulls developers into thinking it's okay to allocate *everywhere* because the cost of an allocation is now out of sight, and therefore, out of mind. This is doubly true for D's hidden allocations. As a quick example, a lot of the code Walter rewrote to use ranges in Phobos over last year(? I think?) runs magnitudes faster while not allocating at all. Yes, there are real-time garbage collectors. Yes, the London Stock Exchange did pay 18 million pounds to move away from C# to a low-latency C++ system despite this. NASDAQ's OMX system, to the best of my knowledge, uses Java. With the garbage collector disabled and replaced with a C++-like allocator(JavaOne 2007, NASDAQ's CIO discussed this, and it is also talked about by Irene Aldridge in her 2012 publication)
Jan 26
parent reply Mathias Lang via Digitalmars-d <digitalmars-d puremagic.com> writes:
2016-01-27 8:10 GMT+01:00 rsw0x via Digitalmars-d <
digitalmars-d puremagic.com>:

 I have to manually create my own functors to be able to capture variables
 by value in lambdas so that they're usable in  nogc. How C++98.
 Alias template parameters are again massive hidden abusers of the GC.
For delegate you can use `scope delegate`, which is stack-allocated. Using a sink-based approach like `toString` that specific point is quite easily solved. `scope` safety being unimplemented, it's also quite easy to abuse if you don't have control over the function decl: ``` import core.stdc.stdio; void main () nogc { string foobar = "Value"; scope sink = (int u) { printf("%s: %d\n", foobar.ptr, u); }; foo(sink); } void foo (void delegate (int) nogc sink) nogc { sink(42); } ``` Alternatively, you can make foo's parameter `scope` and use the literal inline, it's recognized by nogc.
Jan 27
parent reply rsw0x <anonymous anonymous.com> writes:
On Wednesday, 27 January 2016 at 08:48:20 UTC, Mathias Lang wrote:
 2016-01-27 8:10 GMT+01:00 rsw0x via Digitalmars-d < 
 digitalmars-d puremagic.com>:

 [...]
For delegate you can use `scope delegate`, which is stack-allocated. Using a sink-based approach like `toString` that specific point is quite easily solved. `scope` safety being unimplemented, it's also quite easy to abuse if you don't have control over the function decl: ``` import core.stdc.stdio; void main () nogc { string foobar = "Value"; scope sink = (int u) { printf("%s: %d\n", foobar.ptr, u); }; foo(sink); } void foo (void delegate (int) nogc sink) nogc { sink(42); } ``` Alternatively, you can make foo's parameter `scope` and use the literal inline, it's recognized by nogc.
This is not applicable in a scenario where I want to actually copy the parameters by value. It still captures the context, it just allows it to move down the stack.
Jan 27
parent Mathias Lang via Digitalmars-d <digitalmars-d puremagic.com> writes:
2016-01-27 9:56 GMT+01:00 rsw0x via Digitalmars-d <
digitalmars-d puremagic.com>:

 This is not applicable in a scenario where I want to actually copy the
 parameters by value.
 It still captures the context, it just allows it to move down the stack.
Then a library solution to do so is trivial.
Jan 27
prev sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
On Tuesday, 26 January 2016 at 15:51:22 UTC, deadalnix wrote:
 Now, D can do the exact same as C++ .
That is a lie. Large parts of druntime still allocate GC memory and thus will cause the GC to run. For example core.thread. We need a solution where druntime can be used without druntime ever doing a single allocation through the gc.
Jan 26
prev sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 26/01/16 11:33, deadalnix wrote:
 On Tuesday, 26 January 2016 at 09:16:47 UTC, Ola Fosheim Grøstad wrote:
 Would it be possible to make a fully compatible unique_ptr/shared_ptr
 solution that acts as the default memory management scheme in D within
 6 months?
Now if one want to use that, D is very capable of doing it already. Just won't make it the default (like it is not the default in C++ either).
I bring it up every time the subject comes up, in the hopes that at some point it will sink in. No, D is not capable of doing it already. Without 100% reliable destructors, RAII is simply not implementable. D's destructors are not guaranteed to run on 100% of fully initialized structs, which means that a RAII container has no way to make sure its resource is actually freed. It is up to the implementer. This eradicates almost all of the utility RAII was meant to provide. Shachar
Jan 27
next sibling parent reply Minas Mina <minas_0 hotmail.co.uk> writes:
On Wednesday, 27 January 2016 at 14:22:18 UTC, Shachar Shemesh 
wrote:
 On 26/01/16 11:33, deadalnix wrote:
 On Tuesday, 26 January 2016 at 09:16:47 UTC, Ola Fosheim 
 Grøstad wrote:
[...]
Now if one want to use that, D is very capable of doing it already. Just won't make it the default (like it is not the default in C++ either).
I bring it up every time the subject comes up, in the hopes that at some point it will sink in. No, D is not capable of doing it already. Without 100% reliable destructors, RAII is simply not implementable. D's destructors are not guaranteed to run on 100% of fully initialized structs, which means that a RAII container has no way to make sure its resource is actually freed. It is up to the implementer. This eradicates almost all of the utility RAII was meant to provide. Shachar
Can you show a case where this happens?
Jan 27
parent reply Shachar Shemesh <shachar weka.io> writes:
On 27/01/16 16:24, Minas Mina wrote:
 On Wednesday, 27 January 2016 at 14:22:18 UTC, Shachar Shemesh wrote:
 On 26/01/16 11:33, deadalnix wrote:
 On Tuesday, 26 January 2016 at 09:16:47 UTC, Ola Fosheim Grøstad wrote:
 [...]
Now if one want to use that, D is very capable of doing it already. Just won't make it the default (like it is not the default in C++ either).
I bring it up every time the subject comes up, in the hopes that at some point it will sink in. No, D is not capable of doing it already. Without 100% reliable destructors, RAII is simply not implementable. D's destructors are not guaranteed to run on 100% of fully initialized structs, which means that a RAII container has no way to make sure its resource is actually freed. It is up to the implementer. This eradicates almost all of the utility RAII was meant to provide. Shachar
Can you show a case where this happens?
Sure. Here it is, again: import std.stdio; struct RAII { int num; ~this() { writefln("Destructed %s", num); } } struct Container { int num; RAII raii; this(int num) { writefln("Constructing %s", num); this.num = num; raii = RAII(num); if( num==0 ) throw new Exception("Ooops"); } } void test(int num) { try { auto c = Container(num); writefln("Point %s", num); } catch(Exception ex) { writefln("Caught %s", ex.msg); } } void main() { test(1); test(0); }
Jan 27
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/27/2016 09:51 AM, Shachar Shemesh wrote:
 import std.stdio;

 struct RAII {
      int num;

      ~this() {
          writefln("Destructed %s", num);
      }
 }

 struct Container {
      int num;
      RAII raii;

      this(int num) {
          writefln("Constructing %s", num);
          this.num = num;
          raii = RAII(num);

          if( num==0 )
              throw new Exception("Ooops");
      }
 }

 void test(int num) {
      try {
          auto c = Container(num);
          writefln("Point %s", num);
      } catch(Exception ex) {
          writefln("Caught %s", ex.msg);
      }
 }

 void main()
 {
      test(1);
      test(0);
 }
Interesting. It may be worked around, but is arguably a mistake in the language definition. Have you submitted an issue for this? -- Andrei
Jan 27
next sibling parent reply ZombineDev <valid_email he.re> writes:
On Wednesday, 27 January 2016 at 17:08:09 UTC, Andrei 
Alexandrescu wrote:
 On 01/27/2016 09:51 AM, Shachar Shemesh wrote:
 import std.stdio;

 struct RAII {
      int num;

      ~this() {
          writefln("Destructed %s", num);
      }
 }

 struct Container {
      int num;
      RAII raii;

      this(int num) {
          writefln("Constructing %s", num);
          this.num = num;
          raii = RAII(num);

          if( num==0 )
              throw new Exception("Ooops");
      }
 }

 void test(int num) {
      try {
          auto c = Container(num);
          writefln("Point %s", num);
      } catch(Exception ex) {
          writefln("Caught %s", ex.msg);
      }
 }

 void main()
 {
      test(1);
      test(0);
 }
Interesting. It may be worked around, but is arguably a mistake in the language definition. Have you submitted an issue for this? -- Andrei
https://github.com/D-Programming-Language/dmd/pull/5151 has been on the table since Aug 14, 2015.
Jan 27
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/27/2016 03:09 PM, ZombineDev wrote:
 https://github.com/D-Programming-Language/dmd/pull/5151 has been on the
 table since Aug 14, 2015.
Thanks! I've initiated a follow up with Walter and Martin. -- Andrei
Jan 27
prev sibling parent Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Wednesday, 27 January 2016 at 17:08:09 UTC, Andrei 
Alexandrescu wrote:
 Interesting. It may be worked around, but is arguably a mistake 
 in the language definition. Have you submitted an issue for 
 this? -- Andrei
1) https://issues.dlang.org/show_bug.cgi?id=14246 Includes suggestion on how the compiler could handle it. 2) https://issues.dlang.org/show_bug.cgi?id=9704 Related issue with postblits. 3) https://issues.dlang.org/show_bug.cgi?id=2590 Here, Don suggests that it's not a bug because destructors should only run on fully constructed objects, referencing C++. However, IMO this is not a valid argument for D, as we have .init, which is always a valid state. It can still be debated whether the destructor of the failed object itself should run, but it should always be safe to run the destructors of members.
Jan 28
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 27 January 2016 at 14:22:18 UTC, Shachar Shemesh 
wrote:
 I bring it up every time the subject comes up, in the hopes 
 that at some point it will sink in.

 No, D is not capable of doing it already. Without 100% reliable 
 destructors, RAII is simply not implementable.

 D's destructors are not guaranteed to run on 100% of fully 
 initialized structs, which means that a RAII container has no 
 way to make sure its resource is actually freed. It is up to 
 the implementer. This eradicates almost all of the utility RAII 
 was meant to provide.

 Shachar
The only time it may not run, it is when these are collected by the GC. Which is not a problem if you want to use RAII, as in C++, to not use a GC. What need to sink in is that, when it come to RAII, you have all the same tool as in C++ and can do all the same shit (modulo internal pointers), as unasfely as in C++.
Jan 27
parent Chris Wright <dhasenan gmail.com> writes:
On Wed, 27 Jan 2016 20:28:42 +0000, deadalnix wrote:

 On Wednesday, 27 January 2016 at 14:22:18 UTC, Shachar Shemesh wrote:
 I bring it up every time the subject comes up, in the hopes that at
 some point it will sink in.

 No, D is not capable of doing it already. Without 100% reliable
 destructors, RAII is simply not implementable.

 D's destructors are not guaranteed to run on 100% of fully initialized
 structs, which means that a RAII container has no way to make sure its
 resource is actually freed. It is up to the implementer. This
 eradicates almost all of the utility RAII was meant to provide.

 Shachar
The only time it may not run, it is when these are collected by the GC. Which is not a problem if you want to use RAII, as in C++, to not use a GC.
Shachar Shemesh showed us that a struct's fields do not have their destructors called when the struct's constructor throws an exception. This doesn't make RAII impossible. It's an unexpected annoyance, though, and it complicates the use of RAII. On the plus side, there's a pull request to change this.
Jan 27
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
I humbly believe D should not care about C++ any more. It should 
take own path, and attract developers not just from the C++ camp.

No matter from which camp someone comes, that person will 
complain about something. Obviously, C/C++ programmers complain 
about GC because they are used to manage the memory manually. 
People from JVM (this is where I belong even though I use D for 
over 10 years) and .NET worlds can rightfully complain about many 
things especially in the area of business applications and 
systems, distributed systems (90% of big-data solutions run on 
Spark, Hadoop or Storm).

People from functional worlds will complain about OOP approach in 
the standard library. People from OOP world will complain about 
modules in the standard library that are done in more functional 
way...

Finding a balance is hard, and I humbly believe having all the 
features C++ has in D will help...
Jan 26
parent Dejan Lekic <dejan.lekic gmail.com> writes:
 Finding a balance is hard, and I humbly believe having all the 
 features C++ has in D will help...
Correction: ...WILL NOT help...
Jan 26
prev sibling next sibling parent reply Sergei Degtiarev <sdegtiarev yahoo.com> writes:
On Tuesday, 26 January 2016 at 09:16:47 UTC, Ola Fosheim Grøstad 
wrote:
 Just a thought:
 2. Converting C++ programmers is a good recruitment strategy.
 4. When C++17 is released, current C++ programmers will go "I 
 was ready to leave C++
 If not, what is the strategy behind focusing on interfacing 
 with C++? (Evaluated in relation to the C++17 release.)
I think, you see it at wrong angle. Yes, I am C++ programmer, and I love it, and I anticipate C++17 coming. And I also like D, and hope it eventually be another language I will be as fluent as I'm in C++ now, but I'm no way going to be "converted". If you are going to recruit those who about to abandon C++, you will have the worst part. Memory management review in D is a bright idea, and challenging project, it might be a dream project for some, so wouldn't it be better spoken as "attracting" C++ people instead of "converting" them? Sure, you will get much more enthusiasm talking about it this way. I believe, D and C++ are sibling languages and opposing them is kind of counterproductive.
Jan 26
next sibling parent reply Bubbasaur <bubba gmail.com> writes:
Really I don't get this talk about convert someone from a 
language x to y. It will be very hard, some are programming since 
a long time and many don't want to change no matter what, and 
there are other issues like jobs and so on.

I think we need to gather attention from new people that are 
entering in the field. So they don't mind to risk or try new 
languages.

If a guy wants a language that compiles to a native code, and 
it's "easier" than C++, has GC and so on, then he will be 
fascinated by D and finally you won a new user.
Jan 26
parent Sergei Degtiarev <sdegtiarev yahoo.com> writes:
On Wednesday, 27 January 2016 at 06:16:47 UTC, Bubbasaur wrote:
 Really I don't get this talk about convert someone from a 
 language x to y. It will be very hard, some are programming 
 since a long time and many don't want to change no matter what, 
 and there are other issues like jobs and so on.

 I think we need to gather attention from new people that are 
 entering in the field. So they don't mind to risk or try new 
 languages.

 If a guy wants a language that compiles to a native code, and 
 it's "easier" than C++, has GC and so on, then he will be 
 fascinated by D and finally you won a new user.
Absolutely, totally agree, and I am indeed one of these C++ programmers. I'm actually fascinated by different set of D features, but nevertheless.
Jan 27
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 03:06:35 UTC, Sergei Degtiarev 
wrote:
 I think, you see it at wrong angle. Yes, I am C++ programmer, 
 and I love it, and I anticipate C++17 coming. And I also like 
 D, and hope it eventually be another language I will be as 
 fluent as I'm in C++ now, but I'm no way going to be 
 "converted".
Please note that I am talking about getting C++ programmers to pick D for their weekend programming, not their work-related programming. C++ is a good recruitment platform because compiler programmers should: 1. like low level programming 2. understand the hardware 3. like to make code fast 4. be able to drop down to C/C++ for interfacing with backends But you also want them to have a good theoretical background. That makes for a much smaller population to recruit from.
 If you are going to recruit those who about to abandon C++, you 
 will have the worst part.
I don't think so. Most people with a comp. sci. background has known that C++ is a flawed language from it's inception. Those people are better qualified to do improve the language. What keeps C++ rolling is that no other language provides the full feature set in the right packaging. + frameworks.
 Memory management review in D is a bright idea, and challenging 
 project, it might be a dream project for some, so wouldn't it 
 be better spoken as "attracting" C++ people instead of 
 "converting" them? Sure, you will get much more enthusiasm 
 talking about it this way.
Ok, but if they don't favour D over C++, will they then have enough interest in D to work on the compiler + tooling? C++ and Rust have many more people working on compilers and tooling, so over time D either needs to expand the number of core "weekend" contributors or reduce the scope of the project.
Jan 26
prev sibling parent Wilson <sdfdsfsdfsd sdasd.com> writes:
I wouldn't be using D if there wasn't a way around the GC. I 
don't have a grudge against Garbage Collection, I just can't have 
all my threads paused in a real-time application for practical 
reasons. If a user is running my program on a slow machine and I 
need to run a lot of code per frame then I don't have time for a 
collection to run, not ever. I do have to jump through a few 
hoops but with each update of the language and standard library 
I've definitely noticed improvements in getting around the GC.

If you want C++ programmers then you need to make messing around 
with D be near _zero_ commitment. By that I mean that if you 
write some code in D you should be able to make it compatible 
with a C++ project with very little effort. I don't know how D 
handles this as I haven't needed to make my D code work in a 
project that's mostly written in C++, but I haven't seen a 
feature like this heavily marketed, which is what you'd want to 
do when appealing to C++ programmers.

The reverse sweetens the deal. If you can easily use your 
favorite C++ library when writing D code then there are no 
worries about having to roll your own. Having alternatives, 
ports, and bindings for major libraries is great, and D does have 
these for many libraries a C++ developer might want... but I'm 
not sure how someone would go about binding their own C++ code... 
I don't know if it's easy or a huge pain?

D looks better and feels better to write than C++ so retaining 
C++ developers isn't going to be an issue, just getting them to 
try it and providing them with access to the libraries they need 
is all you need to really do... and yeah, making coding without 
the GC more viable would help a lot. I mean, jumping through all 
the hoops to get around the GC is still better than working with 
C++, template semantics alone make up for that, but my life could 
be make a lot easier with less hoops.

The other thing that would really help is better IDE support... 
It might just be because I'm using Linux but I've really had to 
hack together something that supports my needs. Most C++ 
programmers are going to want an easy plugin solution into their 
IDE of choice, which might be VS, or it might be whatever fringe 
IDE that doesn't bug out on their system.
Jan 27