On Friday, 12 June 2020 at 21:00:20 UTC, drug007 wrote:
> On Friday, 12 June 2020 at 20:35:03 UTC, angel wrote:
>> 3. Reference counted memory management. It is predictable.
>
> Sorry for offtopic but why do you think so? Reference counted memory management is a form of garbage collection and is unpredictable too. Imagine you have a large tree and you free the last reference to a node. All child of this node will be freed and this process takes time depending on child nodes count. It is unpredictable in general.

Your scenario sounds totally predictable? With refcounting you get a "free" mark phase (ref goes to 0), and then you know you're holding the only reference so you can just hand it off to a cleanup thread and stop thinking about it for the low cost of an atomic write.

Now, cycles do make it fully GC but they're in the control of the developer and can usually be broken with weak pointers. In general, people don't mind costs so long as they feel they're responsible for them and can do something about them. This is why people will always distrust stop-the-world GC for realtime tasks.

On Friday, 12 June 2020 at 20:35:03 UTC, angel wrote:
>
> 3. Reference counted memory management. It is predictable.

Which D supports today, but only explicitly.

If you want it built in today we would need two pointer types. Raw pointers and pointers to fat pointer structures.

raw pointer -> whatever
fat pointer -> fat pointer structure -> whatever

It will a new language and we will call it "D Phat".

15.06.2020 13:40, FeepingCreature пишет:
> Your scenario sounds totally predictable? With refcounting you get a "free" mark phase (ref goes to 0), and then you know you're holding the only reference so you can just hand it off to a cleanup thread and stop thinking about it for the low cost of an atomic write.
> 

How do you know that you have the only reference? the node can be both the root and a leaf node.

> Now, cycles do make it fully GC but they're in the control of the developer and can usually be broken with weak pointers. In general, people don't mind costs so long as they feel they're responsible for them and can do something about them. This is why people will always distrust stop-the-world GC for realtime tasks.

If someone accepts my humble opinions.
On Friday, 12 June 2020 at 13:12:35 UTC, Chris wrote:
> How would you go about D3?
>
>     1. Which features would you keep?
Interop with C and C++, metaprograming with mixins & templates.

>     2. Which features would you definitely get rid of?
>     3. What type(s) of memory management would you chose?

I don't know, but at least a way to use GC, ref counting or malloc/free on a more transparent way. Perhaps like Beeflang handles allocators.

>     4. How would you design Phobos?

I really miss a solid collections framework. Perhaps it's my Java background speaking here, but I really miss allow to declare a attribute/variable to a Map interface and initialize with a specific implementation of Map.

Another option it's to have a lightweight Phobos and have some community sanctioned dub packages that implements basic stuff like collections framework, xml/json/whatever serialization, test runner, etc.


>     5. What restrictions would you impose? (see below)
>     6. How would you handle backwards compatibility?

A flag to change between language versions ? ie --release d3 and --release d2
Also, the rust epoch's idea, looks interesting. And the suggestion of Andrei about versions the standard library it's interesting : https://forum.dlang.org/post/rc3a7r$178f$1@digitalmars.com

>     7. How would you design the tooling?

Q. Schroll "mini dip" of alternative way to declare a mixing string, would make a lot more easy to IDE/tools to check the mixing code. Something similar should be considered.

>     8. How would you make it “industry friendly”? (see below)
>

> D3 - Programming in 3D

On Friday, 12 June 2020 at 13:12:35 UTC, Chris wrote:
> How would you go about D3?
>
>     1. Which features would you keep?
>     2. Which features would you definitely get rid of?
>     3. What type(s) of memory management would you chose?
>     4. How would you design Phobos?
>     5. What restrictions would you impose? (see below)
>     6. How would you handle backwards compatibility?
>     7. How would you design the tooling?
>     8. How would you make it “industry friendly”? (see below)
>
> As to point 5: I know that it’s great to have a lot of freedom (I know: freedom => responsibility). However, there’s a reason why a lot of programming languages impose certain restrictions on the programmer. E.g. if every library is designed differently, it’s hard to build up a proper ecosystem of libs and reusable code. There’s the aspect of security too.
>
> As to point 8: it closely ties in with point 7. Approach it from the point of view of a project manager or a small tech company. It is important that it is easy to set up and use (IDE, toolchain) and that it caters for different needs. One of the first questions will be how well it ties in with other technologies (e.g. C interop) and if it can easily be ported to the most common platforms (Android, iOS etc.) and architectures. It should be as easy as writing a few lines of a CMake file to cross compile and it should easily interop with the host OS (e.g. it can be laoded as a dynamic lib out of the box). IMO, this is something one should think about right from the start and not leave for later, especially because D already has features that would facilitate this.
>
> D3 - Programming in 3D

