On 1/15/2024 5:11 PM, Mike Shah wrote:
> Getting back to the original topic -- I appreciated reading Atila's response --thanks Atila! Hoping for the best for all projects, I'll contribute where I can!

Can I pester you again for your amazing threading library?

On Tuesday, 16 January 2024 at 01:46:10 UTC, Walter Bright wrote:
> On 1/15/2024 5:11 PM, Mike Shah wrote:
>> Getting back to the original topic -- I appreciated reading Atila's response --thanks Atila! Hoping for the best for all projects, I'll contribute where I can!
>
> Can I pester you again for your amazing threading library?

That might be Roy Margalit you are thinking of? Or maybe it was Sebastiaan Koppe's talk on Structured Concurrency?  :)

(As an aside, my Ph.D. work was in Java doing some concurrency studies on performance -- so eventually I'd like to do more research work in D on this topic)

On Tuesday, 16 January 2024 at 01:37:40 UTC, claptrap wrote:
> On Tuesday, 16 January 2024 at 01:11:16 UTC, Mike Shah wrote:
>> On Tuesday, 16 January 2024 at 00:14:50 UTC, GrimMaple wrote:
>>>
>> I think the C++ committee process is also evolving over time. Though they have the same (sometimes intense) debates I've observed here and other communities in regards to features.
>
> yeah but D pretty much only has to get Walter and Atila to agree on it. It's not like there's vast amount of stakeholders, or committee members that you need to get on board like with C++.
>
> It should actually be an advantage for D but somehow its not.

Pros and cons I imagine to that that, though I'm not trying to push any DIPs,

I think we also need to think about how to grow the team and get them more help. Many other language foundations have money behind them to back a few full-time developers. I'll do what I can on advocacy around D, because I think it's a wonderful language and community -- that's why we're all here! :)

On 1/15/2024 6:25 PM, Mike Shah wrote:
> On Tuesday, 16 January 2024 at 01:46:10 UTC, Walter Bright wrote:
>> On 1/15/2024 5:11 PM, Mike Shah wrote:
>>> Getting back to the original topic -- I appreciated reading Atila's response --thanks Atila! Hoping for the best for all projects, I'll contribute where I can!
>>
>> Can I pester you again for your amazing threading library?
> 
> That might be Roy Margalit you are thinking of? Or maybe it was Sebastiaan Koppe's talk on Structured Concurrency?  :)

Ah, maybe you're right!


> (As an aside, my Ph.D. work was in Java doing some concurrency studies on performance -- so eventually I'd like to do more research work in D on this topic)

That would be something to look forward too!

On 16/01/2024 3:25 PM, Mike Shah wrote:
> (As an aside, my Ph.D. work was in Java doing some concurrency studies on performance -- so eventually I'd like to do more research work in D on this topic)

If you would like a suggestion on this topic, may I suggest coroutines?

From what I've seen in my library implementation they are the right way to do asynchronous coding and they are at the fore-front of concurrency research.

What is very interesting is that in D, as long as a function is being compiled the compiler could slice and dice it into a coroutine object (such as a closure) without needing to be annotated as such explicitly.

It could be done implicitly upon the library struct that represents the language coroutine constructor.

No async/await, no writing for asynchronously, just sequentially.

For these reasons I've told Adam Wilson that if I am to be involved with an event loop library for PhobosV3, I would not consider it without such a feature. Because the alternatives are either a hacked together workaround that is fail heavy (fibers), or rather involved in how you need to write (callbacks).

https://github.com/Project-Sidero/eventloop/blob/master/source/sidero/eventloop/coroutine/builder.d#L213

Lastly, what I call a future completion (a specific coroutine) is probably one of my most genius ideas of all time. It allows things like socket read to return a coroutine that will be triggered in say async read mechanism, but work with the coroutine worker runner dependency analysis.

https://github.com/Project-Sidero/eventloop/blob/master/source/sidero/eventloop/tasks/future_completion.d#L113

On 1/15/2024 10:38 PM, Richard (Rikki) Andrew Cattermole wrote:
> [...]
This sounds cool. Please do a DConf presentation on it!

On 16/01/2024 9:08 PM, Walter Bright wrote:
> On 1/15/2024 10:38 PM, Richard (Rikki) Andrew Cattermole wrote:
>> [...]
> This sounds cool. Please do a DConf presentation on it!

I've talked about this on BeerConf, but there are a few reasons why unless DConf is here in New Zealand, its probably best that I don't go.

However on that topic, I was going to do a Unicode talk for DConf Online this year, but alas that kinda depended upon UAX31 identifiers, and you haven't been too keen to approve that line of work so I haven't done it.

Anyway regarding my stuff, a lot of the lessons learned from it have gone into other work like PhobosV3 and Paul's work on allocators. Its going to show up at DConf at some point I expect.

Now if only I could convince you about having reference counting... that's another lesson that came from it. Good chance I'm going to have to drop DIP1000/scope if that cross behavior isn't resolved tbh. I can bare the pain, but I can't ask others to.

On Monday, 15 January 2024 at 18:33:07 UTC, H. S. Teoh wrote:
> On Mon, Jan 15, 2024 at 10:11:33AM +0000, IGotD- via Digitalmars-d wrote: [...]
>> [...]
>
> This is true, we have been repeating over the last decade or so the pattern of attracting enthusiastic contributors due to the technical excellence of D, only to have them turn around and leave after coming to an impasse with the project's management.  As I have said previously, the problem isn't so much that things did not go their way; I think any reasonable person would understand that in technical decisions there's always pros and cons and one could go either way, and that whichever way a decision goes, it would work out, one could live with it.
>
> [...]

Thanks for the write-up. I think it's true that these perceptions exist, and would like to ask you what you think we can do about it.

If I can summarise my own opinions about contributions, it's that they're absolutely welcome, but that every change has trade-offs and each diff has to justify itself with positive ROI. Of course it's going to be frustrating to work for free and not have it pay off (it's happened to me multiple times), but it also can't be the case that the default is to merge PRs unless "there's a reason not to".

My own perception is that we keep saying this, but maybe not? Perhaps we need to update the contributor guide.

On 16/01/2024 10:54 PM, ikod wrote:
> Hello,
> 
> 
> On Tuesday, 16 January 2024 at 06:38:16 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> On 16/01/2024 3:25 PM, Mike Shah wrote:
>>> (As an aside, my Ph.D. work was in Java doing some concurrency studies on performance -- so eventually I'd like to do more research work in D on this topic)
>>
> 
>> What is very interesting is that in D, as long as a function is being compiled the compiler could slice and dice it into a coroutine object (such as a closure) without needing to be annotated as such explicitly.
> 
> In Rust compiler convert `async` code into state machine with context.

Yeah that is basically what a coroutine becomes.

>> It could be done implicitly upon the library struct that represents the language coroutine constructor.
>>
>> No async/await, no writing for asynchronously, just sequentially.
>>
> 
> I'd start from defining event loop API to decouple interface from implementations.

I have done this in the past. You end up defining the user experience in the process.

Unless you go out of your way with something like coroutines, or fibers, you're pretty much stuck with callbacks of some kind and that is not going to fly.