Isn't it about time for D3?

[Mike via Digitalmars-d]

On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:

> I think it's about time for D3 to start developing.

I would love to see a fork of D2 that attempts to address some 
obstacles I encountered when I was using D.  However, it is quite 
apparent that there is little to no interest in such a venture 
from those in the D community with the talent to actually do it.  
And I have to admit there is still room for innovation in D2, and 
that seems to be where most want to allocate their limited 
resources.

For D3 to happen, it will likely require talent outside D's core 
team.

I do a lot of programming in different domains, and it seems I 
have to use a different language for each one in order to be 
productive. I would like to find a single language that I can use 
to program just about any domain, but still be able to enjoy 
modern features for safety, convenience, zero-cost abstractions, 
and modeling power.  I'm not aware of any language that fits that 
description, but the languages I've found to be somewhat close 
are C++11~17 and Rust.  They're the only ones that appear to be 
scalable down to domains such as resource constrained 
microcontrollers.

* Using D for resource constrained systems requires too many 
compromises and silly runtime hackery.
* C++11~17 is quite good but it is not at all convenient, and 
safety is just too easy to get wrong.
* Rust is probably the best, but it doesn't have the modeling 
power of D and C++.

It'd be more constructive to begin collecting information from 
the community about what changes they'd like to see in D3.  
Here's a start from things just off the top of my head and in no 
particular order.

THINGS TO CHANGE OR ADD
-----------------------
* Final-by-default

* immutable by default

* @safe by default

* Fix attribute inconsistency and revisit if D is using the 
appropriate defaults

* Pay as you go druntime.
The compiler is too coupled to druntime and expects things to be 
there even though they're not required.  This would also make D a 
better language for replacing much of the exising infrastructure 
code out there that is currently written in C because it wouldn't 
require the D runtime dependency and all the overhead that goes 
with it.  Rust has done well in this regard.

* Minimal druntime
The language should be easy to port to other platforms.  Keep 
druntime small and to a few fundamental primitives to whatever 
extent that is possible.  Rust has also done well in this regard.

* Compiler resolves druntime symbols at compile time.
This is important for porting D to other platforms that may not 
have the resources or hardware to support certain features of the 
language.  The compiler would emit a compile-time error if usage 
of such a feature was attempted, but not supported by the 
runtime.  Proposed here [1].

* Some way to mark memory at compile-time with certain attributes 
(e.g. See [2]) to inform the compiler of proper code generation 
(e.g. volatile semantics).  This would probably only be useful 
for bare-metal programming, but I encounter this all the time and 
its getting worse with each new MCU generation.

* Remove the "module must be a file" arbitrary limitation
I ran into this when I was trying to model hundreds of 
memory-mapped IO registers.  I wanted to use a module for each 
register, but each module would only have a small amount of code, 
and I would have ended up with hundreds of little files.  It 
would have been better if I could group all "register" modules 
for a given peripheral under one "peripheral.d" package file.  
Something like `package UART { module SR {} module DR{} }` would 
have been nice.  I ultimately ended up with `final abstract class 
{}` instead, which is stupid.

* get rid of the "_t" suffix added to types from C.
Come up with a better, more consistent naming convention for 
these types that doesn't carry baggage from other languages.

* Drop the GC or at a minimum make it opt-in.  Add a borrow 
checker, automatic reference counting, or some other GC 
alternative that doesn't require a separate thread.
DIP1000 is interesting and may enable some new interesting 
patterns and idioms.  Might be able to take some inspiration from 
it.  I wonder if DIP1000 would have been more elegant if D didn't 
have to worry about breaking code.

* The C standard library bindings and C++ standard library 
bindings should be in Deimos not in the druntime.
I already tried to promote this, but only encountered obstruction.

* Cure the TypeInfo infection [3]
TypeInfo has been over(ab)used in the runtime implementation.  
This is probably due to historical baggage, but also a lack of 
discipline.

THINGS TO KEEP
--------------
* CTFE

* Templates and static-if (static-if is some powerful stuff!)

* Mixins (or some other way to do convenient composition)
I get that one should favor composition over inheritance, but 
most object oriented languages offer precious little to do the 
"right" thing.  D mixins are great for composition.

* Traits (or some other form of reflection)

* UFCS

THINGS TO DROP
--------------
* C++ interoperabiliy
Walter's right:  memory safety is going to kill C and C++ will go 
with it.  Don't waste time on this; it's not going to matter in 
10 or 20 years.

After collecting such a list, begin a fork of LDC, and start 
working on it.  If you can show progress and potential, others 
may be willing to contribute, accelerating the project.  I, 
personally, think it would be very exciting to see and would 
eventually become an active contributor myself if the project 
addressed some of the issues I have with D2.

I was on cloud 9 when I first started using D, and had high hopes 
that it would change my career and even give me a new tool off 
which to build a profitable business.  But the more I used it, I 
just became more disillusioned.  D has so much potential compared 
to all other languages out there, but it's potential that it will 
never reach because it's just carrying too much baggage and has 
not been designed with domains like resource constrained 
microcontrollers in mind, like Rust was.

I don't do anything in D anymore, but I still watch what goes on 
here in the D community, and hope that someday enough people will 
come together and begin a fork to take D to its true potential.  
I don't have the skills or resources at this time to lead such a 
project, but I'll volunteer my resources if it ever gets off the 
ground and shows promise.

Mike

[1] - Proposal to have druntime inform compiler of platform 
support - 
http://forum.dlang.org/post/psssnzurlzeqeneagora@forum.dlang.org
[2] - ARM Cortex-M3 memory attributes - 
https://developer.arm.com/products/processors/cortex-m/cortex-m3/docs/dui0552/latest/2-the-cortex-m3-processor/22-memory-model/221-memory-regions-types-and-attributes
[3] - Discussion about the TypeInfo infection - 
http://forum.dlang.org/post/nevipjrkdqxivoerftlw@forum.dlang.org