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.

On Friday, 19 July 2019 at 00:12:06 UTC, Mike Franklin wrote:
> D is unique from Rust and C# in that is scales both up and down.

    I assume that you're claiming that Rust doesn't scale, or scale well, in some direction, likely 'up', and that D does scale well in this direction, and the other. I don't believe there's evidence for Rust inability to scale yet. C and C++ both scaled, in the sense that they are used from embedded devices up to full scale apps in many domains, and if anything to me Rust looks more promising than either. It's quite young compared to D and has already seen more widespread adoption where I live. Your "weird shit" example suggests that scaling up with D is nontrivial, even for an expert who really wants D to work to avoid C++.

    Also, I like the algebraic data types of Rust/Swift/Scala/OCaml/... a lot. My version of 'Dust' would have algebraic data types, immutability as the default, D templates, overloading, static introspection, and macros. As much Rust as D there. In that sense, just adding more safety features to D is not making it Dust for me. Time for a new D?

>  So, Microsoft is missing an opportunity to have one language for all use cases.  But I still think D has to do something about the technical debt and other "weird sh**" to make it viable.

I don't see why Microsoft would consider D rather than Rust or some other language. With the technical debt and "weird shit" you mention why wouldn't they just start on something new, learning from the design of D?

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

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.

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.

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

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.

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

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

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.