While randomly browsing online, I found this link below

https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Andrei-Alexandrescu

This is a post on Quora, with some interesting statements by Andrei himself

"Overall it could be said that D has the downsides of GC but doesn't enjoy its benefits."

"A historical lack of vision"

"Of the three (D, Rust, Go), Rust is the only language with world-class PL theorists on roster"

"(D) 10x better than any other system language at generic and generative programming"

I am posting this here, because, I see a lot of comments that seem to suggest, that some people - me include, or me me at least, were under the impression that the makers of D, are not fully aware of its competitive advantages and disadvantages

But this post proves at least to me that the D foundation members, are really fully aware, how D compares to its key competitors

This post on Quora, makes it fully clear to me that the makers of D are fully aware of D's position

Anyway, it is a nice read, and reminder to some of us who follow this forum, that we probably dont need to remind D makers what D needs, or where D should go etc..

On Tuesday, 2 January 2018 at 16:34:25 UTC, Ali wrote:
> While randomly browsing online, I found this link below
>
> https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Andrei-Alexandrescu
>
> [...]

Yes, it is a great post. I would be happy to read similar posts from the creators of Rust, Go, Swift, etc.

On Tuesday, 2 January 2018 at 16:34:25 UTC, Ali wrote:
> "Overall it could be said that D has the downsides of GC but doesn't enjoy its benefits."

Not a true statement. Go does not have long pauses, but it has slightly slower code and a penalty for interfacing with C.  Go also has finalization with dependencies, so that they execute in the right order…

The downsides/upsides of GC isn't something fixed for all designs.

> This post on Quora, makes it fully clear to me that the makers of D are fully aware of D's position

Not sure how you reached that conclusion.

On Tuesday, 2 January 2018 at 19:50:55 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 2 January 2018 at 16:34:25 UTC, Ali wrote:
>> "Overall it could be said that D has the downsides of GC but doesn't enjoy its benefits."
>
> Not a true statement. Go does not have long pauses, but it has slightly slower code and a penalty for interfacing with C.  Go also has finalization with dependencies, so that they execute in the right order…
>
> The downsides/upsides of GC isn't something fixed for all designs.
>

That was not a comment about GC implementations in general, it was about D's GC implementation, check the original post on Quora, and read the statement right before this one, maybe it will make this point clearer

>> This post on Quora, makes it fully clear to me that the makers of D are fully aware of D's position
>
> Not sure how you reached that conclusion.

¯\_(ツ)_/¯

Andrei is a smart guy, and the post was very honest, it was not biased at all.
And it raises many concerns I see in many post by people who are a lot less involved with D, like the issues with the GC and the illusive vision

On Wednesday, 3 January 2018 at 19:42:32 UTC, Ali wrote:
> That was not a comment about GC implementations in general, it was about D's GC implementation, check the original post on Quora, and read the statement right before this one, maybe it will make this point clearer

I read it when it was posted… D does get the key benefits of a GC (catching reference cycles and convenient memory management), but it also gets the disadvantages of a 1960s GC implementation.

There are many ways to fix this, which has been discussed to death before (like thread local garbage collection), but there is no real decision making going on to deal with it.  Because to deal with it you should also consider semantic/types system changes.

The chosen direction seems to be to slowly make everything reference counted instead, which doesn't really improve things a whole lot IMO. At best you'll end up where Swift is at. Not bad, but also not great.

> And it raises many concerns I see in many post by people who are a lot less involved with D, like the issues with the GC and the illusive vision

Well, but leadership is about addressing the concerns and making some (unpopular) decisions to get here.  *shrug*

But I don't really care anymore, to be honest… Several other compiled languages are exploring new directions, so I'm currently content to watch where they are going…

I personally think D would be in a stronger position if some hard decisions were made, but that isn't going to happen anytime soon. So there we are.

On Wednesday, 3 January 2018 at 21:43:00 UTC, Ola Fosheim Grøstad wrote:
> There are many ways to fix this, which has been discussed to death before (like thread local garbage collection), but there is no real decision making going on to deal with it.  Because to deal with it you should also consider semantic/types system changes.

