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!)

I'll soon need to port a 30KLOC server application to windows. It is roughly five years old and written in C using glib2. Parts of it are still version controlled in CVS and the build system is based on autotools.

I am quite sure, that there won't be a running/maintainable windows version until we switch away from glib and autotools, but I doubt we will switch to D although there is no _technical_ reason not to.

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!)

Wait, you work for Euclideon?

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!)

On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
> I often wonder if others share the importance of mobile cross-compilers?

I wonder that sometimes too, considering it's only two people working on them.

> 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.

I can't speak for Dan, who's been getting iOS working, but I just got Android/ARM running a week ago, so it's too early to put out builds.  However, it wouldn't take much time to try out the Android/x86 support from source, since the build process is documented on the wiki:

http://wiki.dlang.org/Build_DMD_for_Android

> Who maintains the CI solutions for the various compilers? How hard is
> it to add CI for the common cross-compilers and publish them?

No idea.

> How many contributors does LDC have these days out of curiosity?

Seems like 2-3 regulars.

> GDC could give Android, but all the other points depend on LLVM.

GDC appears to have some support for Android, though it's not clear how much of phobos works:

http://wiki.dlang.org/GDC/Installation/Android

On 5/28/15 8:38 AM, Manu via Digitalmars-d wrote:
> * Forceinline.

Thanks for initiating this! The lack of a means to force inlining has been unpleasant at Facebook as well. It would be great if we got this (and of course other items on the list) rolling. -- Andrei

"it's not enterprise-accepted. and there are no D programmers available on the market, think about you suddenly don't want to work anymore (which happens to me sometimes)."

not that i really pushing, though, as i have personal reasons to not push hard (language warts). and we don't do many C/C++ code, so it's really not much to replace.

On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:

>
> 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?
>
>

We develop tailor made CRM/ERP solutions, mostly in C# or ASP.net.

On the client side, it's obvious why I can't convince anyone to use D (lack of standard GUI, lack of i18n support, unavailability on WinRT/iOS/Android)

On the server side, vibe.d cannot compete with asp.net (AD/SQL/Sharepoint/Office integration, Razor syntax, IDE integration, report generation).

Therefore I took advantage of a situation we encountered - payroll calculation for a big client (>50000 payrolls) took more than 6 hours to complete. So I tried to write some payroll calculation components in D. The main problems encountered were:
- lack of a decimal data type - you cannot perform monetary calculation using floating point.
- lack of a chinese or japanese calendar in the std.datetime module;
- missing of overflow checks for integral data types;

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?
>

Video processing: **lack of x86 SIMD intrinsics** that actually work, specifically like the Intel ones. Assembly rarely get you the best available performance (cost of missed inlining, reordering, register spilling and man-mdade instruction scheduling hurt). Intrinsics with killer optimizing back-ends do. We have _some_ intrinsics but they are unusable right now and don't work on both 32-bit and 64-bit. Other than that, I can't think of nothing that is a blocker. Hopefully LLVM auto-vectorizer becomes so good that this point is not that blocking.

Audio processing: few blockers, @nogc tagged in all of Phobos where applicable would be nice, a way to do @nogc locks, OSX shared libraries with support for Mac idiosyncrasies. ARM support for future Mac if that happens. iOS support.

3D rendering: I can't see any blocker.

Biggest hurdle is often existing C++ programmers and perceived problems :)

On Thursday, 28 May 2015 at 21:31:08 UTC, ponce wrote:
> 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?
>>
>
> Video processing: **lack of x86 SIMD intrinsics** that actually work, specifically like the Intel ones. Assembly rarely get you the best available performance (cost of missed inlining, reordering, register spilling and man-mdade instruction scheduling hurt). Intrinsics with killer optimizing back-ends do. We have _some_ intrinsics but they are unusable right now and don't work on both 32-bit and 64-bit. Other than that, I can't think of nothing that is a blocker. Hopefully LLVM auto-vectorizer becomes so good that this point is not that blocking.

most of this wouldn't be an issue if dmd backend didn't exist, both LDC and GDC expose GCC vector intrinsics.