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

possible, but use Rust when the prior don't scale.


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




[...]


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




 [...]


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

 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 2019
prev sibling next sibling parent bpr <brogoff gmail.com> writes:
On Friday, 19 July 2019 at 00:12:06 UTC, Mike Franklin wrote:




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


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


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


 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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
prev sibling next sibling parent evilrat <evilrat666 gmail.com> writes:
On Tuesday, 23 July 2019 at 00:47:09 UTC, Laeeth Isharc wrote:


 though it's not the number one priority for me right now.




I did wrapping mono for unity engine interop, however despite 

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 

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

 the prior don't scale.
 



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


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

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

better and it's what is used at my job, and what will continue to 
be used. :\
Jul 20 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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.





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 2019
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:



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

their cloud offerings etc.
Jul 20 2019
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 

 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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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, 

does include optional attributes designed to check memory safety.
Jul 24 2019
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, 

 memory-safe, but does include optional attributes designed to 
 check memory safety.


They have .NET Native with the improvements taken from Midori
Jul 24 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019