www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Could D have fit Microsoft's needs?

reply bauss <jj_1337 live.dk> writes:
Microsoft has published article about needing a safer system 
programming language.

https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

Could D (Most likely as betterC) have fit into that domain OR is 
it not yet safe?
Jul 18
next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 Microsoft has published article about needing a safer system 
 programming language.

 https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

 Could D (Most likely as betterC) have fit into that domain OR 
 is it not yet safe?
I knew this day would come, and while I hoped in my heart it would be D, I understand why it isn't. I speculate this is an inflection point in the industry. Walter himself even predicted it with his "memory safety will kill C" prediction at DConf a couple of years ago. Others will likely follow, and I dread the day my employer comes to me and says "Do you know Rust?". I think D could meet Microsoft's needs, but only if they forked it and made some fundamental changes to remove the technical debt, remove some of the "weird sh**" (https://youtu.be/TkNep5zHWNw?t=1378), and a number of other things we all could list to make using D a more professional experience. The D Language Foundation is doing some of that with the copy constructors, the new object hierarchy, templating druntime, etc. but it all happens too slowly. Regardless, I will continue with my part, at least for the time being, but it is an opportune time for some self-reflection. Microsoft isn't the industry, so there could potentially be another major player that decides to use D (or fork it), and that could rescue the trend, but it seems unlikely to me, unfortunately. It's sad news to me, really. I wanted something like D to be the new trend, but Rust seemed to have its act together from the beginning. Mike
Jul 18
next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Thursday, 18 July 2019 at 23:49:00 UTC, Mike Franklin wrote:

 I think D could meet Microsoft's needs, but only if they forked 
 it and made some fundamental changes to remove the technical 
 debt, remove some of the "weird sh**" 
 (https://youtu.be/TkNep5zHWNw?t=1378), and a number of other 
 things we all could list to make using D a more professional 
 experience.
... and D could complete better with Rust if it had safe-by-default and statically-check ownership/borrowing mechanism as Walter recently proposed. I think there is something that Microsoft is overlooking with D. In the last 2 paragraphs of the blog post they say that programmers should be using managed languages like C#|F# whenever possible, but use Rust when the prior don't scale. D is unique from Rust and C# in that is scales both up and down. So, Microsoft is missing an opportunity to have one language for all use cases. But I still think D has to do something about the technical debt and other "weird sh**" to make it viable. Mike
Jul 18
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 19, 2019 at 12:12:06AM +0000, Mike Franklin via Digitalmars-d wrote:
 On Thursday, 18 July 2019 at 23:49:00 UTC, Mike Franklin wrote:
 
 I think D could meet Microsoft's needs, but only if they forked it
 and made some fundamental changes to remove the technical debt,
 remove some of the "weird sh**"
 (https://youtu.be/TkNep5zHWNw?t=1378), and a number of other things
 we all could list to make using D a more professional experience.
[...]
 D is unique from Rust and C# in that is scales both up and down.  So,
 Microsoft is missing an opportunity to have one language for all use
 cases.  But I still think D has to do something about the technical
 debt and other "weird sh**" to make it viable.
[...] Yeah, D has a really beautiful, marvelous core that works really well and addresses safety concerns, productivity, scalability, and meta-programming needs. But outside this core is a bunch of "weird sh**", as the above video aptly puts it, of poorly-interacting corner cases, unexpected (often legacy) behaviours, and incompletely- or poorly- implemented features. These technical debts greatly detract from D's overall value, yet there is no easy way to fix them without causing massive breakage of existing D code (or other D features). It's sad, but it's reminiscient of the bad ole days when C++ shops would dictate, via convention/policy to use only a certain, sane(r) subset of C++ while avoiding the nastier parts. The parts of the language to be avoided is much smaller in D than in C++, but still, it's there, and it detracts from the overall D experience. T -- What is Matter, what is Mind? Never Mind, it doesn't Matter.
Jul 18
parent drug <drug2004 bk.ru> writes:
19.07.2019 4:12, H. S. Teoh пишет:
 On Fri, Jul 19, 2019 at 12:12:06AM +0000, Mike Franklin via Digitalmars-d
wrote:
 On Thursday, 18 July 2019 at 23:49:00 UTC, Mike Franklin wrote:

 I think D could meet Microsoft's needs, but only if they forked it
 and made some fundamental changes to remove the technical debt,
 remove some of the "weird sh**"
 (https://youtu.be/TkNep5zHWNw?t=1378), and a number of other things
 we all could list to make using D a more professional experience.
[...]
 D is unique from Rust and C# in that is scales both up and down.  So,
 Microsoft is missing an opportunity to have one language for all use
 cases.  But I still think D has to do something about the technical
 debt and other "weird sh**" to make it viable.
[...] Yeah, D has a really beautiful, marvelous core that works really well and addresses safety concerns, productivity, scalability, and meta-programming needs. But outside this core is a bunch of "weird sh**", as the above video aptly puts it, of poorly-interacting corner cases, unexpected (often legacy) behaviours, and incompletely- or poorly- implemented features. These technical debts greatly detract from D's overall value, yet there is no easy way to fix them without causing massive breakage of existing D code (or other D features). It's sad, but it's reminiscient of the bad ole days when C++ shops would dictate, via convention/policy to use only a certain, sane(r) subset of C++ while avoiding the nastier parts. The parts of the language to be avoided is much smaller in D than in C++, but still, it's there, and it detracts from the overall D experience. T
Well, I wouldn't afraid anything while D has this great community, first of all. No worries! Everything has its advantages and disadvantages. I totally agree to Andrei that Rust has "a disharmonic personality" (https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/A drei-Alexandrescu). For example you can read a post of one of active Rust user about Rust drawback(s) he has encountered in a real project: http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-in-c.html So let's continue and everything will be ok!
Jul 19
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
On Fri, 2019-07-19 at 00:12 +0000, Mike Franklin via Digitalmars-d wrote:
 [=E2=80=A6]
=20
 I think there is something that Microsoft is overlooking with D. =20
 In the last 2 paragraphs of the blog post they say that=20
 programmers should be using managed languages like C#|F# whenever=20
 possible, but use Rust when the prior don't scale.
[=E2=80=A6] That is going to make the Java and JVM-based languages communities very hap= py indeed. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Jul 19
prev sibling next sibling parent bpr <brogoff gmail.com> writes:
On Friday, 19 July 2019 at 00:12:06 UTC, Mike Franklin wrote:
 D is unique from Rust and C# in that is scales both up and down.
I assume that you're claiming that Rust doesn't scale, or scale well, in some direction, likely 'up', and that D does scale well in this direction, and the other. I don't believe there's evidence for Rust inability to scale yet. C and C++ both scaled, in the sense that they are used from embedded devices up to full scale apps in many domains, and if anything to me Rust looks more promising than either. It's quite young compared to D and has already seen more widespread adoption where I live. Your "weird shit" example suggests that scaling up with D is nontrivial, even for an expert who really wants D to work to avoid C++. Also, I like the algebraic data types of Rust/Swift/Scala/OCaml/... a lot. My version of 'Dust' would have algebraic data types, immutability as the default, D templates, overloading, static introspection, and macros. As much Rust as D there. In that sense, just adding more safety features to D is not making it Dust for me. Time for a new D?
  So, Microsoft is missing an opportunity to have one language 
 for all use cases.  But I still think D has to do something 
 about the technical debt and other "weird sh**" to make it 
 viable.
I don't see why Microsoft would consider D rather than Rust or some other language. With the technical debt and "weird shit" you mention why wouldn't they just start on something new, learning from the design of D?
Jul 19
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/18/2019 5:12 PM, Mike Franklin wrote:
 ... and D could complete better with Rust if it had  safe-by-default and 
 statically-check ownership/borrowing mechanism as Walter recently proposed.
D has some huge advantages over Rust. For example, D has a familiar syntax and jargon. For another, you'll be able to move to memory safety incrementally with D, you won't have to rewrite your app from the start. D's metaprogramming abilities far exceed Rust's. Etc.
Jul 20
next sibling parent reply Laeeth Isharc <laeeth kaleidic.io> writes:
On Sunday, 21 July 2019 at 00:22:11 UTC, Walter Bright wrote:
 On 7/18/2019 5:12 PM, Mike Franklin wrote:
 ... and D could complete better with Rust if it had 
  safe-by-default and statically-check ownership/borrowing 
 mechanism as Walter recently proposed.
D has some huge advantages over Rust. For example, D has a familiar syntax and jargon. For another, you'll be able to move to memory safety incrementally with D, you won't have to rewrite your app from the start. D's metaprogramming abilities far exceed Rust's. Etc.
What's missing is a tool to port C to D. Atila didn't like the idea - 'thats what a C compiler is for' but I think it would make a difference. Rust had a multimillion dollar DoD grant to support their tool that does this, but it's not something out of reach of being a community project I think. One could even use their tool that outputs the libclang tool as CBOR. It's just at the other end - turning that into a D AST was beyond what I could manage in the time available.
Jul 20
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/20/2019 8:27 PM, Laeeth Isharc wrote:
 What's missing is a tool to port C to D.  Atila didn't like the idea - 'thats 
 what a C compiler is for' but I think it would make a difference.  Rust had a 
 multimillion dollar DoD grant to support their tool that does this, but it's
not 
 something out of reach of being a community project I think.  One could even
use 
 their tool that outputs the libclang tool as CBOR.  It's just at the other
end - 
 turning that into a D AST was beyond what I could manage in the time available.
Consider that we already have a C99 compiler at our disposal - DMC. 90% of making a C to D translator is already done. It's also intertwined with a C++98 compiler (!) It's even written in D (!!) https://github.com/DigitalMars/Compiler/tree/master/dm/src/dmc
Jul 20
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Sat, 2019-07-20 at 17:22 -0700, Walter Bright via Digitalmars-d wrote:
=20
[=E2=80=A6]
 D has some huge advantages over Rust.
In certain cases, yes. For me D/GtkD/GStreamerD is better than Rust/gtk- rs/gstreamer-rs for writing GTK+ and GStreamer based applications exactly because inheritance, integral to the GObject mode, is part of D whereas is = not in Rust and there has to be massive superstructure in gtk-rs and gstreamer-= rs to handle this. In other cases, no. GStreamer folk have chosen Rust as the language for GStreamer so using Rust for applications gets support using D leaves you on your own.
 For example, D has a familiar syntax and jargon. For another, you'll be a=
ble
 to=20
 move to memory safety incrementally with D, you won't have to rewrite you=
r
 app=20
 from the start. D's metaprogramming abilities far exceed Rust's. Etc.
I wonder of incremental change of programming language in a codebase is jus= t a nice concept rather than a practiced reality? One of Kotlin's massive advantages was that Java codebases could be incrementally transformed as needed from Java to Kotlin. Yet this is not ho= w things have happened (as far as I know). Kotlin has taken Android developme= nt by storm, but this is nothing to do with incremental change of a code base. It seems Java codebases are treated as Java, and part Java, part Kotlin is = not seen as a way forward. Although Rust is now big in the GStreamer community, it is only for new or replacement plugins, there appears to be no replacement of C code with Rust code in the core libraries. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk better than=20
Jul 21
next sibling parent reply Laeeth Isharc <laeeth kaleidic.io> writes:
On Sunday, 21 July 2019 at 09:55:24 UTC, Russel Winder wrote:
 On Sat, 2019-07-20 at 17:22 -0700, Walter Bright via 
 Digitalmars-d wrote:
 
[…]
 D has some huge advantages over Rust.
In certain cases, yes. For me D/GtkD/GStreamerD is better than Rust/gtk- rs/gstreamer-rs for writing GTK+ and GStreamer based applications exactly because inheritance, integral to the GObject mode, is part of D whereas is not in Rust and there has to be massive superstructure in gtk-rs and gstreamer-rs to handle this. In other cases, no. GStreamer folk have chosen Rust as the language for GStreamer so using Rust for applications gets support using D leaves you on your own.
 For example, D has a familiar syntax and jargon. For another, 
 you'll be able
 to
 move to memory safety incrementally with D, you won't have to 
 rewrite your
 app
 from the start. D's metaprogramming abilities far exceed 
 Rust's. Etc.
I wonder of incremental change of programming language in a codebase is just a nice concept rather than a practiced reality?
It's what we have done with a C++ codebase that was moving very fast (being refactored, not just bug fixes and new features - the refactoring wasn't my decision). Actually took a snapshot, one-off port to D and then gingerly merging in piece by piece of the new code. One problem is that if you replace (as a thought experiment) one randomly chosen C++ class with D then doing it the naive way you have to find a way to deal with translating the recursive includes of every C++ thing depended on by the C++ class you replace with D. Which might be fine till you get to Boost and STL. On the other hand it's only that you need to know the sizes of members for value types and if they are private you can just make them opaque/blobs (which we now do in dpp and I think there is a blacklist feature too for STL etc, though there was some debate about that one and not sure if it went in). But if you imagine the graph of dependencies not everything depends equally on everything else, so you can much more easily replace neighbourhoods than streets. I proposed to use Calypso, but nobody liked the idea enough. The code gen doesn't need to be utterly dependably solid because Calypso would get you the ability to replace one house at a time until you have replaced the neighbourhood (and then at that stage it's much easier to handle manually or in a semi-automated way) whilst having building and likely working code all along the way - no need to actually use Calypso object code in production.
 One of Kotlin's massive advantages was that Java codebases 
 could be incrementally transformed as needed from Java to 
 Kotlin. Yet this is not how things have happened (as far as I 
 know). Kotlin has taken Android development by storm, but this 
 is nothing to do with incremental change of a code base.
But I suppose the mobile market is intrinsically quite different from some other areas? For some kinds of internal enterprise code one can't realistically just throw away the old code and write new code because there is quite a lot of fiddly domain knowledge embedded in that legacy code and the consequence-based calculus means that the bar to trusting tests to catch everything is quite high. Probably a file system or kernel might have similar constraints for different reasons. And I do wonder if the impression one gets from tech media (social and otherwise) leads to a distorted perception of reality. People from mobile, web etc have a much higher propensity to talk about their work than people in other kinds of enterprises, and yet the latter set is quite important, and I would guess in aggregate would hold much greater economic significance.
 It seems Java codebases are treated as Java, and part Java, 
 part Kotlin is not seen as a way forward.
We have some Java code although not a lot and favouring Kotlin for newer things. I think if we ever replaced the Java with Kotlin we wouldn't do a rewrite in one go. My guess is that most people in finance are like that. Finance isn't economically tiny. Deutsche bank has had some challenges recently but they recently announced a tech spending plan of EUR13bn by 2022. I think Generali (a big insurer) started something of similar magnitude a couple of years ago too.
 Although Rust is now big in the GStreamer community, it is only 
 for new or replacement plugins, there appears to be no 
 replacement of C code with Rust code in the core libraries.
It's still quite early though. c2rust has been out just over a year. Corrode came out three years ago and I think wasn't as good. That's a blink of an eye on relevant timescales I think.
Jul 21
parent Russel Winder <russel winder.org.uk> writes:
On Sun, 2019-07-21 at 22:08 +0000, Laeeth Isharc via Digitalmars-d wrote:
[=E2=80=A6]
 But I suppose the mobile market is intrinsically quite different=20
 from some other areas?  For some kinds of internal enterprise=20
 code one can't realistically just throw away the old code and=20
 write new code because there is quite a lot of fiddly domain=20
 knowledge embedded in that legacy code and the consequence-based=20
 calculus means that the bar to trusting tests to catch everything=20
 is quite high.  Probably a file system or kernel might have=20
 similar constraints for different reasons.
As I understand it, the major issue is that the JVM on Android is quite ancient and so is the version of Java that can be used. Kotlin brings moder= n programming techniques to the Android JVM as it is and so has a major advantage over using Java on that platform. In the Web server and desktop application world, most organisations are at least on JDK 8 if not JDK 11. = So the version of Java is less ancient and so less at a disadvantage compared = to Kotlin.
 And I do wonder if the impression one gets from tech media=20
 (social and otherwise) leads to a distorted perception of=20
 reality.  People from mobile, web etc have a much higher=20
 propensity to talk about their work than people in other kinds of=20
 enterprises, and yet the latter set is quite important, and I=20
 would guess in aggregate would hold much greater economic=20
 significance.
=20
[=E2=80=A6] True a lot of Android applications are constructed by big organisations, an= d done quietly, but the Android platform has a much larger number of small organisation and individuals who are very vocal compared to the server aren= a. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Jul 23
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/21/2019 2:55 AM, Russel Winder wrote:
 I wonder of incremental change of programming language in a codebase is just a
 nice concept rather than a practiced reality?
 
 One of Kotlin's massive advantages was that Java codebases could be
 incrementally transformed as needed from Java to Kotlin. Yet this is not how
 things have happened (as far as I know). Kotlin has taken Android development
 by storm, but this is nothing to do with incremental change of a code base.
 
 It seems Java codebases are treated as Java, and part Java, part Kotlin is not
 seen as a way forward.
Both can be true. Having the option to do incremental change can be a major factor in selection, even if one decides later to not make use of it.
Jul 21
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 21 July 2019 at 09:55:24 UTC, Russel Winder wrote:
 On Sat, 2019-07-20 at 17:22 -0700, Walter Bright via 
 Digitalmars-d wrote:
 
[…]
 D has some huge advantages over Rust.
In certain cases, yes. For me D/GtkD/GStreamerD is better than Rust/gtk- rs/gstreamer-rs for writing GTK+ and GStreamer based applications exactly because inheritance, integral to the GObject mode, is part of D whereas is not in Rust and there has to be massive superstructure in gtk-rs and gstreamer-rs to handle this. In other cases, no. GStreamer folk have chosen Rust as the language for GStreamer so using Rust for applications gets support using D leaves you on your own.
 For example, D has a familiar syntax and jargon. For another, 
 you'll be able
 to
 move to memory safety incrementally with D, you won't have to 
 rewrite your
 app
 from the start. D's metaprogramming abilities far exceed 
 Rust's. Etc.
I wonder of incremental change of programming language in a codebase is just a nice concept rather than a practiced reality? One of Kotlin's massive advantages was that Java codebases could be incrementally transformed as needed from Java to Kotlin. Yet this is not how things have happened (as far as I know). Kotlin has taken Android development by storm, but this is nothing to do with incremental change of a code base. It seems Java codebases are treated as Java, and part Java, part Kotlin is not seen as a way forward. Although Rust is now big in the GStreamer community, it is only for new or replacement plugins, there appears to be no replacement of C code with Rust code in the core libraries.
Kotlin will never win the hearts of all Java devs, because platform languages always win in the end, so it will just limp along just like any other JVM alternative language. The KVM is Android, there Kotlin might reign now, specially since Google is only willing to partially update its support up to some Java 10 features, and they announced Kotlin First Everywhere at IO. They just need to take care not to be overtaken by either the ChromeOS or Fuchsia teams.
Jul 22
parent Russel Winder <russel winder.org.uk> writes:
On Mon, 2019-07-22 at 07:06 +0000, Paulo Pinto via Digitalmars-d wrote:
=20
[=E2=80=A6]
 Kotlin will never win the hearts of all Java devs, because=20
 platform languages always win in the end, so it will just limp=20
 along just like any other JVM alternative language.
=20
 [=E2=80=A6]
There is often a deeply conservative approach within medium-sized and big organisations such that programmers stick with Java and only start using ne= w Java features when there is a change of (usually LTS) JVM/JDK version. This has it's real downsides as well as upsides. What is really sad in the JVM-based milieu in far too many organisations is the use of Java and only Java. So many of the systems would benefit from making use of multiple languages on the JVM, in particular Java/Groovy or Java/Clojure to get statically typed and dynamically typed subsystems. Whil= st the JVM was created for Java, it is now an inherently multi-paradigm platfo= rm. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Jul 23
prev sibling next sibling parent Ron Tarrant <rontarrant gmail.com> writes:
On Sunday, 21 July 2019 at 00:22:11 UTC, Walter Bright wrote:

 D has some huge advantages over Rust.

 For example, D has a familiar syntax and jargon. For another, 
 you'll be able to move to memory safety incrementally with D, 
 you won't have to rewrite your app from the start.
I hear ya, Walter. This was one of the reasons I adopted D. Off F#, PHP-Win, and anything else I could find. All I wanted was C _without_ the headache of managing memory and _with_ the many advantages of OOP. I also, like Microsoft, didn't want to be at the mercy of a corporation that might decide to pull the plug without notice... which is almost ironic if you think about it. :)
Jul 21
prev sibling next sibling parent reply aliak <something something.com> writes:
On Sunday, 21 July 2019 at 00:22:11 UTC, Walter Bright wrote:
 On 7/18/2019 5:12 PM, Mike Franklin wrote:
 ... and D could complete better with Rust if it had 
  safe-by-default and statically-check ownership/borrowing 
 mechanism as Walter recently proposed.
D has some huge advantages over Rust. For example, D has a familiar syntax and jargon. For another, you'll be able to move to memory safety incrementally with D, you won't have to rewrite your app from the start. D's metaprogramming abilities far exceed Rust's. Etc.
Me and a colleagues/friends are currently in the process of starting up a startup aimed at the collaboration market, and we have this concept of integrations that integration with github, jira, bugzilla, and other software-related collaboration tools. And these integrations are largely very similar in nature and so we've started writing them in different languages just to see how they all feel - the three so far are D, Rust, and Typescript. Two of us have very heavy C++ backgrounds. So far, Rust's unfamiliar syntax has not been a disadvantage - the person who has the least C/C++ exposure is mainly on that one - reviewing is also nice, because Rust is actually nice to read (IMO) once you get around the whole borrow semantics hoopla. Moving incrementally to memory safety is not an issue, since we are not converting a C/C++ application - we are starting from scratch. So safe by default is the advantage in that case. But, it does slow down our development speed. We have not found familiar jargon to be an advantage (i assume by familiar you mean to C++). Since D has its own unique jargon anyway (init/constructor differences, autodecoding, alias this, shared module ctors, mixin templates, VRP, for e.g.) - so same same. Metaprogramming has been a huge advantage in the D version. It makes writing things like serialization/deserialization, algorithm specializations, and structuring our models much easier. When everything is going smoothly the development speed with D far outweighs the Rust one because of the borrow checker. It's a constant battle. However, the D version suffers form its ecosystem - the other day I had to write jwt/crypto stuff - neither the typescript or rust version needed that. D-bugs is the other thing - A bug in Nullable cause of us to swear off working on the D version - but the same person got defeated by the Rust borrow checker but that for some reason did not make him swear it off.
Jul 21
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/21/2019 11:46 AM, aliak wrote:
 A bug in Nullable cause of us to swear off working on the D version - 
 but the same person got defeated by the Rust borrow checker but that for some 
 reason did not make him swear it off.
I'm not surprised. I see this all the time. It's the "social proof" thing at work.
Jul 21
next sibling parent aliak <something something.com> writes:
On Monday, 22 July 2019 at 01:31:17 UTC, Walter Bright wrote:
 On 7/21/2019 11:46 AM, aliak wrote:
 A bug in Nullable cause of us to swear off working on the D 
 version - but the same person got defeated by the Rust borrow 
 checker but that for some reason did not make him swear it off.
I'm not surprised. I see this all the time. It's the "social proof" thing at work.
One is based on instability and the other is based on an assumed learning curve. So I can understand actually.
Jul 22
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Monday, 22 July 2019 at 01:31:17 UTC, Walter Bright wrote:
 On 7/21/2019 11:46 AM, aliak wrote:
 A bug in Nullable cause of us to swear off working on the D 
 version - but the same person got defeated by the Rust borrow 
 checker but that for some reason did not make him swear it off.
I'm not surprised. I see this all the time. It's the "social proof" thing at work.
I think we can get some social proof, it requires continuing: - emphasizing commercial success ($$$$$), big businesses over smaller ones. - replacing (in volume) talk that excuse D for its choices(GC, supposedly "wrong" default that are actually the right ones...) with a discourse that talks about positives. This is a big one, you can see it all the time: if your release notes detail all the bug that were fixed, the overall impression is that "wow, there are many bugs". - phasing out "D-man", or invest in making it more like a winning mascot In literatture about "diffusion of innovations", it's pretty clear who brings the new technology matters quite a bit more than adequacy. Social proof doesn't _have to_ work against us. "D is ancient and has 'worked out' " => "D is stable and has a growing amount of companies using it for beating the expectations" (which is true btw) In my view, people using unproductive languages (you know what they are) are "loosers", it shouldn't be us that pass as loosers.
Jul 22
parent reply Newbie2019 <newbie2019 gmail.com> writes:
On Monday, 22 July 2019 at 13:18:29 UTC, Guillaume Piolat wrote:
 "D is ancient and has 'worked out' " => "D is stable and has a 
 growing amount of companies using it for beating the 
 expectations" (which is true btw)

 In my view, people using unproductive languages (you know what 
 they are) are "loosers", it shouldn't be us that pass as 
 loosers.
I suggestion we should focus fix bugs and improve support/platform/quality. Keep improve IDE, dub package, language server. Finish the LDC support for IOS/Android, (I read from forum history, people say it take a weekend work to made IOS branch upgrade to latest version, but last commit for IOS is 2017). I see in this forum, people talk about D will catch web/mobile/WASM wave since 2015 or even earlier. But compare other language today, DLANg Github trending is empty almost every time when I check. Lack of user population is hurting D as vicious circle. No people use, resulting in hidden bugs, and then lead to less people use.
Jul 22
next sibling parent reply XavierAP <n3minis-git yahoo.es> writes:
On Monday, 22 July 2019 at 16:29:16 UTC, Newbie2019 wrote:
 Lack of user  population is hurting D as vicious circle.  No 
 people use, resulting in hidden bugs,   and then lead to less 
 people use.
I too think this is the biggest problem (I am repeating myself). So what can we do to encourage newcomers? Is D welcoming, and appealing? There are some good ideas posted above; are they listened to? My two cents: these newsgroups/forums could benefit from some reorganization; many people have asked/proposed changes. As for Learn, the last community survey voted in favor of moving that to StackOverflow (where there is already D traffic); this is a more suitable, powerful and searchable platform, and would provide free exposure and immense search engine exposure compared to here. Does D have or want a plan to promote itself, given that the results so far in this regard have not been good at all? Are we too busy putting out fires, and too stressed because we don't have enough firefighters, that we don't stop to realize that no one besides the firefighters care that fires are burning? Are other people not open to D, or is it that D neglects to promote itself properly at all?
Jul 22
parent reply Laeeth Isharc <laeeth kaleidic.io> writes:
On Monday, 22 July 2019 at 19:52:33 UTC, XavierAP wrote:
 On Monday, 22 July 2019 at 16:29:16 UTC, Newbie2019 wrote:
 Lack of user  population is hurting D as vicious circle.  No 
 people use, resulting in hidden bugs,   and then lead to less 
 people use.
I too think this is the biggest problem (I am repeating myself). So what can we do to encourage newcomers? Is D welcoming, and appealing? There are some good ideas posted above; are they listened to? My two cents: these newsgroups/forums could benefit from some reorganization; many people have asked/proposed changes. As for Learn, the last community survey voted in favor of moving that to StackOverflow (where there is already D traffic); this is a more suitable, powerful and searchable platform, and would provide free exposure and immense search engine exposure compared to here. Does D have or want a plan to promote itself, given that the results so far in this regard have not been good at all? Are we too busy putting out fires, and too stressed because we don't have enough firefighters, that we don't stop to realize that no one besides the firefighters care that fires are burning? Are other people not open to D, or is it that D neglects to promote itself properly at all?
What matters for a tool is are people using it to accomplish things. Not so long ago it seemed like it was mostly Sociomantic and now there are quite a few more cases where people are using it to accomplish things. Enterprise users in particular post very little in the forums, maybe because they have a lot of work to do. You can even see this happen as people move from having primarily a community involvement to actually using D at work. Most obvious to me in people that I work with that came from the community. It's a time of transition. Most companies don't speak at technical conferences and aren't involved at all in open source. So for internal innovation it's not going to leave much of a footprint in the open source world. D isn't competing with Rust or Go really,in my opinion. It's definitely competing with Excel, but it might even be competing with paper and telephone calls. In a sense with the introduction of search at Google there was a fight to the death between C++ and paper, and it really wasn't a fair battle. It's not very nice of you to say the results so far in language outreach have not been good at all without being more specific. The Foundation is just getting started and same thing with the D blog. Seems to me the latter has had a pretty strong start. The world is long people with strong views about what to do,short on those willing to contribute something to make their vision a reality. Just imagine if Seb Wilzbach had spent all his time arguing for why we should have executable examples on the web docs rather than just doing the work needed to make it happen. I do agree that D can still do better to get across its merits but I think the answer to that is contributing educational blog posts and success stories. The values of D are a bit different from those of Rust or Go it seems to me. Bryan Cantrill talk on platform as values is very good on this. It's not that it's a bad idea to do more, but I think that accessibility just is one value that's less important to the D community than for example to Rust. Oh well - values are about how you choose when you can't have everything and accessibility, particularly prematurely, isn't only a benefit. Quality of adopter dominates quantity I think at this stage. One Manu or Liran or Bastiaan or Dragos or Ali is worth quite a few assorted Reddit commentators because there's a much greater contagion effect and because adoption within organisations is driven by different sorts of people who look at different things from what you might expect. Board level people are quite open minded. It's the middle managers that are most caught up in social proof dynamics. I had the outgoing COO of a large UK investment bank (responsible for technology too) stop by to see what we were doing and he was quite open and curious. But I bet the guy five levels down would likely have a rather different mindset; on the other hand it wouldn't be the junior guy that is deciding. There's a massive tech spending boom underway in finance and maybe other non-tech companies. Deutsche Bank is spending 13bn by 2022 and their market cap is only 16bn. Generali,the insurance company, had a similar sized programme. Digital transformation changes so many things that what seemed impossible becomes so. I'm not saying they are going to use D because I don't know. But the context is the pie is expanding and I don't think a zero sum mindset gets you anywhere. Digital transformation is about adaptiveness and speed. Moore's Law is dead in economic terms and yet useful data sets might grow 10x in the next dozen years. I don't think there will be a shortage of people in coming years wanting to write fast code fast and some of those will use D. I've been saying this for a few years now and since then Mercedes, Audi and Weka are just a few of the notable adopters. I don't think people were expecting that to happen five years ago. These things take a long time.
Jul 22
next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Tuesday, 23 July 2019 at 00:03:28 UTC, Laeeth Isharc wrote:
[...]
 Enterprise users in particular post very little in the forums, 
 maybe because they have a lot of work to do. You can even see 
 this happen as people move from having primarily a community 
 involvement to actually using D at work.  Most obvious to me in 
 people that I work with that came from the community.
[...] True. So thank you for finding the time to share your valuable views. Bastiaan.
Jul 23
prev sibling next sibling parent Chris <wendlec tcd.ie> writes:
On Tuesday, 23 July 2019 at 00:03:28 UTC, Laeeth Isharc wrote:

 Digital transformation is about adaptiveness and speed.  
 Moore's Law is dead in economic terms and yet useful data sets 
 might grow 10x in the next dozen years.  I don't think there 
 will be a shortage of people in coming years wanting to write 
 fast code fast and some of those will use D.  I've been saying 
 this for a few years now and since then Mercedes, Audi and Weka 
 are just a few of the notable adopters.  I don't think people 
 were expecting that to happen five years ago.  These things 
 take a long time.
Does the community / D Foundation have stats about the following things: 1. How many companies (big or small) have stopped using D over the years and why? 2. What do Netflix, Mercedes, Audi etc. use D for? In-house / niche programs, R&D or big real world applications? E.g. do command line tools that copy files count as "XYZ is using D now" too? 3. Have they continued to use D or was it just a one-off to see if it'd be a good option? It's easy to drop names of big corporations, but it doesn't tell us anything, really. Also, I suppose a lot of companies / people who just dropped D again wouldn't tell you because they a) couldn't be bothered or b) out for courtesy.
Jul 23
prev sibling parent XavierAP <n3minis-git yahoo.es> writes:
On Tuesday, 23 July 2019 at 00:03:28 UTC, Laeeth Isharc wrote:
 It's not very nice of you to say the results so far in language 
 outreach have not been good at all without being more specific.
  The Foundation is just getting started and same thing with the 
 D blog.  Seems to me the latter has had a pretty strong start.

 The world is long people with strong views about what to 
 do,short on those willing to contribute something to make their 
 vision a reality.

 [...]

 Digital transformation is about adaptiveness and speed.  
 Moore's Law is dead in economic terms and yet useful data sets 
 might grow 10x in the next dozen years.  I don't think there 
 will be a shortage of people in coming years wanting to write 
 fast code fast and some of those will use D.  I've been saying 
 this for a few years now and since then Mercedes, Audi and Weka 
 are just a few of the notable adopters.  I don't think people 
 were expecting that to happen five years ago.  These things 
 take a long time.
I didn't mean to sound so negative. And I agree that there is some promising recent success in specific companies. My meaning is only that all avenues should be pursued, even if fixing one issue or implementing one memory management paradigm looks like the critical priority from the CS point of view. Precisely because, while improvements are on the way, D as is can be used by many more people than now. For example there is a huge gap between the original vision for D (high and low level, GC in principle, etc) and the demands of the current community. The latter is a restriction of the former good to address this demand but in addition, was the original vision so wrong; is D not a good high level language already (and more)? Indeed the biggest success stories I know (such as Weka and other DConf talks) take advantage of D's abilities along the whole spectrum from high to very low level (dealing with whatever open issues, excess of internal dependencies, druntime etc); but why doesn't D have more adoption by purely high level users, competing with e.g. Python -- at least by those who are hitting its limitations and then need to interop with C/C++ etc? Of course D's corporate sponsors aren't as powerful as Google, Microsoft, Oracle or Sun formerly, or even Mozilla. I used to assume that Python must have been the perfect example of a purely grassroots open-source success story; but upon closer examination Python did not have corporate sponsors -- it had two state sponsors (Dutch CWI and USA CNRI)! So indeed experience says that D is at a big disadvantage, and it is not so surprising (or discouraging) that it hasn't reached the adoption of even Rust or Go in a longer time; but this is a reason to try harder in every front. (Note: corporate sponsorship probably helps with promotion/PR/branding as much as it does with manpower and funding.) I must admit I have a big mouth while I am not really using D for any sizable project. So as others I also see the issue from the point of view of what has stopped me from doing so (imo small ecosystem due to low adoption in a vicious circle). Still I've been following D for many years because I like it, I like and basically agree with Walter and Andrei's vision all along, and I hope it grows. I even post on LinkedIn some news e.g. the vacancies at Audi AID. But precisely about media and promotion, I wonder if D has a strategy. There's these news groups/forums. Then there's third party media and various websites frequented by developers, which can be separate islands (Reddit, Hacker News, LinkedIn, Twitter, Stack Overflow...) I reckon corporate directors visit some more than others or not at all. Though I do think introducing a new language will always come from senior developers below; but managers need to be (open to be) convinced.
Jul 23
prev sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Monday, 22 July 2019 at 16:29:16 UTC, Newbie2019 wrote:
 I suggestion we should focus fix bugs and improve 
 support/platform/quality.

 Keep improve IDE,  dub package, language server.

 Finish the LDC support for IOS/Android,  (I read from forum 
 history,  people say it take a weekend work to made IOS branch 
 upgrade to latest version,  but last commit for IOS is 2017).
This is a variation of "build it and they will come" talk. I have thousands of software users, and they couldn't bother that I fix bugs, improve support and quality. What they care is about the perception of that software, which is a social construct. Existing users may care, but new ones won't take a look just because bug X was fixed or "compiler has improved speed by 3%".
Jul 23
prev sibling parent Exil <Exil gmall.com> writes:
On Monday, 22 July 2019 at 01:31:17 UTC, Walter Bright wrote:
 On 7/21/2019 11:46 AM, aliak wrote:
 A bug in Nullable cause of us to swear off working on the D 
 version - but the same person got defeated by the Rust borrow 
 checker but that for some reason did not make him swear it off.
I'm not surprised. I see this all the time. It's the "social proof" thing at work.
Well one has bug(s) and is poorly named for what it actually implements. It isn't being fixed because of "reasons". The other is a feature that is working as intended, preventing the user from doing something they shouldn't be doing. I know which one I would be frustrated with more, especially if it wasn't the first bug I've encountered ;).
Jul 22
prev sibling next sibling parent Newbie2019 <newbie2019 gmail.com> writes:
On Sunday, 21 July 2019 at 00:22:11 UTC, Walter Bright wrote:
 D has some huge advantages over Rust.

 For example, D has a familiar syntax and jargon. For another, 
 you'll be able to move to memory safety incrementally with D, 
 you won't have to rewrite your app from the start. D's 
 metaprogramming abilities far exceed Rust's. Etc.
But most developer in real life will refuse to use D, and they think Rust has huge advantages over D, which include community and developers, not just safety. Compare to Rust developer community, D is a small village. Rust is massive International Capital City. Compare to Rust open source projects, D is Cottages, Rust is Skyscraper. D has GUI/web/mobile support before Rust, but the related real live Github projects quantity and quality is approximately equal to none(except GTKD team, I guess ).
Jul 22
prev sibling next sibling parent reply Margo <margo2 margotics.des> writes:
On Sunday, 21 July 2019 at 00:22:11 UTC, Walter Bright wrote:
 On 7/18/2019 5:12 PM, Mike Franklin wrote:
 ... and D could complete better with Rust if it had 
  safe-by-default and statically-check ownership/borrowing 
 mechanism as Walter recently proposed.
D has some huge advantages over Rust. For example, D has a familiar syntax and jargon. For another, you'll be able to move to memory safety incrementally with D, you won't have to rewrite your app from the start.
If you can not convince a company like Jetbrain, to support a official D language plugin, then those few advantages do not rack up to much. Rust language plugins, be it vscode, jetbrain products or other ides are well developed allowing for more developers choice. There is a reason why some major companies look at Rust for replacing C++ and not D. No matter how much advantages you think D has, it can be said, that without the actual support system to convince the companies and developers, D will simply keep trampling on the same spot. Recently i needed some specific crates for a Rust project, i looked over at D. More then half the stuff simply did not even exist for D. D package growth is like 1 per day, with Rust growing by 25 per day. Its easy to see not just momentum diference but also how easier it is to get going with a project in Rust ( and half a dozen other languages ) compared to D. https://www.youtube.com/embed/TkNep5zHWNw?start=1496 Shows the exact reason why D has issues. Stand alone D is usable but the moment you need specific packages or tools, D can not be considered a main application language. And no, we do not have the time to write packages for D, when we can find perfectly good quality and supported packages for Rust ( and half a dozen other GC languages! ). Stop confusing your language with its eco system. Nobody gives a darn about a language if everything around it is limited and frustrating. Its like having a 15" dong but having the face of a mull. Sure, you can be proud of that one thing but its not going to get you the girls ( or guys, we do not discriminate :) ) if the rest is lacking. In short: Language: A- ( some stuff is simply in conflict and half unfinished ) Library: C+ ( many past issues that haunt it today, ... ) Plugins: D- ( missing even basic plugins, low activity/support for many plugins, ... ) IDE Support: C- ( Only one really good supported IDE plugin, rest is basically C level, limited choice ) ... In other words: Stop being so darn proud of the language and realize that the language without the rest is simply not accepted for mainstream support. Its 2019 and beyond a few companies and some side project, nobody really gives a darn about D. Rust simply moves faster, has a better Eco system, better support, ... So unless you plan on trowing a truckload of money into hiring developers to speed up the development of those issues point, your simply no match for Rust. Its frankly pathetic whenever a popular blog comes up about Rust as a potential choice for a big company, that people here think "but we are also a choice, why does nobody really look at us". In essence, you had your chance for almost 20 years and wasted it. Resulting in the new kid on the block to run circles around you. Its like watching people who's football team that never left 3th league, think its going to be like those other guys. Sorry if it sounds cruel. There is only 2 ways to fix this: Lots of money and a big daddy, preferably both. If you can not go that route, your simply going to be stuck forever going at a snails speed, surviving on volunteers time, thinking you will convince those big guys. While everybody else leaves you behind in the dust. Walter, you remind me why some companies never become a success. Great ideas, genius, hard working but geniuses do not become fortune 500's without the marketing sales pitch to convince people to put the money into your company, for a (potential) payout years down the line. Any talk about code refactoring, library splitting, etc is a wast of hot air. Again, sorry to say this but its like looking at a Echo Chamber whenever i past by here.
Jul 22
next sibling parent reply Laeeth Isharc <laeeth kaleidic.io> writes:
On Monday, 22 July 2019 at 23:16:26 UTC, Margo wrote:
 On Sunday, 21 July 2019 at 00:22:11 UTC, Walter Bright wrote:
 On 7/18/2019 5:12 PM, Mike Franklin wrote:
 ... and D could complete better with Rust if it had 
  safe-by-default and statically-check ownership/borrowing 
 mechanism as Walter recently proposed.
D has some huge advantages over Rust. For example, D has a familiar syntax and jargon. For another, you'll be able to move to memory safety incrementally with D, you won't have to rewrite your app from the start.
If you can not convince a company like Jetbrain, to support a official D language plugin, then those few advantages do not rack up to much. Rust language plugins, be it vscode, jetbrain products or other ides are well developed allowing for more developers choice.
Not everyone uses an IDE. It's obviously an impediment to adoption in the games industry judging by what Manu says, but there are other industries besides games and in some places people don't use IDEs much at all.
 There is a reason why some major companies look at Rust for 
 replacing C++ and not D. No matter how much advantages you 
 think D has, it can be said, that without the actual support 
 system to convince the companies and developers, D will simply 
 keep trampling on the same spot.
Why so concerned about major companies when small and medium sized enterprises are in many places (the US being one) responsible for the majority of job creation. The Mittelstand in Germany has a bunch of world leading companies I have mostly never heard of. I think it would be much more interesting to know what the impediments are for them to adopt D than large companies. The moment you have a committee involved formed of people who are not owners then the facts become much less important than social perceptions. So why bother playing that game when you don't have to.
 Recently i needed some specific crates for a Rust project, i 
 looked over at D. More then half the stuff simply did not even 
 exist for D.

 D package growth is like 1 per day, with Rust growing by 25 per 
 day. Its easy to see not just momentum diference but also how 
 easier it is to get going with a project in Rust ( and half a 
 dozen other languages ) compared to D.

 https://www.youtube.com/embed/TkNep5zHWNw?start=1496

 Shows the exact reason why D has issues. Stand alone D is 
 usable but the moment you need specific packages or tools, D 
 can not be considered a main application language.
Using DPP you have all of C libraries and progressively the C++ capabilities are being extended although it's not there yet. D can easily call pyth though it's not the number one priority for me right now.
 And no, we do not have the time to write packages for D, when 
 we can find perfectly good quality and supported packages for 
 Rust ( and half a dozen other GC languages! ).
Well then maybe you shouldn't use D if that's your own calculus. Others might have a different calculus. My own experience has been that wrapping libraries takes time but it's a rounding error you can amortise in my context. The world is a very big place and it's amazing how different situations can be.
 Stop confusing your language with its eco system. Nobody gives 
 a darn about a language if everything around it is limited and 
 frustrating. Its like having a 15" dong but having the face of 
 a mull. Sure, you can be proud of that one thing but its not 
 going to get you the girls ( or guys, we do not discriminate :) 
 ) if the rest is lacking.
That's the thing - there's tremendous variation in what's important to people or even what they find appealing and not. I think whether D is right for you also depends on time preference of the people involved and the culture. I don't think it's a coincidence that D is surprisingly popular in Germany and Japan and is less appealing to Americans than one might have guessed. Academic work finds quite a big difference in time preference between the US and Germany. If you decide to use D, better be prepared for discomfort and suffering and the pain is front-loaded too. That may or may not be a problem and different people and groups within organisations will have a different degree of pain tolerance. My own view is it's just pain and discomfort and to try to focus on enterprise value added, and from that point of view these things are relevant but not that important.
 In other words: Stop being so darn proud of the language and 
 realize that the language without the rest is simply not 
 accepted for mainstream support. Its 2019 and beyond a few 
 companies and some side project, nobody really gives a darn 
 about D. Rust simply moves faster, has a better Eco system, 
 better support, ... So unless you plan on trowing a truckload 
 of money into hiring developers to speed up the development of 
 those issues point, your simply no match for Rust.
Why is mainstream adoption so important to you ? And I wonder if you have considered that the only way to change something about the world that bugs you is to act. Complaining by itself, I wonder how you think that will change anything.
 Its frankly pathetic whenever a popular blog comes up about 
 Rust as a potential choice for a big company, that people here 
 think "but we are also a choice, why does nobody really look at 
 us".
Big companies again. Can you explain in logical chain of causation terms why people should be particularly concerned about big companies? It reminds me of Americans planning to sell washing machines to China a few years back. But if we could get just 2% share of this enormous market... Yeah but you are thinking about it all wrong. That's simply not the way waves of the adoption of technologies tend to unfold and it definitely isn't going to be the story for D.
 Walter, you remind me why some companies never become a 
 success. Great ideas, genius, hard working but geniuses do not 
 become fortune 500's without the marketing sales pitch to 
 convince people to put the money into your company, for a 
 (potential) payout years down the line.
Study the history of the German Mittelstand. It's a much bigger world than just Anglo culture and in other places things can work quite differently. Marketing in particular is also in flux because people wised up. And btw plenty of companies are very successful not doing any marketing at all. It depends on your context. High trust cultures with a high future time orientation can work a bit differently. Have you ever started a company and sold it for a decent result? You might remember when speaking to Walter that he has, competing for years as a one man band with Microsoft and eventually being acquired. I think myself that yes dub could be improved and the registry also. Maybe we can make it an SAOC project. And that a start has been made on getting the merits of the language across and that from here what's necessary is just to build on that beginning. Success stories are the best form of marketing really I think. That and just educational posts and people quietly doing great work. Seb Wilzbach has achieved by far more in that respect than the total of all the naysayers and people complaining laid end to end. If you want to change reality then unless you have a very unusual mind with insights people are ready to hear,then nothing is going to happen unless you take action. And if one isn't interested in doing so,I wonder why it is that there would be an expectation that there will be a receptiveness to words. Without skin in the game, talk by itself is cheap.
Jul 22
next sibling parent reply Exil <Exil gmall.com> writes:
On Tuesday, 23 July 2019 at 00:47:09 UTC, Laeeth Isharc wrote:
 On Monday, 22 July 2019 at 23:16:26 UTC, Margo wrote:
 On Sunday, 21 July 2019 at 00:22:11 UTC, Walter Bright wrote:
 On 7/18/2019 5:12 PM, Mike Franklin wrote:
 ... and D could complete better with Rust if it had 
  safe-by-default and statically-check ownership/borrowing 
 mechanism as Walter recently proposed.
D has some huge advantages over Rust. For example, D has a familiar syntax and jargon. For another, you'll be able to move to memory safety incrementally with D, you won't have to rewrite your app from the start.
If you can not convince a company like Jetbrain, to support a official D language plugin, then those few advantages do not rack up to much. Rust language plugins, be it vscode, jetbrain products or other ides are well developed allowing for more developers choice.
Not everyone uses an IDE. It's obviously an impediment to adoption in the games industry judging by what Manu says, but there are other industries besides games and in some places people don't use IDEs much at all.
Autocomplete is a basic feature not limited to an IDE. VIM supports autocomplete, emacs, etc... It is an instrument that makes everything much easier to use when you can see all the functions you can call along with their respective documentation right as you are typing.
 There is a reason why some major companies look at Rust for 
 replacing C++ and not D. No matter how much advantages you 
 think D has, it can be said, that without the actual support 
 system to convince the companies and developers, D will simply 
 keep trampling on the same spot.
Why so concerned about major companies when small and medium sized enterprises are in many places (the US being one) responsible for the majority of job creation. The Mittelstand in Germany has a bunch of world leading companies I have mostly never heard of. I think it would be much more interesting to know what the impediments are for them to adopt D than large companies. The moment you have a committee involved formed of people who are not owners then the facts become much less important than social perceptions. So why bother playing that game when you don't have to.
Having small/medium companies that are simply using the language and aren't that affiliated with the language is different than having a larger company driving the language. Those small medium companies don't work together for one. A large company can have numerous projects that out number those small medium companies. All the teams working together, in communication with each other and the development team working on the language. This also doesn't help what you have observed: "Enterprise users in particular post very little in the forums, maybe because they have a lot of work to do. You can even see this happen as people move from having primarily a community involvement to actually using D at work. Most obvious to me in people that I work with that came from the community."
 Recently i needed some specific crates for a Rust project, i 
 looked over at D. More then half the stuff simply did not even 
 exist for D.

 D package growth is like 1 per day, with Rust growing by 25 
 per day. Its easy to see not just momentum diference but also 
 how easier it is to get going with a project in Rust ( and 
 half a dozen other languages ) compared to D.

 https://www.youtube.com/embed/TkNep5zHWNw?start=1496

 Shows the exact reason why D has issues. Stand alone D is 
 usable but the moment you need specific packages or tools, D 
 can not be considered a main application language.
Using DPP you have all of C libraries and progressively the C++ capabilities are being extended although it's not there yet. D can easily call pyth though it's not the number one priority for me right now.
Yes you can, but you won't have access to D's features when using a C library. You will have to do everything the way you do it in C. Including not having overloads. Unless you write a wrapper over it yourself, but then that kind of defeats the entire purpose. I use a C++ library and they have a new release almost every month or two. I've given up keeping my wrapper up to date even though there are features and improvements I want to use in the newer versions.
 In other words: Stop being so darn proud of the language and 
 realize that the language without the rest is simply not 
 accepted for mainstream support. Its 2019 and beyond a few 
 companies and some side project, nobody really gives a darn 
 about D. Rust simply moves faster, has a better Eco system, 
 better support, ... So unless you plan on trowing a truckload 
 of money into hiring developers to speed up the development of 
 those issues point, your simply no match for Rust.
Why is mainstream adoption so important to you ? And I wonder if you have considered that the only way to change something about the world that bugs you is to act. Complaining by itself, I wonder how you think that will change anything.
Assurance of survival. I can see D dying a slow death as it stands now, there isn't enough to keep it going on it's own like say C++.
 Have you ever started a company and sold it for a decent 
 result?  You might remember when speaking to Walter that he 
 has, competing for years as a one man band with Microsoft and 
 eventually being acquired.
First I've heard of it. Though companies like Microsoft swallow small companies whole all the time so not too strange to hear. The one's you hear about are those that don't concede and take a payout, though those are few and far between.
 I think myself that yes dub could be improved and the registry 
 also.  Maybe we can make it an SAOC project.   And that a start 
 has been made on getting the merits of the language across and 
 that from here what's necessary is just to build on that 
 beginning.

 Success stories are the best form of marketing really I think.  
 That and just educational posts and people quietly doing great 
 work.

 Seb Wilzbach has achieved by far more in that respect than the 
 total of all the naysayers and people complaining laid end to 
 end.

 If you want to change reality then unless you have a very 
 unusual mind with insights people are ready to hear,then 
 nothing is going to happen unless you take action.  And if one 
 isn't interested in doing so,I wonder why it is that there 
 would be an expectation that there will be a receptiveness to 
 words.
The problem is who has control of these things. I've made pull requests to dub, they just sit around and nothing gets done. Very few people have access to actually enact change. Don't say stuff like "you have to do action yourself" cause it's not on me or anyone else. There's hundreds of pull requests for DMD and DUB combined. There's only so much people can do when pull requests sit idle for months/years, especially worse when there's no responding. When something somewhat default appears, no one on the D team is willing to do anything about it. They all look to Walter, and Walter is usually to busy doing something else so he never gets around to it. But yah, a very naive thing to say considering the current state of how things are managed with the project. God bless Seb for having enhanced permission status ^TM.
Jul 22
parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2019-07-23 at 03:01 +0000, Exil via Digitalmars-d wrote:
 [=E2=80=A6]
=20
 The problem is who has control of these things. I've made pull=20
 requests to dub, they just sit around and nothing gets done. Very=20
 few people have access to actually enact change. Don't say stuff=20
 like "you have to do action yourself" cause it's not on me or=20
 anyone else. There's hundreds of pull requests for DMD and DUB=20
 combined. There's only so much people can do when pull requests=20
 sit idle for months/years, especially worse when there's no=20
 responding. When something somewhat default appears, no one on=20
 the D team is willing to do anything about it. They all look to=20
 Walter, and Walter is usually to busy doing something else so he=20
 never gets around to it. But yah, a very naive thing to say=20
 considering the current state of how things are managed with the=20
 project. God bless Seb for having enhanced permission status ^TM.
Go and Rust got this right from the very outset =E2=80=93 make the standard= library as small as possible and have everything else provided through user packages/crates. Go only got this partly right in that there was no central repository, just DVCS packages. Rust got this very right in that it has a central repository and Cargo can use DVCS crates and even local file crates= . This creates a vibrant community with some competition (which has bad as we= ll as good sides to it). I am sure Dub can do for D most of the things Cargo does for Rust, but the crucial difference is Phobos in D vs std in Rust. Phobos is driven by the "batteries included" philosophy which is a philosophy past it's time. Pytho= n and C++ are also failing to come to terms with this. What D needs is to rip everything out of Phobos that is not actually needed for the compiler to compile code and put it into the Dub repository as separate packages =E2=80=93 this is what the Rust team did, and it was the = right thing to do. If this means creating D v3, then that seems like a really good thing to do= . --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Jul 23
next sibling parent Andre Pany <andre s-e-a-p.de> writes:
On Tuesday, 23 July 2019 at 10:15:52 UTC, Russel Winder wrote:
 On Tue, 2019-07-23 at 03:01 +0000, Exil via Digitalmars-d wrote:
 […]
 
 The problem is who has control of these things. I've made pull 
 requests to dub, they just sit around and nothing gets done. 
 Very few people have access to actually enact change. Don't 
 say stuff like "you have to do action yourself" cause it's not 
 on me or anyone else. There's hundreds of pull requests for 
 DMD and DUB combined. There's only so much people can do when 
 pull requests sit idle for months/years, especially worse when 
 there's no responding. When something somewhat default 
 appears, no one on the D team is willing to do anything about 
 it. They all look to Walter, and Walter is usually to busy 
 doing something else so he never gets around to it. But yah, a 
 very naive thing to say considering the current state of how 
 things are managed with the project. God bless Seb for having 
 enhanced permission status ^TM.
Go and Rust got this right from the very outset – make the standard library as small as possible and have everything else provided through user packages/crates. Go only got this partly right in that there was no central repository, just DVCS packages. Rust got this very right in that it has a central repository and Cargo can use DVCS crates and even local file crates. This creates a vibrant community with some competition (which has bad as well as good sides to it). I am sure Dub can do for D most of the things Cargo does for Rust, but the crucial difference is Phobos in D vs std in Rust. Phobos is driven by the "batteries included" philosophy which is a philosophy past it's time. Python and C++ are also failing to come to terms with this. What D needs is to rip everything out of Phobos that is not actually needed for the compiler to compile code and put it into the Dub repository as separate packages – this is what the Rust team did, and it was the right thing to do. If this means creating D v3, then that seems like a really good thing to do.
It is a pleasure to have a standard library like Phobos. For most applications I do not have to use any additional dub packages. I do not have to care about licenses and whether it is still maintained tomorrow. Today users can decide to use either Phobos functionality or to use dub packages providing same functionality. You have the choice today. By following your recommendation, the choice is removed. I cannot see a benefit by removing the possibility to choose between Phobos and dub packages. Kind regards André
Jul 23
prev sibling next sibling parent NaN <divide by.zero> writes:
On Tuesday, 23 July 2019 at 10:15:52 UTC, Russel Winder wrote:
 On Tue, 2019-07-23 at 03:01 +0000, Exil via Digitalmars-d wrote:
 […]
What D needs is to rip everything out of Phobos that is not actually needed for the compiler to compile code and put it into the Dub repository as separate packages – this is what the Rust team did, and it was the right thing to do.
+1
Jul 23
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 23 July 2019 at 10:15:52 UTC, Russel Winder wrote:
 Phobos is driven by the "batteries included" philosophy which 
 is a philosophy past it's time. Python and C++ are also failing 
 to come to terms with this.
Hm, I don't see this. A scripting language like Python does need to a have an extensive standard library. C++ only recently got basic file system support... C++ is hardly "batteries included". Go actually has a lot available in it's standard library, even a web server...
Jul 23
prev sibling parent Exil <Exil gmall.com> writes:
On Tuesday, 23 July 2019 at 10:15:52 UTC, Russel Winder wrote:
 On Tue, 2019-07-23 at 03:01 +0000, Exil via Digitalmars-d wrote:
 […]
 
 The problem is who has control of these things. I've made pull 
 requests to dub, they just sit around and nothing gets done. 
 Very few people have access to actually enact change. Don't 
 say stuff like "you have to do action yourself" cause it's not 
 on me or anyone else. There's hundreds of pull requests for 
 DMD and DUB combined. There's only so much people can do when 
 pull requests sit idle for months/years, especially worse when 
 there's no responding. When something somewhat default 
 appears, no one on the D team is willing to do anything about 
 it. They all look to Walter, and Walter is usually to busy 
 doing something else so he never gets around to it. But yah, a 
 very naive thing to say considering the current state of how 
 things are managed with the project. God bless Seb for having 
 enhanced permission status ^TM.
Go and Rust got this right from the very outset – make the standard library as small as possible and have everything else provided through user packages/crates. Go only got this partly right in that there was no central repository, just DVCS packages. Rust got this very right in that it has a central repository and Cargo can use DVCS crates and even local file crates. This creates a vibrant community with some competition (which has bad as well as good sides to it). I am sure Dub can do for D most of the things Cargo does for Rust, but the crucial difference is Phobos in D vs std in Rust. Phobos is driven by the "batteries included" philosophy which is a philosophy past it's time. Python and C++ are also failing to come to terms with this. What D needs is to rip everything out of Phobos that is not actually needed for the compiler to compile code and put it into the Dub repository as separate packages – this is what the Rust team did, and it was the right thing to do. If this means creating D v3, then that seems like a really good thing to do.
Dub will probably never be as good as Cargo. I actively avoid Dub as it is. Even its documentation is atrocious, I loath having to look through it when I am forced to. There's no one on the D team with a vision for it, to make sure it gets to where it needs to go. No one actively developing it. This isn't something you can just thrust on someone else like someone in this thread was proposing to do with their "just do it yourself" mentality.
Jul 23
prev sibling next sibling parent evilrat <evilrat666 gmail.com> writes:
On Tuesday, 23 July 2019 at 00:47:09 UTC, Laeeth Isharc wrote:
 D can easily call pyth
 though it's not the number one priority for me right now.
What's your goals with aiming C#? What's the use case? I did wrapping mono for unity engine interop, however despite that D has many similarities with for such scenario. I've also read Unity devs experience with .net core, and they were having troubles with internal calls(i.e. registering native function to implement .net method), because unlike Mono in .NET Core those are hardcoded. And my biggest problem with Mono is that it seems there is no way to bind native function as delegate, that means events are not possible without writing C# wrappers, and having to write them manually defeats the whole purpose. There is still at least one possible option, to implement utility that automatically plugin itself will add ~15Mb to distribution of 1Mb D plugin. But sure, this is not a problem comparing to monolithic UE4 build ~100Mb executable...
Jul 22
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
On Tue, 2019-07-23 at 00:47 +0000, Laeeth Isharc via Digitalmars-d wrote:
=20
[=E2=80=A6]
 Not everyone uses an IDE.  It's obviously an impediment to=20
 adoption in the games industry judging by what Manu says, but=20
 there are other industries besides games and in some places=20
 people don't use IDEs much at all.
[=E2=80=A6] Restricting a programming language to Emacs/VIM/Atom/etc. users is clearly = a bad idea, especially when the (e.g. Emacs) support really isn't that great. Rust support in CLion is fantastic, D support is currently (huge apologies = to the splendid volunteer team, but it is nonetheless true) inadequate. JetBra= ins see an income stream from the Rust plugin, they see no user community using= D and CLion =E2=80=93 I emphasise CLion over IntelliJ IDEA here as CLion has = gdb support. I am (was) an Emacs person, but compared to using CLion, Emacs is inadequat= e for software development. (I have a guest post on the JetBrains CLion blog currently going through production, hopefully my plea for JetBrains support for the D plugin gets picked up by many, many others so that JetBrains can see an income potentia= l.) --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Jul 23
prev sibling next sibling parent reply greatsam4sure <greatsam4sure gmail.com> writes:
On Tuesday, 23 July 2019 at 00:47:09 UTC, Laeeth Isharc wrote:
 On Monday, 22 July 2019 at 23:16:26 UTC, Margo wrote:
 [...]
Not everyone uses an IDE. It's obviously an impediment to adoption in the games industry judging by what Manu says, but there are other industries besides games and in some places people don't use IDEs much at all. [...]
Thank you. I appreciate this write up. I had been this forum about two years now. I like the D language, for me, it is the best language I have come across. I have a look into languages I know D has room for a lot of improvements and I see the various stakeholders are doing their best with the little resources available. My major problem with D is the critical community. It is discouraging to cope with. This forum is too critical about D challenges and says little or nothing about the strength of D. Most of the post here is about why D cannot succeed or be used. The organizer should do something about such a post. Just Google Dlang and reads the comments about the language, you will be discouraged to go further. But most of the comments are not true as I start learning D. Dlang is a beautiful language that is easy to use. I think the community should put out an article about D outline all the strength in a compelling way especially from proven industry users.
Jul 23
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 23/07/2019 10:31 PM, greatsam4sure wrote:
 I think the community should put out an article about D outline all the 
 strength in a compelling way especially from proven industry users.
We have been doing that. It has improved the responses on Reddit greatly towards our GC.
Jul 23
prev sibling next sibling parent reply drug <drug2004 bk.ru> writes:
23.07.2019 13:31, greatsam4sure пишет:
 
 My major problem with D is the critical community. It is discouraging to 
 cope with. This forum is too critical about D challenges and says little 
 or nothing about the strength of D. Most of the post here is about why D 
 cannot succeed or be used. The organizer should do something about such 
 a post. Just Google Dlang and reads the comments about the language, you 
 will be discouraged to go further. But most of the comments are not true 
 as I start learning D. Dlang is a beautiful language that is easy to use.
 
 
 I think the community should put out an article about D outline all the 
 strength in a compelling way especially from proven industry users.
This is because people who think that D is a suitable language for their needs have no time to write posts just for fun because they are busy writing their products using D. Interestingly that big part of posts that criticize D is written unknown people who has several posts if not single one.
Jul 23
parent a11e99z <black80 bk.ru> writes:
On Tuesday, 23 July 2019 at 11:10:32 UTC, drug wrote:
 23.07.2019 13:31, greatsam4sure пишет:
 This is because people who think that D is a suitable language 
 for their needs have no time to write posts just for fun 
 because they are busy writing their products using D.

 Interestingly that big part of posts that criticize D is 
 written unknown people who has several posts if not single one.
(all names and events are fictitious) Walter: Now you choose your Language. This you must feel inside. If it also chooses you, move quick, like I showed. You will have one chance, Jake. Jake: How will I know if it chooses me? Walter: It will try to kill you. Jake: [after a brief pause] Outstanding...
Jul 23
prev sibling parent bachmeier <no spam.net> writes:
On Tuesday, 23 July 2019 at 10:31:10 UTC, greatsam4sure wrote:

 I think the community should put out an article about D outline 
 all the strength in a compelling way especially from proven 
 industry users.
I personally think a much more valuable project is the GTKD tutorial. We *very seriously* need one for Dub. Rust has https://doc.rust-lang.org/cargo/index.html and we have https://dub.pm/getting_started (No, I will not write it, because I don't use Dub and I'm not the one telling people to use it.)
Jul 23
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/22/2019 5:47 PM, Laeeth Isharc wrote:
 I think whether D is right for you also depends on time preference of the
people 
 involved and the culture.  I don't think it's a coincidence that D is 
 surprisingly popular in Germany and Japan and is less appealing to Americans 
 than one might have guessed.
Curiously, back in the Zortech C++ days, we got a lot of traction in England, Germany, and Japan. Other countries, not so much. I think we sold 2 copies in France :-) Clearly, it's cultural, but I don't know much more than that. England might be because Zortech was a British company. Germany and Japan, I speculate that culturally they attach less importance to social proof and more importance on specific merits. But I don't know.
Jul 23
prev sibling parent reply Aphex <Aphex mail.com> writes:
On Monday, 22 July 2019 at 23:16:26 UTC, Margo wrote:
 On Sunday, 21 July 2019 at 00:22:11 UTC, Walter Bright wrote:
 Any talk about code refactoring, library splitting, etc is a 
 wast of hot air. Again, sorry to say this but its like looking 
 at a Echo Chamber whenever i past by here.
