Walter Bright Wrote: > This is very interesting to hear. > > If there is anything I can do to help any adoption of D at Google, > please let me know.
Thanks, I will. Off hand the only thing I can think of is "finish D2 and commit to it being supported/stable for a few years" :-) I realize there are already interesting ideas kicking around for D3 but if they can be integrated in a backwards compatible way .... Anyway, the amount of work required to integrate a new general purpose language at Google is pretty big, it'd probably be several 20% projects worth of work over a period of about half a year. For illustration here are a few of the tasks that'd be either required or strongly wanted (some stuff is still confidential and I can't mention). I'm not suggesting this list is typical of large companies but it might prove interesting anyway. - Integration of a compiler with our in-house build system (proprietary). If it's GCC based that's better. - Some kind of standard unit testing framework that the testing infrastructure knows how to drive. If it works similar to the ones we use for C++ that's better: http://code.google.com/p/googletest/ http://code.google.com/p/googlemock/ - Protocol buffer support http://code.google.com/p/protobuf/ - google style command line flags implementation: http://code.google.com/p/google-gflags/ - Style guide: It's an open question whether this would purely be how code looks or like the C++ guide also restrict some features. D is a very feature rich language even compared to C++. I'm not sure if expecting developers and reviewers to be familiar with *every* feature is realistic or worth the cost. http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml - The aforementioned readability reviews, reviewers need to be found (they are volunteers) and trained, Perforce needs to be taught about the new filetypes: http://1-800-magic.blogspot.com/2008/01/after-8-months-no-longer-noogler.html - Training materials so engineers who haven't encountered D before can get up to speed quickly, at least to the level where they can do code reviews even if they aren't a master of all the features. - By default emacs/vim at google import customizations for our environment, integrating a d-mode with that would be nice. - Bindings to the core libraries for accessing things like GFS/BigTable and doing RPCs: optional but the utility of any language that can't use them is limited. C++ compatibility would certainly make this easier but SWIG integration would make it even easier still, as we already have SWIG set up for Python. Figuring out an easy way to integrate the garbage collected world with the manually managed world is also a trick. I presume the Python bindings already figured this out but it'd obviously be nice if the bindings could be as thin as possible. Of all those, the last would be the most work. The google "standard library" is a huge collection of robust and well written code - everything from well known stuff like BigTable down to custom threading and malloc libraries. The nice things D brings to the table can't compensate for the loss of that codebase. I haven't tried binding stuff into D, although given that it's got some C/C++ compatibility it's way ahead of Python and Java already.
