Moving back to .NET

Ola Fosheim Grøstad via Digitalmars-d digitalmars-d at puremagic.com
Thu Oct 8 03:59:01 PDT 2015


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.



More information about the Digitalmars-d mailing list