Facebook is using D in production starting today

http://forum.dlang.org/thread/l37h5s$2gd8$1@digitalmars.com

by chmike • 13 years ago

365 232 13 years ago

forum.dlang.org

k__3• 13 years ago

I'm really interested why D doesn't get much love from C/C++ devs.

arte2k2• 13 years ago

garbage collector

k__3• 13 years ago

so the GC isn't optional in D?

qznc• 13 years ago

The D community has not found any good alternative yet. The wiki contains a summary: http://wiki.dlang.org/Versus_the_garbage_collector

speeder• 13 years ago

Making history short: because the first time it took off it ended having two incompatible "standard" libraries that were so competitive that even bad blood happened.

albertzeyer2• 13 years ago

I was mostly not interested by it because the reference implementation is not open source.

I checked, to get the facts straight: DMD is the reference implementation. The frontend is under GPL but the backend (optimizer and codegen) is not. The source code is available but you are not allowed to redistribute it.

https://github.com/D-Programming-Language/dmd/blob/master/sr...

(I wonder if you are allowed to fork it on GitHub.)

samuell• 13 years ago

Yeah, but there are the GDC [1] and LDC [2] implementations, which AFAIK uses their respective (open source) backends, so that should really not be a problem IMO ...

[1] http://gdcgnu.sourceforge.net/ [2] https://github.com/ldc-developers/ldc

