www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] Unity's HPC#

reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
In the vein of keeping our eyes open to the world around us, I found 
this article fascinating:

https://blogs.unity3d.com/2019/02/26/on-dots-c-c/

Being a high-performance game engine, Unity3D is right smack in the 
middle of D's strengths and potential.

Traditionally, Unity's core engine is written in C++ (just like pretty 
much every other high-performance game engine), whereas the game code is 

on the target platform, either run directly on Mono or further compiled 
down to C++/native.)

They have the usual group of complaints about C++ (long compilation, 
headers, and concurrency difficulties like races, sharing etc). And they 
also add another C++ gripe we don't hear about quite as often: Lack of 
guarantees and control over the generated code. (VERY important for game 
engine developers, as I'm sure Manu can attest.)

So they have a rather interesting solution: They're switching from C++ 

Sounds slightly odd, but they make a very convincing case for it.

I think it's very much in D's best interest to be aware of these 
problems/solutions/rationales Unity presents here, as they would easily 
apply to other C++ users and thus a key potential audience for D.
Feb 27 2019
next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Wednesday, 27 February 2019 at 19:13:11 UTC, Nick Sabalausky 
(Abscissa) wrote:

 So they have a rather interesting solution: They're switching 

 IL-based tooling. Sounds slightly odd, but they make a very 
 convincing case for it.




about performance beyond avoiding big O crimes. But when you try 
to do stuff like using structs when you don't need polymorhism or 
trying to minimize allocation when working with an array, it gets 
inpractical. With D, of course you still need to put a bit more 
thought in, but it doesn't feel like the language is fighting 
your optimization efforts.
Feb 28 2019
next sibling parent reply XavierAP <n3minis-git yahoo.es> writes:
I had seen it, it looks really nice. It reminds me of what Weka 
do using D, not as is, but heavily modified by themselves 

.NET that they have implemented.


language they were already using for user scripts. Otherwise they 
might have considered D or others.

On Thursday, 28 February 2019 at 12:05:54 UTC, Dukc wrote:

 when you try to do stuff like using structs when you don't need 
 polymorphism or trying to minimize allocation when working with 
 an array, it gets impractical.


How so?

Precisely the split between GC classes and stack structs without 

(and  unlike C++, Java or other languages I know).
Feb 28 2019
parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 28 February 2019 at 14:47:48 UTC, XavierAP wrote:

 On Thursday, 28 February 2019 at 12:05:54 UTC, Dukc wrote:

 when you try to do stuff like using structs when you don't 
 need polymorphism or trying to minimize allocation when 
 working with an array, it gets impractical.


 How so?

 Precisely the split between GC classes and stack structs 

 same way (and  unlike C++, Java or other languages I know).


This question of mine, with its answers, at Stack Overflow sums 

https://stackoverflow.com/questions/51098690/assigning-value-to-member-of-nullable-struct-in-c-sharp
Mar 01 2019
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 3/1/19 5:40 AM, Dukc wrote:

 
 This question of mine, with its answers, at Stack Overflow sums fairly 

 https://stackoverflow.com/questions/51098690/assigning-value-to-member-of-nullab
e-struct-in-c-sharp 
 


Oh yea, that gets REALLY tiresome in Unity. You can't even change the X, 
Y or Z coordinate of a (game) object without copying the whole position 
struct to a local first, and then copying it all back. It's insane. 
Though to be fair, I'm not entirely clear offhand whether that's 
something involving a nullable somewhere in the chain, or just a failing 
of the lib's API itself or what. But either way, the result is pretty bad.
Mar 01 2019
prev sibling next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 2/28/19 7:05 AM, Dukc wrote:

 


 performance beyond avoiding big O crimes. But when you try to do stuff 
 like using structs when you don't need polymorhism or trying to minimize 
 allocation when working with an array, it gets inpractical. With D, of 
 course you still need to put a bit more thought in, but it doesn't feel 
 like the language is fighting your optimization efforts.




expressiveness (compared to D) pushed me away. Although I do still 
consider it one of the few languages I don't actually hate.

Nonetheless, Unity seems to have very much addressed the "low-level 

any major game engine developer, they're coming from C++, so as far as a 
D-like level of expressiveness, they wouldn't have had that before, so 
they're not really loosing much in that area.

What I think is important for us to look at is: How does D's offering 


To be honest, I'm not entirely happy with how D compares:

+ Expressiveness: The only aspects where I think D has a clear advantage.



- "Performance is correctness": I could be wrong, and I hope I am, but 
I'm not sure D does much better than C++ in this area. Certainly not as 


- Cross-architecture: D has improved here from the past, but it's still 
nowhere near as mature on as wide a range of platforms as Unity is.

- Machine code viewer: We have disassembly and such, but judging by 
their screenshot, no tool that's quite that nice.

+ Memory Safety: D's probably about on par here.

- Concurrency Safety: We're way beyond many languages, but we have 
nothing that goes nearly as far as the job scheduling system they describe.

Being basically a better C++, this is exactly the sort of software that 
D should excel at, so it's rather disappointing how D seems to stack up
Feb 28 2019
parent reply Manu <turkeyman gmail.com> writes:
On Thu, Feb 28, 2019 at 9:10 AM Nick Sabalausky (Abscissa) via
Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 2/28/19 7:05 AM, Dukc wrote:



 performance beyond avoiding big O crimes. But when you try to do stuff
 like using structs when you don't need polymorhism or trying to minimize
 allocation when working with an array, it gets inpractical. With D, of
 course you still need to put a bit more thought in, but it doesn't feel
 like the language is fighting your optimization efforts.




 expressiveness (compared to D) pushed me away. Although I do still
 consider it one of the few languages I don't actually hate.

 Nonetheless, Unity seems to have very much addressed the "low-level

 any major game engine developer, they're coming from C++, so as far as a
 D-like level of expressiveness, they wouldn't have had that before, so
 they're not really loosing much in that area.

 What I think is important for us to look at is: How does D's offering



Their work you describe is almost exactly the work I've been doing for
the last however long.
This is the best opportunity I've ever had for D to demonstrate
motivating value before me; there are *so many* ways we can make
compelling arguments in favour of C++, but somehow we're still just
not quite there.

I've raised a bunch of issues I've been facing from this angle
recently; the `shared` stuff, dll stuff, inline stuff.


 To be honest, I'm not entirely happy with how D compares:

 + Expressiveness: The only aspects where I think D has a clear advantage.


Yes, and no. DIP1016 failed, and for all my colleagues, that is the
most annoying thing that appears, every single time, within minutes of
opening their code editors.
It's proven hard to keep people excited and motivated, when they're on
the back foot over something so trivial right off the mark.

Implicit construction is also a major deficiency we have, and people
tend to seriously struggle with that. `alias this` as a solution often
feels awkward, and only goes so far.





/agree, there's no meaningful distinction here. D has expressions
which can make working with buffers a little but nicer (slices in
particular).


 - "Performance is correctness": I could be wrong, and I hope I am, but
 I'm not sure D does much better than C++ in this area. Certainly not as



No linear metric exists, but in practise, I think D often does worse
than C++ actually.
I have to work to write performant D code, but when I do work for it,
it's usually very easy to beat C++.


developing frameworks which facilitate appropriate patterns for the
problem space.

...and that's hard, because my experience so far, is that we really
need to lean on `shared` to do a good job here, but `shared` is
broken.
I started a big thread on shared a while back, nothing came out of it.
If someone wants to fix shared (remove read/write access), that would
be absolutely mega!


 - Cross-architecture: D has improved here from the past, but it's still
 nowhere near as mature on as wide a range of platforms as Unity is.


I think this is actually okay in a practical sense. I don't think D
has an answer for PS4, but all other targets I'm aware of are okay.


 - Machine code viewer: We have disassembly and such, but judging by
 their screenshot, no tool that's quite that nice.


This is a function of VisualD having low man-power. VisualD has a nice
feature which will compile and disassemble a single source file and
focus on the code at your cursor location, so you can get a quick
disassembly of the code as you're editing it.
The implementation is a little big janky, it needs a little more
polish, but it could get there.

People need to care about VisualStudio to nail this checkmark. The
entire industry uses VS, 100's of thousands of native code developers,
there are practically no exceptions.
VS is not popular in this forum, but people NEED TO CARE about it if
they want to succeed generally, even if they don't use it themselves.
It's the most important piece of tooling by lightyears.


 + Memory Safety: D's probably about on par here.


Not really. It's almost all talk at the moment with little substance.
`shared` is a gaping safety violation, escape analysis isn't baked, we
still don't have ref-counting.


 - Concurrency Safety: We're way beyond many languages, but we have
 nothing that goes nearly as far as the job scheduling system they describe.


Are we? What do we have?
I argue that we have literally nothing. Shared is straight-up broken,
and `const` is often such that you can't use it... what else is there
to say on this story?

I write job scheduling systems of the kind they describe, that's my
job. I tried to work one in D. I started that thread about `shared`,
it went no where... I write it in C++ instead with no meaningful loss
of safety (ie, there is none either way, and we depend on convention).
Infact, in C++ we have const, which helps us a lot. In D we don't even
have `const`, because it falls over so often... so we have lost a key
typesafety tool to assist with concurrent work. We can use `const` to
statically enforce read-only access to shared data. In D, that often
doesn't work out.


 Being basically a better C++, this is exactly the sort of software that
 D should excel at, so it's rather disappointing how D seems to stack up



I agree, we should we killing this. I've asked for help over the last
6 months, we've made no progress.
`shared`s broken, inline's broken.
The thread about making -H (.di output) also able to output .h files
is a big part of it.
We have a lot of fundamental issues too, some are in progress like
copy construction, maybe move construction?
Feb 28 2019
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 28 February 2019 at 20:31:34 UTC, Manu wrote:

 
 If someone wants to fix shared (remove read/write access), that 
 would
 be absolutely mega!


I don't really use shared, so I'm confused by the "remove 
read/write access". I thought the point of shared was to only 
allow atomic read/write access.
Feb 28 2019
next sibling parent Manu <turkeyman gmail.com> writes:
On Thu, Feb 28, 2019 at 12:55 PM jmh530 via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Thursday, 28 February 2019 at 20:31:34 UTC, Manu wrote:

 If someone wants to fix shared (remove read/write access), that
 would
 be absolutely mega!


 I don't really use shared, so I'm confused by the "remove
 read/write access". I thought the point of shared was to only
 allow atomic read/write access.


I'm not sure what the 'point' of shared is exactly in it's current
incarnation... but it's definitely not that! ;)
Feb 28 2019
prev sibling parent Rubn <where is.this> writes:
On Thursday, 28 February 2019 at 20:53:01 UTC, jmh530 wrote:

 On Thursday, 28 February 2019 at 20:31:34 UTC, Manu wrote:

 
 If someone wants to fix shared (remove read/write access), 
 that would
 be absolutely mega!


 I don't really use shared, so I'm confused by the "remove 
 read/write access". I thought the point of shared was to only 
 allow atomic read/write access.


 From what I gather it's to prevent using functions in the class 
that aren't marked with shared.

You can modify members that are shared for a struct:

struct A {
    int a;
    void setA(int v) shared {
        synchronized {
           a = v;
        }
    }
}

shared A a;
a.a = 10; // shouldn't be ok

This kind of defeats the purpose of shared, it can't guarantee 
that this is safe. It should prevent modifying the struct, except 
through functions marked as shared.

Seems Walter is against this though. I don't think anyone is 
going to waste their time on something that Walter already has a 
biased opinion against.
Feb 28 2019
prev sibling next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 2/28/19 3:31 PM, Manu wrote:

 
 I've raised a bunch of issues I've been facing from this angle
 recently; the `shared` stuff, dll stuff, inline stuff.


My sympathies, I feel your pain :/

But on a side note, this makes me think: We could *really* use a 
different format for all this argumentative stuff. Forums are too 
transient. What we need is something like a Wiki, but organized like this:

- Ideas
    - Arguments For/Against, and/or possible Cautions
       - Rebuttals
          - Counter-Rebuttals

...For everything, all in one canonical place. Wouldn't that be nice? I 
get so tired of everyone's arguments about everything having no viewable 
structure whatsoever...it's no wonder nobody's arguments ever get 
anywhere!!! This would be so much more practical as a standard 
base-of-operations for (hopefully) a meritocracy, don't you think?


 To be honest, I'm not entirely happy with how D compares:

 + Expressiveness: The only aspects where I think D has a clear advantage.


 
 Yes, and no. DIP1016 failed, and for all my colleagues, that is the
 most annoying thing that appears, every single time, within minutes of
 opening their code editors.
 It's proven hard to keep people excited and motivated, when they're on
 the back foot over something so trivial right off the mark.
 


Ugh, I had to look up "DIP1016"...It's rvalue references, 
and...just...ugh...

See, this is something we should've had ten freaking years ago. It's so 
freaking basic, it's so freaking obvious. I mean, I'm all for the *idea* 
of some sort of DIP system, as long as it isn't too red-tape-y. Heck, I 
started working on a DIP rough draft recently and the need for technical 
details has really *helped* it, but...rvalue references?? That should 
never have even needed a DIP: You make a freaking temporary as 
necessary. Done! Worried about start/end lifetime of the temporary? 
Interactions? It's pretty freaking obvious what choices do/don't work, 
and if we *still* get it wrong, the test suite will tell us. That's the 
*point* of the test suite - to tell us when/how we've broken something. 
But NO! We've gotta define a manual process to soak up as much time as 
it takes to catch things BEFORE the test suite has a chance to!


 - Cross-architecture: D has improved here from the past, but it's still
 nowhere near as mature on as wide a range of platforms as Unity is.


 
 I think this is actually okay in a practical sense. I don't think D
 has an answer for PS4, but all other targets I'm aware of are okay.


This surprises me actually. My perception was that the PS4/XB1 were very 
on-par with each other in terms of architecture: Both are x64-based with 
PC-like GPUs (and without all the hardware variation within a single 
platform, like on desktop/laptop). Wouldn't have expected any 
significant differences regarding a compiler's ability to generate 
machine code. Or is this more an OS issue than a hardware one? (Or not 
allowed to say?)


 

 - Machine code viewer: We have disassembly and such, but judging by
 their screenshot, no tool that's quite that nice.


 
 This is a function of VisualD having low man-power. VisualD has a nice
 feature which will compile and disassemble a single source file and
 focus on the code at your cursor location, so you can get a quick
 disassembly of the code as you're editing it.
 The implementation is a little big janky, it needs a little more
 polish, but it could get there.


I guess that sounds promising at least, y'know, considering. 'Least it's 
not something fundamental that requires changing any higher-ups minds ;)


 People need to care about VisualStudio to nail this checkmark. The
 entire industry uses VS, 100's of thousands of native code developers,
 there are practically no exceptions.
 VS is not popular in this forum, but people NEED TO CARE about it if
 they want to succeed generally, even if they don't use it themselves.
 It's the most important piece of tooling by lightyears.