It is exactly that... You are right in your analysis and this is why D will never get anywhere. It's past it's prime. It will continue going down the same path that hasn't worked. It is highly unlikely that real change will come because of what you have stated. You have the cult leaders and the cult followers. The followers simply parrot what the leaders say in trying to gain favorable position but ultimately reinforcing the failed mentalities of the leaders, who actually need to be challenged because they ultimately will lead the cult astray. It's how all things go with humans. One will always be successful at sometime when they only look at the pro's... Real progress is made in turning the weaknesses into strengths. Only thing I'd disagree with you is I'd give D's library an F though. It's a terrible trash heap of organization. While it may contain a useful things, the way it is organized and the nomenclature is just moronic. It's obvious that it was cobbled together and one pays the price when they use it. It may have quite a lot of functionality but the way it is presented is a mess. The problem with the leaders, generally, is that they are myopic. They want to focus on the successes and ignore the failures. This is what most humans do. They want to feel good about the accomplishments so they can feel good about themselves. The ones that generally are the most successful are the people who are never happy.... they keep pushing and pushing and pushing and eventually they have made so much progress that the result is a cohesive. One see's this not just in programming but in everything. Great musicians are no different. They are the ones who were never satisfied with what they were good at. There are many musicians in the world who have amazing talent and will never get anywhere... and we always see these kids who are amazing yet never turn out to be squat because at some point they fail to work on their weaknesses(which may not even be musical). D simply does not have the leadership to take it where everyone wants to go. What it boils down to is this: Walter is happy with where D is at. Many of the followers are happy where D is at(although you'll notice over time the ones who have invested in D tend to see the flaws and become disgruntled or leave(this is typical behavior since the veil of truth reveals the flaws with time))... and so D will stay where it is at. This is why I use D for nothing new. I'm not going to waste any time with it. It's already a very difficult ecosystem to use compared to other languages and, to be honest, it really doesn't offer anything that can't be done anywhere else. It's just nice to have as a convenience for certain problems, but when everything else is inconveniencing around it, it becomes counter productive. With D I've become the most unproductive programmer I have ever been while thinking I've become the most productive... that is D in a nutshell for me and it's not an exaggeration. It's not the language that is the problem either.
Jul 23
parent Greatsam4sure <greatsam4sure gmail.com> writes:
On Tuesday, 23 July 2019 at 17:58:20 UTC, Aphex wrote:
 On Monday, 22 July 2019 at 23:16:26 UTC, Margo wrote:
 On Sunday, 21 July 2019 at 00:22:11 UTC, Walter Bright wrote:
 Any talk about code refactoring, library splitting, etc is a 
 wast of hot air. Again, sorry to say this but its like looking 
 at a Echo Chamber whenever i past by here.
