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

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 parse space. C# also deprecated e.g. non generic containers and 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.

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.

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.

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.

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

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.

-- 
Russel.
===========================================
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

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 and on, over a period of about ten years, I dug into C#, Mono, F#, PHP-Win, and anything else I could find. All I wanted was C _without_ the headache of managing memory and _with_ the many advantages of OOP.

I also, like Microsoft, didn't want to be at the mercy of a corporation that might decide to pull the plug without notice... which is almost ironic if you think about it. :)

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.

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.