On Thursday, 8 October 2015 at 10:31:57 UTC, Chris wrote:
On Thursday, 8 October 2015 at 09:45:53 UTC, Ola Fosheim
Grøstad wrote:
That's not vague at all.
1. Define the target, then you can figure out the features.
Then define the target. Make some suggestions.
I've already raised this topic in a thread where I asked where D
sits in the web space. And I did that because it has been said
that vibe.d defines a key application area. However, that is a
very hard market to capture which many expressed in that thread.
I think D could do well if it focused on engine-level system
programming and made sure it was absolutely top notch for that
purpose. (Game engines, search engines, ray tracing engines, in
memory database engines, business logic engines, etc).
The current focus goes the other way. The current assumption is
that engines are written in C/C++ and they are used to complete
applications in D. That would make D an application level
language, which makes success _very_difficult. As time progresses
I believe it makes less and less sense to do a full application
in languages like C/C++/Rust/D...
But if you create an "engine language" then you also need to be
very good at exporting APIs. Like having compact and readable API
definitions in D that lends itself to auto-generating interfaces
for other languages (Python, Ruby, Go, Javascript etc).
2. Solid non-gc memory management and ownership.
Any specific implementation in mind?
Change the language enough so that you can do full pointer
analysis and compete with Rust/C++.
Limit GC to actors. Use move semantics between actors.
Point 3 and out really depends on what you do with point 1 and 2.
The key point here is that the project leadership needs to start
with defining enough constraints to do rational focused and
strategic decision making.
Then make a high level plan that takes you from where you are to
a finished project, then you refine the plan (and evolve it).
Piling up proposals and endless non-breaking evolution isn't
effective.
