On Tuesday, 20 April 2021 at 17:09:48 UTC, Stefan Koch wrote:

@safe @system @pure @nogc @noreturn @help @nothrow void doSomethingForMePlease()
{
   writeln("is this where we want to go?");
}

That's the point of the joke, all looks the same, they adds, and things becomes confusing/visual noise

On Tuesday, 20 April 2021 at 09:52:07 UTC, Ola Fosheim Grøstad wrote:

Are you familiar with this:
https://github.com/hsutter/gcpp

How similar are these ideas?

On Tuesday, 20 April 2021 at 16:21:39 UTC, Petar Kirov [ZombineDev] wrote:

Yes, but I think it is too tedious to pass around allocators. Having a global user-modified variable is also not good for static analysis. I think a Task ought to be a compiler construct, or at least a language-runtime-construct.

It might be desirable to have different types of Tasks, like one that is GC based and another type that is more like C++.

Then the compiler need to keep tabs of the call-tree and ensure that only a GC call-tree allows a regular pointer to own a new object.

And shared pointers could always be owning (possibly RC-based) unless some kind of borrowing scheme is implemented.

I guess that could be useful. How would it affect scheduling?

Hm, what implications are you thinking of that are different from what D has to deal with under the current scheme? Are you thinking about coexisting with the current regime of having a global GC as a transition, perhaps?

* The framework can run a non-optional linter as part of the build process, which would ensure that you don't have:
    * `@system` or `@trusted` code

But you should be able to call @trusted? Or maybe have a different mechanism like @unsafe.

* reference capabilities like [Pony][3]'s

Yes, I think being able to transition a shared object with a refcount of 1 into a GC-owned non-shared object could be desirable.

Yes, I think you either have a thread local current_task pointer or have a dedicated hardware-register point to the current task. (implementation defined)

* Add `context` as the last parameter to each of druntime function that may need to allocate memory set it's default value to the global GC context. This is a pure refactoring, no change in behavior.

I guess an alternative would be to transition to a new runtime. Then code that depends on the current runtime will have to be rewritten to work with the new regime, and compilation failure would protect mistakes from going unnoticed. Or, if a transition is needed, then I guess each runtime could assert that it isn't called from a task call-tree (check a thread local variable).

* Add Scala `implicit` parameters [⁴][4] [⁵][5] [⁶][6] [⁷][7] [⁸][8] to the language and mark the `context` parameters as `implicit`

The FAQ on implicits was long... maybe it is a language design mistake? :-)

Ola.

On Tuesday, 20 April 2021 at 16:28:46 UTC, russhy wrote:

Well, it would be 0ms, if it runs when the task is idle. If the task is short lived then it would be like an arena-allocator (faster than malloc).

The people who were unhappy with D having a GC has probably left for Rust at this point. So it seems like the majority wants to have a GC.

If it keeps moving at this pace then it will never happen... and the language semantics for borrowing isn't there.

Yes, if it had happened 4 years ago, but it is kinda too late. If there had been traction in the community for making everything RC then things wouldn't move so slowly with memory management as it does now. Borrowing won't happen either, for it to happen there should've been a gamma-release by now. It will take years to get it to work properly after the first gamma-release.

GC-based tasks should make converting existing code reasonable in most cases. Except for heavily user-level multithreaded code.

It can also be done as a prototype in short order. Just adapt the existing GC code, even though that might be a bit heavy for production use.

On Tuesday, 20 April 2021 at 16:21:39 UTC, Petar Kirov [ZombineDev] wrote:

* The framework can run a non-optional linter as part of the build process, which would ensure that you don't have:
    * `@system` or `@trusted` code

Just want to add that there should be imposed some constraints on what can execute as safe code in a task so that one can get fully precise garbage collection and over time add compaction.

I guess untagged unions is the main source for imprecision.

One might also want to prevent non-safe code from allocating GC objects so that all code that is GC-relevant is checked properly by the compiler.

On Tuesday, 20 April 2021 at 17:52:33 UTC, jmh530 wrote:

I've read about it, but it seems to be just a local collector?

It isn't similar as we want to trace stacks and don't want to rely on conventions. We want the type system to prevent bad situations from happening.

Then just use an arena allocator, why everyone wants to make things complicated for everyone, and as a default

It's just like the Thread, or even Fibers, can't even be used without the GC, that is a very very very poor and short sighted mindset

Reason why language stagnates, noone left to take it to the next level

Worse, the ones who stayed are taking D to the wrong direction by focusing on the GC

Argument that i share, we need the foundation people and walter/atila etc to show up in these discussions, but they never do, so no interesting debates happen, reason why language stagnates

That is a very short term mindset, another reason why language stagnates, lack of vision and lack of proper discussion to make pragmatic and future proof changes/deprecations/decisions

Whenever that discussion happen, it's always "it's too late", "it'll never happen", "it's the way it is", "just embrace the bad, stagnating, non-scalable GC"

The main issue is the lack of will and courage from the team to ackowledge the poor state of the GC and they play hide&seek when it comes to discussing/debating about it

On Tuesday, 20 April 2021 at 21:59:30 UTC, russhy wrote:

It is too late for D to attract C++ developers. I am ok with C++20 and dont think it is realistic for D to play catch up.

D needs to find its own vision, or it will be displaced.

On Tuesday, 20 April 2021 at 22:32:08 UTC, Ola Fosheim Grostad wrote:

What RC has to do with C++?

What using a pragmatic approach and IAllocator oriented apis has to do with C++?

I'm not talking about C++, at all

Defeatist mindset, that is what i am talking about when i say the people who stayed are taking D to the wrong direction

And i never said it needs to catch up with C++, sticking to GC means it can't be a compelling alternative to the people with C/C++/Rust and soon Zig background

Worst, it can't be a compelling alternative to Java/C# for cloud purposes because Go already fit the role perfectly fine, because they did what D failed to do

https://blog.golang.org/ismmkeynote

Is this allocating memory? is this using arena GC? is this gonna end up blocking all my threads? how long can we expect a pause to be? 20ms? 1ms?

Actor model isn't bound to GC uses, so your wish of a vision for D has nothing to do with the way memory is managed

Solving real world issues is what drives adoption, but at some point your solution will have to work with D's features, and these are using a poor's man GC that'll stop their world, and won't scale well

Foundations have to work well, and to be pragmatic, so you aren't bound to a specific scenario, that is the most future proof solution because it allows anyone with ideas on how to solve real world problems, that is what

C is not displaced because of that, it doesn't tell you what to do, and how to do, it gives you the tools so you can write portable code, efficient and better software

I personally doesn't give a damn about all of this since i stick to core.stdc

But i care about D, and this vision of D being a managed language is not doing good for D's future, managed language come and go because they made strong choices that they are unable to revert, C/C++ still strong today, why? i guess -i don't know right?-

I went way too offtopic, i should have created a separate from the beginning..

And i agree with Andrei this place needs a voting system, with proper moderating tools, so i'd know if what i said speaks to people or if i should just stop because i am becoming annoyingly rude for no real reasons

On Tuesday, 20 April 2021 at 16:28:46 UTC, russhy wrote:

Maybe I'm wrong, but wouldn't we be just going from one form of memory management people find slow to another? And a kind we know is particularly slow (even if more predictable)? It seems to me that the really anti-GC crowd (or the portion of it that I know of - the Handmade / game dev group) doesn't want GC nor RC, but instead something way more C-like, with custom allocators and such. I think that's what languages like Zig that sprang up out of nowhere are suddenly taking off and why there's still anticipation for Jai nearly 7 years later.

I do kind of agree that maybe a D3 is what's needed in order to have a clean rethinking and uncrufting of the language. I've been feeling that despite D's amazing features and upsides, something just isn't clicking with people. Since I became an avid D fan many years ago, most programmers I talk to have never heard of it, and the situation has not gotten better over time.