[GSoC] Trying to find a good topic

[Mike Franklin]

On Friday, 29 March 2019 at 15:35:10 UTC, Dan Printzell wrote:
> If you want to you (others are also welcomed) can look through
> my draft to make sure I have not written anything stupid and
> possibly suggest improvements.
>
> https://docs.google.com/document/d/15ba1vC1T7n2vX8kvQVikOj1Ip1-mt-zyiEwd0OYBoQA/edit?usp=sharing

I've been spending some time trying to think about how to 
articulate the benefits of this work to D, and its community.  
For some reason, I'm finding it difficult to articulate, but I'll 
try.  Hopefully, it will help you write a stronger proposal.

Andei recently "hit the nail on the head" with this post - 
https://forum.dlang.org/post/q7j4sl$17pe$1@digitalmars.com

> Oh, and druntime must go.
>
> The whole distinction between the runtime library and the 
> standard library is clowny and has more to do with poorly 
> ported tradition from other languages, than with anything else.
>
> We need one standard library that is entirely pay-as-you-go 
> (e.g. empty main() means no library file is ever needed for 
> linking) and that offers an opt-in continuum.

IMO, that is *exactly* what we need.

Some of D's features are extremely powerful assets in some 
problem domains (e.g. PC application software, Web services, 
etc.), but an unfortunate liability in other problem domains 
(e.g. bare-metal, resource-constrained applications, etc.)  To 
make D scalable to all of these domains, it needs to be more 
pay-as-you-go and provide an opt-in continuum, as Andrei so 
eloquently stated.

Converting the runtime hooks to templates provides an excellent 
first step towards reaching that goal.  There are immediate 
benefits (I've already mentioned these, so sorry for the 
repetition.)

*  Some language features will no longer depend on `TypeInfo` 
(and therefore, classes, and the GC) so D will immediately become 
more scalable to bare-metal and other resource-constrained 
platforms that want features like arrays, but don't want the 
overhead classes and the GC (at least initially while they are 
bringing up a board, OS, or porting the D language to a new 
platform).

*  There is evidence in Lucia Cojocaru's work that this work has 
the potential to provide significant performance increases.

*  The new templates will finally run through the full semantic 
phase of the compiler enforce compiler guarantees such as memory 
safety, purity, etc.

*  This work makes druntime more of a "header-only" library.  
This is helpful in cross-compiling scenarios (e.g. 
microcontroller programming) because one will not need to 
cross-compile the runtime ahead of time to use those D features 
implemented by the templates.

But the benefits will not stop there.  Once this initial work is 
completed it will open up new opportunities for more performance 
optimizations and the aforementioned pay-as-you-go, opt-in 
continuum for expanding D to more platforms and problem domains.

*  The new templates will allow developers to make better 
decisions at design-time (design by introspection) and 
compile-time to make additional performance optimizations to the 
template implementations.  I suspect significant exploitations 
will be discovered and implemented over time.

*  The templates can be further refactored with versioning and 
design by introspection to remove additional dependencies (i.e. 
`Exception`s).  This will further bring the aforementioned 
pay-as-you-go, opt-in continuum to reality.  Indirect benefits 
include more D features available to betterC, and consequently, 
more Phobos features available to betterC.  In the longer term, 
however, if the pay-as-you-go, opt-in continuum becomes a 
reality, there will no longer be any reason for betterC; one just 
chooses not to use the D features they're not willing to pay for.

*  With the runtime hooks converted to templates, software 
building blocks like `memcpy`, `memcmp`, `malloc`, etc. can be 
re-written in D, extending the aforementioned design by 
introspection, compile-time optimizations, memory safety and 
other compiler enforced guarantees all the way down the call 
stack for fine-tuned, high-performance, reliable software.  An 
exploration of `memcpy` in D can be found at 
https://github.com/JinShil/memcpyD

*  As the pay-as-you-go, opt-in continuum becomes more and more a 
reality, users will find D an attractive alternative for all kind 
of bare-metal, embedded, IoT, microcontroller, etc. problem 
domains competing with the likes of C and Rust that currently 
dominate those domains.  One of the reasons Rust is taking off in 
the embedded space is due to it's "minimal runtime" philosophy.  
D can have that too, and converting the runtime hooks to 
templates is an important step in that direction.

To keep the project within scope and on schedule, I recommend a 
direct translation first (to whatever extent possible).  Avoid 
the temptation to do too much refactoring.  Remember, you can 
always followup with more PRs to clean things up, optimize, 
whatever if time and energy remain.

I hope I'm being helpful.  Keep in mind I've never participated 
in GSoC or anything like it.  I don't know much about writing 
proposals like this.  Don't feel compelled to include any of it 
in your proposal.

I'm also no expert with this stuff.  I'm just someone who spent 
some time on it in 2018.  I didn't submit many pull requests 
because I had to learn so much first about what needed to be 
done, and how.  I'm trying to pass that on to you and others.  I 
hope even after GSoC this kind of work will continue.

I'll take another look at your proposal in a few days, assuming 
you do some polishing between now and then.

Mike