New competitor to D

[Nicholas Wilson]

On Wednesday, 20 July 2022 at 09:35:14 UTC, Templated Person 
wrote:
> On Wednesday, 20 July 2022 at 07:23:04 UTC, Nicholas Wilson 
> wrote:
>> We have multiple GC's
>
> Do we _really_ have multiple GCs though? How do you we use 
> them, what are the advantages / disadvantages of each one?

Yes, there is the standard (conservative) GC, there is a Precise 
GC (which is really the same as the standard GC but with a 
precise sweep), and there is a fork GC (which is only for linux) 
which is different to the other two.
  I believe you can choose which one with a `--DRT` flag, and I 
think you can set some config at runtime in druntime somewhere, 
but I'm not sure. I've not bothered to change it.

The standard GC is a stop the world, conservative mark and sweep. 
It treats any value that looks like it could point to valid 
objects to be pointers (called false pointers). False pointers 
are only really a problem on 32-bit, which unless you are writing 
for microcontrollers are going the way of the dodo.
The precise GC is a stop the world, precise mark and sweep. 
Advantage: should not ever get confused by false pointers. 
Disadvantage often slower than the conservative GC.
Fork GC forks the current process and uses linux's cheap copy on 
write pages to mark dead objects asynchronously and then reap 
them. Advantages: not stop the world, asynchronous, usable in 
soft (and probably hard) realtime. Disadvantages: Linux only.

>> there is also std.experimental.allocator
>
> Which is useless until Phobos data types are refactored to use 
> that as a parameter.

Theres not really that many "data" types in the standard library. 
We should have a better container library that should be 
parameterised by the allocator that backs it, but the advantages 
of ranges is most of the code doing computation doesn't care what 
the memory is that backs it.

> If you ask me, D is better than most languages out there and it 
> should be the default way of migrating out of C++. But that's 
> not gonna happen until at least multiple of the following 
> happens:
>
> - The runtime gets leaner and more configurable, gotta have 
> that wasm support.

LDC has (some?) support for WASM, and the runtime is becoming 
less reliant on TypeInfo, by becoming templated to what is 
actually used. I'm not sure how far away we are from a no 
typeinfo runtime being usable.

> - Modern features such as sum types & pattern matching, 
> nullables & tuples in the language (not as libraries).

Good tuples would be very nice to have.

> - Allocators passed into functions (+ a "garbage collecting 
> allocator" like we have now)

There is nothing stopping you from doing that now. I'm not sure 
what you mean here.