Sadly, we have given up on using D for our Linux project, despite my hopes and favorable overall impression of the D language.  I thought I would share briefly our reasons in hopes that the information is useful to those in the D community.

We are writing a distributed media publishing system that uses a relational database to store media programming schedules and other related information.  We need a language that has a library that provides easy database access (something along the lines of Perl's DBI, for example), CGI programming support, access to system-level routines, reasonable performance, YAML support, and other features.

We came to a quick conclusion that D wasn't going to work, as the DBI code proffered on dsource has apparently been abandoned and does not come close to compiling with the current dmd (1.028 or 1.029) compiler.  We had a laborious run-around trying to figure out if DBI requires Tango or Phobos, wrestled with the "bud" make-ish system, and finally gave up in disgust --- it just wasn't going to work without serious effort.

We settled on ruby, after spending a short time installing the necessary components, coding up test routines, and deciding it fit the bill.

The sad thing is that D looks very promising, but the future for it does not, I'm afraid, unless the D community can produce a coherent set of tools that are used in the real world and that can be installed without developers being burdened with trying to figure out arcane install problems, incompatibility issues, and the like.  With ruby, we had just a few easy commands to run to install DBI and it was up and running, and we have had no problems with it since.

I told our CTO that maybe in a year or two D would have a stable set of libraries and support systems in place that could be considered, but we'll be long past choosing D at that point.

I think some serious attention needs to be focused on this, rather than the minutiae of the latest cool language feature.  I have been following D for some years now, hoping it would all come together --- and I hope it does, soon --- as it feels D is being left in the dust.


Bill

== Quote from Bill Lear (rael@zopyra.com)'s article
> Sadly, we have given up on using D for our Linux project, despite my hopes and favorable overall impression of the D language.  I thought I would
share briefly our reasons in hopes that the information is useful to those in the D community.
> We are writing a distributed media publishing system that uses a relational database to store media programming schedules and other related
information.  We need a language that has a library that provides easy database access (something along the lines of Perl's DBI, for example), CGI
programming support, access to system-level routines, reasonable performance, YAML support, and other features.
> We came to a quick conclusion that D wasn't going to work, as the DBI code proffered on dsource has apparently been abandoned and does not
come close to compiling with the current dmd (1.028 or 1.029) compiler.  We had a laborious run-around trying to figure out if DBI requires Tango
or Phobos, wrestled with the "bud" make-ish system, and finally gave up in disgust --- it just wasn't going to work without serious effort.
> We settled on ruby, after spending a short time installing the necessary components, coding up test routines, and deciding it fit the bill.
> The sad thing is that D looks very promising, but the future for it does not, I'm afraid, unless the D community can produce a coherent set of tools
that are used in the real world and that can be installed without developers being burdened with trying to figure out arcane install problems,
incompatibility issues, and the like.  With ruby, we had just a few easy commands to run to install DBI and it was up and running, and we have had no
problems with it since.
> I told our CTO that maybe in a year or two D would have a stable set of libraries and support systems in place that could be considered, but we'll
be long past choosing D at that point.
> I think some serious attention needs to be focused on this, rather than the minutiae of the latest cool language feature.  I have been following D
for some years now, hoping it would all come together --- and I hope it does, soon --- as it feels D is being left in the dust.

I agree with your comment on tools and libraries in general, but D does already have a solid
install/update/build tool in DSSS/rebuild.  With it, installing supported packages is as simple
as "dsss net install blah", which I believe is roughly equivalent to ruby gems or whatever you
used there instead.  Regarding DB support, I think some branch of DDBI may actually build
with the current version of D, but you're right that it doesn't receive a lot of attention.
Unfortunately, D is still very much a language for self-starters, and the overarching focus
on newer and more features rather than building a solid base for development probably
doesn't help things either.  Overall, the trend seems to be a churn of new users rather than
a growing group of serious professionals--likely for these reasons.  That said, there are
more than a few professional developers which have found a development environment
which suits them--from my experience it tends to be DMD/Linux and Tango with either
makefiles or DSSS for building and GDB with the demangling patch for debugging.


Sean

Bill Lear wrote:
> Sadly, we have given up on using D for our Linux project, despite my hopes and favorable overall impression of the D language.  I thought I would share briefly our reasons in hopes that the information is useful to those in the D community.
> 
> We are writing a distributed media publishing system that uses a relational database to store media programming schedules and other related information.  We need a language that has a library that provides easy database access (something along the lines of Perl's DBI, for example), CGI programming support, access to system-level routines, reasonable performance, YAML support, and other features.
> 
> We came to a quick conclusion that D wasn't going to work, as the DBI code proffered on dsource has apparently been abandoned and does not come close to compiling with the current dmd (1.028 or 1.029) compiler.  We had a laborious run-around trying to figure out if DBI requires Tango or Phobos, wrestled with the "bud" make-ish system, and finally gave up in disgust --- it just wasn't going to work without serious effort.

Did you ask on the newsgroup or the ddbi forum?  These questions are easily answered by almost anyone familiar with how things work D world.  The last commit in ddbi svn[1] was two weeks ago, so it's reasonable to assume that ddbi works with dmd 1.028, which is the latest stable compiler version[2].  From reading the log, it's also clear that Tango is supported, and Phobos support has been removed.

And the version in svn also seems to support building with dsss, which I would recommend over bud for linux use.  Of course, this assumes that you're prepared to use an unreleased, work-in-progress version of the library...

That said, I agree that the state of D tools and libraries is not what it should have been.  Most projects are run by a single person, some work well on one platform but not others, etc.  Some projects are of good quality though, the best example probably being Tango.  Another problem is that dsource doesn't give you a way to distinguish the mature, actively maintained projects from the ones that are abandoned or not quite ready yet.

[1] http://www.dsource.org/projects/ddbi/log/
[2] http://www.digitalmars.com/d/download.html

Bill Lear:
> We settled on ruby,

Python/Ruby and D are in two quite different classes of languages. Usually where you use one of them you don't want to use the other. So to me it's strange that seeing D unfit, you have used Ruby.


> I think some serious attention needs to be focused on this, rather than the minutiae of the latest cool language feature.

I think D is younger and it's used by quite less people, so you have not even 1/100 of the modules you can find in the Python world (there are some modules available thanks to the easy binding to C libs).
I think D language focuses on language features because it's developing still, because it's looking for its place in the world still. I think that if D succeeds in the parallel programming it may have a chance to become widely used (at the moment C#, Java, Erlang, Haskell and Fortress look like the few languages able to use the future multi core CPUs. Among them something like Haskell looks one of the more promising, despite being a bit too much complex to become an industry standard language).

Bye,
bearophile

bearophile schrieb:
> Bill Lear:
>> We settled on ruby,
> 
> Python/Ruby and D are in two quite different classes of languages. Usually where you use one of them you don't want to use the other. So to me it's strange that seeing D unfit, you have used Ruby.

and disqualify a "language" because of missing working database libs - strange base decision ...

Bill Lear wrote:

> We came to a quick conclusion that D wasn't going to work, as the DBI code proffered on dsource has apparently been abandoned and does not come close to compiling with the current dmd (1.028 or 1.029) compiler.  We had a laborious run-around trying to figure out if DBI requires Tango or Phobos, wrestled with the "bud" make-ish system, and finally gave up in disgust
> --- it just wasn't going to work without serious effort.

I suppose you already made your decision, but as mentioned, a question in the forum would have given you more information on this. DDBI has moved very slowly over the last 18 months, but is being picked up again now, and will hopefully have a new release soonish. DDBI in trunk is now Tango only, but should work with DMD 1.028/29.

> We settled on ruby, after spending a short time installing the necessary components, coding up test routines, and deciding it fit the bill.
> 
> The sad thing is that D looks very promising, but the future for it does not, I'm afraid, unless the D community can produce a coherent set of tools that are used in the real world and that can be installed without developers being burdened with trying to figure out arcane install problems, incompatibility issues, and the like.  With ruby, we had just a few easy commands to run to install DBI and it was up and running, and we have had no problems with it since.

I won't critize your company for making the choice it did, as it obviosly will need to earn money, but I don't see how you can expect the community to do what you want it to do with getting involved yourself. At the very least the community needs to know what you as a potential user needs from the project, so that tasks can be prioritized. Most of D still being open source, one cannot normally expect anything to happen without contributing self at some level. Posting your summary here may or may not help, but going to the specific project will always be best. Not all in the D community follow these newsgroups regularly.

An example of how I think a company could get involved to help D move on, is
how the work I will do on DDBI is sponsored (part time) by a company that
plans to use D commerically. In light of that, now may be the right time to
get involved in that particular project.

> I think some serious attention needs to be focused on this, rather than the minutiae of the latest cool language feature.  I have been following D for some years now, hoping it would all come together --- and I hope it does, soon --- as it feels D is being left in the dust.

Tools situation may have stagnated, but I'm not sure you have followed Tango too closely :)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Lars Ivar Igesund Wrote:

> I suppose you already made your decision, but as mentioned, a question in the forum would have given you more information on this. DDBI has moved very slowly over the last 18 months, but is being picked up again now, and will hopefully have a new release soonish. DDBI in trunk is now Tango only, but should work with DMD 1.028/29.

> I won't critize your company for making the choice it did, as it obviosly will need to earn money, but I don't see how you can expect the community to do what you want it to do with getting involved yourself.

He has just done so?

>At the very
> least the community needs to know what you as a potential user needs from the project, so that tasks can be prioritized. Most of D still being open source, one cannot normally expect anything to happen without contributing self at some level. Posting your summary here may or may not help, but going to the specific project will always be best. Not all in the D community follow these newsgroups regularly.

He has just told you !
> 
> An example of how I think a company could get involved to help D move on, is how the work I will do on DDBI is sponsored (part time) by a company that plans to use D commerically. In light of that, now may be the right time to get involved in that particular project.
>

Give me some money and I will help you !


> > I think some serious attention needs to be focused on this, rather than the minutiae of the latest cool language feature.  I have been following D for some years now, hoping it would all come together --- and I hope it does, soon --- as it feels D is being left in the dust.
> 
> Tools situation may have stagnated, but I'm not sure you have followed Tango too closely :)
> 
> -- 
> Lars Ivar Igesund
> blog at http://larsivi.net
> DSource, #d.tango & #D: larsivi
> Dancing the Tango

This is a typical of a lot of what like to call themselves "The D Community" They are more interested in attacking the messenger.

Torhu says as well that DBI should work with 1.029 etc etc but has he checked? Has Lars checked?  Obviously Bill checked and it didn't .

 If you aren't sure why post?

From what I have seen it is a mess but listening to people like this and DOING SOMETHING ABOUT IT would be a good start . Don't start on me ! I am still here and contributing with posts wherever I see stupidity, or where somethiong does not work properly, but I am no master programmer so I can't fix it.

Bill Lear wrote:

> We are writing a distributed media publishing system that uses a relational database to store media programming schedules and other related information.  

Out of curiosity - did you guys consider Erlang? I'd be curious to hear why Ruby seemed more suited.

Ty Tower Wrote:

> Lars Ivar Igesund Wrote:
> 
> > I suppose you already made your decision, but as mentioned, a question in the forum would have given you more information on this. DDBI has moved very slowly over the last 18 months, but is being picked up again now, and will hopefully have a new release soonish. DDBI in trunk is now Tango only, but should work with DMD 1.028/29.
> 
> > I won't critize your company for making the choice it did, as it obviosly will need to earn money, but I don't see how you can expect the community to do what you want it to do with getting involved yourself.
> 
> He has just done so?

He criticized the decision, but everyone's entitled to their own opinion.

Ruby is probably a better choice for a product they need to make money off of.  Ruby has a bigger community, it's older, and more stable.  It has better, more mature libraries, and setting it up is far easier than it is with D.

In addition, he said that database support was lacking in D.  I have to second that.  DDBI is really the only viable tool that I can find, and on its dsource page it says to not use it because it's "going to change."  I can totally understand the confusion on that point.  The Tango confusion, not so much.

Ruby, on the other hand, is an SQL embedded language.  Doing things with databases is going to be trivially easy with Ruby.

Furthermore, Ruby has some excellent web-facing support with Ruby on Rails.  If they wanted to add some web-facing support to their product, they could use the exact same source code and the exact same libraries for the web application that they use for the rest of the whole mess.  Ruby can also make use of C extensions, which will doubtlessly become useful for managing - or even mangling - videos (since Ruby itself isn't all that fast in comparison).  That will also allow them to tap into an existing, impressive set of C libraries for video stuff, which they won't have to code.

It's probably a better choice to go with Ruby -- for **them**.

> > > I think some serious attention needs to be focused on this, rather than the minutiae of the latest cool language feature.  I have been following D for some years now, hoping it would all come together --- and I hope it does, soon --- as it feels D is being left in the dust.
> > 
> > Tools situation may have stagnated, but I'm not sure you have followed Tango too closely :)
> > 
> This is a typical of a lot of what like to call themselves "The D Community" They are more interested in attacking the messenger.
> 
> Torhu says as well that DBI should work with 1.029 etc etc but has he checked? Has Lars checked?  Obviously Bill checked and it didn't .
> 
>  If you aren't sure why post?

I found that it compiled into a library with DMD 1.030, though I haven't verified to see if it works beyond that point.  Neither 1.029 or 1.030 are stable, so they really don't count much.

> From what I have seen it is a mess but listening to people like this and DOING SOMETHING ABOUT IT would be a good start . Don't start on me ! I am still here and contributing with posts wherever I see stupidity, or where somethiong does not work properly, but I am no master programmer so I can't fix it.

The obvious solution is to write more code.

A very good friend of mine and an absolutely fantastic programmer once told me some great advice: stop making stupid UML diagrams and write code!

bearophile wrote:
> Python/Ruby and D are in two quite different classes of languages. Usually where you use one of them you don't want to use the other.

Not necessarily. D is still useful for quick scripting. More to the point, webapps are often written with Ruby/Python/Perl backends which could be swapped out for one written in a native language to help performance.