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