(In my tests, they are also mostly the fastest ones, especially LDC ... see for example my comparisons in http://saml.rilspace.org/moar-languagez-gc-content-in-python... ... D with LDC is among the top contenders, together with various optimized C versions ...)

kybernetyk2• 13 years ago

I'm a C++ dev. For me it's:

- C++11 is good enough (and a little better than that)

- The eco system. Yes, I can use C libs from dlang but managing extra bridges/headers is too much overhead if the alternative is just to throw them into my C++ project and use them without writing any glue code.

- The garbage collector. (RAII fan here)

- Tooling. Are there any good dlang IDEs with mature refactoring support and code completion?

For the tasks I'm using C++ for, C++11 is more than sufficient. For more abstract/high level stuff where I don't particularly care about top performance/memory layout I don't need another C++ contender but can use higher level languages/scripting languages.

D would look more tempting if there was no C++11 but for now for me I'm perfectly happy with C++.

k__3• 13 years ago

sorry, I killed your 1337 karma.

alecbenzer• 13 years ago

What exactly is the argument for garbage collection over RAII-style freeing? Even in garbage-collected languages, you still need to do things like close file objects; the runtime doesn't do so automatically when it detects that there are no stack references to the file. Same goes for unlocking mutexes, or any of the other things that RAII tends to address.

Is it just that maintaining ownership semantics for heap memory tends to be more complicated than doing the same for file objects (much more rarely shared, I'd guess) or mutexes (not sure if "sharing" is even sensibly defined here).

p0nce3• 13 years ago

I'm a C++ dev too. Why I'm interested in D:

- Sensible, pragmatic design decisions.

- dub + VisualD makes building code, managing dependencies and debugging painless for me.

- being part of building the ecosystem is fun

- I'm not comfortable with the high cost of developing in C++ (even with last revision) and never chose to use it in the first place. C++ is basically forced on me since years.

- I feel like I can be more productive and write higher quality programs when using D. I can use RAII in D like I would in C++.

- I feel like Go and Rust do not address C++ shortcomings while introducing problems of their own.

- D programs are short. I don't need nor want IDE refactorings.

eco5• 13 years ago

C++11 borrowed a few good ideas from D and other languages so that certainly helped close the gap between D and C++ but D is still significantly nicer to work in than C++ (which is what I spend all day at work writing).

You can use RAII all you want in D. The D standard library uses it for things like Files, containers, and smart pointers. I feel like Garbage Collectors have become something of a bogeyman for native languages. There is a lot of value a garbage collector can add. In D it's rarely hard to switch to managing your own memory if your profiler shows the garbage collector taking up more time than you'd like. For most programs avoiding the garbage collector is a premature optimization though.

For IDEs you have: - Mono-D http://mono-d.alexanderbothe.com/ - VisualD (should be included with Windows DMD in the next release) https://github.com/D-Programming-Language/visuald - Code completion for a variety of editors including vim, emacs, SublimeText2 , Textadept, and zeus. DCD https://github.com/Hackerpilot/DCD

jussij• 13 years ago

- Tooling. Are there any good dlang IDEs with ... code completion?

The DCD utiltiy can drive the code completion for a bunch of editors/IDEs.

https://github.com/Hackerpilot/DCD

It works well.

Keyframe5• 13 years ago

I kind of bet hard on D, and I know people that bet even more. Last time I used it was 4 years ago.

I was using the other standard library (yeah, there were two, kind of), there were bugs which weren't resolved for years, there were issues with people camping on both sides of standard libraries, there was development stagnation because D2 was being pushed hard... but it all boils down to preference.

D1 (with Tango) to me was like a really really good blend of C with classes and modern stuff in it (mixins for example). I was happy with it, but then D2 started to emerge which was more templatey than I was comfortable with. I have accepted, long ago, that I am a C programmer, not C++, by heart. Ultimately following factors threw me away from D altogether:

- my code isn't an island, I leverage a lot of libraries, and for each and every one I had to use I had to either make my own bindings or rely on somewhat unstable other people's bindings. I accepted the reality of it, but it wasn't something I wanted to waste my time on.

- D2 - it just didn't feel the same

- Lack of tools. DMD compiler, while somewhat working, was a lackluster (to be polite) compared to what I was used to in C world. There was a GDC frontend for gcc which, at the time, wasn't actively developed, there was an attempt to make a LLVM thing.. but if you wanted to work with D, at that time, you pretty much had to use DMD

- several bugs which were ignored in core development which were uncomfortable for my use. I didn't have the expertise at the time to help with resolving that. Coincidentally just yesterday I received an update from bug tracker that bug I reported four years ago is still in.

- Development of D pretty much relied on one man alone

- out of frustration and a tight deadline, I developed something in C at that time and came to a realization that "it just works". I was able to concentrate on my task at hand instead of tackling various gotchas and doing extra amount of work that I had to with bindings etc.

D is more than 10 years old. Honestly, I think it has good ideas, I really liked the approach of D1, but I think it will never catch on en masse.

steveklabnik6• 13 years ago

My friends and I implemented an operating system in D back in college, and I just want to say that I agree entirely with this post. It's mostly why I went into Ruby instead of staying in D, and why I'm doing Rust now instead of D today.

That said, D has a lot of promise, and a lot of these issues have been worked out, but I feel like there are many people like you and I...

pjmlp16• 13 years ago

D is more than 10 years old. Honestly, I think it has good ideas, I really liked the approach of D1, but I think it will never catch on en masse.

History proves that the only system programming languages that succeed in the industry, have been at a given moment adopted by OS vendors as their main language.

It hasn't happened so far to D, but it might still happen.

eco5• 13 years ago

A few updates on the current state of things today.

The Tango/Phobos split has been resolved for awhile. You can now use Phobos, Tango, or both in the same D2 program.

The number of libraries and bindings is growing rapidly. There is the new dub package manager that makes it easy to include dependencies < http://code.dlang.org/ > and Deimos which is a collection of C library bindings < https://github.com/D-Programming-Deimos/ >.

GDC and LDC are both actively developed and kept up to date with the state of DMD.

It used to be you'd usually hit a bug while working on something in D but the community is really starting to notice they aren't hitting many bugs these days (especially over the last year or so). < http://dlang.org/bugstats.php >

Everything is up on Github now < https://github.com/D-Programming-Language > and Walter is just one of 21 committers. Github says dmd has 72 contributors and Phobos has 116.

If you don't like D2's template approach though you probably still won't be happy with it even with almost everything being better. Personally I love the power it gives you without sacrificing speed.

mratzloff6• 13 years ago

An interesting comment from the mailing list:

"Aside from speaking whether 5112 lines of code is really a good sign, there is separate issue regarding quality. When you will look at claim that some language (lets take for example C# or Java) "supports feature X", that really means that the feature is supported. In D this for sure means that the feature is either broken or misdesigned (shared libraries, routine code breakages, obsolete ms32 object format, AA arrays, shared, const postblits, odd template crosstalk bugs, type system holes, segfaulting lambdas, unstable stdlib, absent of third-party libraries). Untill this stuff is fixed this is a huge barrier irrespective of whether D is used in Facebook or not."

scott_s• 13 years ago

I think that D2 is really interesting. But I think it doesn't get as much traction because it was an improvement over C++03, but there was no fundamental change in how one developed. I think people switch languages when there's a huge change in how they develop programs - such as a new abstraction that opens up a new programming model. Many, smaller improvements don't seem to add up quite the same way.

Now, I'm less clear on how D2 compares to C++11. Certainly some of the smaller improvements matter less, as C++11 has them.

sol16842• 13 years ago

My feeling is that you really have to try it out for some time to see why it really makes a difference* . And, although C++11 indeed has caught up in some areas, there are in fact many smaller and some larger things that still do make a big difference in practice. But in general the fact that it's not just one or maybe a few primary features indeed probably makes it more difficult to judge the actual benefits from the outside.

The drawbacks today are in my eyes mostly the relatively minimal support for non-PC platforms and that a number of language features are not yet completely finished. But if the main target are x86 based systems and the use of cutting edge features is not the primary concern, D2 is a great development tool today.

* I can only really talk about my experiences going from C++ -> D, but it was a long process where my way of designing systems and solving problems was gradually altered in many areas - much to the better. And the immediate reward of course is the extreme gain in productivity due to concise syntax, fast compilation times and, last but not least, the lack of a need for header files.

he_the_great8• 13 years ago

Much of the initial design come from improving the language grammar and syntax. That limited improvement didn't last long, but it was an initial motivator (Walter being a compiler writer and C++ being horrible language to parse).

The D community has greatly pushed D away from this initial improvement. In C++ there is a separation of the developer tools and the library writer tools. I think that separation still exists in D, but it is in an area even library writers don't/can't reach for in C++.

Ultimately D doesn't force a fundamental change, but as one learns to use the language, the result is a fundamental change.

d0m2• 13 years ago

I knew when I was a C++ dev that any "other languages" was just not serious. Lots of friends who are master in C++ call everything else than C and C++ "scripting languages". I was in that closed-mind ecosystem of C++ elitist but then, luckily, I learned about Python and it caught my interest.. and then from there I've learned Lisp, Ruby, Javascript, etc etc. And I haven't touched C++ after that.

Note that I live in a startup environment all the time and the time and cost to develop in C++ is just too damn high for me. Also, the verbosity and its philosophy kills me.

What was it?

    std::map<int, std::vector<int>> whatever = new std::map<int, std::vector<int>>();

Why not

   d = {}

dleimbach• 13 years ago

Why not: using namespace std; map<int, vector<int>> whatever;

It's a lot shorter, actually correct, and it's totally cool to import whole namespaces in a .cpp implementation file where you're likely to actually declare something like that.

If you're going to critique the language you should try to learn it first.

subb• 13 years ago

Well to be honest,

  d = {}

is absolutely not equivalent to a map of int to a vector of ints. Sure in javascript, you can indeed use an object as a map, but you are lacking the type safety that the C++ version provide and all the nice API. Also, in C++11, you can shorten it with auto :

  auto whatever = new std::map<int, std::vector<int>>();

and to be fair with the js, if you want it as short as possible, you could use a using namespace statement for std (although not really recommended) :

  auto whatever = new map<int, vector<int>>();

or maybe not use new :

  map<int, vector<int>> whatever;

I don't think it's that bad. But sure, any dynamic language will be less verbose that a static language because, well, you are removing information...

zokier2• 13 years ago

C++11 brought type inference so these days it would be either

    auto whatever = new std::map<int, std::vector<int>>();

    std::map<int, std::vector<int>> whatever;

depending on if you want heap or stack allocated variable, stack allocation usually being preferred as the default solution (and thus being the tersest form).

But lets look a bit deeper why C++ is more verbose in this case. One central reason is the idea that standard library should not be special/privileged in the language syntax. The upside from that is that almost all syntax sugar can be applied to user defined types. A relevant example would be uniform initializer lists in C++11, which allow you to write eg.

    std::vector<int> foo {1,2,3};

but also

    MyFunkyDatastructure bar {1,2,3};

as long as suitable constructors are defined. In comparison afaik in Python you can not define a class that can be initialized with sugared syntax.

The theme of non-privileged standard library also extends to global namespace pollution. In C++ stdlib does not get to reserve names at global namespace, which leads slightly increased verbosity (std:: -prefixes or using-statements).

So when you ask why you cant make a map/dict in C++ with just 'd = {}', know that there are actually good reasons for (some/most) of the verbosity. The tradeoffs might make it less suitable in your usecases, but there is no absolute/general superiority in either way.

cldr4• 13 years ago

This isn't really a fair criticism because:

1. You picked probably the most verbose way to do it.

2. It's not valid C++ because you're assigning a pointer to a value.

3. Idiomatic C++ doesn't use `new` explicitly anyway

4. The `d = {}` of Python is not really equivalent.

My feeling is that python gains brevity in exchange for putting a heavier mental load on the programmer, which is manageable for small programs but becomes unwieldy for larger ones.

WalterBright9• 13 years ago

In D it would be:

   int[int] whatever;

nly• 13 years ago

This works just fine:

    map<int, vector<int>> d = {{0, {1,2,3,4,5}},
                               {1, {6,7,8,9,10}}};

WalterBright9• 13 years ago

About half of D developers (according to an informal poll) come from a C/C++ background.

yarrel• 13 years ago

It's the Opera of programming languages.

telephonetemp• 13 years ago

Between D, Nimrod and Julia it looks like there's a resurgence of fun in (JIT) compiled languages.

pjmlp16• 13 years ago

All available D compilers generate native code directly, there is no JIT involved.

Sometimes I wonder how computing would look like if the default implementations of Java and C#[1] were available from the start as native compilers, instead of VM environments.

[1] Funny enough, the precursor of .NET was native and COM based, similar to what is now WinRT, more info here,

http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-co...

rbehrends10• 13 years ago

All available D compilers generate native code directly, there is no JIT involved.

I think that's why the GP has the JIT in parentheses (to account for Julia's implementation, which does use a JIT-compiler, as opposed to D and Nimrod)

Jtsummers6• 13 years ago

Sometimes I wonder how computing would look like if the default implementations of Java and C#[1] were available from the start as native compilers, instead of VM environments.

At least with Java that would defeat one of the main intents of its development. What would you think would be gained by having non-VM based implementations of these by default?

rbehrends10• 13 years ago

The crucial combination appears to be static typing + automatic memory management + imperative programming. This is a niche that has not been served well by languages outside the JVM/.NET families; and the JVM has the problem of having pretty high per-process overheads while the problem with .NET languages has always been portability/deployment outside the Windows ecosystem.

Sathi• 13 years ago

Really interested to know what other compile-to-native-code languages that they evaluated and why they chose D over other alternatives. Anyone knows if such comparison is available?

steveklabnik6• 13 years ago

Andrei is a well-known member of both the C++ and D communities; he's probably #2 after the language's creator, Walter Bright.

So I'd imagine it has something to do with said expertise.

X8FntewI• 13 years ago

There is another project at facebook which uses Haskell [1]. It's a DSL that replaces an interpreter which was written in C++. Performance was one of the reasons for replacing it, and the talk includes an comparison of the performance of the two approaches.

[1] http://skillsmatter.com/podcast/home/simon-marlow

ferd• 13 years ago

Today I committed the first 5112 lines of D code to Facebook's repository.
The project is in heavy daily use at Facebook

So, they had code under heavy use which was not under source-control?

guelo• 13 years ago

The way I read it is that he added some D code to an existing C++ project's repo.

speg• 13 years ago

It was probably in a personal or team repo.

ryanSrich• 13 years ago

I read it as the facebook repository, the live site. They'd been using it on other internal projects which I'm sure were under source-control.

asdasf2• 13 years ago

The project was in C++, in source control, and under heavy use. Now it is in D.

deepvibrations• 13 years ago

Facebook loves the D

boduh• 13 years ago

I remember having a chat with Andrei, one of D's creators, almost one year ago and saying: "If you want D to be more popular, maybe you should make an announcement about Facebook using D internally". Seems that day is here :)

progx• 13 years ago

But 1 year ago, facebook was popular than today ;-)

