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