A good point. I guess at some point D has to decide where its priorities 
are: Increased adoption of D vs meeting the needs of existing D users, 
or a more equitable balance of both. Or perhaps D's already made it's 
decision here...*shudder*...


 - Concurrency Safety: We're way beyond many languages, but we have
 nothing that goes nearly as far as the job scheduling system they describe.


 
 Are we? What do we have?
 I argue that we have literally nothing. Shared is straight-up broken,
 and `const` is often such that you can't use it... what else is there
 to say on this story?


I guess I was just thinking of TLS-by-default. Perhaps I overstated D's 
case.


 I write job scheduling systems of the kind they describe, that's my
 job. I tried to work one in D. I started that thread about `shared`,
 it went no where... I write it in C++ instead with no meaningful loss
 of safety (ie, there is none either way, and we depend on convention).


That's sad to hear :(


 Infact, in C++ we have const, which helps us a lot. In D we don't even
 have `const`, because it falls over so often...


I admit, I don't really use it much myself. Partly because of bad 
experiences attempting to do so.

Do you think the lack of both tailconst and logical-const are the 
ultimate issues here, or does it go deeper than that?


 Being basically a better C++, this is exactly the sort of software that
 D should excel at, so it's rather disappointing how D seems to stack up



 
 I agree, we should we killing this. I've asked for help over the last
 6 months, we've made no progress.
 `shared`s broken, inline's broken.
 The thread about making -H (.di output) also able to output .h files
 is a big part of it.
 We have a lot of fundamental issues too, some are in progress like
 copy construction, maybe move construction?
 