lclemente• 13 years ago

For anybody wondering how D compares to Go, have a look at http://stackoverflow.com/questions/3554956/d-versus-go-compa...

pjmlp16• 13 years ago

Easy,

Go is targeted for developers that can move out of C in their use cases.

D is targeted for developers that can move out of C++ in their use cases.

judk2• 13 years ago

The Go core devs have said they are targeting Python devs now who want more stability and performance for heavy applications.

asdasf2• 13 years ago

Except that the go developers explicitly stated their design goal was to replace C++ for their needs, not C. And that completely failed, and now the focus is on pulling in python devs.

axaxs• 13 years ago

I'm not sure 'targeted' would be the correct term, at least for Go. Go initially was targeting C++ devs(however ambitious and failed that attempt may have been) by offering this stripped down new language that more resembles C.

I've always much preferred C style to C++/D/Rust based mainly on readability and how small the language felt. I completely agree though that Go has given me this similar feeling - to me it really is a modern C. That said, I'm not sure how many C devs are going to like the bounds put in place by Go, or the mandatory GC.

I am, admittedly, a big fan of go also. For me, it has taken from both C and Python use cases, which I think says a lot about its versatility.

The D statement may be accurate, I've never done anything with D and only minimal brush ins with C++ - but to my untrained eyes, they seem pretty similar.

