www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D street cred: Just a thought

reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
Just a thought for boosting D's street cred:

Perhaps...take a worthwhile C/C++ project with real potential, fork it, 
and port it to D. And make a real commitment to maintaining it. 
Obviously a bit of a gambit, granted, but the potential payout is 
improving a worthwhile tool's maintainability while showing off a 
real-world example of the benefits and practical worthiness of switching 
to D.

Just a thought.

In a similar vein, I have to say I'm thoroughly impressed with what I've 
learned of Mir. AIUI, aside from being a fantastic lib, it looks like a 
tool with very high widespread potential that's written in D, yet also 
targets, more or less, C/C++ users in addition to D users. A tactic I've 
definitely been in favor of[1] and would love to see pushed as far as it 
can go.

Rah rah, D, sys boom bah, insert mental image here of me 
<https://avatars1.githubusercontent.com/u/714873?v=3&s=460> with pom-poms ;)

[1] 
https://semitwist.com/articles/article/view/we-re-overlooking-a-key-part-of-c-c-d-user-migration
Mar 03
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Saturday, 4 March 2017 at 07:09:17 UTC, Nick Sabalausky 
(Abscissa) wrote:
 Just a thought for boosting D's street cred:

 Perhaps...take a worthwhile C/C++ project with real potential, 
 fork it, and port it to D. And make a real commitment to 
 maintaining it. Obviously a bit of a gambit, granted, but the 
 potential payout is improving a worthwhile tool's 
 maintainability while showing off a real-world example of the 
 benefits and practical worthiness of switching to D.

 Just a thought.

 In a similar vein, I have to say I'm thoroughly impressed with 
 what I've learned of Mir. AIUI, aside from being a fantastic 
 lib, it looks like a tool with very high widespread potential 
 that's written in D, yet also targets, more or less, C/C++ 
 users in addition to D users. A tactic I've definitely been in 
 favor of[1] and would love to see pushed as far as it can go.

 Rah rah, D, sys boom bah, insert mental image here of me 
 <https://avatars1.githubusercontent.com/u/714873?v=3&s=460> 
 with pom-poms ;)

 [1] 
 https://semitwist.com/articles/article/view/we-re-overlooking-a-key-part-of-c-c-d-user-migration
I recently ported this small C++/OpenGL ES 2.0 Android app to D, just finished fixing the last bug I know of: https://developer.android.com/ndk/samples/sample_teapot.html https://github.com/googlesamples/android-ndk/tree/master/teapots/classic-teapot/src/main I need to clean up the source now and commit it to the app samples section in my Android repo: https://github.com/joakim-noah/android/tree/master/samples All the apps there are tiny ports from the C samples for the Android NDK. Obviously not a bigger project like you had in mind, but just thought I'd mention this one.
Mar 03
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 03/04/2017 02:29 AM, Joakim wrote:
 I recently ported this small C++/OpenGL ES 2.0 Android app to D, just
 finished fixing the last bug I know of:
[...]
 Obviously not a bigger project like you had in mind, but just thought
 I'd mention this one.
Actually, that's very cool, particularly since it's Android. In fact, it's one I did specifically have in mind that would be great to see ported to D. Looking forward to seeing the result!
Mar 03
prev sibling next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Saturday, 4 March 2017 at 07:09:17 UTC, Nick Sabalausky 
(Abscissa) wrote:
 Just a thought for boosting D's street cred:

 Perhaps...take a worthwhile C/C++ project with real potential, 
 fork it, and port it to D. And make a real commitment to 
 maintaining it. Obviously a bit of a gambit, granted, but the 
 potential payout is improving a worthwhile tool's 
 maintainability while showing off a real-world example of the 
 benefits and practical worthiness of switching to D.
The compiler front-end did just that. I can not comment on the quality of the code but on the speed of compilation, wow, just wow. Building v2.067 takes 1'38" on the server at work (westmere at 2.2 GHz, gcc 6.2, dmd v2.073, single core build). Building v2.073 takes 0'15" and most of that time is taken by building the backend which is still in C++. If that were rewritten in D, I suppose building the compiler would take 2 or 3 seconds max.
Mar 04
parent Daniel Murphy <yebbliesnospam gmail.com> writes:
On 4/03/2017 7:10 PM, Patrick Schluter wrote:
 The compiler front-end did just that. I can not comment on the quality
 of the code but on the speed of compilation, wow, just wow.

 Building v2.067 takes 1'38" on the server at work (westmere at 2.2 GHz,
 gcc 6.2, dmd v2.073, single core build).
 Building v2.073 takes 0'15" and most of that time is taken by building
 the backend which is still in C++.
 If that were rewritten in D, I suppose building the compiler would take
 2 or 3 seconds max.