I honesty find D very frustrating these days. On one hand, it's still by 
far my favorite language, due to expressiveness, ranges, the low-level 
abilities it does have (unlike most languages these days), and all of 
the basic common-sense pragmatism that went into its early design about 
ten or so years ago. But OTOH, I feel the focus on pragmatism and common 
sense has been thrown straight out the window for the past many years, 
and its already accelerating down the same paths that led C++ to become 
the mess that it is today. I feel like D's obsessively doing *exactly* 
what Scott Meyers warned us against, in stark contrast to the early 
principles that made D worthwhile in the first place.
Feb 28 2019
next sibling parent reply JN <666total wp.pl> writes:
On Friday, 1 March 2019 at 06:54:07 UTC, Nick Sabalausky 
(Abscissa) wrote:

 But OTOH, I feel the focus on pragmatism and common sense has 
 been thrown straight out the window for the past many years, 
 and its already accelerating down the same paths that led C++ 
 to become the mess that it is today. I feel like D's 
 obsessively doing *exactly* what Scott Meyers warned us 
 against, in stark contrast to the early principles that made D 
 worthwhile in the first place.


C++ seems like a super complicated language to interop with. 
Perhaps it will never be possible to do it right. We already 
added copy constructors, what if we keep adding C++ features in 
the name of interop. I hope in the end D doesn't become a mere 
imitation of C++, with 10% of it's ecosystem.
Mar 01 2019
parent Manu <turkeyman gmail.com> writes:
On Fri, Mar 1, 2019 at 1:10 AM JN via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Friday, 1 March 2019 at 06:54:07 UTC, Nick Sabalausky
 (Abscissa) wrote:

 But OTOH, I feel the focus on pragmatism and common sense has
 been thrown straight out the window for the past many years,
 and its already accelerating down the same paths that led C++
 to become the mess that it is today. I feel like D's
 obsessively doing *exactly* what Scott Meyers warned us
 against, in stark contrast to the early principles that made D
 worthwhile in the first place.


 C++ seems like a super complicated language to interop with.
 Perhaps it will never be possible to do it right. We already
 added copy constructors, what if we keep adding C++ features in
 the name of interop. I hope in the end D doesn't become a mere
 imitation of C++, with 10% of it's ecosystem.


We didn't add copy ctors in the name of C++ interop, we added it in
the name of "postblit was broken".
D has gaps, and you can usually get by if you squint and look the
other way, but there's things that really need to be fixed, like the
copy semantics.

There have been no compromises to language that I know if in the name
of C++ interop. No effect other than an extern statement.
Mar 01 2019
prev sibling next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Friday, 1 March 2019 at 06:54:07 UTC, Nick Sabalausky 
(Abscissa) wrote:

We could *really* use
 a different format for all this argumentative stuff. Forums are 
 too transient. What we need is something like a Wiki, but 
 organized like this:

 - Ideas
    - Arguments For/Against, and/or possible Cautions
       - Rebuttals
          - Counter-Rebuttals

 ...For everything, all in one canonical place. Wouldn't that be 
 nice? I get so tired of everyone's arguments about everything 
 having no viewable structure whatsoever...it's no wonder 
 nobody's arguments ever get anywhere!!! This would be so much 
 more practical as a standard base-of-operations for (hopefully) 
 a meritocracy, don't you think?


Nice Idea!


 But NO! We've gotta define a  manual process to soak up as much 
 time as it takes to catch things BEFORE the test suite has a 
 chance to!


Hopefully the DIP process will change significantly at DConf, 
doing the above for it would be a good start!


 This surprises me actually. My perception was that the PS4/XB1 
 were very on-par with each other in terms of architecture: Both 
 are x64-based with PC-like GPUs (and without all the hardware 
 variation within a single platform, like on desktop/laptop). 
 Wouldn't have expected any significant differences regarding a 
 compiler's ability to generate machine code. Or is this more an 
 OS issue than a hardware one? (Or not allowed to say?)


IIRC its system (e.g. linker) related. There was a person trying 
to get LDC to produce code for PS3(? or 4?) and the problem was 
Sony use a patched clang and he couldn't reverse engineer what 
was needed, may have needed LLVM changes.



 I guess that sounds promising at least, y'know, considering. 
 'Least it's not something fundamental that requires changing 
 any higher-ups minds ;)


