I've been fortunate enough to convince management to let me write
D code. Up until now it's been mostly tools, but I recently
rewrote some of our functionality in D and somehow my team was
convinced that we can use the D server to test our client code,
with them willing to learn D and modify my code.
Atila
On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
I've been using D in all my personal projects for years now,
but I
lament coding C at work every day, and I pine for salvation.
I seem to have reasonable influence in my workplaces, and I
suspect I
could have my workplace adopt D, but when considering the
notion with
other staff, we always seem to encounter hard blockers to
migration
that stop us in our tracks.
I expect I'm not alone. Please share the absolute blockers
preventing
you from adopting D in your offices. I wonder if there will be
common
themes emerge?
Every place I work has a slightly different set of blockers. I
have
potential opportunity to involve D in my workplace in multiple
key
areas, but blockers exist along every path, as follows:
Web:
* We need NaCl + Emscripten support in LDC. Doesn't need to be
comprehensive, just successfully compile code. Emscripten alone
may
satisfy; probably a much easier target.
Core engine/applications:
* Android+iOS. (plus also the web targets above in the future)
Desktop utilities:
* Workable Qt bindings.
General friction/resistance from colleagues:
* Forceinline. We have SO MUCH CODE that simply must inline.
It's
non-negotiable, nobody is comfortable to write ranges or
properties
without forceinline. I can't sell "just trust that the
optimiser might
maybe hopefully do what you want" to low-level engineers, I've
been
trying for years.
* Debugging experience; it's come a long way, but there's still
significant usability inhibitors.
I often wonder if others share the importance of mobile
cross-compilers?
They seem to be getting lots of love recently, which is very
exciting!
I'd like to encourage those working on the Android/iOS
toolchains to
publish regular binary builds of the toolchains so we with
little
allocated working time can grab the latest toolchains and try
our
stuff from time to time.
Who maintains the CI solutions for the various compilers? How
hard is
it to add CI for the common cross-compilers and publish them?
The interesting observation I make from that list above, is that
barring Qt bindings, everything I list is a problem for LDC. It
would
seem to that LDC is the most important point of focus for my
company
at this time.
How many contributors does LDC have these days out of curiosity?
GDC could give Android, but all the other points depend on LLVM.
The trick is getting something (anything) to shift to D in the
office,
giving other programmers some exposure, and give us a context to
experiment with D in application to our particular workload;
that is,
realtime processing and rendering of geospatial data, an ideal
workload for D in my mind! http://udserver.euclideon.com/demo
(demo is
NaCl + Emscripten, we'd love to have written it in D!)