Yup. And the same exact approach would be applicable to many other large C++ projects. Most would be easier than converting the D compiler, because a huge part of the work was perfectly matching the C++ ABI so the glue layer/backend could still be in C++. I did consider trying this with some other projects but there really aren't any large C++ projects I work with frequently enough for this to be worth the time. LLVM would probably be a good project, but without someone to maintain the fork and zero chance of switching upstream to D, there isn't much point. It's worth noting that maintaining an automatically converted fork is much much less work than maintaining a manually converted fork.
Mar 09
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Nick Sabalausky (Abscissa) wrote:

 Just a thought for boosting D's street cred:

 Perhaps...take a worthwhile C/C++ project with real potential, fork it, 
 and port it to D. And make a real commitment to maintaining it. 
 Obviously a bit of a gambit, granted, but the potential payout is 
 improving a worthwhile tool's maintainability while showing off a 
 real-world example of the benefits and practical worthiness of switching 
 to D.

 Just a thought.
my 1 cent: we should stop trying to convert C++ users.
Mar 04
parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Saturday, 4 March 2017 at 13:24:25 UTC, ketmar wrote:
 Nick Sabalausky (Abscissa) wrote:

 Just a thought for boosting D's street cred:

 Perhaps...take a worthwhile C/C++ project with real potential, 
 fork it, and port it to D. And make a real commitment to 
 maintaining it. Obviously a bit of a gambit, granted, but the 
 potential payout is improving a worthwhile tool's 
 maintainability while showing off a real-world example of the 
 benefits and practical worthiness of switching to D.

 Just a thought.
my 1 cent: we should stop trying to convert C++ users.
Please, do no push devs to do not do something. There are two directions: betterC and DRuntime. I believe in betterC and betterC target is C/C++ industry. Old D users are happy with DRuntime and growing Phobos. This ways are not compatible at least for now. Mir libraries are going to be betterC, the next great betterC goal is DCV. Ilya
Mar 04
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Saturday, 4 March 2017 at 15:35:13 UTC, Ilya Yaroshenko wrote:
 [...]
 my 1 cent: we should stop trying to convert C++ users.
Please, do no push devs to do not do something. There are two directions: betterC and DRuntime.
I've tried to follow the "betterC" discussion, but so far a precise specification of what betterC is supposed to be eluded me. What I got was that you seem to be judging druntime to be too heavyweight and want something more lightweight, but I was never clear on what exactly.
 I believe in betterC and  betterC target is C/C++ industry. Old 
 D users are happy with DRuntime and growing Phobos.
Please don't throw all "old D users" in the same category, generalizations like that only alienate. On a related note: What I believe in is that D's community can't take another rift like Phobos/Tango, D1/D2, so I've been very skeptical regarding the value of betterC. This doesn't mean I'm happy with druntime and phobos, though.
 This ways are not compatible at least for now.
I must have missed that: Are you saying that someone using druntime in his application will not be able to use "betterC" libraries?
 Mir libraries are going to be betterC, the next great betterC 
 goal is DCV.

 Ilya
Would it be possible for you to provide a precise specification of what exactly betterC is going to be? Or, if that already exists, and I have missed it, point me to it?
Mar 04
parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Saturday, 4 March 2017 at 16:43:21 UTC, Moritz Maxeiner wrote:
 On Saturday, 4 March 2017 at 15:35:13 UTC, Ilya Yaroshenko 
 wrote:
 [...]
 my 1 cent: we should stop trying to convert C++ users.
Please, do no push devs to do not do something. There are two directions: betterC and DRuntime.
I've tried to follow the "betterC" discussion, but so far a precise specification of what betterC is supposed to be eluded me. What I got was that you seem to be judging druntime to be too heavyweight and want something more lightweight, but I was never clear on what exactly.
 I believe in betterC and  betterC target is C/C++ industry. 
 Old D users are happy with DRuntime and growing Phobos.
Please don't throw all "old D users" in the same category, generalizations like that only alienate. On a related note: What I believe in is that D's community can't take another rift like Phobos/Tango, D1/D2, so I've been very skeptical regarding the value of betterC.
I don't care about existing D users. Sorry about that. In the same time I do not see any problem with betterC for existing D users. Any betterC library can be used with Druntime like either a common C library or generic D library.
 This doesn't mean I'm happy with druntime and phobos, though.