Just wait for Dconf ;)


 People need to care about VisualStudio to nail this checkmark. 
 The
 entire industry uses VS, 100's of thousands of native code 
 developers,
 there are practically no exceptions.
 VS is not popular in this forum, but people NEED TO CARE about 
 it if
 they want to succeed generally, even if they don't use it 
 themselves.
 It's the most important piece of tooling by lightyears.


 A good point. I guess at some point D has to decide where its 
 priorities are: Increased adoption of D vs meeting the needs of 
 existing D users, or a more equitable balance of both. Or 
 perhaps D's already made it's decision here...*shudder*...


We just need to make and record decisions period. With the 
discontinuation of the publication of the Vision documents we are 
directionless. Fear not DConf will fix that.


 I honesty find D very frustrating these days. On one hand, it's 
 still by far my favorite language, due to expressiveness, 
 ranges, the low-level abilities it does have (unlike most 
 languages these days), and all of the basic common-sense 
 pragmatism that went into its early design about ten or so 
 years ago. But OTOH, I feel the focus on pragmatism and common 
 sense has been thrown straight out the window for the past many 
 years, and its already accelerating down the same paths that 
 led C++ to become the mess that it is today. I feel like D's 
 obsessively doing *exactly* what Scott Meyers warned us 
 against, in stark contrast to the early principles that made D 
 worthwhile in the first place.


I think Scott was warning us not to make stupid non-sensical 
decisions (hence playing the game "what is the value of this 
variable?"), I think we have a different problem, namely that we 
aren't making enough decisions. Anyway I hope you are coming to 
dconf so we can sort out some of these problems at the Foundation 
AGM there.
Mar 01 2019
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 1 March 2019 at 09:13:42 UTC, Nicholas Wilson wrote:

 On Friday, 1 March 2019 at 06:54:07 UTC, Nick Sabalausky 
 (Abscissa) wrote:

We could *really* use
 a different format for all this argumentative stuff. Forums 
 are too transient. What we need is something like a Wiki, but 
 organized like this:

 - Ideas
    - Arguments For/Against, and/or possible Cautions
       - Rebuttals
          - Counter-Rebuttals

 ...For everything, all in one canonical place. Wouldn't that 
 be nice? I get so tired of everyone's arguments about 
 everything having no viewable structure whatsoever...it's no 
 wonder nobody's arguments ever get anywhere!!! This would be 
 so much more practical as a standard base-of-operations for 
 (hopefully) a meritocracy, don't you think?


 Nice Idea!


Something organised like that could be useful...

https://www.kialo.com/is-c%2B%2B-a-menace-for-security-in-computer-software-10844/10844.0=10844.1/=10844.1

- P
Mar 01 2019
prev sibling next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 1 March 2019 at 06:54:07 UTC, Nick Sabalausky 
(Abscissa) wrote:


 But OTOH, I feel the focus on pragmatism and common sense has 
 been thrown straight out the window for the past many years, 
 and its already accelerating down the same paths that led C++ 
 to become the mess that it is today. I feel like D's 
 obsessively doing *exactly* what Scott Meyers warned us 
 against, in stark contrast to the early principles that made D 
 worthwhile in the first place.


+1
Mar 01 2019
prev sibling next sibling parent Olivier FAURE <couteaubleu gmail.com> writes:
On Friday, 1 March 2019 at 06:54:07 UTC, Nick Sabalausky 
(Abscissa) wrote:

 But on a side note, this makes me think: We could *really* use 
 a different format for all this argumentative stuff. Forums are 
 too transient. What we need is something like a Wiki, but 
 organized like this:

 - Ideas
    - Arguments For/Against, and/or possible Cautions
       - Rebuttals
          - Counter-Rebuttals

 ...For everything, all in one canonical place. Wouldn't that be 
 nice? I get so tired of everyone's arguments about everything 
 having no viewable structure whatsoever...it's no wonder 
 nobody's arguments ever get anywhere!!! This would be so much 
 more practical as a standard base-of-operations for (hopefully) 
 a meritocracy, don't you think?


It's not a bad idea.

However, one thing to keep in mind is that online communities 
have entropy: they get more and more disorderly as time goes on, 
unless you put a constant amount of effort into keeping them 
ordered.

So your "arguments and rebuttals" wiki would likely get abandoned 
after a while, unless someone (probably Mike Parker) spends 
active effort making sure it's organized and directing the people 
with the skill to write structured idea to the wiki, etc... which 
is effort they're not spending on doing something else.

Again, not a bad idea, but keep in mind: keeping a community 
structured is expensive.
Mar 01 2019
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On Thu, Feb 28, 2019 at 10:55 PM Nick Sabalausky (Abscissa) via
Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 2/28/19 3:31 PM, Manu wrote:

 I've raised a bunch of issues I've been facing from this angle
 recently; the `shared` stuff, dll stuff, inline stuff.


 My sympathies, I feel your pain :/

 But on a side note, this makes me think: We could *really* use a
 different format for all this argumentative stuff. Forums are too
 transient. What we need is something like a Wiki, but organized like this:

 - Ideas
     - Arguments For/Against, and/or possible Cautions
        - Rebuttals
           - Counter-Rebuttals

 ...For everything, all in one canonical place. Wouldn't that be nice? I
 get so tired of everyone's arguments about everything having no viewable
 structure whatsoever...it's no wonder nobody's arguments ever get
 anywhere!!! This would be so much more practical as a standard
 base-of-operations for (hopefully) a meritocracy, don't you think?


Yeah, I dunno what format.
It's already fragmented, there's slack, there's discord, this forum,
and IRC, and there's subsets of the community on each one.
Reddit is a better forum, and stack-overflow needs to be more lively
for PR reasons.
There's already a lot.


 To be honest, I'm not entirely happy with how D compares:

 + Expressiveness: The only aspects where I think D has a clear advantage.


 Yes, and no. DIP1016 failed, and for all my colleagues, that is the
 most annoying thing that appears, every single time, within minutes of
 opening their code editors.
 It's proven hard to keep people excited and motivated, when they're on
 the back foot over something so trivial right off the mark.


 Ugh, I had to look up "DIP1016"...It's rvalue references,
 and...just...ugh...

 See, this is something we should've had ten freaking years ago. It's so
 freaking basic, it's so freaking obvious. I mean, I'm all for the *idea*
 of some sort of DIP system, as long as it isn't too red-tape-y. Heck, I
 started working on a DIP rough draft recently and the need for technical
 details has really *helped* it, but...rvalue references?? That should
 never have even needed a DIP: You make a freaking temporary as
 necessary. Done! Worried about start/end lifetime of the temporary?
 Interactions? It's pretty freaking obvious what choices do/don't work,
 and if we *still* get it wrong, the test suite will tell us. That's the
 *point* of the test suite - to tell us when/how we've broken something.
 But NO! We've gotta define a manual process to soak up as much time as
 it takes to catch things BEFORE the test suite has a chance to!


I need to not think about it anymore. It's really bad for my mental health.


 - Cross-architecture: D has improved here from the past, but it's still
 nowhere near as mature on as wide a range of platforms as Unity is.


 I think this is actually okay in a practical sense. I don't think D
 has an answer for PS4, but all other targets I'm aware of are okay.


 This surprises me actually. My perception was that the PS4/XB1 were very
 on-par with each other in terms of architecture: Both are x64-based with
 PC-like GPUs (and without all the hardware variation within a single
 platform, like on desktop/laptop). Wouldn't have expected any
 significant differences regarding a compiler's ability to generate
 machine code. Or is this more an OS issue than a hardware one? (Or not
 allowed to say?)


XBox runs windows, PS4 runs a modified FreeBSD. We have Win64
compilers. I don't know how much Sony have messed with their
LLVM/Clang.
Architecture isn't the problem, it's having a toolchain that targets
the os/system.


 - Machine code viewer: We have disassembly and such, but judging by
 their screenshot, no tool that's quite that nice.


 This is a function of VisualD having low man-power. VisualD has a nice
 feature which will compile and disassemble a single source file and
 focus on the code at your cursor location, so you can get a quick
 disassembly of the code as you're editing it.
 The implementation is a little big janky, it needs a little more
 polish, but it could get there.


 I guess that sounds promising at least, y'know, considering. 'Least it's
 not something fundamental that requires changing any higher-ups minds ;)