It is exactly that... You are right in your analysis and this is why D will never get anywhere. It's past it's prime. It will continue going down the same path that hasn't worked. It is highly unlikely that real change will come because of what you have stated. You have the cult leaders and the cult followers. The followers simply parrot what the leaders say in trying to gain favorable position but ultimately reinforcing the failed mentalities of the leaders, who actually need to be challenged because they ultimately will lead the cult astray. It's how all things go with humans. One will always be successful at sometime when they only look at the pro's... Real progress is made in turning the weaknesses into strengths. Only thing I'd disagree with you is I'd give D's library an F though. It's a terrible trash heap of organization. While it may contain a useful things, the way it is organized and the nomenclature is just moronic. It's obvious that it was cobbled together and one pays the price when they use it. It may have quite a lot of functionality but the way it is presented is a mess. The problem with the leaders, generally, is that they are myopic. They want to focus on the successes and ignore the failures. This is what most humans do. They want to feel good about the accomplishments so they can feel good about themselves. The ones that generally are the most successful are the people who are never happy.... they keep pushing and pushing and pushing and eventually they have made so much progress that the result is a cohesive. One see's this not just in programming but in everything. Great musicians are no different. They are the ones who were never satisfied with what they were good at. There are many musicians in the world who have amazing talent and will never get anywhere... and we always see these kids who are amazing yet never turn out to be squat because at some point they fail to work on their weaknesses(which may not even be musical). D simply does not have the leadership to take it where everyone wants to go. What it boils down to is this: Walter is happy with where D is at. Many of the followers are happy where D is at(although you'll notice over time the ones who have invested in D tend to see the flaws and become disgruntled or leave(this is typical behavior since the veil of truth reveals the flaws with time))... and so D will stay where it is at. This is why I use D for nothing new. I'm not going to waste any time with it. It's already a very difficult ecosystem to use compared to other languages and, to be honest, it really doesn't offer anything that can't be done anywhere else. It's just nice to have as a convenience for certain problems, but when everything else is inconveniencing around it, it becomes counter productive. With D I've become the most unproductive programmer I have ever been while thinking I've become the most productive... that is D in a nutshell for me and it's not an exaggeration. It's not the language that is the problem either.
I am thinking of myself using a tool which making me counter productive but yet I am stick to it though I thought there is nothing serious about the tool and that the tool is not special, other betters tools are out there. Why can't I move on instead of being cynical, it is because I cannot find equality to the tool out there. D is difficult to drop because of it elegance and beauty. People just want to use in all ramifications, when they are not able they because very unhappy and critize all. I understand that feeling. Why will a beautiful language like D not be the talk of the whole world and be adopted by many? I am really concern too. If D must become what it suppose to be, our attitude toward the language must change as community members or stake holders. I believe the leadership must listen more but we must speak in a manner that they can listen to us. For me, if this all about D, it is a success
Jul 23
prev sibling parent bioinfornatics <bioinfornatics fedoraproject.org> writes:
On Sunday, 21 July 2019 at 00:22:11 UTC, Walter Bright wrote:
 On 7/18/2019 5:12 PM, Mike Franklin wrote:
 ... and D could complete better with Rust if it had 
  safe-by-default and statically-check ownership/borrowing 
 mechanism as Walter recently proposed.