Yep. Additions to std.range like orElse will make idiomatic Phobos code slower then C++ and Scala. It is not clear when you do a benchmark for single implementation, but idiomatic combinations of D Ranges will became slow.
 This ways are not compatible at least for now.
I must have missed that: Are you saying that someone using druntime in his application will not be able to use "betterC" libraries?
No, betterC libraries can be used by D apps like a common C libs.
 Mir libraries are going to be betterC, the next great betterC 
 goal is DCV.

 Ilya
Would it be possible for you to provide a precise specification of what exactly betterC is going to be? Or, if that already exists, and I have missed it, point me to it?
betterC is wide concept. Examples: A generic betterC library can be used to write precompiled betterC libraries. Example: https://github.com/libmir/mir-algorithm A precompiled betterC library in binary form is a library with extern(C) API that can be used without DRuntime by other libraries, apps, and languages (!!!). Examples: https://github.com/tamediadigital/hll-d https://github.com/libmir/mir-cpuid https://github.com/libmir/mir-glas Why without DRuntime? I had explained this multiple times. 1. DRuntime has not stable ABI between versions 2. DRuntime has not stable ABI between compilers 3. DRuntime depends on GC, D GC is slow, and because D design GC will always will be slow. 1,2,3 are important for real world business. Most of existing D users do not need 1-3 (otherwise they would switch to C). So, I do not expect any understanding from the community about my opinion :P
Mar 04
next sibling parent reply Arun Chandrasekaran <aruncxy gmail.com> writes:
On Sunday, 5 March 2017 at 05:45:19 UTC, Ilya Yaroshenko wrote:
 Why without DRuntime? I had explained this multiple times.
Could this be captured in a wiki or somewhere in a more positive tone so that new comers are not scared by the first look of it?
 because D design GC will always will be slow.
Can you please elaborate on this? Which design choice and why?
 1,2,3 are important for real world business.
+1
Mar 05
parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Sunday, 5 March 2017 at 08:49:33 UTC, Arun Chandrasekaran 
wrote:
 On Sunday, 5 March 2017 at 05:45:19 UTC, Ilya Yaroshenko wrote:
 Why without DRuntime? I had explained this multiple times.
Could this be captured in a wiki or somewhere in a more positive tone so that new comers are not scared by the first look of it?
They are https://gist.github.com/ximion/fe6264481319dd94c8308b1ea4e8207a https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b
 because D design GC will always will be slow.
Can you please elaborate on this? Which design choice and why?
Please read this: http://forum.dlang.org/post/oetnnywqhcedrnvxukcy forum.dlang.org http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e#.6zz5an77a
 1,2,3 are important for real world business.
+1
Mar 05
parent Moritz Maxeiner <moritz ucworks.org> writes:
On Sunday, 5 March 2017 at 09:27:25 UTC, Ilya Yaroshenko wrote:
 [...]
 Can you please elaborate on this? Which design choice and why?
Please read this: http://forum.dlang.org/post/oetnnywqhcedrnvxukcy forum.dlang.org http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e#.6zz5an77a
Thank you for this, please disregard my request for clarification on this point in my other post.
Mar 05
prev sibling next sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
On Sunday, 5 March 2017 at 05:45:19 UTC, Ilya Yaroshenko wrote:
 On Saturday, 4 March 2017 at 16:43:21 UTC, Moritz Maxeiner 
 wrote:
 Please don't throw all "old D users" in the same category, 
 generalizations like that only alienate. On a related note: 
 What I believe in is that D's community can't take another 
 rift like Phobos/Tango, D1/D2, so I've been very skeptical 
 regarding the value of betterC.
