May 18, 2022
On 5/17/2022 2:11 PM, Paulo Pinto wrote:
> Easy, they did a whole talk on the matter,
> 
> https://www.adacore.com/nvidia

Sweet! Thanks
May 18, 2022
On 5/17/2022 2:09 PM, Paulo Pinto wrote:
> It surely does, read the graphic with attention, 8%.

And so it does, you're right. 8% of the enormous Java market is huge.
May 18, 2022
On Tuesday, 17 May 2022 at 15:47:31 UTC, Walter Bright wrote:
> If you come to DConf, you'll get a beer from me regardless!

Yay!
May 18, 2022
On Wednesday, 18 May 2022 at 07:35:20 UTC, Walter Bright wrote:
> On 5/17/2022 2:09 PM, Paulo Pinto wrote:
>> It surely does, read the graphic with attention, 8%.
>
> And so it does, you're right. 8% of the enormous Java market is huge.

Yeah, but it got there thanks to Google replacing Java with Kotlin on Android, althought they might still be "commited" to their Android Java flavour in regards to backwards compatibility.

You know how to turn Java code into Groovy?

Start by changing the file extension from .java to .groovy, yet it can hardly do better than 6%, and mostly thanks to Gradle being around, and having been chosen as Android's official build system.

This is what D lacks, the killer use case, ImportC on its own will hardly change the current adoption state.
May 18, 2022

On Tuesday, 17 May 2022 at 15:41:25 UTC, Paulo Pinto wrote:

>

It certainly does have to a lot to catch up with SPARK, and NVidia has chosen Ada instead of Rust exactly because of that, yet there is money being thrown out at the problem, and standard organizations interested into making it happen.

It won't be there today, but it will eventually, because they have one specific answer to "what you use X for".

I'd say solutions will be developed when enough people who are into verification use it.

E.g. smart contracts in Rust: https://github.com/move-language

May 18, 2022
On Monday, 16 May 2022 at 02:34:16 UTC, forkit wrote:
> On Monday, 16 May 2022 at 02:05:32 UTC, forkit wrote:
>>
>
> i just realised, I can now answer the question 'Why is D unpopular?'
>
> Because it has no shared vision.

Yes.
May 18, 2022
On Wednesday, 18 May 2022 at 12:47:52 UTC, deadalnix wrote:
> On Monday, 16 May 2022 at 02:34:16 UTC, forkit wrote:
>> On Monday, 16 May 2022 at 02:05:32 UTC, forkit wrote:
>>>
>>
>> i just realised, I can now answer the question 'Why is D unpopular?'
>>
>> Because it has no shared vision.
>
> Yes.

I suggest the vision be to make me happy. For example, the impossibility to have anonymous struct literals as the RHS of an assignment (or as a function argument in general) makes me unhappy. Moreover, after DIP1030 is implemented, D wants to deprecate anonymous struct literals entirely, which makes me the unhappiest man in the world.
May 18, 2022
On Wednesday, 18 May 2022 at 15:34:33 UTC, Max Samukha wrote:
> I suggest the vision be to make me happy. For example, the impossibility to have anonymous struct literals as the RHS of an assignment (or as a function argument in general) makes me unhappy. Moreover, after DIP1030 is implemented, D wants to deprecate anonymous struct literals entirely, which makes me the unhappiest man in the world.

Realistically, brace initialization for structs is probably never going to be deprecated or removed. It would cause too much disruption to existing code for too little benefit.

With DIP 1030 implemented, D's struct literals will achieve feature parity with C99's compound literals (which are also not anonymous--they require you to specify the type using a cast-like syntax).
May 18, 2022
On Wednesday, 18 May 2022 at 16:02:52 UTC, Paul Backus wrote:
>
> With DIP 1030 implemented, D's struct literals will achieve feature parity with C99's compound literals (which are also not anonymous--they require you to specify the type using a cast-like syntax).

In C, you only have to specify the top level type:

struct Foo {
    int x;
};

struct Bar
{
    struct Foo f[2];
};

int main()
{
    struct Bar b;
    b = (struct Bar){{{1}, {2}}};
    // or just
    b = (struct Bar){{1, 2}};
    return 0;
}

In D, you would have to:

b = Bar([Foo(1), Foo(2)]);

May 18, 2022
On 5/18/2022 1:56 AM, Paulo Pinto wrote:
> This is what D lacks, the killer use case, ImportC on its own will hardly change the current adoption state.

Even if it doesn't, it will make things much easier for current D users.

For example, look at the dmd source code itself. We maintain, by hand, a set of equivalent .h for them. A cumulatively enormous amount of time has been expended on that, and finding/fixing the bugs from when they get out of sync.

(ImportC doesn't directly address that, because it's C++ not C, but it's still illustrative. I have also considered adding "C with Classes" support in ImportC as dmd's C++ interface is "C with Classes".)