Why aren't you using D at work?

[w0rp via Digitalmars-d]

I'll add in my story.

My job is working as part of a team on a small-to-medium scale 
web application. Our application layer is implemented in Python 
and Django. This would be the place where D would fit in the 
most. So I think this comes down to an argument of why we would 
choose to use Python and Django instead of D and vibe.d. I can 
think of the following reasons.

1. Obviously, we have already written everything in Python, so we 
would have to justify the cost of moving to D quite strongly.
2. Django offers more features useful for developing a web 
application than vibe.d, like an excellent API for building SQL 
queries with an ORM. The South or first party migrations (ALTER 
TABLE, etc.) APIs in 1.7 are brilliant, and after you use them, 
you can't live without them. These APIs work well and save time.
3. Python has greater mind share, so switching to D would incur 
the cost of training everyone to use D. It's hard enough finding 
a decent Python programmer.
4. The third party libraries implement many things we need to 
use, like SSO support.
5. We use Celery a lot for task management, so to use D we would 
need similar software D could work with.
6. I must mention that the execution model makes the sites easier 
to develop. When you change a function and save the file, Django 
reloads the module, (when it doesn't break) so you can test the 
effects of your modification instantly.


I can't compare on testing web pages in Django against vibe.d, as 
I've never tried it on vibe.d. I will add that Django allows you 
to send fake HTTP requests to your 'views' for web pages, so you 
can write automated tests for the pages on your site. This level 
of testing does wonders for code quality, and catches website 
regressions quickly.

I hope that in the future some clever person could implement an 
API for generating SQL queries in an RDBMS indepent way for D, 
with support for creating ALTER TABLE statements automatically. 
I've thought about it, and it wouldn't even necessarily need to 
be ORM, as something like the "data mapper" pattern could work. 
Just something which lets you build queries for objects you can 
serialise, and generate queries needed to update the tables for 
the objects when you change them.