I don't care about existing D users. Sorry about that. In the same time I do not see any problem with betterC for existing D users. Any betterC library can be used with Druntime like either a common C library or generic D library.
I'm not asking you to, but imho it would benefit you to care about pushing people away from your betterC idea by misrepresenting them like that (as it steers from a technical discussion to an emotional debate). And since AFAICT you still use a D compiler adhering to a D spec, which likely contains bugs, I do think it would benefit you to care about the D ecosystem as a whole, since the smaller the ecosystem the unlikelier it becomes that bugs in the compiler get detected, reported, and fixed. In any case, as long as you don't intend to create some incompatible rift (which I wasn't clear on up till now) I'm happy.
[...]

 No, betterC libraries can be used by D apps like a common C 
 libs.
Ok, thank you for the clear confirmation.
[...]

 betterC is wide concept. Examples:

 A generic betterC library can be used to write precompiled 
 betterC libraries. Example:
 https://github.com/libmir/mir-algorithm

 A precompiled betterC library in binary form is a library with 
 extern(C) API that can be used without DRuntime by other 
 libraries, apps, and languages (!!!). Examples:

 https://github.com/tamediadigital/hll-d
 https://github.com/libmir/mir-cpuid
 https://github.com/libmir/mir-glas
Thanks for the examples, I'll have a look at how they work.
 Why without DRuntime? I had explained this multiple times.
 1. DRuntime has not stable ABI between versions
 2. DRuntime has not stable ABI between compilers
 3. DRuntime depends on GC, D GC is slow,
Yeah, I got why you don't want to use druntime (and 1+2 are one one the things I'm not happy about), I just wasn't clear on whether you planned to replace it with something else (or just don't use any runtime, like you are). This is quite interesting, since the primary reason for druntime's existence IIRC was the Phobos/Tango split where people didn't like Phobos, hence for consolidation, it was split into only the minimal parts to support the language features (druntime) and the new Phobos, so people using different standard libraries for D wouldn't be incompatible (since they share a common druntime).
 and because D design GC will always will be slow.
I was not aware of that: Am I right in understanding here that there is something about the language itself that inherently makes any attempt at using any GC slow? There is no possible way to implement a fast GC for D?
 1,2,3 are important for real world business.
Correct me if I'm wrong, but I was under the impression that Sociomantic Labs was using D1 (which contains the GC that's now in druntime AFAIK) extensively for extremely time-sensitive tasks (web advertisement auctions in the microsecond range IIRC). Druntime implements the GC and several features in it depend on the GC, yes, but linking against druntime doesn't - AFAIK - necessitate actually using any of those features, i.e. linking against druntime should not inherently result in any slow down. Regardless, I can see why one wouldn't want to link against a library one doesn't actually use.
 Most of existing D  users do not need 1-3 (otherwise they would 
 switch to C).
I agree that most don't seem to need them from my POV, but I don't agree with the assumption that people switching to C is a necessary conclusion from people needing them.
 So, I do not expect any understanding from the community about 
 my opinion :P
This is bordering on being derogative, though, since AFAIK we are supposed to be in a forum for (technical) discussions, not (political) debates, i.e. facts and reasoning are important as opposed to anyone's opinion. These are the facts as I now see them (after your explanation): 1. You need to expose a stable ABI between compilations/releases of a library 2. You need to be as fast as possible. 3. 1. and 2. are hard requirements, i.e. you cannot change them. Analysis: Does linking with druntime and/or phobos get in the way of 1. or 2.? 1. If you depend on any symbols from them, yes. Otherwise, no. 2. No Conclusion: You cannot depend on any symbols from druntime or phobos. Corollary: You don't need to link against druntime or phobos. You don't need to worry (or care at all) about anyone's understanding of any of your opinions, you just need to lay out the facts and reason about them.
Mar 05
prev sibling next sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
On Sunday, 5 March 2017 at 05:45:19 UTC, Ilya Yaroshenko wrote:
 On Saturday, 4 March 2017 at 16:43:21 UTC, Moritz Maxeiner [...]

 This doesn't mean I'm happy with druntime and phobos, though.
Yep. Additions to std.range like orElse will make idiomatic Phobos code slower then C++ and Scala. It is not clear when you do a benchmark for single implementation, but idiomatic combinations of D Ranges will became slow.
Sorry for the double post, I missed this section in my earlier reply. Could you elaborate on why that is (probable another link to a discussion I missed xD )?
Mar 05
prev sibling next sibling parent reply XavierAP <n3minis-git yahoo.es> writes:
On Sunday, 5 March 2017 at 05:45:19 UTC, Ilya Yaroshenko wrote:
 1. DRuntime has not stable ABI between versions
 2. DRuntime has not stable ABI between compilers
Anyone can shed light on why this is so? Is there just too much evolution at the moment that the ABI needs to be constantly updated? Or was there a failure to include sufficient ABI, name mangling etc. rules into the specificiation? Can this be expected to change in the foreseeable future?
 slow.
This reminds me my last discussion with the C++ guru at work... Every complaint of mine against the language, he argued against in terms of performance. I felt every argument of this could be reused to abandon C++ in favor of C (which would make me happy lol).
Mar 05
next sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
On Sunday, 5 March 2017 at 14:27:28 UTC, XavierAP wrote:
 On Sunday, 5 March 2017 at 05:45:19 UTC, Ilya Yaroshenko wrote:
 1. DRuntime has not stable ABI between versions
 2. DRuntime has not stable ABI between compilers