Oh yeah, Rainer punches way above his weight, but it's such critical
tooling that it really needs extensive and ongoing investment.
It has to compare favourably against some of the best tooling out

close. There's nothing about D structurally that should prevent a
similarly excellent experience.


 - Concurrency Safety: We're way beyond many languages, but we have
 nothing that goes nearly as far as the job scheduling system they describe.


 Are we? What do we have?
 I argue that we have literally nothing. Shared is straight-up broken,
 and `const` is often such that you can't use it... what else is there
 to say on this story?


 I guess I was just thinking of TLS-by-default. Perhaps I overstated D's
 case.


Right, TLS by default is really helpful, but in C++ where you just
write a framework which implements that reality, then you're on the
same playfield.
The trouble comes when you DO interact with shared data. In C++ you
can't distinguish it from the non-shared data, so there's no way
beyond convention to do shared interaction.
In D, `shared` should help us, but it's completely unsafe, while
pretending to give the impression that it is. It should be an
excellent tool, but it's dangerously broken, and it turns out that a
totally broken feature is worse than if the feature didn't exist in
terms of public opinion.
We just need to fix it. It would be really easy to fix!
I suspect someone that knew how could do it in a couple hours.


 Infact, in C++ we have const, which helps us a lot. In D we don't even
 have `const`, because it falls over so often...


 I admit, I don't really use it much myself. Partly because of bad
 experiences attempting to do so.

 Do you think the lack of both tailconst and logical-const are the
 ultimate issues here, or does it go deeper than that?


I don't know. I do know that I've spent 10 years trying to defend D's
const, and also trying to use it in practise... but I've never
succeeded generally.
It always hits a wall somewhere along the way. I think you might be
able to make it work for small programs, when you're super thoughtful
and careful along the way. I don't think that's practical, or
particularly useful.

I think one of 2 things; a series of articles and demonstration
material needs to be produced to show how to successfully interact
with D's const, or it should be admit that it's a nice fantasy, and
relaxed. I'd prefer the former, but I'm not actually sure it's not
just fantasy as the project becomes 'real' in scale/scope.
I also think that many super-common designs and patterns are
effectively const-incompatible. We need to know that such designs are
essentially _incompatible with D_, and discourage those forms of
program. I don't know what they are. I only realise when I find myself
in the hole.


 Being basically a better C++, this is exactly the sort of software that
 D should excel at, so it's rather disappointing how D seems to stack up



 I agree, we should we killing this. I've asked for help over the last
 6 months, we've made no progress.
 `shared`s broken, inline's broken.
 The thread about making -H (.di output) also able to output .h files
 is a big part of it.
 We have a lot of fundamental issues too, some are in progress like
 copy construction, maybe move construction?


 I honesty find D very frustrating these days. On one hand, it's still by
 far my favorite language, due to expressiveness, ranges, the low-level
 abilities it does have (unlike most languages these days), and all of
 the basic common-sense pragmatism that went into its early design about
 ten or so years ago. But OTOH, I feel the focus on pragmatism and common
 sense has been thrown straight out the window for the past many years,
 and its already accelerating down the same paths that led C++ to become
 the mess that it is today. I feel like D's obsessively doing *exactly*
 what Scott Meyers warned us against, in stark contrast to the early
 principles that made D worthwhile in the first place.


I'm frustrated beyond reason. I don't know how to be happy anymore.
Should I let it go? Sunk-cost fallacy...

It comes to this; I can only really engage with D as a toy, and that's
absolutely not what I want.
I want to use D professionally, that is all. If I can't use it
professionally, then I'm wasting my short lifetime here.

I've tried to push it in the direction that it can be useful to me for
a really long time, we've made ground, but we're still nowhere near
the mark, and the timeline involved is unreasonably long.
I've written and shipped like 5-6 gigantic projects in C++ in the
meantime. Those were real programs/games that did real things,
customers enjoyed, and made real money.
I don't know that if I'm honest about the trajectory that I'm able to
satisfy myself that we'll get there. So what should I do? :/


have a small group with a laser focus on making it fit for purpose.
I think that can only occur at a bold company. I suspect that's
chicken/egg stuff :/
Mar 01 2019
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 01 Mar 2019 01:54:07 -0500 schrieb Nick Sabalausky (Abscissa):


 On 2/28/19 3:31 PM, Manu wrote:

 
 I've raised a bunch of issues I've been facing from this angle
 recently; the `shared` stuff, dll stuff, inline stuff.


 
 My sympathies, I feel your pain :/
 
 But on a side note, this makes me think: We could *really* use a
 different format for all this argumentative stuff. Forums are too
 transient. What we need is something like a Wiki, but organized like
 this:
 
 - Ideas
     - Arguments For/Against, and/or possible Cautions
        - Rebuttals
           - Counter-Rebuttals
 


