On Fri, Jun 5, 2020 at 3:20 AM Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 6/4/2020 7:44 PM, Manu wrote:
> > ...
>
> Regarding shared,
>
>      void test(shared(int)* p) { *p = 1; }
>
> dmd -preview=nosharedaccess test
>
>      test.d(31): Error: direct access to shared *p is not allowed, see
> core.atomic
>
> Isn't that what you wanted?
>

That's the very very very start of the journey. That change alone only
opens the door; but there's open issues relating to initialisation from
that change, there's important opportunities with `shared` in conjunction
with `scope` (which is what I was arguing for when I was making the case
for `scope` as it is today way back in dconf2013, if you can recall those
long arguments), and we had a big discussion about how to implement
parallel-for (and associated machinery) which you rejected because you
found it unacceptable that a library may have to insert fences at the
appropriate places rather than the compiler doing it automatically
(redundantly) everywhere the pattern emerged. Timon said he thought he knew
how to work the proposal into a form you'd find agreeable, but he hasn't
replied to me on that recently.
This was all discussed at length over many months. It kinda just stalled
when I fatigued. If we're ready to pick up the ball, that would be really
valuable work.

On Fri, Jun 5, 2020 at 3:30 AM Dibyendu Majumdar via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Friday, 5 June 2020 at 02:44:17 UTC, Manu wrote:
>
> > Back on-topic; I still use D because I just can't stand C++, and I somehow fundamentally believe D can 'get there'... but god is it a hard and frustrating road! Eternally so close, but always juuuust misses the mark. Maybe one day we'll land the shot >_<
>
> In my opinion there will always be that one missing feature that prevents D from getting there. In other words, if features were a stopping factor then how did anyone ever use C++ 10 years ago?
>

I feel like I made the case that it's not strictly 'features', so much as implementation quality and/or the complete package experience.

I mean, one instance of 'new functionality' is extern(C++), which really is a massive enabler; it creates a migration opportunity which wouldn't be there otherwise. I've been working for years to improve C++ interaction and make it comprehensive and useful. It hasn't been on my list of key struggles recently. We do need to get on top of move construction though... but it's not holding me back personally.

`shared` though, that's been in a weird limbo state for a very very long
time, and in this instance, the key competitive advantage D offers over C++
is that it has `shared` in the type system.
But having that sticker on the box isn't enough, it has to do something
meaningful. It actually has to implement mechanics that help us resist the
kinds of bugs that you experience with shared data.

Even if those _features_ do work, it still needs to pass the tests where it shows it can fit into an elaborate existing ecosystem. When really basic things like inline and weak linkage don't work, that's just a kind of super boring mechanical barrier to successful integration, and there's no excuse I can make for those. We can make workarounds, but they're embarrassing, and we should spend our small quota of "disadvantage points" on the key stuff that's not trivial to fix.

So when I say "always just one thing", it's not features; it might be...
but it's often also implementation quality, or binary environment
integration issues, or build issues, or tooling issues... unfortunately we
must _exceed_ a very high bar set by the C++ to ecosystem be successful.
We're not evaluating which environment is the best experience overall, what
we have to do is *dislodge* a deeply seated establishment by demonstrating
sufficient advantages that it tips a subjective threshold of a businesses
technical directors. They need to do an evaluation, easily recognise the
advantages, and not be nervous.
I think we've been pretty close to having everything we need for a while
now, but what I was saying here is it absolutely needs to WORK... we can't
show that an idea (`shared`) is there but the implementation is broken.
That will be received worse than if it wasn't there at all.

On 6/5/2020 5:08 PM, Manu wrote:
> but there's open issues relating to initialisation from that change,

I know about that one, but it doesn't seem a showstopper.

> there's important opportunities with `shared` in conjunction with `scope` (which is what I was arguing for when I was making the case for `scope` as it is today way back in dconf2013, if you can recall those long arguments),

Yes.


> and we had a big discussion about how to implement parallel-for (and associated machinery) which you rejected because you found it unacceptable that a library may have to insert fences at the appropriate places rather than the compiler doing it automatically (redundantly) everywhere the pattern emerged.

I don't recall that one.


> Timon said he thought he knew how to work the proposal into a form you'd find agreeable, but he hasn't replied to me on that recently.
> This was all discussed at length over many months. It kinda just stalled when I fatigued. If we're ready to pick up the ball, that would be really valuable work.

I'm not ready today, but it'd be nice if you made a text file of the status of all your initiatives with links to the discussions, so you won't have to keep retyping them.

On Sat, Jun 6, 2020 at 3:05 PM Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 6/5/2020 5:08 PM, Manu wrote:
> > but there's open issues relating to initialisation from that change,
>
> I know about that one, but it doesn't seem a showstopper.
>