Anyone can shed light on why this is so? Is there just too much evolution at the moment that the ABI needs to be constantly updated? Or was there a failure to include sufficient ABI, name mangling etc. rules into the specificiation? Can this be expected to change in the foreseeable future?
See [1] and in particular [2] for how horrible this can be if that's something you care about. There's a reason why dub packages are compiled (automatically) locally for your current toolchain.
 slow.
This reminds me my last discussion with the C++ guru at work... Every complaint of mine against the language, he argued against in terms of performance. I felt every argument of this could be reused to abandon C++ in favor of C (which would make me happy lol).
<sarcasm> Assembler code is best code! </sarcasm> [1] https://forum.dlang.org/thread/ivbnsgqoyjrxkkhvzhcg forum.dlang.org?page=1 [2] https://forum.dlang.org/post/20160421194152.51652783 gmx.de
Mar 05
prev sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 03/05/2017 09:27 AM, XavierAP wrote:
 This reminds me my last discussion with the C++ guru at work... Every
 complaint of mine against the language, he argued against in terms of
 performance. I felt every argument of this could be reused to abandon
 C++ in favor of C (which would make me happy lol).
What OOP is to Java, and functional is to Haskell, that's what premature optimization is to C/C++.
Mar 05
prev sibling next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 5 March 2017 at 06:45, Ilya Yaroshenko via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Saturday, 4 March 2017 at 16:43:21 UTC, Moritz Maxeiner wrote:
 On Saturday, 4 March 2017 at 15:35:13 UTC, Ilya Yaroshenko wrote:
 [...]
 my 1 cent: we should stop trying to convert C++ users.
Please, do no push devs to do not do something. There are two directions: betterC and DRuntime.
I've tried to follow the "betterC" discussion, but so far a precise specification of what betterC is supposed to be eluded me. What I got was that you seem to be judging druntime to be too heavyweight and want something more lightweight, but I was never clear on what exactly.
 I believe in betterC and  betterC target is C/C++ industry. Old D users
 are happy with DRuntime and growing Phobos.
Please don't throw all "old D users" in the same category, generalizations like that only alienate. On a related note: What I believe in is that D's community can't take another rift like Phobos/Tango, D1/D2, so I've been very skeptical regarding the value of betterC.
I don't care about existing D users. Sorry about that. In the same time I do not see any problem with betterC for existing D users. Any betterC library can be used with Druntime like either a common C library or generic D library.
 This doesn't mean I'm happy with druntime and phobos, though.
Yep. Additions to std.range like orElse will make idiomatic Phobos code slower then C++ and Scala. It is not clear when you do a benchmark for single implementation, but idiomatic combinations of D Ranges will became slow.
 This ways are not compatible at least for now.
I must have missed that: Are you saying that someone using druntime in his application will not be able to use "betterC" libraries?
No, betterC libraries can be used by D apps like a common C libs.
Ha! Did no one tell you any horror stories about people dealing with C++ ABIs? If this is the essentially the crux of your problem, then you are barking up the wrong tree in blaming druntime for the mess we are allegedly in.
 Mir libraries are going to be betterC, the next great betterC goal is
 DCV.

 Ilya