Maybe some open source debate platform like pol.is: https://pol.is/demo/
2demo . However, polis focuses more on opinions than presenting pro/con 
arguments and facts. I think I've seen software for that before, maybe 
something like kialo ( https://www.youtube.com/watch?v=MifNyU49_JA ) or 
one of the solutions here: https://www.quora.com/What-are-the-best-online-
platforms-for-holding-logical-and-honest-debates


-- 
Johannes
Mar 01 2019
prev sibling parent Yatheendra <s832 gmail.com> writes:
On Friday, 1 March 2019 at 06:54:07 UTC, Nick Sabalausky 
(Abscissa) wrote:

 On 2/28/19 3:31 PM, Manu wrote:

 
 I've raised a bunch of issues I've been facing from this angle
 recently; the `shared` stuff, dll stuff, inline stuff.


 My sympathies, I feel your pain :/

 But on a side note, this makes me think: We could *really* use 
 a different format for all this argumentative stuff. Forums are 
 too transient. What we need is something like a Wiki, but 
 organized like this:
 <snip>
 ...For everything, all in one canonical place. Wouldn't that be 
 nice? I get so tired of everyone's arguments about everything 
 having no viewable structure whatsoever...it's no wonder 
 nobody's arguments ever get anywhere!!! This would be so much 
 more practical as a standard base-of-operations for (hopefully) 
 a meritocracy, don't you think?


What do you think of the format of Ward Cunningham's wiki: c2.com?
Or even www.tiddlywiki.com while at it.
May 15 2019
prev sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 28 February 2019 at 20:31:34 UTC, Manu wrote:

 People need to care about VisualStudio to nail this checkmark. 
 The
 entire industry uses VS, 100's of thousands of native code 
 developers,
 there are practically no exceptions.
 VS is not popular in this forum, but people NEED TO CARE about 
 it if
 they want to succeed generally, even if they don't use it 
 themselves.
 It's the most important piece of tooling by lightyears.


+1
Also for the audio segment
and the video segment. :)
Mar 01 2019
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 28 February 2019 at 12:05:54 UTC, Dukc wrote:

 On Wednesday, 27 February 2019 at 19:13:11 UTC, Nick Sabalausky 
 (Abscissa) wrote:

 So they have a rather interesting solution: They're switching 

 IL-based tooling. Sounds slightly odd, but they make a very 
 convincing case for it.




 don't care about performance beyond avoiding big O crimes. But 
 when you try to do stuff like using structs when you don't need 
 polymorhism or trying to minimize allocation when working with 
 an array, it gets inpractical. With D, of course you still need 
 to put a bit more thought in, but it doesn't feel like the 
 language is fighting your optimization efforts.




Versions 7 and 8 incorporate many of the Midori lessons, some of 
which even landend on C++.
Feb 28 2019
parent arakan arkino <marcosdonalonso gmail.com> writes:
On Friday, 1 March 2019 at 07:18:17 UTC, Paulo Pinto wrote:

 On Thursday, 28 February 2019 at 12:05:54 UTC, Dukc wrote:

 On Wednesday, 27 February 2019 at 19:13:11 UTC, Nick 
 Sabalausky (Abscissa) wrote:

 So they have a rather interesting solution: They're switching 

 and IL-based tooling. Sounds slightly odd, but they make a 
 very convincing case for it.




 don't care about performance beyond avoiding big O crimes. But 
 when you try to do stuff like using structs when you don't 
 need polymorhism or trying to minimize allocation when working 
 with an array, it gets inpractical. With D, of course you 
 still need to put a bit more thought in, but it doesn't feel 
 like the language is fighting your optimization efforts.




 Versions 7 and 8 incorporate many of the Midori lessons, some 
 of which even landend on C++.