I don't know much about GCs, but can you explain why that would be necessary?

On Wednesday, January 03, 2018 22:06:22 Mark via Digitalmars-d wrote:
> On Wednesday, 3 January 2018 at 21:43:00 UTC, Ola Fosheim Grøstad
>
> wrote:
> > There are many ways to fix this, which has been discussed to death before (like thread local garbage collection), but there is no real decision making going on to deal with it.  Because to deal with it you should also consider semantic/types system changes.
>
> I don't know much about GCs, but can you explain why that would be necessary?

Well, with how shared and casting works, it's not actually possible to have thread-local GC heaps, because objects can be passed between threads. Casting to and from shared would have to also tell the GC to change which thread manages that object's memory, and that would be a pretty big change to how casting works. It also wouldn't play well at all with how shared is used, because in order to use a shared object, you either have to use atomics (which wouldn't be a problem, since no casting is involved), or you have to temporarily cast the object to thread-local after protecting that section of code with a mutex to ensure that it's safe to treat that object as thread-local within that portion of code. Changing what manages the object's memory for that would just harm performance. Another thing to consider is that pointers don't actually know what manages their memory. That's not part of the type system. So, how would having casts move objects from the thread-local GC to the shared one (or vice versa) interact with stuff like pointers that refer to malloc-ed memory?

Seemingly simple improvements to the GC fall apart _really_ fast when you consider how much you can legally do in D and how the type system doesn't really have anything in it to indicate what owns or manages a block of memory. Some of the really big GC improvements that have occurred in other GC-managed languages were able to be done, because the languages disallowed all kinds of stuff that a language like D or C++ considers perfectly legal and legitimate. Improvements can certainly be made to D's GC (and some improvements have definitely been done), but without changing how D works, we're _really_ restricted about what type of GC we can have.

- Jonathan M Davis

On Wednesday, 3 January 2018 at 22:06:22 UTC, Mark wrote:
> I don't know much about GCs, but can you explain why that would be necessary?

Necessary is perhaps a strong word, but since D will never put restrictions on pointers then you need something else than what Java/C#/JavaScript/Go is using.

There are many ways to do memory management, but if you want "smart" memory management where the programmer is relieved from the burden of manually making sure that things work then the compiler should also be able to reason about intent of the programmer and you need some way to express that intent.

E.g. Pony differentiate between different types of "ownership" and can transition between them, so you can go from memory that is isolated to a single pointer, pointers that only know the address but cannot access the content, pointers that are fully shared etc.

You also have something called effect-systems, which basically a sort of type system that can statically track that a file is opened before it is closed etc.

So, if you have a smart compiler that is supposed to do the hard work for you, you probably also want some way to ensure that it actually is doing the smart things and that you haven't accidentally written some code that will prevent the compiler from generating smart code.

For instance if you have a local garbage collector for a graph, you might want to statically ensure that there are noe external pointers into the graph when you call the collection process, although you might want to allow such pointers between collections. That way you don't have to scan more than graph itself, otherwise you would have to scan all memory that could contain pointers into the graph...

On Wednesday, 3 January 2018 at 22:22:12 UTC, Jonathan M Davis wrote:
> [...]

Makes sense. Thanks. I use casting so little that sometimes I forget it exists.

On Wednesday, 3 January 2018 at 22:26:50 UTC, Ola Fosheim Grøstad wrote:
>
> E.g. Pony differentiate between different types of "ownership" and can transition between them, so you can go from memory that is isolated to a single pointer, pointers that only know the address but cannot access the content, pointers that are fully shared etc.
>

Pony relates to Rust in terms of what they are trying to accomplish with ownership. Pony's iso reference capability seems to mirror Rust's borrow checker rule that you can only have one mutable reference. D's DIP 1000 already seems to incorporate one of the borrow checker's rules on scope length. Adding something like iso would probably help in the ownership department after DIP 1000 is officially added.