Would it be possible for you to provide a precise specification of what exactly betterC is going to be? Or, if that already exists, and I have missed it, point me to it?
betterC is wide concept. Examples: A generic betterC library can be used to write precompiled betterC libraries. Example: https://github.com/libmir/mir-algorithm A precompiled betterC library in binary form is a library with extern(C) API that can be used without DRuntime by other libraries, apps, and languages (!!!). Examples: https://github.com/tamediadigital/hll-d https://github.com/libmir/mir-cpuid https://github.com/libmir/mir-glas Why without DRuntime? I had explained this multiple times. 1. DRuntime has not stable ABI between versions
I was curious to see if there were any ABI changes in GDC with functions that it generates code for, and the first I found was 5 years ago, where _aaDelp (DMD didn't support a non-variadic 'delete aa' at the time) had it's return type changed from void to bool. Changes since then have either been functions added or functions removed - but only *after* the compiler stopped generating calls to it some 2 years down the line. So I am a bit amused when you say that ABI is not stable.
 2. DRuntime has not stable ABI between compilers
I think you mean common ABI. GDC and LDC should be compatible on anything that is extern(C). Feel free to request an apology from DMD however for using a made up calling convention, which has single-handedly caused the biggest rift between us and them.
 3. DRuntime depends on GC, D GC is slow, and because D design GC will always
 will be slow.

 1,2,3 are important for real world business. Most of existing D users do not
 need 1-3 (otherwise they would switch to C). So, I do not expect any
 understanding from the community about my opinion :P
I think this deserves only a blink. Considering that there are some companies out there, using real-time applications that make use of D's GC also (of course, within reason). The only feedback I can offer you here is that not only should you expect community to not understand you, real world business won't understand you either.
Mar 05
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Sunday, 5 March 2017 at 05:45:19 UTC, Ilya Yaroshenko wrote:
 I don't care about existing D users. Sorry about that. In the 
 same time I do not see any problem with betterC for existing D 
 users. Any betterC library can be used with Druntime like 
 either a common C library or generic D library.
But you're not going to convince any existing D users with that attitude.
Mar 05
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
Ilya Yaroshenko wrote:

 I don't care about existing D users.
i wonder if "existing D users" care about your "betterC" and other initiatives then. rethorical sentence, no need to answer to it.
Mar 07
prev sibling next sibling parent reply Gerald <gerald.b.nunn gmail.com> writes:
On Saturday, 4 March 2017 at 07:09:17 UTC, Nick Sabalausky 
(Abscissa) wrote:
 Perhaps...take a worthwhile C/C++ project with real potential, 
 fork it, and port it to D. And make a real commitment to 
 maintaining it. Obviously a bit of a gambit, granted, but the 
 potential payout is improving a worthwhile tool's 
 maintainability while showing off a real-world example of the 
 benefits and practical worthiness of switching to D.

 Just a thought.
Maybe it's just me and this isn't to pick on you specifically, but I'm getting tired of all of these threads where people tout various ideas/actions as a way to improve D, make it more popular, cure cancer, solve world hunger, etc with no actual action by the original poster. If you feel strongly about it, then follow the Nike slogan and "Just do it".
Mar 04
next sibling parent XavierAP <n3minis-git yahoo.es> writes:
On Saturday, 4 March 2017 at 16:03:46 UTC, Gerald wrote:
 Maybe it's just me and this isn't to pick on you specifically, 
 but I'm getting tired of all of these threads where people tout 
 various ideas/actions as a way to improve D, make it more 
 popular, cure cancer, solve world hunger, etc with no actual 
 action by the original poster. If you feel strongly about it, 
 then follow the Nike slogan and "Just do it".
These discussion will always come up... but imo it's a good reason why development threads should have their own board separate from General.
Mar 04
prev sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 03/04/2017 11:03 AM, Gerald wrote:
 On Saturday, 4 March 2017 at 07:09:17 UTC, Nick Sabalausky (Abscissa)
 wrote:
 Just a thought.
Maybe it's just me and this isn't to pick on you specifically, but I'm getting tired of all of these threads where people tout various ideas/actions as a way to improve D, make it more popular, cure cancer, solve world hunger, etc with no actual action by the original poster. If you feel strongly about it, then follow the Nike slogan and "Just do it".
*Ahem* "Just a thought." ;)
Mar 04
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 4 March 2017 at 07:09:17 UTC, Nick Sabalausky 
(Abscissa) wrote:
 In a similar vein, I have to say I'm thoroughly impressed with 
 what I've learned of Mir. AIUI, aside from being a fantastic 
 lib, it looks like a tool with very high widespread potential 
 that's written in D, yet also targets, more or less, C/C++ 
 users in addition to D users. A tactic I've definitely been in 
 favor of[1] and would love to see pushed as far as it can go.
Is Mir available as both D and C++ source?
Mar 09
parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Thursday, 9 March 2017 at 17:31:53 UTC, Ola Fosheim Grøstad 
wrote:
 On Saturday, 4 March 2017 at 07:09:17 UTC, Nick Sabalausky 
 (Abscissa) wrote:
 In a similar vein, I have to say I'm thoroughly impressed with 
 what I've learned of Mir. AIUI, aside from being a fantastic 
 lib, it looks like a tool with very high widespread potential 
 that's written in D, yet also targets, more or less, C/C++ 
 users in addition to D users. A tactic I've definitely been in 
 favor of[1] and would love to see pushed as far as it can go.
Is Mir available as both D and C++ source?
Mir written in D. mir-cpuid and mir-glas has extern(C) ABI, mir-algorithm (ndslice) is generic and be used to write extern(C) libraries.
Mar 09