JulianMorrison• 13 years ago

How do D and Rust compare?

zokier2• 13 years ago

D is mature and actually usable, Rust is in alpha stages at best. The current outlook seems to be that they should be fairly comparable one day, but right now making such comparisons wouldn't be really fair. We don't even know yet what the final form of Rust will be like.

kibwen• 13 years ago

Rust has much less emphasis on CTFE than D, and instead has a very extreme focus on zero-cost memory safety (and, following from that, a concomitant focus on easy concurrency).

D also owes more of its ancestry to C++, while Rust takes a lot of its inspiration from the ML family of languages.

Both languages are gunning to appeal to C++ programmers, and they're both worthy in this regard depending on your use case. The C++ pie is more than big enough to let both languages thrive independently (and their underlying philosophies are different enough that I expect very little overlap between their communities).

pcwalton9• 13 years ago

I'd say the biggest differences are (a) Rust is more functional (preferring algebraic data types over OO, pattern matching, immutability by default, typeclasses over templates); (b) Rust is newer and younger; (c) Rust has safe manual memory management, enforcing memory safety even if the GC is not used. Of these, I think (c) is the most fundamental difference: it gives the language a very different feel and niche, at the cost of a learning curve.

(Disclaimer: I work on Rust, among other things.)

knodi• 13 years ago

