On Thursday, 3 September 2020 at 16:36:46 UTC, Ola Fosheim Grøstad wrote:

> E.g. What happens if someone loads the whole file to GC-memory and then retains a pointer to a tiny slice of it. Can the runtime know that only that specific slice is "live"? If it can, then it can release the unused parts surrounding the slice (the big bulk of allocated memory). Can the runtime prove that there is only one reference to the slice? Then it can move it (compaction).

My experience is with mixing R and C. When you write code in C, you can tell R to allocate an array (or whatever you want) using the GC. It tracks the number of times you do those allocations in your C code. You then either release the underlying memory back to the GC or you return that memory to R as the return value of your function. If you missed something, R throws an error and tells you that you didn't release everything.

Naturally, you can still do all kinds of crazy things on the C side, including stashing pointers to GC-allocated memory. That's how it goes if you want to write C code - it's your responsibility to make it work. Everything on the R side is guaranteed safe.

I'm not saying this is a strategy D should pursue. Just that it's easy to use and it's worked well for decades, allowing you to mix your safe GC code with unsafe, GC-free, complete-control-of-everything code. There's nothing original in anything I've written. All you have to do is track GC allocations in the unsafe functions, check your bookkeeping when passing data between the two types of code, and enforce the usual @nogc restrictions on the relevant code.

On Friday, 4 September 2020 at 07:08:40 UTC, Russel Winder wrote:
>
> My feeling is that C++20 and C++23 are likely to satisfy C++ addicts such that any thoughts of using D get washed away.
>
> My belief is that programmers now attribute programming languages as no-GC, GC-possible, and GC – with GC-possible being a very small set.
>
> I have no problem iwth D trying to be both GC and non-GC for those D programmers that feel they need it, but D is very much seen fairly widely as a GC language, I see no reason to fight that.

Modern C++ is the reason I'm to begin with and I'm satisfied with C++11. I use C++ often but that is for low level programming and that's where C++ has its niche. All the new features of C++ don't really target low level programming but tries to become a language it is not and that is a high level big hauling language (it actually was in the 80-90s). Think server, cloud, micro services. This is really Java, Python and others territory and C++ has no chance there. C++ in this realm is very unusual unless you have strict performance and/or resource footprint requirements but more often people use the big haulers like Java because of convenience.

D already support manual memory management and you can mix how much you want. The question is how the standard libraries should written and used. I'd say leave them as it is and people who want manual memory management are free to do that but then you have create your own libraries (mainly because nobody will port druntme/phobos to non-GC). I agree with you that D should be a GC language first since that is what most people will be looking for when programming D. For those who are not are probably programming betterC and there a lot of features are disabled.

We'll see if you are right when it comes to C++23 and so on. I believe that C++ will not increase its popularity because of new features. What C++ tries to target with the newer standards is out of its reach, better alternatives exist. This includes D. One funny observation is that C++20 is starting to look like D in some aspects (modules), however the name resolution in D is superior in my opinion.

I believe that C++23 will not decrease the interest for D, and it will be interesting to see what will really happen.


There is another misconception I want to address and that is that Rust is non-GC. Rust is partly a garbage collected language. Due to the single ownership limitation many algorithms use reference counting. Reference counting is a form of GC. Same goes for C++ when it uses shared_ptr.

On Friday, 4 September 2020 at 21:51:18 UTC, IGotD- wrote:
> programming and that's where C++ has its niche. All the new features of C++ don't really target low level programming but tries to become a language it is not and that is a high level big hauling language (it actually was in the 80-90s).

Some are low level, like aligned allocators, SIMD, punning...

> others territory and C++ has no chance there. C++ in this realm is very unusual unless you have strict performance and/or resource footprint requirements but more often people use the big haulers like Java because of convenience.

Yes, unfortunally, memory can still be precious in cloud settings. But it is a matter of pricing vs convinience.

> D already support manual memory management and you can mix how much you want. The question is how the standard libraries should written and used. I'd say leave them as it is and people who want manual memory management are free to do that but then you have create your own libraries (mainly because nobody will port druntme/phobos to non-GC).

Then you will end up with a Phobos/Tango situation. Keep in mind that GC apps benefit from nogc libaries as you will get fewer collection cycles and less memory waste.

> We'll see if you are right when it comes to C++23 and so on. I believe that C++ will not increase its popularity because of new features.

C++ is one of the few languages where we can see increased enthusiasm in terms of awarded stars on github. So there is increasing developer enthusiasm, but probably less so with managers.