Could D have fit Microsoft's needs?

[Laeeth Isharc]

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.