My background was high assurance systems and security plus regular software/system development. Mainly do R&D now while evangelizing field's developments. The academic and industrial side of the field keep making great progress in transformation (see Semantic Designs), static checking (Astree Analyzer), compilation (CompCert), better optimization, and so on. The main thing that hurts such work, though, is when the language and/or its standard get too complex or vague. C++ was horrid in this regard.
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. :)
Looks like the target audience for C++ mindshare is being taken away by Golang and Rust. When I think of "D" I think of nothing but "oh, yeah, they use it at Facebook". Who else uses it? How do you see Golang and Rust as competition?
D would be definitely helped by a large corporate sponsor. I think the foundation will make the language a more serious alternative for such adoption.
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.
We built all of our machine learning backend in D at AdRoll. Some examples:
- 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.
Is there a lot of C++ to go traffic ? I have not seen much along those lines. Go doesn't remotely look like a language that a C++ programmer would be interested in. Given its limitation go is an ok enough language but that's about it.
Pardon my ignorance, but do you have some kind of roadmap for D ? What features do you prioritize to develop or enhance ?
Will D focus on concurrency (Erlang's domain) first, RAD web app/service (PHP, Java, and Ruby's domain), or something else ?
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.
1. I got std.experimental.allocator accepted for inclusion. On its basis it's not difficult to build the structures and algorithms necessary for garbage collection.
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.)
I want to work on something where I can make a difference, and I think this is it. Paul Graham wrote (paraphrased from http://www.paulgraham.com/procrastination.html) one should at best work on things likely to be part of one's obituary. At this point I feel there'd be little difference if my obituary read "worked for 6 years at Facebook" vs. 7, 8 etc. But if I helped people get code written better, that's a lure I wasn't willing to not seize.
Probably not; D is not a particularly suited language for being a backend target. To be fair, neither is Javascript; it got in that position by accident.
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).
I think the lack of demand for it has been an indicator that ranges with additions are just enough. We're currently looking at adding optional primitives to ranges in a Design by Introspection manner to support bulk streaming of data.
nickpsecurity|10 years ago
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!
jordigh|10 years ago
andralex|10 years ago
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.
99decisionstr|10 years ago
- 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.
srean|10 years ago
p0nce|10 years ago
http://wiki.dlang.org/Current_D_Use
And many more companies not in that list.
rezaprima|10 years ago
andralex|10 years ago
(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.
thepumpkin1979|10 years ago
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?
andralex|10 years ago
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.)
alessioalex|10 years ago
andralex|10 years ago
twsted|10 years ago
andralex|10 years ago
crudbug|10 years ago
Do you vision D becoming a transpiler platform, similar to JavaScript land where languages target D source ?
x-lang => D => ldc => binary
andralex|10 years ago
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).
umanwizard|10 years ago
On a serious note... what do you think you will miss the most about Facebook?
andralex|10 years ago
jeremiep|10 years ago
andralex|10 years ago
bionsuba|10 years ago
unknown|10 years ago
[deleted]