Removing new (https://dlang.org/spec/expression.html#new_expressions) and replacing it with a library-based solution (such as https://dlang.org/phobos/std_experimental_allocator.html)
New is seen as the obligation to use the gc, we need a new solution that includes the choice of allocator.

I know that you can currently choose but it is not a great marketing to propose two methods of allocating one of which uses gc and the other would be excellent but it has been "experimental" for years

On Monday, 15 June 2020 at 14:38:31 UTC, drug wrote:
> 15.06.2020 13:40, FeepingCreature пишет:
>> Your scenario sounds totally predictable? With refcounting you get a "free" mark phase (ref goes to 0), and then you know you're holding the only reference so you can just hand it off to a cleanup thread and stop thinking about it for the low cost of an atomic write.
>> 
>
> How do you know that you have the only reference? the node can be both the root and a leaf node.
>

You know you have the only reference because your refcount goes to 0...

On Monday, 15 June 2020 at 22:30:23 UTC, Ernesto Castellotti wrote:
>
> Removing new (https://dlang.org/spec/expression.html#new_expressions) and replacing it with a library-based solution (such as https://dlang.org/phobos/std_experimental_allocator.html)
> New is seen as the obligation to use the gc, we need a new solution that includes the choice of allocator.
>
> I know that you can currently choose but it is not a great marketing to propose two methods of allocating one of which uses gc and the other would be excellent but it has been "experimental" for years

You not need to removed new. Only to improve it. Again... I think that the approach that BeefLang did it's really good on this :

String AllocGlobalString(int len)
{
    return new String(len);
}
String AllocCustomString(int len)
{
    return new:customAllocator String(len);
}

16.06.2020 13:23, FeepingCreature пишет:
> On Monday, 15 June 2020 at 14:38:31 UTC, drug wrote:
>> 15.06.2020 13:40, FeepingCreature пишет:
>>> Your scenario sounds totally predictable? With refcounting you get a "free" mark phase (ref goes to 0), and then you know you're holding the only reference so you can just hand it off to a cleanup thread and stop thinking about it for the low cost of an atomic write.
>>>
>>
>> How do you know that you have the only reference? the node can be both the root and a leaf node.
>>
> 
> You know you have the only reference because your refcount goes to 0...

How do you know how many childs this node has? You don't know the height of the subtree, so you can't predict how many childs will be freed.

On Tuesday, 16 June 2020 at 12:35:35 UTC, drug wrote:
> 16.06.2020 13:23, FeepingCreature пишет:
>> On Monday, 15 June 2020 at 14:38:31 UTC, drug wrote:
>>> 15.06.2020 13:40, FeepingCreature пишет:
>>>> Your scenario sounds totally predictable? With refcounting you get a "free" mark phase (ref goes to 0), and then you know you're holding the only reference so you can just hand it off to a cleanup thread and stop thinking about it for the low cost of an atomic write.
>>>>
>>>
>>> How do you know that you have the only reference? the node can be both the root and a leaf node.
>>>
>> 
>> You know you have the only reference because your refcount goes to 0...
>
> How do you know how many childs this node has? You don't know the height of the subtree, so you can't predict how many childs will be freed.

The point is you don't need to worry about this memory in the main thread anymore, so you can gradually free it in a background thread and it doesn't matter how many children it has, because the problem with memory management isn't CPU consumption but latency, and the latency of "send this pointer to the cleanup thread" is constant.