about performance beyond avoiding big O crimes. But when you try 
to do stuff like using structs when you don't need polymorhism or 
trying to minimize allocation when working with an array, it gets 
inpractical. With D, of course you still need to put a bit more 
thought in, but it doesn't feel like the language is fighting 
your optimization efforts.
Mar 30 2019
prev sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Wednesday, 27 February 2019 at 19:13:11 UTC, Nick Sabalausky 
(Abscissa) wrote:

 In the vein of keeping our eyes open to the world around us, I 
 found this article fascinating:

 https://blogs.unity3d.com/2019/02/26/on-dots-c-c/

 Being a high-performance game engine, Unity3D is right smack in 
 the middle of D's strengths and potential.

 Traditionally, Unity's core engine is written in C++ (just like 
 pretty much every other high-performance game engine), whereas 

 CLIR and then, depending on the target platform, either run 
 directly on Mono or further compiled down to C++/native.)

 They have the usual group of complaints about C++ (long 
 compilation, headers, and concurrency difficulties like races, 
 sharing etc). And they also add another C++ gripe we don't hear 
 about quite as often: Lack of guarantees and control over the 
 generated code. (VERY important for game engine developers, as 
 I'm sure Manu can attest.)

 So they have a rather interesting solution: They're switching 

 IL-based tooling. Sounds slightly odd, but they make a very 
 convincing case for it.

 I think it's very much in D's best interest to be aware of 
 these problems/solutions/rationales Unity presents here, as 
 they would easily apply to other C++ users and thus a key 
 potential audience for D.


As a professional game developer, I use Unity at work on a daily 


And I must tell you that the main interest of this technology for 
Unity users is that it allows to implement the highly-optimized 
data-oriented parallelized parts of our code using a C-like 
close-to-the-metal language.



For instance, in my company, despite we mostly develop mobile 
games, most of our gameplay code is STILL based on Monobehaviour 

unfortunate price of a much higher verbosity and very low 
expressiveness.

This means that a MonoBehaviour-based 10-liner function will 
require 5 to 10 times more code for the same result in a very 
cryptic data-oriented C-like code. And btw you can also say 
goodbye to physics, networking, etc.

For games involving hundreds of game entities, this may be worth 
the effort, but for most games this isn't worth the effort.

So IMHO, it's much more urgent for D to try to close its gap with 
Go and Crystal by adding a fiber-based http capabilities in the 
standard library, that once again trying to make D become the 
ultimate C++ replacement, because to reach that goal you will 
need to reimplement all the D standard library using C++-like 
reference-counted memory management, which you won't, or loose 
it's current expressiveness and ease of use, which means 
targeting an even smaller development niche...
Mar 03 2019
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Sunday, 3 March 2019 at 09:50:17 UTC, Ecstatic Coder wrote:


 So IMHO, it's much more urgent for D to try to close its gap 
 with Go and Crystal by adding a fiber-based http capabilities 
 in the standard library


I would be happy to have at least a modern  IO subsystem in 
Phobos...

- P
Mar 03 2019
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Sunday, 3 March 2019 at 10:50:44 UTC, Paolo Invernizzi wrote:

 I would be happy to have at least a modern  IO subsystem in 
 Phobos...


Can you clarify exactly what you are looking for?

I think there might be quite a lot of us with a shared interest 
in having a really robust and well-designed system for handling 
asynchronous tasks in D.  It may be a good idea to examine all 
the different options (vibe-core, Sociomantic's ocean library, 
potential alternative approaches...) and see if we can come up 
with something that suits everyone.
Mar 03 2019
prev sibling parent reply Margo <margo margotics.des> writes:
On Sunday, 3 March 2019 at 09:50:17 UTC, Ecstatic Coder wrote:

 So IMHO, it's much more urgent for D to try to close its gap 
 with Go and Crystal by adding a fiber-based http capabilities 
 in the standard library, that once again trying to make D 
 become the ultimate C++ replacement, because to reach that goal 
 you will need to reimplement all the D standard library using 
 C++-like reference-counted memory management, which you won't, 
 or loose it's current expressiveness and ease of use, which 
 means targeting an even smaller development niche...


Unlike D, you can simply install Crystal or Go and create a high 
performance website/microservice/... within minutes.

D does not work like this. There is literally no interest into a 
build-in fiber based  solution. Unless you consider vibe.d as 
"performant", when its performing at barely PHP levels. Can just 
as well use PHP at that point and get the benefit from 100.000 
cheap already trained developers!

Talking about D for web development, simply does not work as 
there is no interest here. The focus is still trying to be a C++ 
replacement ( and now C replacement ), when that boat has sailed. 
Rust is simply a better C++ replacement then D at this point. D 
is simply carrying too much baggage from all the year and this is 
reflected in the compiler issues and community attitude. Even Zig 
is turning into a better C replacement compared to D.

Lots of opinions, lots of burned out people. On a lot of points, 
D is extreme stagnant and on a lot of points that people like me 
do not give a darn about, D is way too busy.

The reality is i can hire people to write in Crystal easier, then 
finding people who can figure out D. The same applies to Go, 
where its simply easier to train people because of the simple 
language structure and lack of major "gotchas" unlike D.

D as a language is ok but its all the issues left and right that 
simply eat time. Time is exactly what you do not have with most 
web development projects. So Ecstatic, i see very little support 
on this issue.

Tell us, what do you program in right now for anything HTTP 
related? I am betting Go, Crystal or PHP but not D, am i right?
May 15 2019
next sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 15 May 2019 at 13:35:57 UTC, Margo wrote:


 Talking about D for web development, simply does not work as 
 there is no interest here.


Trying to make a push into the web space as a way to increase D 
usage is a complete waste of time. That is extremely competitive, 
with language after language doing the same things, and no hope 
for a new language to gain interest.

Having said that, there is nothing stopping anyone that thinks D 
offers big advantages over the alternatives from creating 
something and making their billions. This has come up many times. 
I don't understand what the complaint is. Nobody's stopping 
anyone from working on it. You don't need permission.
May 15 2019
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 5/15/19 11:15 AM, bachmeier wrote:

 Trying to make a push into the web space as a way to increase D usage is 
 a complete waste of time. That is extremely competitive, with language 
 after language doing the same things, and no hope for a new language to 
 gain interest.


Interesting, I didn't think of it that way. Thanks!
May 15 2019
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Wednesday, 15 May 2019 at 15:15:26 UTC, bachmeier wrote:

 Trying to make a push into the web space as a way to increase D 
 usage is a complete waste of time. That is extremely 
 competitive, with language after language doing the same 
 things, and no hope for a new language to gain interest.

 Having said that, there is nothing stopping anyone that thinks 
 D offers big advantages over the alternatives from creating 
 something and making their billions. This has come up many 
 times. I don't understand what the complaint is. Nobody's 
 stopping anyone from working on it. You don't need permission.


It depends. I agree that if one looks purely from web programming 
perspective, all other considerations ditched, there are probably 

Scala, Kotlin or Go.

The reason one might choose D is that if it still stays 
reasonably close to the best ones, you can use the same language 
for systems programming. With the alternatives I mentioned, one 
might need to use two langugages when there's need to do, for 
example, data crunching. This can be a bigger disadvantage for 
some than the lack of some web related bells and whistles in D.

So we have little hope if we try to market ourselves as with 
"better" MVC models or database automation. But by talking about 
our low-level fallback feature, we offer something the majority 
of others do not.
May 16 2019
parent evilrat <evilrat666 gmail.com> writes:
On Thursday, 16 May 2019 at 08:17:26 UTC, Dukc wrote:

 The reason one might choose D is that if it still stays 
 reasonably close to the best ones, you can use the same 
 language for systems programming. With the alternatives I 
 mentioned, one might need to use two langugages when there's 
 need to do, for example, data crunching. This can be a bigger 
 disadvantage for some than the lack of some web related bells 
 and whistles in D.


That HR guy(or gal) makes it pretty clear, there is no other 
activities exists except weeb development. Who's in their own 
mind needs a language that doesn't do *THAT*-only thing? Nobody!

And also I find the fact that web folk saying that normal OS's is 
in decline and web is the next desktop just silly, like if there 
is no browser thing exists and they run their Electron apps 
directly on our hardware (phew, hardware? so archaic. can't wait 
to see the fancy sci-fi holograms that descends straight from the 
clouds)
May 16 2019
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 15 May 2019 at 15:15:26 UTC, bachmeier wrote:

 On Wednesday, 15 May 2019 at 13:35:57 UTC, Margo wrote:


 Talking about D for web development, simply does not work as 
 there is no interest here.


 Trying to make a push into the web space as a way to increase D 
 usage is a complete waste of time. That is extremely 
 competitive, with language after language doing the same 
 things, and no hope for a new language to gain interest.


Well, there is hope for a new infrastructure to gain interest if 
it is domain specific, but it isn't really making a good argument 
for a general purpose language.

One such example is server-less event-driven websites running on 
cloud-solutions. The language used in event handlers is less 
important, could be javascript for that matter (e.g. Google 
Functions). Although something domain specific probably would be 
better.

Of course, a general purpose system level language is used for 
implementing the infrastructure that enables this, but that is a 
very small market.

On the other hand, a language that allows you to build domain 
specific features on top of it, with ease, could offer something 
unique.

Not really a B&W issue, but most, if not all, current languages 
fails at that critical "with ease" requirement.
May 16 2019
prev sibling next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 5/15/19 9:35 AM, Margo wrote:

 On Sunday, 3 March 2019 at 09:50:17 UTC, Ecstatic Coder wrote:

 So IMHO, it's much more urgent for D to try to close its gap with Go 
 and Crystal by adding a fiber-based http capabilities in the standard 
 library, that once again trying to make D become the ultimate C++ 
 replacement, because to reach that goal you will need to reimplement 
 all the D standard library using C++-like reference-counted memory 
 management, which you won't, or loose it's current expressiveness and 
 ease of use, which means targeting an even smaller development niche...


 
 Unlike D, you can simply install Crystal or Go and create a high 
 performance website/microservice/... within minutes.
 
 D does not work like this. There is literally no interest into a 
 build-in fiber based  solution. Unless you consider vibe.d as 
 "performant", when its performing at barely PHP levels. Can just as well 
 use PHP at that point and get the benefit from 100.000 cheap already 
 trained developers!
 
 Talking about D for web development, simply does not work as there is no 
 interest here. The focus is still trying to be a C++ replacement ( and 
 now C replacement ), when that boat has sailed. Rust is simply a better 
 C++ replacement then D at this point. D is simply carrying too much 
 baggage from all the year and this is reflected in the compiler issues 
 and community attitude. Even Zig is turning into a better C replacement 
 compared to D.
 
 Lots of opinions, lots of burned out people. On a lot of points, D is 
 extreme stagnant and on a lot of points that people like me do not give 
 a darn about, D is way too busy.
 
 The reality is i can hire people to write in Crystal easier, then 
 finding people who can figure out D. The same applies to Go, where its 
 simply easier to train people because of the simple language structure 
 and lack of major "gotchas" unlike D.
 
 D as a language is ok but its all the issues left and right that simply 
 eat time. Time is exactly what you do not have with most web development 
 projects. So Ecstatic, i see very little support on this issue.


Two important things here:

1. He who hires developers that cannot learn a new language, is 
incompetent at HR.

2. He who views languages as interchangeable commodities with the only 
differentiating factors being existing libs and pool of existing 
developers, is incompetent at software management.


 Tell us, what do you program in right now for anything HTTP related? I 
 am betting Go, Crystal or PHP but not D, am i right?


Umm, no, you're not right. I use D for HTTP, and you'll find that many 
people here do. And I'd literally sooner kill myself than go back to 
suffering through the festering cr*pfest that is PHP. Switching to Go 
would be like fighting with one hand tied behind my back. And 
Crystal...I don't even know that one, but a quick search shows it's not 
even 1.0 yet, making it more than a little bizarre that someone making 
the arguments you're making would suggest it over D. You're not actually 
interested in making a real point, you're just here to argue, right?
May 15 2019
next sibling parent bachmeier <no spam.net> writes:
On Wednesday, 15 May 2019 at 18:43:38 UTC, Nick Sabalausky 
(Abscissa) wrote:


 Umm, no, you're not right. I use D for HTTP, and you'll find 
 that many people here do.


I think what it amounts to is that you use the language you're 
comfortable with because you're doing the same thing no matter 
which language it is. You don't choose a language for csv support 
or SQLite support, because csv files and .sqlite files hold the 
same data independent of the language. R is seeing a lot of 
momentum in the web space. It's not because it's a great web 
language but because folks do their statistical analysis and then 
they want to share it with the world.


 And Crystal...I don't even know that one, but a quick search 
 shows it's not even 1.0 yet, making it more than a little 
 bizarre that someone making the arguments you're making would 
 suggest it over D. You're not actually interested in making a 
 real point, you're just here to argue, right?


It read to me like an attempt to spam about Crystal. Last I 
checked, Crystal didn't even have Windows support. A more 

Kotlin, Python, or Ruby rather than Crystal if you're making a 
point about hiring programmers.
May 15 2019
prev sibling parent reply Margo <margo margotics.des> writes:
On Wednesday, 15 May 2019 at 18:43:38 UTC, Nick Sabalausky 
(Abscissa) wrote:

 Umm, no, you're not right. I use D for HTTP, and you'll find 
 that many people here do.


And that is the issue, is it not. A small group of people are not 
a reflection of a performance based HTTP solution.


 And I'd literally sooner kill myself than go back to suffering 
 through the festering cr*pfest that is PHP.


And yet, you are reading most of your websites using that 
"cr*pfest ". Its always popular to b*tch about PHP but it gets 
the job done. Unlike D that just can not get any traction because 
it keep spreading its resources left and right between C/C++, 
that very few people are interested in. You know that C++ has 
taken over most of D its advantages right? Rust is a better C++ 
replacement. Let alone the C alternatives.


 Switching to Go would be like fighting with one hand tied 
 behind my back. And Crystal...



 I don't even know that one, but a quick search shows it's not 
 even 1.0 yet, making it more than a little bizarre that someone 
 making the arguments you're making would suggest it over D.


Maybe because despite being pre-1.0, it actually performance 5 
times better then D? Its easy to judge a language on a label 
without trying it out yourself, is it not :)

