On Tuesday, 27 April 2021 at 15:23:30 UTC, sighoya wrote:

This can be solved by not allowing destructors/finalizers on GC objects. Then a modelling error would only lead to leaks.

If you do that then you can let libraries be written for RC. Then when a GC is available you convert strong and weak RC-pointers to non-RC pointers if the RC-pointer pointed to a class with no destructors/finalizers.

But since people won't give up on destructors/finalizers for GC, we can't do this. The alternatives are likely to be bug ridden...

So, people who want libraries to be memory management agnostic actually have to successfully champion that destructors/finalizers are removed from the GC for all programs.

Get consensus for that, then move on to getting rid of the GC from libraries. First thing first.

On Tuesday, 27 April 2021 at 13:29:43 UTC, evilrat wrote:

That's kinda irrelevant. You can say that for basically any language with a C-bridge. Doesn't mean it is cost efficient. If it isn't cost efficient, then it isn't competitive. If it isn't competitive then it isn't interesting.

And as far as C#/Java/Go goes, D is not going to get memory barriers and is therefore going to freeze or significantly slow down execution for any reasonable collection scheme during collection. (I don't consider fork() reasonable.)

So any argument based on what people do with a GC in C#/Java/Go is irrelevant for D.

Can we please focus this discussion on getting a competitive memory management scheme? Reverting to C is not a competitive option.

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

I think this sounds good.

There is already a language taking the same/similar direction:

Pony: https://tutorial.ponylang.io/appendices/garbage-collection.html

Any(one) experience with it?

On Tuesday, 27 April 2021 at 21:18:30 UTC, sighoya wrote:

I have no real experience with it, but I read quite a bit about it when it first came. I think the typing system for references is interesting. Basicially keeps track at compile time of whether a pointer has been given out or not and restricts capabilities for the reference based on that.

On Tuesday, 27 April 2021 at 14:59:22 UTC, russhy wrote:

LibGDX is pretty much alive, https://libgdx.com, I guess you keep referring to the old site.

Yes it probably has been shadowed by the facts that the original author kind of left the project after being burned with the Xamarin acquisition and shutdown from the original RoboVM project.

And the tiny detail that nowadays Unreal and Unity are mostly free beer for indies, alongside their GC implementations, graphical tools, the preferred teaching tool at game universities around the globe, with first party support from Microsoft, Apple, Google, Sony and Nintendo on their OS, VR/AR and gaming platforms.

As for Verona, it is Microsoft Research language and it is mostly paperware in 2021, did you forgot to read the link?

On Tuesday, 27 April 2021 at 19:51:55 UTC, Ola Fosheim Grøstad wrote:

This kind of direction isn't the problem, but the other way around is. You can't easily transform GC code to RC code which is much more needed than the other way around given the amount of libraries written.

The model of Weak/Strong references is in my opinion either not fast or unsafe.

On Tuesday, 27 April 2021 at 14:59:22 UTC, russhy wrote:

The problem is that you solely consider manual or managed resources on their own, but resources alias other resources and other resources alias the considered resource, the connection is the problem.

Not only does the GC manage memory for you at runtime, it also does this in a way to guarantee memory safety, speaking differently, the GC is some kind of runtime lifetime manager, although not a deterministic lifetime manager.
Anyway, this is a feature Rust completely lacks.

There are ways to reformulate the solution to cyclic data structures differently, but mostly with some additional memory or performance hit.

And just to say, no one moans when Rust didn't allow deleting resources when lifetimes say no, but the GC shouldn't say no?

Solving the problem in Rust is similar to solving the problem in D, just choose another memory model for the specific problem.

Could libraries more engage in providing such solutions, I think yes, but generalizing algorithms to offer you the most performant and safe code is hard and leads probably to a state space explosion.

Just look at the many ways you can create containers in Rust, you have Owned, Rc, Pin, Cell, Pin<...<...>> and whatever.

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

So region-based memory management with per-region GC?

On Thursday, 29 April 2021 at 01:24:27 UTC, James Lu wrote:

You could say that, although it is more based on the context of a task which can suspend.