D has some huge advantages over Rust. For example, D has a familiar syntax and jargon. For another, you'll be able to move to memory safety incrementally with D, you won't have to rewrite your app from the start. D's metaprogramming abilities far exceed Rust's. Etc.
To my point of view Dlang should focus on libraries and services. If the question is what to be done to make D language popular. The answer is simple: 1/ libraries on trending field: AI, big data, cloud computing, web, containerization... I think W&A should focus the energy to provide some open sources tools on these fields 2/ Some services to get a reasonable quality of life: which is explained by Margo -> https://forum.dlang.org/post/kxtzthubfuwiszxgejkf forum.dlang.org
Jul 23
prev sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 7/18/19 8:12 PM, Mike Franklin wrote:
 On Thursday, 18 July 2019 at 23:49:00 UTC, Mike Franklin wrote:
 
 I think D could meet Microsoft's needs, but only if they forked it and 
 made some fundamental changes to remove the technical debt, remove 
 some of the "weird sh**" (https://youtu.be/TkNep5zHWNw?t=1378), and a 
 number of other things we all could list to make using D a more 
 professional experience.
... and D could complete better with Rust if it had safe-by-default and statically-check ownership/borrowing mechanism as Walter recently proposed. I think there is something that Microsoft is overlooking with D. In the last 2 paragraphs of the blog post they say that programmers should be using managed languages like C#|F# whenever possible, but use Rust when the prior don't scale. D is unique from Rust and C# in that is scales both up and down.
For almost as long as I can remember now, it's always bugged me to no end that the vast majority of the programming world is completely, 100% convinced that a a good general-purpose high-AND-low language isn't even possible (or desirable). It's always been obvious to me that it IS possible, and also that the popular false dichotomy only came about because more than a decade of language design took all low-level and threw it straight out the window (and they all did it because that was Java's approach, and Java was super hot Macarena-popular shit at the time). That left low-level to C, C++...umm...assembler...and really not much else. (And then, of course, JVM eventually would up proving that the whole VM-sandboxing thing doesn't really even save you from the security problems it was created to solve anyway.) I never understood why nobody else could see that's what was happening. Maybe that's what D's slogan should be about, "high-level AND low-level" (instead of the "fast, fast, fast" horribleness).
Jul 22
prev sibling parent reply XavierAP <n3minis-git yahoo.es> writes:
On Thursday, 18 July 2019 at 23:49:00 UTC, Mike Franklin wrote:
 On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 Microsoft has published article about needing a safer system 
 programming language.
 https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

 Could D (Most likely as betterC) have fit into that domain OR 
 is it not yet safe?
I knew this day would come, and while I hoped in my heart it would be D, I understand why it isn't. I speculate this is an inflection point in the industry. Walter himself even predicted it with his "memory safety will kill C" prediction at DConf a couple of years ago. Others will likely follow, and I dread the day my employer comes to me and says "Do you know Rust?". I think D could meet Microsoft's needs, but only if they forked it and made some fundamental changes to remove the technical debt, remove some of the "weird sh**" (https://youtu.be/TkNep5zHWNw?t=1378), and a number of other things we all could list to make using D a more professional experience. The D Language Foundation is doing some of that with the copy constructors, the new object hierarchy, templating druntime, etc. but it all happens too slowly. Regardless, I will continue with my part, at least for the time being, but it is an opportune time for some self-reflection.
Great thread! And very interesting article from MS, and the fact that they're interested in Rust. Technical debt and inconsistency (weird shit) subtract indeed from D's great promises. After claiming that C++ is insalvageable we now see that the Devil is in the details, and it isn't so easy to keep a language clean over the years and over the features. The simple story was that C++'s original sin had been building over C and taking over unsafe stuff, the preprocessor and whatnot; but now that we see the difference between theory and practice, maybe C++ didn't do such a bad job of staying relatively sane over 30 years; and compiling C as C++ was probably, as originally and naively assumed, a huge benefit despite the cost (see now Atila's dpp). I disagree that D can't fill the role because it aims at both systems and productivity. This is potentially a good thing -- and I think that all real success stories of D take advantage of this primarily (e.g. Weka). I think the problems may have persisted because nothing is modular inside D, in its private implementation. Everything in the runtime and the std library depends on everything else and is tangled together. This can make as difficult to make GC optional outside the std library, as to fix any one piece of weird shit. Still the only problem with D is ultimately low adoption. It has many causes, lack of corporate sponsor, of promotion, and other unknowable or random ones. Weird shit feeds back negatively, if it causes friction when people consider adopting, because if adoption was higher weird shit could be fixed in reasonable time.
Jul 19
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 19, 2019 at 09:03:50PM +0000, XavierAP via Digitalmars-d wrote:
[...]
 Still the only problem with D is ultimately low adoption. It has many
 causes, lack of corporate sponsor, of promotion, and other unknowable
 or random ones. Weird shit feeds back negatively, if it causes
 friction when people consider adopting, because if adoption was higher
 weird shit could be fixed in reasonable time.
I think it's a big assumption that adoption would make fixing weird sh*t easier. It could be that it's inherently hard, given the current language and implementation, and higher adoption isn't going to help with that. Regardless, in spite of D's warts it still has remained my favorite language so far, and the closest to my ideals of what a good language should be, and I don't see myself choosing another language over it anytime soon. I already ported over a couple of major personal projects to D, and have not regretted it since. T -- Spaghetti code may be tangly, but lasagna code is just cheesy.
Jul 19
parent reply XavierAP <n3minis-git yahoo.es> writes:
On Friday, 19 July 2019 at 21:32:56 UTC, H. S. Teoh wrote:
 On Fri, Jul 19, 2019 at 09:03:50PM +0000, XavierAP via 
 Digitalmars-d wrote: [...]
 Still the only problem with D is ultimately low adoption. It 
 has many causes, lack of corporate sponsor, of promotion, and 
 other unknowable or random ones. Weird shit feeds back 
 negatively, if it causes friction when people consider 
 adopting, because if adoption was higher weird shit could be 
 fixed in reasonable time.
I think it's a big assumption that adoption would make fixing weird sh*t easier. It could be that it's inherently hard, given the current language and implementation, and higher adoption isn't going to help with that.
At least in the sense that it would make much more manpower available. There's lots of issues identified (even avoiding breaking changes conservatively as Bachmeier mentions) that aren't solved because no one's working on them.
Jul 19
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 19, 2019 at 10:20:04PM +0000, XavierAP via Digitalmars-d wrote:
 On Friday, 19 July 2019 at 21:32:56 UTC, H. S. Teoh wrote:
 On Fri, Jul 19, 2019 at 09:03:50PM +0000, XavierAP via Digitalmars-d
 wrote: [...]
[...]
 I think it's a big assumption that adoption would make fixing weird
 sh*t easier.  It could be that it's inherently hard, given the
 current language and implementation, and higher adoption isn't going
 to help with that.
At least in the sense that it would make much more manpower available. There's lots of issues identified (even avoiding breaking changes conservatively as Bachmeier mentions) that aren't solved because no one's working on them.
Well, of course there are smaller issues that could use more manpower to fix. But I was referring to the fundamental issues (the "weird sh*t" that Amaury refers to in the video). I don't think many of them can be fixed without either breaking existing code, or doing some precision surgery on the language / implementation. Adding more manpower to it may not change this fact (cf. The Mythical Man-Month). T -- Why waste time reinventing the wheel, when you could be reinventing the engine? -- Damian Conway
Jul 19
prev sibling parent reply bachmeier <no spam.net> writes:
On Friday, 19 July 2019 at 21:03:50 UTC, XavierAP wrote:

 After claiming that C++ is insalvageable we now see that the 
 Devil is in the details, and it isn't so easy to keep a 
 language clean over the years and over the features.
It's a simple, solved problem. The D leadership made a decision that, for better or worse, breaking changes were (approximately) no longer acceptable. Keeping a language clean means you need a high standard to add features to the language and a higher standard to leave them in/not change them once you've had experience with them. Everyone complains about autodecoding, for instance, but it's by choice that it stays. There's nothing mysterious about how it can be fixed, you just make a decision to break existing code. {And just to be clear, I'm not saying the wrong choice was made, only that it would be trivial keep the language clean if that was the goal, and it would be called D3.}
Jul 19
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 19, 2019 at 09:57:01PM +0000, bachmeier via Digitalmars-d wrote:
 On Friday, 19 July 2019 at 21:03:50 UTC, XavierAP wrote:
 
 After claiming that C++ is insalvageable we now see that the Devil
 is in the details, and it isn't so easy to keep a language clean
 over the years and over the features.
It's a simple, solved problem. The D leadership made a decision that, for better or worse, breaking changes were (approximately) no longer acceptable. Keeping a language clean means you need a high standard to add features to the language and a higher standard to leave them in/not change them once you've had experience with them. Everyone complains about autodecoding, for instance, but it's by choice that it stays. There's nothing mysterious about how it can be fixed, you just make a decision to break existing code. {And just to be clear, I'm not saying the wrong choice was made, only that it would be trivial keep the language clean if that was the goal, and it would be called D3.}
To be honest, while I understand W&A's stance of wanting to stabilize the language and thereby (hopefully) drive adoption, IMO things would be better served if we started working towards D3. T -- One Word to write them all, One Access to find them, One Excel to count them all, And thus to Windows bind them. -- Mike Champion
Jul 19
next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Friday, 19 July 2019 at 22:12:17 UTC, H. S. Teoh wrote:

 To be honest, while I understand W&A's stance of wanting to 
 stabilize the language and thereby (hopefully) drive adoption, 
 IMO things would be better served if we started working towards 
 D3.
I generally agree, but I was encouraged by Andrei's relatively recent post (https://forum.dlang.org/post/q7j3s0$15n7$1 digitalmars.com) "We've been worrying too much about changing things." "We should do what C, C++, Java, C# and many other languages do - leave past mistakes in maintenance mode and move on with new stuff." This "add, but do no harm" is a good compromise, though it's much harder to avoid the "weird sh**" because that new stuff often interacts badly with the existing stuff and often limits what new stuff can be done. But it's a better stance than that of the past 5 years. It was quite exciting to see that from Andrei and it prompted me to get back into contributing to D. I think D can have a brighter future if that attitude is embraced by all. Now we just need more talent, manpower, and much better cooperation. Mike
Jul 19
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 19, 2019 at 11:19:12PM +0000, Mike Franklin via Digitalmars-d wrote:
 On Friday, 19 July 2019 at 22:12:17 UTC, H. S. Teoh wrote:
 
 To be honest, while I understand W&A's stance of wanting to
 stabilize the language and thereby (hopefully) drive adoption, IMO
 things would be better served if we started working towards D3.
I generally agree, but I was encouraged by Andrei's relatively recent post (https://forum.dlang.org/post/q7j3s0$15n7$1 digitalmars.com) "We've been worrying too much about changing things." "We should do what C, C++, Java, C# and many other languages do - leave past mistakes in maintenance mode and move on with new stuff."
Yeah, I remember Andrei saying that, and it *was* pretty refreshing to hear. However, I haven't seen any major steps in that direction (yet?). Andrei was talking about std.v2, but so far I haven't seen any actual action on that front. Would be nice to see that it's not just a pipe dream.
 This "add, but do no harm" is a good compromise, though it's much
 harder to avoid the "weird sh**" because that new stuff often
 interacts badly with the existing stuff and often limits what new
 stuff can be done.  But it's a better stance than that of the past 5
 years.
[...] The way I envisioned it is, using std.v2 as an example, we'd put the current (v1) std.* on maintenance mode, begin to build std.v2 until it gains enough traction to be viable, then begin migrating stuff (including user code) over, with the goal of eventually deprecating the v1 stuff, and, in a more distant future, renaming std.v2 to std. The thing about programming is, change is inevitable, so instead of locking ourselves to our initial decisions, many of which will likely turn out to be wrong / suboptimal in retrospect, why not build a way of embracing and adapting to change instead of fearing it. Of course, this will be much harder to do with language features, since right now there's no such thing as language feature versioning in D (and I've a hard time visualizing how such a thing could be pulled off in a reasonable way). So at some point, the only way to fix some of the language-related "weird sh*t" is to just bite the bullet and make a breaking change. That has to happen *somehow*, lest we end up with the fate of C++, accumulating crud from decades ago but you can't fix it. T -- What's an anagram of "BANACH-TARSKI"? BANACH-TARSKI BANACH-TARSKI.
Jul 19
prev sibling parent XavierAP <n3minis-git yahoo.es> writes:
On Friday, 19 July 2019 at 23:19:12 UTC, Mike Franklin wrote:
 On Friday, 19 July 2019 at 22:12:17 UTC, H. S. Teoh wrote:

 To be honest, while I understand W&A's stance of wanting to 
 stabilize the language and thereby (hopefully) drive adoption, 
 IMO things would be better served if we started working 
 towards D3.
I generally agree, but I was encouraged by Andrei's relatively recent post (https://forum.dlang.org/post/q7j3s0$15n7$1 digitalmars.com)
Indeed if technical debt is a big problem, some radical plan of action would be needed. Though again, do we have the manpower? Or are we able to attract it? I'm guilty. I've been curious about D from the beginning, but I have barely started a couple of h better and it's what is used at my job, and what will continue to be used. :\
Jul 20
prev sibling parent reply NaN <divide by.zero> writes:
On Friday, 19 July 2019 at 22:12:17 UTC, H. S. Teoh wrote:
 On Fri, Jul 19, 2019 at 09:57:01PM +0000, bachmeier via 
 Digitalmars-d wrote:
 On Friday, 19 July 2019 at 21:03:50 UTC, XavierAP wrote:
 
 After claiming that C++ is insalvageable we now see that the 
 Devil is in the details, and it isn't so easy to keep a 
 language clean over the years and over the features.
It's a simple, solved problem. The D leadership made a decision that, for better or worse, breaking changes were (approximately) no longer acceptable. Keeping a language clean means you need a high standard to add features to the language and a higher standard to leave them in/not change them once you've had experience with them. Everyone complains about autodecoding, for instance, but it's by choice that it stays. There's nothing mysterious about how it can be fixed, you just make a decision to break existing code. {And just to be clear, I'm not saying the wrong choice was made, only that it would be trivial keep the language clean if that was the goal, and it would be called D3.}
To be honest, while I understand W&A's stance of wanting to stabilize the language and thereby (hopefully) drive adoption, IMO things would be better served if we started working towards D3.
I think both can / should be done. Really nail down where the end is for D2, whats in and what will be fixed. And start exploratory work on D3, but it should be "only use D3 if you're OK it breaking hard and often" and keep it like that indefinitely. At least until the major stuff is really worked out. D has often felt like living in the house at the same time you're renovating it. And that isn't a good situation.
Jul 20
parent XavierAP <n3minis-git yahoo.es> writes:
On Saturday, 20 July 2019 at 11:02:36 UTC, NaN wrote:
 I think both can / should be done. Really nail down where the 
 end is for D2, whats in and what will be fixed. And start 
 exploratory work on D3, but it should be "only use D3 if you're 
 OK it breaking hard and often" and keep it like that 
 indefinitely. At least until the major stuff is really worked 
 out. D has often felt like living in the house at the same time 
 you're renovating it. And that isn't a good situation.
Sounds hood. But first of all D has to identify the rooy cause of weird shit appearing in such a young language. D has delievered great successes in some areas (metaprogramming, productivity, performance) but it compares unfavorably to any other language. C++ hasn't done such a bad job if you consider it's 30 years old; it keeps adding modern features and deprecating square parsecs of interfaces based on System.Object, when they added generics; but it remains a remarkably neat language after adding any new modern features and syntactic sugar.
Jul 20
prev sibling next sibling parent JN <666total wp.pl> writes:
On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 Microsoft has published article about needing a safer system 
 programming language.

 https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

 Could D (Most likely as betterC) have fit into that domain OR 
 is it not yet safe?
I don't think D can compete on this with Rust. Yes, D has safety features built-in the language, but they are opt-in. Rust has the safety features opt-out. Now both approaches have their advantages of course. D is more pragmatic and lets you write code without fighting the borrow checker each step of the way. But from the safety perspective, since Rust mandates safety, you can look at the codebase, and focus on the unsafe blocks for auditing. In case of D it wouldn't be that simple. Sure, you can safe sections of code, but it's harder to find which sections are safe and which aren't compared to Rust where everything is safe by default and you look for the unsafe ones. BetterC... it occupies that weird spot between C and D. I think it has some usecases (the no GC/runtime part works wonders for things like WebAssembly), but I don't think it's a production ready solution.
Jul 19
prev sibling next sibling parent reply matheus <matheus gmail.com> writes:
On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 ...
 Could D (Most likely as betterC) have fit into that domain OR 
 is it not yet safe?
Question: Have anyone from Dlang PR team tried to send Ryan Levick (Principal Cloud Developer Advocate) or Sebastian Fernandez (Security Software Engineer) an e-mail to talk about D? I mean maybe "our" language is over their radar (Or not), but this could may increase the chances or at least give them a thought. I pretty sure that should be nice or maybe engage some sort a relationship in the future. Matheus.
Jul 19
parent reply user1234 <user1234 12.de> writes:
On Friday, 19 July 2019 at 12:24:10 UTC, matheus wrote:
 On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 ...
 Could D (Most likely as betterC) have fit into that domain OR 
 is it not yet safe?
Question: Have anyone from Dlang PR team tried to send Ryan Levick (Principal Cloud Developer Advocate) or Sebastian Fernandez (Security Software Engineer) an e-mail to talk about D? I mean maybe "our" language is over their radar (Or not), but this could may increase the chances or at least give them a thought. I pretty sure that should be nice or maybe engage some sort a relationship in the future. Matheus.
They'd never take a language that they don't dominate / create. If something new emerge this will come from their labs / experimental languages. Before .Net the situation was similar, i.e they could have chosen something like Delphi but created .Net in response. To the best what could happen is that they borrow D features and everyone here then would get mad because of that...
Jul 19
next sibling parent reply matheus <matheus gmail.com> writes:
On Friday, 19 July 2019 at 12:59:40 UTC, user1234 wrote:
 On Friday, 19 July 2019 at 12:24:10 UTC, matheus wrote:
 On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 ...
 Could D (Most likely as betterC) have fit into that domain OR 
 is it not yet safe?
Question: Have anyone from Dlang PR team tried to send Ryan Levick (Principal Cloud Developer Advocate) or Sebastian Fernandez (Security Software Engineer) an e-mail to talk about D? I mean maybe "our" language is over their radar (Or not), but this could may increase the chances or at least give them a thought. I pretty sure that should be nice or maybe engage some sort a relationship in the future. Matheus.
They'd never take a language that they don't dominate / create. If something new emerge this will come from their labs / experimental languages. Before .Net the situation was similar, i.e they could have chosen something like Delphi but created .Net in response. To the best what could happen is that they borrow D features and everyone here then would get mad because of that...
I'm not saying they would jump the ship right the way or use as it is. But they are changing, just take a look over Microsoft embracing Chromium or adding Linux support on Windows. And since they're even mentioning Rust, I think they may be open to D. Matheus.
Jul 19
parent Laeeth Isharc <laeeth kaleidic.io> writes:
On Friday, 19 July 2019 at 13:20:00 UTC, matheus wrote:
 On Friday, 19 July 2019 at 12:59:40 UTC, user1234 wrote:
 On Friday, 19 July 2019 at 12:24:10 UTC, matheus wrote:
 On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 ...
 Could D (Most likely as betterC) have fit into that domain 
 OR is it not yet safe?
Question: Have anyone from Dlang PR team tried to send Ryan Levick (Principal Cloud Developer Advocate) or Sebastian Fernandez (Security Software Engineer) an e-mail to talk about D? I mean maybe "our" language is over their radar (Or not), but this could may increase the chances or at least give them a thought. I pretty sure that should be nice or maybe engage some sort a relationship in the future. Matheus.
They'd never take a language that they don't dominate / create. If something new emerge this will come from their labs / experimental languages. Before .Net the situation was similar, i.e they could have chosen something like Delphi but created .Net in response. To the best what could happen is that they borrow D features and everyone here then would get mad because of that...
I'm not saying they would jump the ship right the way or use as it is. But they are changing, just take a look over Microsoft embracing Chromium or adding Linux support on Windows. And since they're even mentioning Rust, I think they may be open to D. Matheus.
I suppose it's a big company and there are lots of teams within and then individual choices could play a part. Microsoft already used D ages back for something reasonably important but funnily enough they didn't send out a press release announcing the fact. If you look at some of the changes that have accompanied large publicly-listed corporations becoming involved in open source and some of the changes in values associated with that then it's quite an interesting question as to how the long run influence might be seen. I did not think I would live to see the day when somebody who has written a manifesto against meritocracy would have an important influence on the values on which some open source communities are based, but it's a funny world. I would just suggest that some kinds of alliance can be a mixed blessing and be careful of what you wish for. It's definitely worth contacting individuals at Microsoft though.
Jul 20
prev sibling next sibling parent Cym13 <cpicard purrfect.fr> writes:
On Friday, 19 July 2019 at 12:59:40 UTC, user1234 wrote:
 They'd never take a language that they don't dominate / create. 
 If something new emerge this will come from their labs / 
 experimental languages. Before .Net the situation was similar, 
 i.e they could have chosen something like Delphi but created 
 .Net in response.

 To the best what could happen is that they borrow D features 
 and everyone here then would get mad because of that...
I'm far from being a MS fan but they don't always want to dominate. Look at what happened with Linux, not the linux-in-windows thing (WLS ?) but the Linux kernel. Microsoft is one of the biggest contributors to the kernel because they wanted to adapt it to their needs (Azure and possibly WLS). If Microsoft wanted to contribute to D to better it for their use I'd be more than happy to accept them.
Jul 19
prev sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
On Friday, 19 July 2019 at 12:59:40 UTC, user1234 wrote:
 On Friday, 19 July 2019 at 12:24:10 UTC, matheus wrote:
 On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 ...
 Could D (Most likely as betterC) have fit into that domain OR 
 is it not yet safe?
Question: Have anyone from Dlang PR team tried to send Ryan Levick (Principal Cloud Developer Advocate) or Sebastian Fernandez (Security Software Engineer) an e-mail to talk about D? I mean maybe "our" language is over their radar (Or not), but this could may increase the chances or at least give them a thought. I pretty sure that should be nice or maybe engage some sort a relationship in the future. Matheus.
They'd never take a language that they don't dominate / create. If something new emerge this will come from their labs / experimental languages. Before .Net the situation was similar, i.e they could have chosen something like Delphi but created .Net in response. To the best what could happen is that they borrow D features and everyone here then would get mad because of that...
They would take another language actually. Before .NET they used Java, but it looks like they were sued by Sun because they didn't implement it strictly to the standard, so they decided to create their own rather than being subject to Sun. https://www.quora.com/Why-did-Microsoft-create-C-Wasnt-Java-good-enough-in-the-1990s
Jul 19
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 Microsoft has published article about needing a safer system 
 programming language.

 https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

 Could D (Most likely as betterC) have fit into that domain OR 
 is it not yet safe?
Let's not go crazy over one post by a couple of guys that work in some division of Microsoft. They like Rust for a small sliver of programming tasks, but that doesn't mean anything one way or the other for D, and it doesn't mean MS is converting everything to Rust.
Jul 19
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 19, 2019 at 10:00:41PM +0000, bachmeier via Digitalmars-d wrote:
 On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 Microsoft has published article about needing a safer system
 programming language.
 
 https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/
 
 Could D (Most likely as betterC) have fit into that domain OR is it
 not yet safe?
Let's not go crazy over one post by a couple of guys that work in some division of Microsoft. They like Rust for a small sliver of programming tasks, but that doesn't mean anything one way or the other for D, and it doesn't mean MS is converting everything to Rust.
Hysteria has always been a common feature in the mad race for language popularity; why would this time be different? ;-) T -- Klein bottle for rent ... inquire within. -- Stephen Mulraney
Jul 19
prev sibling next sibling parent reply XavierAP <n3minis-git yahoo.es> writes:
On Friday, 19 July 2019 at 22:00:41 UTC, bachmeier wrote:
 On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 Microsoft has published article about needing a safer system 
 programming language.

 https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

 Could D (Most likely as betterC) have fit into that domain OR 
 is it not yet safe?
Let's not go crazy over one post by a couple of guys that work in some division of Microsoft. They like Rust for a small sliver of programming tasks, but that doesn't mean anything one way or the other for D, and it doesn't mean MS is converting everything to Rust.
Employees of a software company such as MS are not allowed to use any language they want, let alone promote it on an official channel. It's fair to assume they have management approval.
Jul 19
parent reply bachmeier <no spam.net> writes:
On Friday, 19 July 2019 at 22:23:23 UTC, XavierAP wrote:

 Employees of a software company such as MS are not allowed to 
 use any language they want, let alone promote it on an official 
 channel. It's fair to assume they have management approval.
It's also fair to assume they'll be using C++ far more than Rust for a long time.
Jul 19
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 19 July 2019 at 23:58:52 UTC, bachmeier wrote:
 On Friday, 19 July 2019 at 22:23:23 UTC, XavierAP wrote:

 Employees of a software company such as MS are not allowed to 
 use any language they want, let alone promote it on an 
 official channel. It's fair to assume they have management 
 approval.
It's also fair to assume they'll be using C++ far more than Rust for a long time.
Yup, th programming and create a transition path Just like apple is more likely to move Swift towards systems programming than adopting an external language and gradually move more and more C/C++ code to Swift... Why would they move out of their comfort zone? Not gonna happen unless a revolutionary solution is created by some advanced research group project. That could happen, but it would most likely be agent based with not only memory safety but also strong concurrency support built in. So, we need to see a technological paradigm shift for a massive transition. Without a paradigm shift we will only see gradual evolution. A new hardware architecture design could drive such a shift, but that is at least 10 years into the future... and again, would IMO most likely be agent based...(lots of cheap cores with local solid state memory, perhaps FPGAs too).
Jul 20
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 19 July 2019 at 22:00:41 UTC, bachmeier wrote:
 On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 Microsoft has published article about needing a safer system 
 programming language.

 https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

 Could D (Most likely as betterC) have fit into that domain OR 
 is it not yet safe?
Let's not go crazy over one post by a couple of guys that work in some division of Microsoft. They like Rust for a small sliver of programming tasks, but that doesn't mean anything one way or the other for D, and it doesn't mean MS is converting everything to Rust.
They might not rewrite everything, but they already: - H - Are using a rigrep (grep implementation in Rust) as part of VSCode - Are helping porting Firefox to HoloLens and were hiring Rust devs for that purpose - Created the Actix web framework, one of the best Rust web frameworks and are using it as part of Azure infrastructure. On a sidenote, the new ChromeOS sandbox demoed at Google IO is written in a mix of Rust and Go.
Jul 21
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 Microsoft has published article about needing a safer system 
 programming language.

 https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

 Could D (Most likely as betterC) have fit into that domain OR 
 is it not yet safe?
Microsoft Research has teams working on advancing the state of the art of verifiable programming... They probably has the most knowledgable group of people in this area, so I they could move beyond Rust (with ease) if it was made a company policy, but it might not pay off in terms of profit. They will probably continue to evolve th their cloud offerings etc.
Jul 20
parent reply user1234 <user1234 12.de> writes:
On Saturday, 20 July 2019 at 08:54:36 UTC, Ola Fosheim Grøstad 
wrote:
 On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 Microsoft has published article about needing a safer system 
 programming language.

 https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

 Could D (Most likely as betterC) have fit into that domain OR 
 is it not yet safe?
Microsoft Research has teams working on advancing the state of the art of verifiable programming... They probably has the most knowledgable group of people in this area, so I they could move beyond Rust (with ease) if it was made a company policy, but it might not pay off in terms of profit. They will probably continue to evolve th relation to their cloud offerings etc.
I agree. This is more or less the same idea that I explained in a previous message.
Jul 20
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 20 July 2019 at 09:33:21 UTC, user1234 wrote:
 I agree. This is more or less the same idea that I explained in 
 a previous message.
Yeah, but it is worth stressing that they actually have one of the most competent research groups on practical verification. So, if managers decided that they needed linear or affine types then they certainly know how to add it to a language. Although their research seems to aim at more comprehensive verification than just memory ownership. So, I think they will aim for higher goals than what Rust can deal with before actually creating a completely new language to be deployed across the organization. (They have plenty of advanced toy-languages, though.)
Jul 20
prev sibling next sibling parent reply Domain <dont_email empty.com> writes:
On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 Microsoft has published article about needing a safer system 
 programming language.

 https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

 Could D (Most likely as betterC) have fit into that domain OR 
 is it not yet safe?
Rust is the winner. https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/
Jul 23
next sibling parent bachmeier <no spam.net> writes:
On Wednesday, 24 July 2019 at 01:16:23 UTC, Domain wrote:
 On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 Microsoft has published article about needing a safer system 
 programming language.

 https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

 Could D (Most likely as betterC) have fit into that domain OR 
 is it not yet safe?
Rust is the winner. https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/
Well they already said that in the first post.
Jul 23
prev sibling next sibling parent bauss <jj_1337 live.dk> writes:
On Wednesday, 24 July 2019 at 01:16:23 UTC, Domain wrote:
 On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 Microsoft has published article about needing a safer system 
 programming language.

 https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

 Could D (Most likely as betterC) have fit into that domain OR 
 is it not yet safe?
Rust is the winner. https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/
They already stated they were Rust. My question wasn't whether D would be considered by Microsoft but whether it __could__ have been been considered. See the bottom of the article: "In our next post, we’ll explore why we think the Rust programming language is currently the best choice for the industry to adopt whenever possible due to its ability to write systems-level programs in a memory-safe way."
Jul 23
prev sibling parent reply drug <drug2004 bk.ru> writes:
24.07.2019 4:16, Domain пишет:
 On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 Microsoft has published article about needing a safer system 
 programming language.

 https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-p
ogramming-language/ 


 Could D (Most likely as betterC) have fit into that domain OR is it 
 not yet safe?
Rust is the winner. https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe- ystems-programming/
I wouldn't say so: ``` ... While researching Rust, we found some issues that gave and continue to give us pause. Some of these concerns include how to regulate the usage of the “unsafe” superset of Rust at scale, lack of first-class interoperability with C++, and interoperability with existing Microsoft tooling. ... But we’re excited about the possibilities. While there are many questions still left to figure out about how Rust fits into the overall Microsoft engineering story, we encourage others to join us in taking a serious look at the language for their systems programming needs. ``` In fact they already have problem using Rust and they don't know how to solve them. They just are excited.
Jul 24
next sibling parent reply aliak <something something.com> writes:
On Wednesday, 24 July 2019 at 08:45:19 UTC, drug wrote:
 In fact they already have problem using Rust and they don't 
 know how to solve them. They just are excited.
Can you elaborate a little on these issues?
Jul 24
parent aliak <something something.com> writes:
On Wednesday, 24 July 2019 at 08:56:58 UTC, aliak wrote:
 On Wednesday, 24 July 2019 at 08:45:19 UTC, drug wrote:
 In fact they already have problem using Rust and they don't 
 know how to solve them. They just are excited.
Can you elaborate a little on these issues?
Oh you mean the things they mentioned :o)
Jul 24
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 24 July 2019 at 08:45:19 UTC, drug wrote:
 In fact they already have problem using Rust and they don't 
 know how to solve them. They just are excited.
Sounds more like they are playing a game of internal politics. If demand for a feature increases it is more likely to land in tooling...
Jul 25
parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 25 July 2019 at 21:23:20 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 24 July 2019 at 08:45:19 UTC, drug wrote:
 In fact they already have problem using Rust and they don't 
 know how to solve them. They just are excited.
Sounds more like they are playing a game of internal politics. If demand for a feature increases it is more likely to land in tooling...
That's how I read it too. I just wonder, if this will really work in the real world: 'According to an internal survey, the top reason for adoption was “correctness” – an extension of Rust’s safety guarantees that work towards making true the adage “if it compiles, then it works”.' [1] After all, it's MS ;) [1] https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/
Jul 29
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 29 July 2019 at 13:56:49 UTC, Chris wrote:
 On Thursday, 25 July 2019 at 21:23:20 UTC, Ola Fosheim Grøstad 
 wrote:
 Sounds more like they are playing a game of internal politics.
  If demand for a feature increases it is more likely to land 
 in tooling...
That's how I read it too. I just wonder, if this will really work in the real world: 'According to an internal survey, the top reason for adoption was “correctness” – an extension of Rust’s safety guarantees that work towards making true the adage “if it compiles, then it works”.' [1] After all, it's MS ;)
Hm, yes... no, it won't work throughout the organization, but they do have a focus on "correctness" at Microsoft research, so I guess they have some kind of long term vision for where they want to go. Or maybe not. Who knows. Anyway, Rust does not bring "correctness", so that quote only makes it sound more political to me...
Jul 29
prev sibling next sibling parent reply CaitlinSmith <CaitlinSmith dooinfo.com> writes:
On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 Microsoft has published article about needing a safer system 
 programming language.

 https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

 Could D (Most likely as betterC) have fit into that domain OR 
 is it not yet safe?
It's a real possibility that Microsoft may chose dlang some day.But there are also other possibilities.Perhaps one day a more advanced and secure language will be invented as the rapid development of computers.Dlang does have some unique advantages-- It has redesigned some core C++ features, while also sharing characteristics of other languages, notably Java, Python, Ruby, C#, and Eiffel. The language as a whole is not memory-safe, but does include optional attributes designed to check memory safety.
Jul 24
parent Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 24 July 2019 at 07:38:44 UTC, CaitlinSmith wrote:
 On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 [...]
It's a real possibility that Microsoft may chose dlang some day.But there are also other possibilities.Perhaps one day a more advanced and secure language will be invented as the rapid development of computers.Dlang does have some unique advantages-- It has redesigned some core C++ features, while also sharing characteristics of other languages, notably Java, Python, Ruby, C#, and Eiffel. The language as a whole is not memory-safe, but does include optional attributes designed to check memory safety.
They have .NET Native with the improvements taken from Midori
Jul 24
prev sibling next sibling parent reply vladislavp <vladislavp outlook.com> writes:
On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 Microsoft has published article about needing a safer system 
 programming language.

 https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

 Could D (Most likely as betterC) have fit into that domain OR 
 is it not yet safe?
I am new to D-Lang community. I am impressed at the level of openness that the moderators have in this forum, to be honest. The number of negativism in some posts is very high. To the point where it is actually hard to understand the technical details behind particular grievances. Rust has theoretical foundations behind its type system and compile-time checking of the pointer ownership. Some great innovation and pragmatic, focused implementation team(s). But D has a whole language operating on meta-types, plus a number of very mature backends integrating into C/C++ ecosystems. So D's metaprogramming capabilities can, technically, allow it to become Rust, Scala, Agda, Idris, Coq and Z3. Sure D's bolt package is a 'nascent' step (more like a utility) of a type algebras. And, yes, languages with non-trivial type algebras take very long to build (and require advanced understanding of dependent types, relation program derivation and so on) But, there is really nothing else like D out there. As for Microsoft, It would be interesting to hear how they view D's BetterC and its, hopefully soon, upcoming DIP 1000 for their Driver Verification (SLAM) https://www.microsoft.com/en-us/research/project/slam/ And building devices drivers in BetterC (since it specifically allows to use C's or C++ runtime).
Jul 25
next sibling parent IGotD- <nise nise.com> writes:
On Friday, 26 July 2019 at 03:29:33 UTC, vladislavp wrote:
 The number of negativism in some posts is very high.
 To the point where it is actually hard to understand the 
 technical details behind
 particular grievances.
