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/[email protected]
[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/[email protected]
