[andralex]

I have quite a few things in mind for the immediate future. Organizationally, I want to get the D Language Foundation rolling as an organizational mothership of the language. Technically, I want to focus on: (a) completely defining the language - fuzzy corners such as the meaning of "shared" are a liability; (b) offer a solid experience to users who don't want a garbage collector; and (c) design more libraries using the fledgling Design by Introspection technique.

(EDIT sorry, submitted too soon) With regard to targeted users and uses, D is an ample language that could be used for a large range (heh) of applications. I want to make sure the core language and libraries offers a solid support on which various applications, frameworks, and libraries can build.

[minthd]

>> D is an ample language that could be used for a large range (heh) of applications. I want to make sure the core language and libraries offers a solid support on which various applications, frameworks, and libraries can build.

The advice given in marketing new products is often opposite - find a niche, offer much better value than competitors for that niche ,become the leader of that niche - and use that base to expand.

I wonder if this kind of advice offers a better route for success for a programming language ? What was the case historically ?

[andralex]

This is good food for thought. Yes, working through a niche has been a good "in" for some languages.

[vinceguidry]

I feel this advice leaves a lot to be desired.

Ruby was around for 10 years before Rails released version 1.0. Rails itself didn't get popular until version 2, 4 years later.

It takes a long time for a language to mature to the point to where someone loves it so much they're willing to bet their career on it, as DHH did.

The best thing for a language designer to do IMO is not to try to decide what the killer app is, but rather to make it as nice as possible so that more and more people want to use it to solve problems.

Rails isn't the best web development stack because of any kind of monolithic effort on the part of the Ruby core team. It was built on top of the work of dozens of programmers who did things like write HTTP client libraries, HTML parsing tools, templating languages, all the things that a framework relies completely on.

My advice: You can only focus on so much at once. Let the community build the tools. You build the language. You'll never be able to do both, there just isn't enough time.

There's so much other stuff for you to do. Figure out governance, setting a tone for the community, reaching out to heavyweights so as to raise your profile, working out what your relationship to corporate sponsors is, how you're going to ensure stability across versions, package management. The countless little things that make one language more of a joy to work with than another.

[jeremiep]

I'm pretty sure there's a market for D on consoles and mobile gaming. This is the first thing I get asked every time I suggest using D at work (we mainly do casual games while also porting AAA titles with a few internal engines).

So far I've only been successful with a few shell scripts calling into the tools of the console's SDK doing mass reflection on 75k shader object files among other things. Yet I do half of my home projects in D and absolutely love it.

I think getting D to interopt with more existing code in all of C#, Java and Objective-C as well as on both mobile devices and game consoles will greatly help its adoption with the "oh its just another library we add to our existing codebase" factor which has tremendously helped Clojure take off.

This means D could make it easy to extend both JVM and CLR applications with lighting fast code while getting free access to their respective ecosystems. I for one would love to use D instead of C# to write Unity code.

[pekk]

Clojure isn't really a fair comparison. Clojure hasn't got low-level interop with all those things, just JVM, and that interop is bought at the cost of closely tying Clojure to JVM. I don't think D can be changed in all the basic ways that would be required to give it the same level of integration with JVM, and that would also basically mean abandoning the entire standard library. JVM's difficulties integrating with things other than JVM aren't something I imagine D can really solve.

[jeremiep]

I meant things such as extern(C#) and extern(Java) to work the same way extern(C) and extern(C++) do now.

I don't see the point of compiling D to JVM or CLR byte-code for all the efforts it would involve, but rather the CLR or JVM load native code written in D and have each call into each other easily.

Say I can't reach the performance I want in C# and I want to write that part of the system in D and load it in Unity and then call into native D code from there. Without having to mess with the CLR implementation details. That would definitely allow people to try it out and integrate it gradually until it has completely taken over.