What do you mean with negativism. Is it negativism towards other languages, which could be expected as this is a D forum. Or is it negativism towards technical problems with the D language itself.
Jul 29
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Friday, 26 July 2019 at 03:29:33 UTC, vladislavp wrote:
 The number of negativism in some posts is very high.
 To the point where it is actually hard to understand the 
 technical details behind
 particular grievances.
It is because it is a forum (and a particularly accessible ones). In audio software we too have internet PHP forums which at first sight seem important, many opinions in there, many debates... At the end of the day the LARGE majority of customers are not there. It's not even representative, since so much of the audience of internet forums is skewed towards "people that like to talk on the internet" and yes, they will tend to be unhappy and critical. If you have 7000 message on an internet forums, probably what you are doing in your life is "writing on this forum", not doing anything else. And the more people realize that internet forums are sweked, the more they also realize the opinion of internet forums - comically - almost do not matter, it's almost always a reaction towards some underlying event. Do not mistake these forums with the D community at large... D has excellent reputation in the trenches. These forums are certainly not representative, with so many people purposedly trying to discourage contributors, who don't use D and/or never had this intention.
Jul 29
prev sibling parent JN <666total wp.pl> writes:
On Friday, 26 July 2019 at 03:29:33 UTC, vladislavp wrote:
 The number of negativism in some posts is very high.
 To the point where it is actually hard to understand the 
 technical details behind
 particular grievances.
