January 04, 2018
On Thursday, 4 January 2018 at 19:04:36 UTC, jmh530 wrote:
> 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.

But Rust isn't using garbage collection...


January 04, 2018
On Thursday, 4 January 2018 at 19:18:30 UTC, Ola Fosheim Grostad wrote:
> On Thursday, 4 January 2018 at 19:04:36 UTC, jmh530 wrote:
>> 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.
>
> But Rust isn't using garbage collection...

That probably makes Pony easier to compare to D. I was just noting that Rust shares some ownership stuff with Pony. I suppose I'm curious what is the bare minimum that needs to get added to D to enjoy the benefits of an ownership system (and it seemed like something like the iso type was most important).
January 05, 2018
On Thursday, 4 January 2018 at 20:25:17 UTC, jmh530 wrote:
> That probably makes Pony easier to compare to D. I was just noting that Rust shares some ownership stuff with Pony.

I get your point. Pony is probably closer to Go and Erlang, but nevertheless comparable to what some want from D based on what they say in the forums at least.

> I suppose I'm curious what is the bare minimum that needs to get added to D to enjoy the benefits of an ownership system (and it seemed like something like the iso type was most important).

There should at least be a strategy for having transitions between pointer types and tracking of pointer types in relation to compile time code gen and run-time behaviour.  So knowing that a pointer is iso can allow many things like transitioning into immutable, automatic deallocation, reusing memory without realloction, moving heap allocations to the stack…

But if D is going to have a GC and no special code-gen to back it up then it becomes important to stratify/segment the memory into regions where you know that pointers that cross boundaries are limited to something known, so that you can scan less during collection. Which is rather advanced, in the general case, IMO. But a possibility if you impose some restrictions/idioms on the programmer.

January 05, 2018
On Friday, 5 January 2018 at 00:58:12 UTC, Ola Fosheim Grøstad wrote:
>
> But if D is going to have a GC and no special code-gen to back it up then it becomes important to stratify/segment the memory into regions where you know that pointers that cross boundaries are limited to something known, so that you can scan less during collection. Which is rather advanced, in the general case, IMO. But a possibility if you impose some restrictions/idioms on the programmer.

I think it's a good idea. It relates to an idea I had had in the past with all the discussion on precise GC. One of the problems (as I think someone else mentioned above) with creating a precise GC for D is that it allows all sorts of things with unions and pointer arithmetic. However, it seems like just about all the stuff that makes a precise GC difficult is disabled in @safe code (or at least assumed to be @safe if coming through a @trusted block). So you could have a @safe region that is precise and a @system region that is as it is now. From the current system, you would have to be able to do some kind of run-time reflection to know if the code is in a @safe block or not. The simplest implementation would begin by handling just the case where you allocate in a @safe block and the object is only referred to in safe blocks (that way you know it's always safe). And then you'd have to probably do something special for when point to @safe code from @system code.

It also occurs to me that you could have a region for (completely) const/immutable data (not sure if you need to do this as a subregion within a precise region), assuming the GC can get that information. Transitive const/immutable means that pointers to this data cannot modify it. GC strategies that normally require write barriers wouldn't need them here.
January 05, 2018
On Friday, 5 January 2018 at 03:11:42 UTC, jmh530 wrote:
>
> It also occurs to me that you could have a region for (completely) const/immutable data (not sure if you need to do this as a subregion within a precise region), assuming the GC can get that information. Transitive const/immutable means that pointers to this data cannot modify it. GC strategies that normally require write barriers wouldn't need them here.

In std.experimental.allocator, I was thinking that in something like GCAllocator you could have the allocate function be a template that changes the behavior based on the the type you are trying to create. So for instance, if you are creating a const/immutable object do one thing and if creating a mutable object do something else. However, it looks like the allocate function is not templatized so it might require a bit of modification to get it work. It also mean the allocator would depend on the type it is trying to create, which may not be a design they want to pursue.

I noticed there is a second parameter in allocate in IAllocator for TypeInfo. This is for run-time type info, but I don't see an example for it.
January 05, 2018
On Friday, 5 January 2018 at 20:20:04 UTC, jmh530 wrote:
> On Friday, 5 January 2018 at 03:11:42 UTC, jmh530 wrote:
>> [...]
>
> In std.experimental.allocator, I was thinking that in something like GCAllocator you could have the allocate function be a template that changes the behavior based on the the type you are trying to create. So for instance, if you are creating a const/immutable object do one thing and if creating a mutable object do something else. However, it looks like the allocate function is not templatized so it might require a bit of modification to get it work. It also mean the allocator would depend on the type it is trying to create, which may not be a design they want to pursue.
>
> [...]

It seems you are thinking about this:
https://dlang.org/phobos-prerelease/std_experimental_allocator_typed.html
January 05, 2018
On Friday, 5 January 2018 at 22:09:03 UTC, Petar Kirov [ZombineDev] wrote:
>
> It seems you are thinking about this:
> https://dlang.org/phobos-prerelease/std_experimental_allocator_typed.html

Ha, that is exactly what I was thinking of!
January 21, 2023
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
>

Today i attempted to take a look at the post, and it says "Quora deleted this answer."  There is no further elaboration.  (It was also not on the Way Back machine at the Internet Archive.)

Could somebody please post a current link to the article?

Thanks in advance!

dan

PS: The reason i am responding to this very old thread is i happened to stumble on it in a google search.  I imagine that i am not the only one who will land here, and so i think that for the benefit of other stumblers a current link to the article would be useful.
January 21, 2023
On Saturday, 21 January 2023 at 04:58:29 UTC, dan wrote:

>
> PS: The reason i am responding to this very old thread is i happened to stumble on it in a google search.  I imagine that i am not the only one who will land here, and so i think that for the benefit of other stumblers a current link to the article would be useful.

It wasn't an article, as I recall. It was a comment he posted on Quora. If it's been deleted there and isn't in the internet archive, I'm unaware of it having been copied anywhere else.
January 21, 2023
On Saturday, 21 January 2023 at 04:58:29 UTC, dan wrote:

https://archive.ph/hbBte
Maybe someone want to copy paste text here for history. Idk