Biggest advantage of D synchronized functions as a lang feature.

vvnraman• 13 years ago

For an excellent discussion between the philosophies that went into the design of D and how they compare to Go, visit

  https://groups.google.com/forum/#!topic/golang-nuts/8k59RgkeJ6s

The discussion between Andrei Alexandrescu (Facebook) and Ian Lance Taylor (Google) is highly intellectual, especially the part about how each language addresses concurrency.

EDIT: Removed dot at the end of the URL

swah• 13 years ago

(extra dot in the end of the URL)

mcav• 13 years ago

PSA: The best way to delimit URLs is to enclose them with angle brackets (< and >) as per < http://www.ietf.org/rfc/rfc2396.txt >.

However, like many flaws with HN's underdeveloped software, you can't actually do that on HN because the parser includes the trailing > in the URL. So your best bet here is with whitespace.

acqq2• 13 years ago

The most important Andrei's quote:

"D has resolutely exited C++'s shade because it is good at things C++ is not good at, in addition to being good at things C++ is good at. Also, Go would be tenuous to frame as a better C because it cannot do everything C does - e.g. unsafe memory access and manual memory management, which are needed in certain systems - and it interoperates poorly with C."

In short, he states that D can do unsafe memory access and manual memory management. Go can't.

javajosh• 13 years ago

Yes, if I was to learn a systems programming language, I would only pick from those that allow manual memory manipulation. Either that or the ability to trivially integrate with C functions that can do manual memory manipulation.

howeman• 13 years ago

Go can do unsafe memory access, can't it? See http://golang.org/pkg/unsafe/

_ak2• 13 years ago

Go can do unsafe memory access. Andrei has no idea what he's talking about.

derefr• 13 years ago

Sounds like D would be better-compared to Rust, then.

kisielk• 13 years ago

Note that the discussion in question dates back to 2010, before the existence of cgo. Go now has quite good C interoperability. And Go can now do unsafe memory access and manual management using the "unsafe" package.

AsymetricCom• 13 years ago

