So, as you try to formalize it, I encourage you to try to remove as much ambiguity and processing complexity as possible. Maybe also work with academics who specialize in formal specs or methods that caught many defects in prior language or system specs. The result is that researchers interested in building assurance and QA tools for D will have a much easier time. Just look at how long it took to certify a C compiler vs ML and LISP compilers despite latter languages being much more powerful.

Reason it's important, whether an immediate concern or not, is that much of the best stuff comes from cash- and time-strapped, but smart, academics trying to make a name or push state-of-the-art. Easier your language is to work with, the more of them might choose it. And you've done a really, good job on a C++ replacement that I thought would've had more adoption. So, I'd like to see some of those brains get put on your work, too. :)

Regardless, good luck to you on your next move!

Competition is good for all involved. Rust and C++ are the competitors closer to the same turf. I think we have a solid value proposition and several ways to enhance it and differentiate ourselves. Time will tell.

- learning of large-scale classifiers and regressors using custom optimizers

- real-time pricing of billions of ads a day using these models on ad exchanges. <.5ms latency to parse complex bid requests and compute sparse and simd dense dot-products

- a real-time event processing system that hits DynamoDB with ~4.5K json queries per sec on a single node

We literally have D systems deployed on hundreds of ec2 instances as we speak and responsible for mission critical tasks of a >100$M run rate company. D is ready for prime time and works at scale.

It's a fun time.

Not on ARM. I will try again but last time I tried setting up a toolchain (~6 months ago) met with headache, pain, and eventually heartache.

http://wiki.dlang.org/Current_D_Use

And many more companies not in that list.

Remedy is responsible for Alan Wake and Max Payne, Funatics for Cultures, Zanzarah, among others.

Remedy: "integrating D with a typical C/C++ game engine as an extension language for use processing game logic"

Funatics: "D as a replacement for the parts of our infrastructure that use nodejs right now"