Let me help...

https://www.techempower.com/benchmarks/#section=test&runid=2539a0c7-934c-4eaf-93ed-a1980566cffe&hw=ph&test=fortune&l=zdk8af-7

Yea, D is really bad with vibe.d, when it comes down to web 
performance.


 You're not actually interested in making a real point, you're 
 just here to argue, right?


Tomato, Potato ...

I see mostly people here that are delusional about D its future. 
And as i pointed out in my post, there are simply better 
alternatives for anything HTTP related then D. If you can not 
handle this, ...
May 18 2019
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 19 May 2019 at 01:45:07 UTC, Margo wrote:

 And that is the issue, is it not. A small group of people are 
 not a reflection of a performance based HTTP solution.


Well, but I don't think a very high performance HTTP solution is 
a requirement to succeed for a language.

It is becoming a requirement to have an easy-to-use HTTPS 
solution. Easy to use with "normal" performance is far more 
important than being superior on some very narrow metrics. The 
vast majority of HTTP servers do not need very high theoretical 
HTTP performance.

If you really need high performance you would nevertheless have 
to look at a scalable distributed solution, and then you are 
locked to more tricky cloud based solutions that have been 
through heavy duty testing... which no small language can ever 
provide. You cannot establish market confidence of a high level 
of reliability without a large user base and backing by a major 
entity anyway. If you need to run something that requires a lot 
of throughput, then you probably also care a lot about 
established reliability and support.



 C++ has taken over most of D its advantages right? Rust is a 
 better C++ replacement.


I don't really think Rust is displacing C++. Rust has some of the 
same issues as D in that regard. Vendors support C++, not Rust. 
The biggest lost opportunity for D was to not align its lower 
level semantics with C++. If you choose to be different in ways 
that make you incompatible with the status quo then there should 
be substantial benefits to those choices.

For some Rust has provided that by their ownership model, but I 
suspect that it is not really used all that much for low level 
programming as it quickly becomes inconvenient. Rust seems to be 
much more of an application-engine programming language, it has a 
narrow application field where it is better than C++, but not if 
you look more broadly at all the areas where C++ is used.


 Maybe because despite being pre-1.0, it actually performance 5 
 times better then D? Its easy to judge a language on a label 
 without trying it out yourself, is it not :)


Both Crystal and D have LLVM based compilation, so for comparable 
codebases there should be no real difference.

Anyway, Crystal looks more like it would appeal to people looking 
for a replacement for a scripting language. Which is good. But it 
will never stand a chance in embedded programming. D could, if 
that had been a priority, sadly it isn't, so neither does D. As 
such C++ is pretty much irreplaceable at this point, unless you 
are willing to go out of your way to use something esoteric. Only 
a small minority do that.



 future. And as i pointed out in my post, there are simply 
 better alternatives for anything HTTP related then D. If you 
 can not handle this, ...


Better depends on what you try to achieve. To me being better for 
anything HTTP related has less to do with the language and more 
to do with the infrastructure around it as well as cloud support.

Also, it depends on what you interface with. Node.js might not be 
the best base for a HTTP server, but the fact that you get to use 
the same language on both server and client does make it superior 
for many developers.

Same goes for vibe.d.  If your write clients in D or has D as 
your main language then vibe.d will be superior in many cases.

Most HTTP sever-frameworks are simple and very similar. (Cloud 
solutions are more diverse.)
May 18 2019
prev sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 5/15/19 9:35 AM, Margo wrote:

 Unlike D, you can simply install Crystal or Go and create a high 
 performance website/microservice/... within minutes.
 
 D does not work like this. There is literally no interest into a 
 build-in fiber based  solution. Unless you consider vibe.d as 
 "performant", when its performing at barely PHP levels.


This quoted stuff here is also a complete load of bull.
May 15 2019