What is certain is that D's type system is expressive enough to allow libraries to reject during compilation embarrassments such as transporting pointers over the network.

How does the language do this? Doesn't that have more to do with the design of the program itself? It certainly is a interesting security idea, much more strict than sending remote procedure calls or serializing objects and sending them across the network.

smrtinsert2• 13 years ago

Facebook seems to use any language they want to at any time. I don't consider it a major endorsement that it appears in production, it just lets me know its on their radar.

If Google picked up D I would be much more interested as to why.

warmwaffles• 13 years ago

Seeing D in production is a good thing. Google picking up a language doesn't prove anything. Seeing a language in production in a high volume setting is impressive.

jmdavisProg4• 13 years ago

Having D used in production in a big company like Facebook is a big deal. No, it doesn't mean that D has taken over the programming world or anything like that, but it shows that the language is maturing and that real companies are now willing to use it in the real world - and it's a pretty major company at that.

So, this is just one step forward, but it's a big one and exciting to the folks who are fans of D - especially those who have put a lot of time and effort into it.

warmfuzzykitten• 13 years ago

Might have as much to do with the persuasive powers of Andrei Alexandrescu as the maturity of D.

utopkara2• 13 years ago

Does D have anything to do with the client-side? All this morning, the browser tab keeps crashing whenever I load facebook in chrome.

utopkara2• 13 years ago

Safari seems to load fine. I have a OSX 10.8.4 and Chrome 27.0.1453.110

WalterBright9• 13 years ago

For one example of a D program in production use, check out http://forum.dlang.org. The forum software is entirely written in D (written by Vladimir Panteleev).

(Although due to this announcement, the site is being slammed at the moment. It's a single server hosting dlang.org, not a farm.)

jkn• 13 years ago

The responsiveness of this forum is amazing. Is the client side doing some pre-fetching?

I remember finding the website disturbingly fast on my first visit. I wonder if it is just me being so used to loading delays, or if there is a point were you can be so fast that it is detrimental to the user experience. The latter doesn't sound like it makes sense so it must be of matter of getting used to it.

dscrd• 13 years ago

Well, a forum is essentially the same thing as BBSs were in the 80s but now we have computers that are several thousand times faster. I find it much more "amazing" that the other forums are so slow.

Erwin• 13 years ago

The forum sends back a simple preformatted chunk of HTML which is then inserted at a certain spot.

It does not send a complex JSON object that is then marshalled into some kind of Angular-Knockout-Backbone framework of the day where complex magic creates views, links and templating language formats objects into HTML created via DOM.

As JS in the browser speed up, all those framework find some way of using it. Sure, your 5-item TODO list app looks good...

deviltry• 13 years ago

http://forum.dlang.org/thread/l37h5s$2gd8$1@digitalmars.com

Back to the 90s URLs.

sliverstorm3• 13 years ago

It's not like modern forum URLs are all that much better.

I mean, yes, superficially this is less obtuse:

http://advrider.com/forums/showthread.php?t=801516

But the number holds no meaning to a human either way.

mattgreenrocks2• 13 years ago

Is there any caching going on, server-side?

It is ridiculously fast.

sliverstorm3• 13 years ago

I'm not kidding here, I had forgotten the internet could be that fast. Static content, I miss you...

he_the_great8• 13 years ago

There is caching of the newsgroup messages, but I don't know about the generated page.

WalterBright9• 13 years ago

The D project code is entirely on github:

https://github.com/d-programming-language

Naturally, contributors are welcome!

freyr3• 13 years ago

Apple has Objective-C, Mozilla has Rust, Google has Go, Microsoft has C#. I wonder if Facebook was feeling a little left out of the post-C++ language party?

andralex2• 13 years ago

One of these languages is not like the others.

garg• 13 years ago

None of these languages are like the others.

elnate• 13 years ago

Which?

panic• 13 years ago

Objective-C isn't exactly a "post-C++ language". The two languages showed up around the same time in the 80's and have orthogonal object models (in a very concrete sense given the existence of Objective-C++).

freyr3• 13 years ago

You're right, and Go was being touted as a modern C, not a new C++. Writing "post-C++" was a mistake.

shawn-butler• 13 years ago

Congratulations. What is the status of workable compiler and standard library on ARM?

Facebook is using D in production starting today

Related Stories