How do you use D?

Wed Aug 2 02:29:23 PDT 2017

On Fri, Jul 28, 2017 at 4:58 PM, Ali via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> While the Orgs using D page is very nice ... I hoping to hear more
> personal stories ...
>
> So
>
> How do you use D?
>

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)

>
> Did you introduce D to your work place? How? What challenges did you face?
>

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.

>
> What is you D setup at work, which compiler, which IDE?
>

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

>
> And any other fun facts you may want to share :)
>

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.

The result of that approach is phpdispatcher. So instead of starting new
process for every file request there is a D deamon (phpdispatcher) which
put file request into queue and assign them to php processes (workers).
Phpdispatcher and workers communicating through TCP, because of not
starting new php process every time, we can utilize caches (opcache...) or
JIT when HHVM is used. And we do not need to reestablish db connections
every time.

So after phpdispatche has been moved to production, we was able to go from
five machines to only one (ok we have to because of failover)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20170802/a4464341/attachment.html>