Feedback on Átila's Vision for D

[Radu]

On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:
> This thread is for general feedback and discussion regarding 
> Átila's blog post on his vision for D's future.
>
> https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/

I like most of the meta goals that are listed in the blog post.

However, I would like to see a road map with some specifics and 
time estimates attached to them.

I'm really interested in the "Make D the default implementation 
language" section.
And this comes from a semi failed experiment of mine trying to 
code a C library in D using -betterC. My conclusions:

- You miss the nice dynamic arrays and hash map structures, and 
others. You end-up rolling your own or wrapping C libraries, 
which requires lots of effort.
- There is no way to generate C/C++ header files from your 
extern(C/C++) declaration, I know this is being worked on. So had 
to roll my own.
- I had to roll out my own RefCount, Nullable and friends.
- At that time copy ctor was not available, so me wanting to 
properly use immutable for non POD types was a pain.
- CTFE is severely limited.
Most of these are tracked as bugs already, in case *thatsomeone* 
asks :)

All these problems are systemic and come from the lack of 
orthogonality in the core and std libs, the language had some 
improvements in using a template based run-time interface, but 
still has warts like no betterC CTFE. There are a lot of 
assumptions about what is available in terms of language and 
run-time, and vast majority of APIs in std lib is written with 
RTTI, exceptions and GC in mind.
In a perfect world core/std APIs will be layered bottom-up, so 
you have access to some (most?) algorithms and data structures 
from the lower denominator (betterC) till up the chain with GC, 
exceptions, type info where it makes sense.
It's the "pay as you go" mindset, that was discussed at length on 
this forum, that is not a reality yet.
std.v2 could be a good place to exercise this, as it could 
liberate the way APIs are constructed and how the whole thing 
plays together.

So there is a great deal of potential there for library writers, 
you can write some nice and elegant system code that can be used 
from any language, using the C API (or even C++), and still 
maintain the higher level D API, all without a fat run-time 
attached.