April 27
On Tuesday, 27 April 2021 at 14:59:22 UTC, russhy wrote:
> i am asking we should aim to be a memory agnostic language, where one can plugin a GC transparently and do what ever he wants, and at the same time transition to a full manually managed scheme with allocators transparently

That would be nice, wouldn't it? But there is no such design on the table for D. You have to write your framework differently in order to support reference counting and garbage collection if it does something non-trivial.

You have to write frameworks differently for RAII and non-deterministic destruction...

So in practice you have to settle on one main memory management scheme, and let other management schemes be optional. Library authors are not going to do a good job of testing their libraries for multiple memory management scheme, even if they thought they wrote the code to support both.

Sure the standard library can default to reference counting, but 3rd party libraries probably won't.

This has nothing to do with moving to task-local GC or not, tough.
April 27

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

>

Without to be invited too much in the details here, I think you are right. But how should a stdlib look like which abstract over all allocators, would it be safe can it be safe and performant and generalizing?

I mean RC, for instance, is inferior in what it can accept for a language/what it can manage safely compared to GC.

So in return, some algorithms may only work for a GC.

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.

April 27

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

>

And the most important thing - you are free to manage the memory what ever way you want!

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.

April 27

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

>

Is this a direction D is able to move in or is a new language needed?

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?

April 27

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

>

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

Any(one) experience with it?

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.

April 28

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

>

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

>

On Tuesday, 27 April 2021 at 12:01:33 UTC, russhy wrote:

>

And at least with Unreal, since it is using C++, you are not forced to stick with the GC all the time

With unity, they had to come up with a special language to workaround the GC/JIT issues, and if you stick to regular C#, you are forced to stick with the GC no matter what

They don't. HPC# is a subset of C# without objects (no references).

>

So yes i want D to be as pragmatic as C++

You guys want D to be as closed minded as C#, we all know where that leads

If it leads to be #1 platform for cross platform development that I'd call it success.

Oof. People who make games with Java can has malloc buffers via C bridge(libgdx if you want example), C# can even call C almost directly, that also opens the door to malloc and other allocators, moreover it is even has pointers right in the language (in unsafe code).

And just to be clear, object pools is the GC managed memory, this is simply an optimization technique and not GC avoidance, the memory is still under GC control, it's still will be collected by GC at some point, it is just delayed to some moment in time in future.

I don't get it, in D you have basically SINGLE scenario when GC actually runs - memory allocation using GC.
It just sits there, takes up just a bit of memory, but it doesn't waste your precious CPU ticks, it doesn't sucks power.
And the most important thing - you are free to manage the memory what ever way you want!
D even gives you the tools(-vgc flag) to know where exactly GC allocation can happen so you could optimize away that so much hated GC to zero.
All this available right now without changing the language and waiting for implementation.
So what's the problem with you?

libgdx also is a pain in the ass to work with because you have to constantly fight with java and the GC, they had to rewrite all the data structures (collections etc because they allocate on foreach)

that is why libgdx is dead, java is not suitable for gamedev

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?

>

This project is at a very early stage, parts of the type checker are still to be implemented, and there are very few language features implemented yet. This will change, but will take time.

April 28

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

>

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.

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.

April 28

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

>

i am asking we should aim to be a memory agnostic language, where one can plugin a GC transparently and do what ever he wants, and at the same time transition to a full manually managed scheme with allocators transparently

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.

April 29

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

>

As computer memory grows, naive scan and sweep garbage collection becomes more and more a burden.

Also, languages have not really come up with a satisfactory way to simplify multi-threaded programming, except to split the workload into many single-threaded tasks that are run in parallel.

It seems to me that the obvious way to retain the easy of use that garbage collection provides without impeding performance is to limit the memory to scan, and preferably do the scanning when nobody is using the memory.

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

April 29

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

>

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

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

1 2 3 4 5 6 7 8 9 10