Mainly at work, for lot of things.

    autoloader - tool for parsing all php files at our main project and generate file for autoloading php files

    esatd - deamon for controling and communicating with our servers (reading logs, do releases of our products, controlling of availability...)

    cronchecker - tool for managing and watchdoging our crons

    dbsync - db tool for syncing and moving our databases around different servers

    testdbsync - dbtool sync our production databases to our test databases

    phpdispatcher - deamon for managing php workers processes

    camera-media-server - reverse engineering server for communicating with some chinese DVR units

    esat-map-engine - tool for (reverse) geocoding, and generating map tiles

    mapfactorbridge - REST API over MapFactor OCX(windows only, we used it under wine), so it is possible to use it on many machines through network and on any platform

    MapfactorWrapper - demon for calculating shortest path from one city(or any place) to another using mapfactor ocx api (mapfactorbridge)

 

Yes in 2012, only problem was with the ecosystem. There has been no good IDE and too few libraries, but because of posibility to use C libraries it was not a problem.

But good IDE is still a problem for some of us.

 

DMD for development, LDC or GDC for release binaries, VSCode with webfreak dlang plugin (2017-now), monodevelop (2013-2016)

 

In 2012 at work we have been looking for a way how to improve performance of our data processing machines. These machines process lots of files (binary,xml,text...).

These files comes from GPS units and has been (still are) process by PHP scripts (called parsers).

So we decided to rewrite those PHP scripts to something faster (PHP has been quite slow theses days, now with PHP7 and HHVM it is little better). 

So I was responsible for finding another language (the right one) in which we wil rewrite those scripts. OK easy task, so I selected few languages I know to select from.

Java, C/C++, Go, Python. But quite fast I realized none of these languages fulfil our requirements.

Our requirements was:

OOP (Go is out)

GC (C++ is out, ok there is a way to use gc in c++, but i have never done that before)

Fast startup (Java is out because of VM)

Syntax similar to PHP as much as posible (python is out)

Fast compilation (C++ is out again)

Our best choice has been Java, but it would mean change architecture (instead of executing own process for every file, we will need to process them in one process with multiple threads or something similar), which has been no go these days.

So I have been looking for some another language. And for some reason I have remembered that there has been some language, which I have try at my high school days (2004-2008).  Unfortunately I did not remembred the name. So I start typing into google things I have remembred about this language. And after some time I have found  it (D language). So I looked at D closer and was very satisfied. My first  thoughts was something like "This is it".

So I introduce D to my coworkers. At first there has been two camps. One camp has the same feeling about D as me, the other ones was OK with D as a language, but has been afraid of ecosystem. So I have started to showing them how easily I can use C ecosystem so they do not have to be worried. So after some time D has been chosen and we started to rewrite our parsers into D.

First results (just data processing) has been promising (new parsers has been 10 to 100 times faster than the old(PHP) ones with smaller system requirments), but after integrating other parts (database, filesystem...) we have realized there is an almost no gain in the end. Data processing was only small part of parsers, so database and filesystem interaction has been the problem. So we start to improve this part of parsers. In the end we was 5 times faster than the old parsers, but we could just do all these changes to old parsers too. So we end up with rewriting our D parsers back to PHP, because D parsers has been to far from being complete.

But it was not complete failure. Because of this we have improved our parsers and D has established in our ecosystem. After few years parsers performance became problem again (even with PHP 7). So we need to improve them again. We have already known that rewriting it to something faster would not help. So I have try another approach.