Re: D street cred: Just a thought

[Ilya Yaroshenko via Digitalmars-d]

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.

Re: D street cred: Just a thought

[Ola Fosheim Grøstad via Digitalmars-d]

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?

Re: D street cred: Just a thought

[Daniel Murphy via Digitalmars-d]

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.

Re: D street cred: Just a thought

[ketmar via Digitalmars-d]

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.

Re: D street cred: Just a thought

[jmh530 via Digitalmars-d]

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.

Re: D street cred: Just a thought

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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++.

Re: D street cred: Just a thought

[Iain Buclaw via Digitalmars-d]

On 5 March 2017 at 06:45, Ilya Yaroshenko via Digitalmars-d
 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.

Re: D street cred: Just a thought

[Moritz Maxeiner via Digitalmars-d]

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).



Assembler code is best code!


[1] 
https://forum.dlang.org/thread/ivbnsgqoyjrxkkhvz...@forum.dlang.org?page=1

[2] https://forum.dlang.org/post/20160421194152.51652...@gmx.de

Re: D street cred: Just a thought

[XavierAP via Digitalmars-d]

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).

Re: D street cred: Just a thought

[Moritz Maxeiner via Digitalmars-d]

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/oetnnywqhcedrnvxu...@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.

Re: D street cred: Just a thought

[Moritz Maxeiner via Digitalmars-d]

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 )?

Re: D street cred: Just a thought

[Moritz Maxeiner via Digitalmars-d]

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.

Re: D street cred: Just a thought

[Ilya Yaroshenko via Digitalmars-d]

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/oetnnywqhcedrnvxu...@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

Re: D street cred: Just a thought

[Arun Chandrasekaran via Digitalmars-d]

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

Re: D street cred: Just a thought

[Ilya Yaroshenko via Digitalmars-d]

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

Re: D street cred: Just a thought

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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."

;)

Re: D street cred: Just a thought

[XavierAP via Digitalmars-d]

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.

Re: D street cred: Just a thought

[Moritz Maxeiner via Digitalmars-d]

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?

Re: D street cred: Just a thought

[Gerald via Digitalmars-d]

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".

Re: D street cred: Just a thought

[Ilya Yaroshenko via Digitalmars-d]

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

Re: D street cred: Just a thought

[ketmar via Digitalmars-d]

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.

Re: D street cred: Just a thought

[Patrick Schluter via Digitalmars-d]

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.

Re: D street cred: Just a thought

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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!

Re: D street cred: Just a thought

[Joakim via Digitalmars-d]

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