Could D be used by Jonathan Blow rather jai language?
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Sat Nov 21 11:14:24 UTC 2020
On Saturday, 21 November 2020 at 05:51:53 UTC, Bruce Carneal
> I don't have a comprehensive understanding of where D is at and
> where it is headed wrt memory safety models. The @live stuff
> looks a little "iffy". Hopefully Walter's upcoming talk will
Yes, it will be interesting to see where D is headed.
Right now I think maybe automatic reference counting for dynamic
arrays and class objects would go a long way, but...
The more I think about it, the more it makes sense to add Actor
as a compiler construct and let that represent one thread (heavy
or light). Then that Actor can have its own collection strategy
and provide its own allocator in TLS. So for instance if most
objects in that Actor is 100 bytes then it can have a separate
heap for those. This can be profiled. Or if the Actor is short
lived with low memory usage, just use a bump-allocator.
> As you note, some language advances may not be practical for D
> but others could be built atop extant automated/correct
> checking and some could be independent, never-existed-before,
> capabilities where backward compatibility is not a concern:
> type functions, monadic type variables, new memory guarantees,
> arbitrarily prolonged "compile time", ...
I do at least hope that there will be clean guarantees for shared
and nonshared memory, so that you can keep them on separate heaps
and avoid atomics in allocators etc.
There is a need to list the language constraints that are needed
to get semantic/runtime improvements. Some kind of matrix,
More information about the Digitalmars-d