Hello,

Here is some feedback from using D, vibe.d, and small parts of arsd
to write micro-services to feed 3D products at my company [1][2][3].

Overall great: expressive code, fun and reliable development
(esp. using CTFE), excellent runtime performance (critical for 3D),
and last but not least, very helpful community.

I put further below a few critics, mostly details where something
could be improved, from my point of view.

Most of our code is closed-source, so for now I can only contribute
a short, disparate collection of tools [4]. I hope to be able at
some point of time to contribute more, in whatever form that may be.

Thanks and best regards,
Guillaume Lathoud

.

Where I'd see room for improvement:

(a) When beginning coding, esp. when using rdmd, it was not obvious
to me how to get a meaningful stacktrace. For example, when I open
the rdmd page [5], I have to go down to the options, open the link
to the dmd page [6], then scroll down and search through the options
until I find the -g* ones. Probably obvious to seasoned users, but
not necessarily to beginners. A mention on the rdmd page could help.

(b) Line numbers in errors in string mixins: two line numbers are
given corresponding to the beginning line and the actual error line,
which is already quite helpful. Often I also need the difference
between the two numbers, to find the corresponding line of the mixin
source code. That would be a great addition, at least for me.

(c) I don't need to reproduce here the usual rant about the current
compilation speed of a few particular libraries like std.regex, when
used. Ironically, I found that cost a lot smaller than
catastrophical slowdowns of the compilation due to my very own abuse
of the CTFE, which was a bit humbling... and now corrected.

In my experience (a) (b) (c) really are small details, compared to
the positive sides of using D.

[1] 3D video in summer: https://www.youtube.com/watch?v=R2aZHKa-iuY
[2] 3D video in winter: https://www.youtube.com/watch?v=qIpnH_NSfS8
[3] Company's main website: https://www.outdooractive.com
[4] https://github.com/glathoud/d_glat
[5] https://dlang.org/rdmd.html
[6] https://dlang.org/dmd-linux.html

On Thursday, 28 March 2019 at 06:36:11 UTC, Guillaume Lathoud wrote:
> Hello,
>
> Here is some feedback from using D, vibe.d, and small parts of arsd
> to write micro-services to feed 3D products at my company [1][2][3].
>
> [...]

Thanks a lot for this insights and your contributions. For me it would be interesting to hear whether there are any reasons to not use Dub. (The debug option is on by default here).

Kind regards
Andre

On Thursday, 28 March 2019 at 11:11:05 UTC, Andre Pany wrote:
>> [...]
>
> Thanks a lot for this insights and your contributions. For me it would be interesting to hear whether there are any reasons to not use Dub. (The debug option is on by default here).
>
> Kind regards
> Andre

You're welcome. I forgot to mention that, yes, we've been using dub in the production projects. To summarize:
 * when doing the very first steps to learn the language, with rdmd, it is not obvious that flags have to be added to get a better stacktrace on errors. It plays also a role when using rdmd to run unit tests and debug them if they fail.
 * when doing the very first steps using Dub, it was not obvious to me that -debug is the default.

Of course, once these two facts are known, the issues disappears - but having just a few helping comments about this, even just one sentence, targeted to beginners, might help others.

Best regards,
Guillaume

On Thursday, 28 March 2019 at 06:36:11 UTC, Guillaume Lathoud wrote:
> ...
> Here is some feedback from using D, vibe.d, and small parts of arsd
> to write micro-services to feed 3D products at my company...

It's nice to see some stories/feedback for D code in production. I usually write some tools in D to help with my work, where the main language there is C#.

> Overall great: expressive code, fun and reliable development
> (esp. using CTFE), excellent runtime performance (critical for 3D)...

Could you elaborate about this 3D part? Because in many cases you fetch the data and GPU will handle the rendering etc. So I don't think the language itself should be a bottleneck.

Matheus.

On Thu, Mar 28, 2019 at 06:36:11AM +0000, Guillaume Lathoud via Digitalmars-d wrote:
> and small parts of arsd

What parts did you use? (We probably talked before, but I don't remember
right now.)

On Thursday, 28 March 2019 at 14:38:46 UTC, Matheus wrote:
> Could you elaborate about this 3D part? Because in many cases you fetch the data and GPU will handle the rendering etc. So I don't think the language itself should be a bottleneck.

The original data was a rectangular raster of elevation values, which had to be smartly reduced to a few triangles wherever available, and accompanied with some meta-data, both parts highly useful for the final device to render motion in a 3D world in a performant manner. Otherwise, simply feeding the raster to the final device led to a barely acceptable user experience.

Since this precomputation should run in any part of the world, D was critical to quickly compute the reduced-and-expanded vector data over the whole world down to an acceptable level AND be able to quickly compute the rest on-demand. In short: performance!

I chose D because I had already had impressive experiences in terms of performance in the past.

Best regards,
Guillaume

On Thursday, 28 March 2019 at 14:43:37 UTC, destructionator wrote:
> On Thu, Mar 28, 2019 at 06:36:11AM +0000, Guillaume Lathoud via Digitalmars-d wrote:
>> and small parts of arsd
>
> What parts did you use? (We probably talked before, but I don't remember
> right now.)

At the moment we use color.d and png.d to manipulate some satellite images. Everything working very fine, thanks for the code!

Best regards,
Guillaume