(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.

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 ?

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.

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.

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.

2. is there any plan to include Mobile(mainly iOS/Android) in the D roadmap?

3. any plans to safely use the standard library with GC disabled?

However, there were two concurrent developments. One is Martin Nowak and others did great work on improving D's existing garbage collector. The other trend is that it became increasingly clear that a category of users will always be weary of a GC, be it for the right or wrong reasons. So the better place to hit is to offer a great experience in D without requiring any garbage collection at all.

2. Mobile is an important area for a language like D. We don't have many experts on team to work on that, but we're looking. One thing I can do soon is to encourage ARM support, which right now works only experimentally and in a science project kind of way.

3. I want to make it possible to use a well-defined subset of the standard library without a GC. (The subset part is for legacy compatibility.)

Do you vision D becoming a transpiler platform, similar to JavaScript land where languages target D source ?

x-lang => D => ldc => binary

That said, just as a related aside, there's the Daniel Murphy's magicport program that translates real projects from C++ do D semiautomatically (Daniel used it to translate the D compiler itself; we recently committed to bootstrapping).

On a serious note... what do you think you will miss the most about Facebook?

How about adding a byte buffer concept alongside with ranges? I'm thinking an API similar to Netty's ByteBuf but using D's compile-time capabilities instead. These would be valid ranges as well but offer direct byte access on top.

It would be great if the reflection info could be outputted to a separate file for those cases where its only needed during program initialization or used by external tools.

I want more than empty, front and popFront to manipulate byte buffers with high performance.

I'm thinking about reading data structures, performing bit conversion, and extracting primitive values from untyped byte arrays. Going as far as to reuse the array's memory for the values being read which isn't possible with ranges.

(Yeah, I get it that the languages target different niches in theory, but there will be significant overlap among the people who use them, I'm sure...)

D would be awesome for game development, because it's a "C++ done right", but I don't think Andrei has the salesman qualities needed to sell his child to game devs, like getting a bunch of people together to write a good open-source game engine that could also serve as an example of codding patterns.

And Rust and his daddy... they are just too smart to become popular nowadays, people just don't have the will and time to sit and learn better ways of doing things when they have alternatives that "mostly work most of the time" and have an easier learning curve...

That presupposes that Rust is more complex than C++ in a way that causes developers to learn C++ instead of Rust. Certainly there are a lot of C++ developers at the moment (though that number is much less than in years and decades past!) But I don't see that many new developers learning C++ anymore. Even beginning programmers who are interested in games are turning to higher-level languages and frameworks these days. My employer hires lots of C++ developers, and it's well-known that it's getting increasingly harder to find them.

When comparing Rust to Go, sure, Go is an easier language to pick up. When comparing Rust to C++, the majority of people I've talked to think the ease of use advantage goes to Rust.

I think D and Rust will both be fairly well received (if they aren't already), if only for their perspective on memory management.

Andrei hopefully doesn't need salesman like qualities. I hope that there will be enough D evangelists to do the selling for him.

Rust will hopefully be hugely successful, but if not, the ideas it espoused will certainly be developed further by future languages.

Those 4 languages are aiming at different targets (I think Rust and D would be aiming at the most common group). C++ is looking to gain the ability to do "modern things" in C++ without confusing existing C++ devs, Go is looking to attract devs who want to do modern stuff with a tiny ramp-up cost (low cognitive over-head, low time-to-productivity, brilliant standard library, native concurrency primitives) whereas D and Rust are both offering languages with more "modern" features that may be theoretically sound, but don't have as much proven use in production code.

These differences are blurred, and the languages obviously do have cross-over in terms of features and paradigms, but I doubt they're truly competing for many jobs yet.

They all have their place, depending on what you're trying to achieve.

He states D isn't different enough to encourage most devs to go through the pain of switching. If they are going to switch, they would like that language to be much better targeted at solving game dev specific needs.

I also think that, due to it's early start, D simply fails to appeal to non-C++-developers. The other new native compiled languages, Go and Rust, are not just a new toy for C++ people, but are also seen as long awaited "on metal" opportunities for people from other language backgrounds (python and ruby for go, type-heavy managed languages for rust), who would never touch c++ or, guilty by association, D. This is a much bigger audience than the subset of c++ devs willing to give up their hard-earned mastery of c++. The perceived promise of native for high-level devs might not hold, but this won't help D at all.

Edit: yeay the downvote bandwagon, you should go to a AAA studio and ask about C++.

There are reasons why AAA studios stick to C++: they don't know any better, they're in constant crunch-mode and don't have time to look for better alternatives, they use an existing engine with years of development history and don't want to invest in a new one, they target platforms where only C/C++ compilers are available, etc.

You'd be surprised of the horrors you can find in a game's C++ code base (there are gems too, but you kind of expect those.)

While it's true that some languages make some horrors easier to bring into the world (if you take away people's access to the memory, for example, you remove an entire class of memory-related nightmares), in my experience, the key requirement for creating these horrors isn't the language; it's the programmer and the constraints they're working under (such things as inexperience, painful levels of urgency, inappropriate processes, team churn, and so on and so on). People can and will make horrors in any language, and if D becomes the new C++, in twenty years people will be saying the same things about D.

When I think about all the different variable initialization rules in C++ I know I'll get it wrong in crunch time and most likely get it wrong when all my work conditions are perfect because there's like 7 different rules. And that's for one feature only.

D doesn't make it impossible to write horrors, it just doesn't ask for it the way C++ does.

Relatively small backend apps written in C++ may be a better target for D and Rust.

The difference is that they only do it when the OS vendors, or game console vendors, force them to adopt new languages in their SDKs.

First there was only Assembly, C and Pascal dialects were dog slow, and the OS vendors forced them to go C.

Then there was only C, C++ was dog slow, and the OS vendors forced them to go C++.

Then there was only C++, language X was dog slow, and the OS vendors force them to go language X.

The question is what language X stands for.

https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced...

And the new generation usually comes with a fresh set of ideas about things, and some of the newbloods will be "stupid" enough to start and rewrite some of the C++ tools, at the expense of their employers that will see delayed projects and tons of bugs because of this, and probably fire the trouble-makers, but the retooling will happen anyway, so it's probably better for people to embrace it and start allocating budget slices for it.

I know many gamdevs using Unity, LUA, Javascript, Gamemaker and a ton of other options.

take for example a lot of C++ samples that that guy shows in the video, he calls it "C++11" and uses code like:

- void* data = NULL;

- no STL

- no stack allocations

- only dynamic memory allocation using new and delete

i mean come on..

Stack allocations are discouraged because they can introduce non-deterministic bugs (stack overflow depending on the call sequence which can't be predicted in advance).

Its nearly impossible to write a game without dynamic allocations. Most of the time they'll override the new/delete operators and on that level they work almost exclusively on void*.

You're working on a scale where a lot of the C++ features work against you.

that’s probably because most of the AAA games you've seen used old in-house libraries that replaced the STL, since the earlier STL implementations weren't the best.

STL is not 100% the way to go every time, but i would say that nowadays unless there’s a really specific implementation need, it should be used at least 90% of the times, even if only for base for new data structures to be built on top of.

- "Stack allocations are discouraged because they can introduce non-deterministic bugs (stack overflow depending on the call sequence which can't be predicted in advance)."

i really don’t understand this problem, you can change the stack size on every compiler and every OS either on compile time or runtime. also, are you writing functions or methods with 10k LoC?

stack allocations are actually easier to follow than heap, its not even close..

- "Its nearly impossible to write a game without dynamic allocations. Most of the time they'll override the new/delete operators"

yes i agree, dynamic allocations are still really needed, and not only for games.

But, overriding new / delete operators in C++ when you can set custom allocators and deallocators for both unique_ptr and shared_ptr? once again i think that’s more of a legacy code update problem than an actually implementation need problem.

- "and on that level they work almost exclusively on void*."

only if they want to, that’s what templates (and again the STL) are here for.

I’m not saying pure C++11/14 features are the only way to go, i just think that at least in new code it should take priority, the cleanness and robustness it provides its just too good to ignore.

On the last AAA game I worked on we had very tight memory constraints and running about a dozen threads. Almost all of them used the minimum stack size except for the main thread. There were still a lot of stack allocations, but only for very small temporary objects and when the call stack was known to be shallow. Using megabytes for stack sizes would consume a noticeable percentage of the available memory which was direly needed elsewhere.

I've seen one game using shared_ptr and it was far from being great. There's a big overhead to it when compared to custom allocators. You can't easily optimize for cache locality with shared_ptr (as far as I know!) and working around enable_shared_from_this can be a real pain. With custom allocators you can easily optimize according to the use-cases.

Finally, templates are required to know their type at compile time, which for things like allocators is just not possible in many cases. For example, we used a bump-the-pointer allocator for a frame's temporary values which could be of any type but still needed cache locality. We also used a fixed-size allocator when avoiding memory fragmentation was more important than cache locality. Both would be impossible to do on anything but void*.

I haven't taken the time to dig into seeing how these techniques will translate to Rust(obviously unsafe).

I've lost count of the number of times I've thought to myself "I wish C++ has this D feature." A lot of them are being added now but the interesting ones (concepts!) are still years away and some (inout functions!) are nowhere in sight.

And then there's templates, mixins, auto this, compile-time reflection, and so much more. Its far from perfect (nothing is) but constantly improving and rather productive. Of course also being a user of Clojure (and Emacs-LISP) I sometimes miss something like defmacro, which I can almost get with mixins and templates but often not as elegantly. On the other hand, I write shell scripts in D all the time and not in Clojure!

Last time I looked std::vector::clear() wasn't required to release memory and caused a lot of headache when certain implementations wouldn't free the underlying memory.

I'm aware that the work around is to assign a new std::vector<T>() but that always felt like more of a hack then anything else.

they didn’t really "fix" it, instead they added a method called std::vector<T>::shrink_to_fit() which i'll admit its not the most elegant way, but it works.

what it does is, it resizes the capacity() to be the same as the size(), deallocating all the extra memory.

"Abstractions like RAII, constructors and destructors, polymorphism, and exceptions were invented with the intention of solving problems that game programmers don’t have, and with the result of interfering with the solutions to problems that game programmers do have."

...that's basically enough to make me never bother to look him up again. We don't need more special purpose languages, we need more general purpose ones. That's the cool thing about D and Rust and Go too. You can easily use the same language for anything from simple scripts (D even has rdmd that basically works like a ruby/python-style interpreter to run a file without even compiling!) to, I don't know, navigation control code for a drone.

We really don't need more special purpose tools now, the hardware allows us to have languages that span the full spectrum from metal to web page (via compile-to-js, but still...), so let's use this. Yeah, full-spectrum languages will be neither C-like (like close enough to metal so you can see the resulting machine code in your head) nor Javascript-like (idiot-friendly but professional-hostile), so we should prepare for some "weirdness".

It's not like we don't already know that this is possible since like 30 years ago: Lisp machines used one high level language for everything from OS to GUIs but and it worked great, with the exception that their price/performance ratio was horrible, but now we kind of solved the problem of building dirt-cheap machines, so we can get back to dreaming awesome stuff! And in the games world, I think that John Carmack has partially "seen the light" too, and maybe he'll convince more people of what he's seen ;)

https://www.reddit.com/r/rust_gamedev it's pretty small though (1264 subscribers, /r/rust has 12000, /r/swift is the same and /r/golang has 16000)

http://dlang.org/interfaceToC.html

Can anyone comment further?

https://github.com/crabtw/rust-bindgen is a tool in the vein of dstep.

(Rust has the advantage of having no runtime beyond what C needs unlike D with its current garbage collector, so FFI, especially exposing a C interface, is likely somewhat simpler.)

It looks pretty much like what one would want C++ to be like if one were to start over again, free of the need for backwards compatilibity with C (at the syntax level)

I haven't had the A-Ha moment with D, I have to admit, not the way I had with Go. Right now, Go feels more aligned with the way I tend to think.

But I still think that D is a brilliant language that people will come to like if they are not tied to the ground by legacy code they have to maintain. I don't think D will ever replace C++, but if Alexandrescu is behind it, that might go a long way.

Here's a snippet of code I hacked together in D for a bot to scrape titles from pages of urls in irc messages.

    matchAll(message, re_url)
              .map!(      match => match.captures[0] )
              .map!(        url => getFirst4k(url).ifThrown([]) )
              .map!(    content => matchFirst(cast(char[])content, re_title) )
              .cache // cache to prevent multiple evaluations of preceding
              .filter!( capture => !capture.empty )
              .map!(    capture => capture[1].idup.entitiesToUnicode )
              .map!(  uni_title => uni_title.replaceAll(re_ws, " ") )
              .array
              .ifThrown([]);

for those now interested in the D language one must recommend Ali Çehreli's free book that now is also available as print:

http://ddili.org/ders/d.en/index.html

Matz is working only on ruby at heroku? Guido, is working full time at dropbox?

I think this is huge lose for Facebook and a big win for D lang comunity

"Facebook is and continues to be a D user, the last project I was working on (and is ongoing) uses D, and there's more use in smaller internal projects. But there is no stronger involvement for the time being."

http://forum.dlang.org/post/qnfbjzpldfhqsfqclqdx@forum.dlang...

1: https://github.com/facebook/Haxl

To my memory it's basically generated static content. That's why it handles high load with such grace, and is so fast even on the slowest devices. I don't know the complexities behind that, but damn, I wish more sites did it.

(I'm an occasional lurker on D mailing list and proud owner of the D book. That mailing list, BTW, taught me a great deal of things about a whole bunch of programming languages.)

http://www.amazon.com/Modern-Design-Generic-Programming-Patt...

Unfortunately - I changed jobs to work on some start ups and said bye to C++ for Python, JS, etc and never had a chance to really use the concepts

Will the foundatiom be sponsoring development of plugins for popular ide's like atom, netbeans, intelij, eclipse etc.

Even if I just built something simple in both languages it would be a fun exercise.

http://www.informit.com/articles/article.aspx?p=1381876

"Next step with the D Language Foundation is a formal talk with the foundation's prospective attorney tomorrow."

Isn't that something you'd like to do before leaving your day job?

[1]https://github.com/ericniebler/range-v3

https://news.ycombinator.com/item?id=716111

I think he said he had an implementation almost ready to release but I never saw it. I would be very interested to see it. Thought it would be a good thread to ask.

http://goldns.ru/cppmap-2012.png

it makes me sad :(