Initialisation and `ref` emit errors?
They're absolutely show stoppers. Values must be initialised, and code has
`ref` in it all the time.
You can't write code without those things.

> there's important opportunities with `shared` in conjunction with `scope` (which
> > is what I was arguing for when I was making the case for `scope` as it
> is today
> > way back in dconf2013, if you can recall those long arguments),
>
> Yes.
>
>
> > and we had a big
> > discussion about how to implement parallel-for (and associated
> machinery) which
> > you rejected because you found it unacceptable that a library may have
> to insert
> > fences at the appropriate places rather than the compiler doing it
> automatically
> > (redundantly) everywhere the pattern emerged.
>
> I don't recall that one.
>

There are uber-threads on it. But if you feel like you have time to think about this problem space we can open it up again.

> Timon said he thought he knew how
> > to work the proposal into a form you'd find agreeable, but he hasn't
> replied to
> > me on that recently.
> > This was all discussed at length over many months. It kinda just stalled
> when I
> > fatigued. If we're ready to pick up the ball, that would be really
> valuable work.
>
> I'm not ready today, but it'd be nice if you made a text file of the
> status of
> all your initiatives with links to the discussions, so you won't have to
> keep
> retyping them.
>

Okay, I'll try and find some time to dig them up.
I have almost no time recently; work-from-home is hard and I work 12-14
hours a day to try and make up for lost productivity, and still falling
behind.
... and, tragically, the reason for that is mostly because we wrote this
thing in C++! I've been having a really un-fun time at work because I
failed to make a pitch for D in the ~18 months window we had, and now I
have to suffer that failure :(

On 6/5/2020 10:16 PM, Manu wrote:
> Initialisation and `ref` emit errors?
> They're absolutely show stoppers. Values must be initialised, and code has `ref` in it all the time.
> You can't write code without those things.

You can declare them with =void; and set them with the atomics. That's inconvenient, but NOT a showstopper.

You can use pointers instead of ref, inconvenient, not a showstopper.

> Okay, I'll try and find some time to dig them up.
> I have almost no time recently; work-from-home is hard and I work 12-14 hours a day to try and make up for lost productivity, and still falling behind.
> ... and, tragically, the reason for that is mostly because we wrote this thing in C++! I've been having a really un-fun time at work because I failed to make a pitch for D in the ~18 months window we had, and now I have to suffer that failure :(

I understand.

On Fri, 2020-06-05 at 10:22 +0000, Cogitri via Digitalmars-d wrote: […]
> Same for me, writing in D is just so much more fun and quicker than writing it in Rust (at least for GTK applications since the GTK concept doesn't really map well onto Rust). Most advantages of Rust are kind of moot when using GTK anyway since that means refcounting all the things and trusting upon the D GC to handle the refcounting works really well for that. I do have to admit that I miss how infrequent SIGSEGVs are with Rust (read: somewhat impossible unless you have bad bindings/C libs), but since I don't have to manually manage memory in D too often it's not too bad in D either and in return I save loads of time while coding due to the capabilities I have in D that Rust takes away from me. Also, static-if and static-for rocks and at least in the way I use it doesn't cause my compilation times to easily go into the minutes for small programs (right, Rust? :)

I get the feeling that there is a bit of a fight going on between the C++,
Rust, Python, and Vala camps as to what is the replacement for C for GTK+ – it
has been going on since C++ created a binding and Vala was created, but I
think GTK+ 4 is reopening things obviously.

For so many Python is a non-starter, and yet it gets used for so much stuff. Interesting.

Clearly there are people saying C is the one true language that shall never be replaced, which is fine for them but not for me.

Vala has a following but is just a bit too niche to get real traction, but maybe I am wrong.

C++ had lost the race till C++11, but didn't really get moving after that except amongst the C++ lovers. C++20 may change that, but maybe not.

Rust is being seen as the replacement for C for application developers and a lot of effort is going into it.

Of course D is the "happy place" between C++, Vala, and Rust. (And Python?) It has inheritance of classes so beats Rust, It is less niche so beats Vala. (It is static and not dynamic so beats Python?) Whilst a big language D is simpler and easier than C++ so beats C++.

GTK+ does all it's own garbage collection of GTK+ objects, so none of the D GC gets used there. This provides ammunition for the GC haters to say Rust (and C++?) is better that D. Obviously they are wrong but as the saying goes "haters going to hate". Python has it's own GC and no-one treats that as a downside of using Python for GTK+ work. Clearly then D having a GC means just the same as Python having a GC: managing memory is the last of your worries as an application programmer.

Regarding SIGSEGV, I get none from Rust, some from D, but most from the C libraries all my stuff gets build on. This is just going to be a problem until all the libraries get written in Rust, D, or Go.

The big problem for me staying with D for GTK+ stuff, and I may just be repeating myself here, is that whilst D has GtkD, rust had gtk-rs, and Python is dynamic. The issue here is that GtkD is a pure automated translated binding, whereas gtk-rs is an automated translated binding with added extras. gtk-rs is just that little bit more Rust-y that GtkD is D-y. But most importantly gtk-rs has a lot more support for asynchronous working using event loops. D has the tools, but compared to the Rust tools, D is just a little bit more clunky, enough to get irritating. Irritation leads to fear and thence "Fear Leads to Anger. Anger Leads to Hate. Hate Leads to Suffering". Or something like that.

So for pure GTK+ stuff D is great, so why hasn't it wiped Vala off the map? I guess because Vala is a GTK+ home grown offering, and very few GTK+ folk look outside the C++, Rust, Vala, C, Python, bubble.

Clearly the problem is resource. C, C++, Python and Rust have it, D and Vala don't. And that is the problem at the end of the day, Rust and Python support for GTK+ working evolves as people complain and use it, D support does not. :- (


PS Thanks to Mike Wey for all he does with GtkD, I just there were ways of getting more people working on it.

PPS Thanks to Samael for all he does with IntelliJ-DLanguage, I just wish
there were ways of getting more people working on it.

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

On Fri, 2020-06-05 at 09:08 +0000, Andre Pany via Digitalmars-d wrote:
> On Friday, 5 June 2020 at 08:39:09 UTC, Russel Winder wrote:
> > On Fri, 2020-06-05 at 12:44 +1000, Manu via Digitalmars-d wrote: […]

Does this mean using the Microsoft build with all the telemetry it has or Codium which is a build without all the branding and telemetry?

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

On Saturday, 6 June 2020 at 07:00:57 UTC, Walter Bright wrote:
> On 6/5/2020 10:16 PM, Manu wrote:
>> Initialisation and `ref` emit errors?
>> They're absolutely show stoppers. Values must be initialised, and code has `ref` in it all the time.
>> You can't write code without those things.
>
> You can declare them with =void; and set them with the atomics. That's inconvenient, but NOT a showstopper.
>
> You can use pointers instead of ref, inconvenient, not a showstopper.
>

The whole point of a programming language feature is to be more convenient.
If a feature is any more inconvenient than it needs to be people will be a averse to using it.
(For some reason the boost people don't fall into that ...)
For shared to be convenient the shared checks have to be disabled based on context.
For example during initialization or when taking a ref.

On Saturday, 6 June 2020 at 09:10:04 UTC, Russel Winder wrote:
> On Fri, 2020-06-05 at 09:08 +0000, Andre Pany via Digitalmars-d wrote:
>> On Friday, 5 June 2020 at 08:39:09 UTC, Russel Winder wrote:
>> > On Fri, 2020-06-05 at 12:44 +1000, Manu via Digitalmars-d wrote: […]
>
> Does this mean using the Microsoft build with all the telemetry it has or Codium which is a build without all the branding and telemetry?

I am using codium. So far I didn't have any problems.

On Saturday, 6 June 2020 at 01:17:02 UTC, Manu wrote:
> On Fri, Jun 5, 2020 at 3:30 AM Dibyendu Majumdar via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> On Friday, 5 June 2020 at 02:44:17 UTC, Manu wrote:
>>
>> > Back on-topic; I still use D because I just can't stand C++, and I somehow fundamentally believe D can 'get there'... but god is it a hard and frustrating road! Eternally so close, but always juuuust misses the mark. Maybe one day we'll land the shot >_<
>>
>> In my opinion there will always be that one missing feature that prevents D from getting there. In other words, if features were a stopping factor then how did anyone ever use C++ 10 years ago?
>>
>
> I feel like I made the case that it's not strictly 'features', so much as implementation quality and/or the complete package experience.
>

> So when I say "always just one thing", it's not features; it might be...
> but it's often also implementation quality, or binary environment
> integration issues, or build issues, or tooling issues... unfortunately we
> must _exceed_ a very high bar set by the C++ to ecosystem be successful.
> We're not evaluating which environment is the best experience overall, what
> we have to do is *dislodge* a deeply seated establishment by demonstrating
> sufficient advantages that it tips a subjective threshold of a businesses
> technical directors. They need to do an evaluation, easily recognise the
> advantages, and not be nervous.

In my opinion it's been to D's detriment that there is this ever present view that if only this particular feature was added, it would take D over the line...

But really what matters more in organizations is that can they depend on D to always work. It is far more important that all existing features work 100% reliably all the time.
And most organizations want good tooling support as well.

Regards