I think the issue is that many flaws of D are not strictly technical. For old languages like C/C++ the idea was that language is king, makefiles are the ultimate build tool and IDE support means vim syntax highlighting plugin. Those times have changed. The ecosystem around the language, in form of available packages, frameworks, boilerplate projects, IDE plugins is just as important, if not even more important as the language itself. Just look at Go. It's such an uninspired language with hardly any notable features other than goroutines, and yet it's popular because it's easy to get started with, easy to find ready packages to use for various tasks, fast to compile and easy to deploy. All while maintaining good performance, as most native languages do. The vision document has not been posted in a while, and most of the progress comes in form of bugfixes, memory safety related DIPs or extern(C++) related changes. But overall, I feel like many people believe that D is wasting it's potential. Now, normally, it wouldn't be an issue, and D would move forward at its pace as it always did. However, Rust happened, and people see how quickly it exploded in popularity. I guess people like to downplay popularity of Rust here, but for many new projects Rust is just the new default, if you don't need compatibility with legacy code. It's still not a language I'd call mainstream, but I believe in several years the question asked will be "why are we doing it in C++? can't we just do it in Rust?".
 As for Microsoft, It would be interesting to hear how they view
  D's BetterC and its, hopefully soon, upcoming DIP 1000
 for their Driver Verification (SLAM)
 https://www.microsoft.com/en-us/research/project/slam/
 And building devices drivers in BetterC (since it specifically 
 allows to use C's or C++ runtime).
Oh. That one is simple to answer. I'm not Microsoft, but the answer will be along the lines of: "Our engineers are not familiar with the D language. While it has some interesting ideas, we really enjoy the opt-out safety features of Rust and the compile time checks provided by the borrow checker. Combined with a powerful toolchain and a very active community, it seems to be the future of native GC-less programming. Also, -betterC mode seems to be barely documented and it's hard to say what the future of it will be".
Jul 30
prev sibling parent reply lempiji <lempiji gmail.com> writes:
On Thursday, 18 July 2019 at 23:00:03 UTC, bauss wrote:
 Microsoft has published article about needing a safer system 
 programming language.

 https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

 Could D (Most likely as betterC) have fit into that domain OR 
 is it not yet safe?
I am Japanese. I would not mind other people's evaluation if they fit my values, but I felt a little sad that nothing was mentioned in the article. In Japanese companies, many people think based on the opinions of large companies. Some companies even purposely appeal that the product is 100% Microsoft technology. I think it is certain that Rust's rating goes up. But they don't think about memory safety, and they only do enough with GC. I can say they will not use Rust in Japan. And since the practicality and productivity of D do not change, there is no pessimism. By the way, D-man (and Gopher) are very popular in Japan. https://www.instagram.com/p/Bq45DGfFLg-/
Jul 29
parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Monday, 29 July 2019 at 13:04:52 UTC, lempiji wrote:
 By the way, D-man (and Gopher) are very popular in Japan.

 https://www.instagram.com/p/Bq45DGfFLg-/
Haha I want a pan like that! Marvellous. We should serve those at next DConf. Bastiaan.
Jul 29