www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why aren't you using D at work?

reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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!)
May 28 2015
next sibling parent "Palmstroem" <palmstroem bohemia.org> writes:
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.
May 28 2015
prev sibling next sibling parent reply "Meta" <jared771 gmail.com> writes:
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?
May 28 2015
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 29 May 2015 at 02:40, Meta via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Wait, you work for Euclideon?


Yeah. And I'd say our work is a killer use-case for D!
May 29 2015
prev sibling next sibling parent "Atila Neves" <atila.neves gmail.com> writes:
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!)
May 28 2015
prev sibling next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
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
May 28 2015
parent reply Dan Olson <gorox comcast.net> writes:
"Joakim" <dlang joakim.fea.st> writes:


 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


And for iOS - https://github.com/smolt/ldc-iphone-dev

I was hoping others would try out this ldc for iOS and give feedback,
suggest where to focus next, but nothing so far.  It does pretty well if
all you need is to compile D code but don't need Objective-C interop or
nice Xcode interaction.

Would putting up a binary build help?  I can do that.

In meantime I have been getting ready for upcoming LDC 0.16.0 with dmd
frontend 2.067.  Also coming soon is support of iOS sim in addition to
existing arm support.  Latest Xcode 6.3.1 apparently fixed something
because now D dwarf debug kind of works.  Xcode crashes sometimes while
navigating the stack, but way better than thumb instruction level
debugging.
May 31 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1 June 2015 at 16:50, Dan Olson via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 "Joakim" <dlang joakim.fea.st> writes:


 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


 And for iOS - https://github.com/smolt/ldc-iphone-dev

 I was hoping others would try out this ldc for iOS and give feedback,
 suggest where to focus next, but nothing so far.  It does pretty well if
 all you need is to compile D code but don't need Objective-C interop or
 nice Xcode interaction.

 Would putting up a binary build help?  I can do that.


Yes. I basically won't look at anything without a binary build.
Call me whatever you like; I am a completely typical Windows developer
in this way. If there is no binary, the thought that I should build it
myself doesn't cross my mind ;)

It would be nice if it were easy to find; present among the other LDC downloads?
Possible to work iOS toolchain build into the existing LDC CI solution?

I think all these missing cross-compilers need to find themselves into
regular build cycles, and maintained alongside the existing releases.
Much easier to take them seriously in that context, and gives better
visibility; it feels like these efforts are somewhat fragmented until
recently.
Having toolchain alpha-releases available, even without libraries in
working order, makes the bar much lower for people to get in and start
hacking on the libraries.
Jun 01 2015
parent reply Dan Olson <gorox comcast.net> writes:
Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:

 On 1 June 2015 at 16:50, Dan Olson via Digitalmars-d

 And for iOS - https://github.com/smolt/ldc-iphone-dev

 I was hoping others would try out this ldc for iOS and give feedback,
 suggest where to focus next, but nothing so far.  It does pretty well if
 all you need is to compile D code but don't need Objective-C interop or
 nice Xcode interaction.

 Would putting up a binary build help?  I can do that.


 Yes. I basically won't look at anything without a binary build.
 Call me whatever you like; I am a completely typical Windows developer
 in this way. If there is no binary, the thought that I should build it
 myself doesn't cross my mind ;)


In this case you'd have to be an OS X developer, as the binaries will be
for a Mac.


 It would be nice if it were easy to find; present among the other LDC
 downloads?


When ready, I will add a link to the iOS section of
http://wiki.dlang.org/LDC


 Possible to work iOS toolchain build into the existing LDC CI solution?

 I think all these missing cross-compilers need to find themselves into
 regular build cycles, and maintained alongside the existing releases.
 Much easier to take them seriously in that context, and gives better
 visibility; it feels like these efforts are somewhat fragmented until
 recently.
 Having toolchain alpha-releases available, even without libraries in
 working order, makes the bar much lower for people to get in and start
 hacking on the libraries.


Yeah, we need to work on getting iOS support into LDC main offering. For
now there is a stumbling block (at least perceived by me) of requiring a
patched LLVM to support TLS on iOS.
Jun 01 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-06-01 18:38, Dan Olson wrote:


 Yeah, we need to work on getting iOS support into LDC main offering. For
 now there is a stumbling block (at least perceived by me) of requiring a
 patched LLVM to support TLS on iOS.


How you tried contributing that back to LLVM? And in that case, what's 
the status?

-- 
/Jacob Carlborg
Jun 01 2015
next sibling parent reply Danni Coy via Digitalmars-d <digitalmars-d puremagic.com> writes:
I forgot to add that bindings to a UI framework would open the door
for D in a lot more projects. Qt is the option that sucks the least by
a significant margin.
force-inline would also be useful.
Jun 02 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 03 Jun 2015 11:24:33 +1000, Danni Coy via Digitalmars-d wrote:


 I forgot to add that bindings to a UI framework would open the door for
 D in a lot more projects. Qt is the option that sucks the least by a
 significant margin.


it was like that until Qt5. now it suxalot.

anyway, while Qt bindings still must be created, GtkD is already here.=
Jun 02 2015
prev sibling parent reply Dan Olson <gorox comcast.net> writes:
Jacob Carlborg <doob me.com> writes:


 On 2015-06-01 18:38, Dan Olson wrote:


 Yeah, we need to work on getting iOS support into LDC main offering. For
 now there is a stumbling block (at least perceived by me) of requiring a
 patched LLVM to support TLS on iOS.


 How you tried contributing that back to LLVM? And in that case, what's
 the status?


Not yet.  I greedily work on puzzles I think I can solve..  On the other
hand, a Rust dev last year was able to use the iOS TLS patch to LLVM and
perhaps made some progress.  Or found another way.

http://vhbit.net/blog/2014/04/12/rust-on-ios/

Reports good progress beginning of this year too.

http://vhbit.net/blog/2015/01/18/rust-for-ios-status-update/

I've lately been work on unwinding SjLj exception in Fibers, because
until the 2.067, there weren't any unittests to show it off.  It was
funny seeing an exception thrown in one Fiber being caught by another
Fiber! Luckily I've got that solved now.
-- 
Dan
Jun 03 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-06-03 09:43, Dan Olson wrote:


 Not yet.  I greedily work on puzzles I think I can solve..


But since you have patched LLVM you have already solved the issue ;)


 On the other
 hand, a Rust dev last year was able to use the iOS TLS patch to LLVM and
 perhaps made some progress.  Or found another way.

 http://vhbit.net/blog/2014/04/12/rust-on-ios/


The blog post says that Rust has built-in TLS emulation. It seems it 
wasn't necessary to use a patched LLVM. Although, I have no idea which 
way was used in the end.


 Reports good progress beginning of this year too.

 http://vhbit.net/blog/2015/01/18/rust-for-ios-status-update/

 I've lately been work on unwinding SjLj exception in Fibers, because
 until the 2.067, there weren't any unittests to show it off.  It was
 funny seeing an exception thrown in one Fiber being caught by another
 Fiber! Luckily I've got that solved now.


Ok, I see.

-- 
/Jacob Carlborg
Jun 03 2015
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
May 28 2015
next sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Thursday, 28 May 2015 at 17:22:21 UTC, Andrei Alexandrescu 
wrote:

 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


Yes, likely, unlikely, forceinline, and noinline are important 
tools.
You should already be able to use PGO which gives the compiler 
real statistics about your program and is good for a 5-10% 
speedup.
https://github.com/D-Programming-Language/dmd/pull/4651
May 29 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Friday, 29 May 2015 at 08:57:46 UTC, Martin Nowak wrote:

 On Thursday, 28 May 2015 at 17:22:21 UTC, Andrei Alexandrescu 
 wrote:

 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


 Yes, likely, unlikely, forceinline, and noinline are important 
 tools.
 You should already be able to use PGO which gives the compiler 
 real statistics about your program and is good for a 5-10% 
 speedup.
 https://github.com/D-Programming-Language/dmd/pull/4651


Walter said likely/unlikely won't be implemented as the compiler 
already assumes the first condition is the more likely one the 
last time this was brought up.
I'm not sure if this is still true.
May 29 2015
parent reply "Martin Nowak" <code dawg.eu> writes:
On Friday, 29 May 2015 at 09:50:29 UTC, weaselcat wrote:

 Walter said likely/unlikely won't be implemented as the 
 compiler already assumes the first condition is the more likely 
 one the last time this was brought up.


That is not what he said 
http://forum.dlang.org/post/m8739b$an$1 digitalmars.com.
May 29 2015
parent "weaselcat" <weaselcat gmail.com> writes:
On Friday, 29 May 2015 at 10:32:50 UTC, Martin Nowak wrote:

 On Friday, 29 May 2015 at 09:50:29 UTC, weaselcat wrote:

 Walter said likely/unlikely won't be implemented as the 
 compiler already assumes the first condition is the more 
 likely one the last time this was brought up.


 That is not what he said 
 http://forum.dlang.org/post/m8739b$an$1 digitalmars.com.


Wow, I shouldn't post before going to bed.
My apologies, remembered it way differently. Sorry for the noise.
May 29 2015
prev sibling parent "ixid" <adamsibson hotmail.com> writes:
On Thursday, 28 May 2015 at 17:22:21 UTC, Andrei Alexandrescu 
wrote:

 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


I understand the position you and Walter are in that you are 
nagged regularly for wrong-headed or pet features but I do think 
a lesson needs to be taken from forceinline that standard 
features like this need to go in. Poor Manu has been beating that 
drum for so long. If multiple members of the community keep 
coming back to a thing over time then it needs to be seriously 
reexamined and not enter the state I see in some communities 
where it because almost a religious commandment as the community 
is sick of discussing it and there has been a command from on 
high that it will not be that way. It's very much like generics 
in Go. The problem is that people forget what the arguments 
actually were and take away a possibly wrongheaded sense of 
conclusion which fossilizes. Perhaps the issue re-openner should 
be responsible for a detailed summary of the arguments previously 
given before and against and any new additions rather than people 
making references to disparate and sometimes private threads.
May 29 2015
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
"it's not enterprise-accepted. and there are no D programmers available=20
on the market, think about you suddenly don't want to work anymore (which=20
happens to me sometimes)."

not that i really pushing, though, as i have personal reasons to not push=20
hard (language warts). and we don't do many C/C++ code, so it's really=20
not much to replace.=
May 28 2015
prev sibling next sibling parent reply "rumbu" <rumbu rumbu.ro> writes:
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?




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;
May 28 2015
next sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Thursday, 28 May 2015 at 20:22:44 UTC, rumbu wrote:

 - lack of a decimal data type - you cannot perform monetary 
 calculation using floating point.


http://dlang.org/phobos/std_bigint.html?


 - lack of a chinese or japanese calendar in the std.datetime 
 module;
 - missing of overflow checks for integral data types;


http://dlang.org/phobos/core_checkedint.html
May 29 2015
next sibling parent reply "rumbu" <rumbu rumbu.ro> writes:
On Friday, 29 May 2015 at 09:22:56 UTC, Martin Nowak wrote:

 On Thursday, 28 May 2015 at 20:22:44 UTC, rumbu wrote:

 - lack of a decimal data type - you cannot perform monetary 
 calculation using floating point.


 http://dlang.org/phobos/std_bigint.html?


No. There is no scale in BigInt. 1 / 2 will result in 0 not in 
0.5. If BigInt in D was inspired from java BigInt, the direct 
equivalent should be java BigDecimal, but this does not exist in 
phobos. Even if I keep a scale myself, there are missing features 
like rounding. Anyway, I implemented my own decimal type : 
https://github.com/rumbu13/sharp/blob/master/src/system/package.d#L2512, 
but I would prefer that D will provide such types built in the 
language, at least this was the intention many years ago: 
http://dlang.org/d-floating-point.html


 - lack of a chinese or japanese calendar in the std.datetime 
 module;
 - missing of overflow checks for integral data types;


 http://dlang.org/phobos/core_checkedint.html


Division overflow is not implemented (int.min / -1) and using a 
linear syntax instead of a simple expression is not the best way 
to convince people to switch sides.
May 29 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 29 May 2015 at 12:23:14 UTC, rumbu wrote:

 On Friday, 29 May 2015 at 09:22:56 UTC, Martin Nowak wrote:

 On Thursday, 28 May 2015 at 20:22:44 UTC, rumbu wrote:

 - lack of a decimal data type - you cannot perform monetary 
 calculation using floating point.


 http://dlang.org/phobos/std_bigint.html?


 No. There is no scale in BigInt. 1 / 2 will result in 0 not in 
 0.5. If BigInt in D was inspired from java BigInt, the direct 
 equivalent should be java BigDecimal, but this does not exist 
 in phobos. Even if I keep a scale myself, there are missing 
 features like rounding. Anyway, I implemented my own decimal 
 type : 
 https://github.com/rumbu13/sharp/blob/master/src/system/package.d#L2512,


Fair play to you! We should bundle these efforts. What about a 
page where we collect all this stuff like "I miss this feature in 
D, and here's my own library for it." We all have stuff like this 
in the attic somewhere.


 but I would prefer that D will provide such types built in the 
 language, at least this was the intention many years ago: 
 http://dlang.org/d-floating-point.html


 - lack of a chinese or japanese calendar in the std.datetime 
 module;
 - missing of overflow checks for integral data types;


 http://dlang.org/phobos/core_checkedint.html


 Division overflow is not implemented (int.min / -1) and using a 
 linear syntax instead of a simple expression is not the best 
 way to convince people to switch sides.
May 29 2015
parent "Martin Nowak" <code dawg.eu> writes:
On Friday, 29 May 2015 at 12:55:13 UTC, Chris wrote:

 Fair play to you! We should bundle these efforts. What about a 
 page where we collect all this stuff like "I miss this feature 
 in D, and here's my own library for it." We all have stuff like 
 this in the attic somewhere.


http://code.dlang.org/
May 29 2015
prev sibling parent reply Danni Coy via Digitalmars-d <digitalmars-d puremagic.com> writes:
I have been doing my first serious attempt at D after convincing other
people that it was the way to go quite a few years ago. (My copy of
"The D Programming Language" doesn't have Andrei's name on it so it
would have been around that time)
and these are the things which are fresh for me.

I had no idea that it was so easy to call C code from my D code, and
how little effort I had to go to disguise the fact that it was C code
thanks mostly to UFCS and  property.
This makes it feasible to write bindings on the fly and makes me a lot
less hesitant to try using it for any job I could use C or C++.

So far so good.

Now lets get to the friction points.

Tooling - it's still a step down from what I am used to with C/C++ on
linux. This is now for me at the point where it is acceptable but not
great.

Documentation - What is there is generally quite good, also quite
terse. I am not seeing a huge number D specific results whenever I
search on any issues I am having with my code.

The Standard Library. I want to use D so I can do more with less hours
writing code and less hours debugging code. Having a high quality
standard library really helps this - unfortunately for me the first
thing I needed from the standard library was xml parsing, which the
documentation tells me is sub par and will be replaced in the near
future, There is no indication of what I might like to use instead. Do
I now use one of the other xml libraries floating around, bind a C
based one or roll my own. All this eats into the efficiency that I am
gaining by virtue of D being a really nice language.
May 30 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 31/05/2015 11:37 a.m., Danni Coy via Digitalmars-d wrote:

 I have been doing my first serious attempt at D after convincing other
 people that it was the way to go quite a few years ago. (My copy of
 "The D Programming Language" doesn't have Andrei's name on it so it
 would have been around that time)
 and these are the things which are fresh for me.

 I had no idea that it was so easy to call C code from my D code, and
 how little effort I had to go to disguise the fact that it was C code
 thanks mostly to UFCS and  property.
 This makes it feasible to write bindings on the fly and makes me a lot
 less hesitant to try using it for any job I could use C or C++.

 So far so good.

 Now lets get to the friction points.

 Tooling - it's still a step down from what I am used to with C/C++ on
 linux. This is now for me at the point where it is acceptable but not
 great.

 Documentation - What is there is generally quite good, also quite
 terse. I am not seeing a huge number D specific results whenever I
 search on any issues I am having with my code.

 The Standard Library. I want to use D so I can do more with less hours
 writing code and less hours debugging code. Having a high quality
 standard library really helps this - unfortunately for me the first
 thing I needed from the standard library was xml parsing, which the
 documentation tells me is sub par and will be replaced in the near
 future, There is no indication of what I might like to use instead. Do
 I now use one of the other xml libraries floating around, bind a C
 based one or roll my own. All this eats into the efficiency that I am
 gaining by virtue of D being a really nice language.



Ahh std.xml, it's been that way for years.
We NEED to get that replaced. Although don't hold your breath :/
May 30 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, May 31, 2015 at 02:17:59PM +1200, Rikki Cattermole via Digitalmars-d
wrote:

 On 31/05/2015 11:37 a.m., Danni Coy via Digitalmars-d wrote:


[...]

The Standard Library. I want to use D so I can do more with less
hours writing code and less hours debugging code. Having a high
quality standard library really helps this - unfortunately for me the
first thing I needed from the standard library was xml parsing, which
the documentation tells me is sub par and will be replaced in the
near future, There is no indication of what I might like to use
instead. Do I now use one of the other xml libraries floating around,
bind a C based one or roll my own. All this eats into the efficiency
that I am gaining by virtue of D being a really nice language.


 
 
 Ahh std.xml, it's been that way for years.
 We NEED to get that replaced. Although don't hold your breath :/


What we *really* need, like almost everything else in D, is for somebody
to get sufficiently provoked by the sorry state of the current std.xml
to write something better and push it through the review process. Until
then, further discussion is unlikely to make any difference.


T

-- 
Famous last words: I *think* this will work...
May 30 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 31/05/2015 2:27 p.m., H. S. Teoh via Digitalmars-d wrote:

 On Sun, May 31, 2015 at 02:17:59PM +1200, Rikki Cattermole via Digitalmars-d
wrote:

 On 31/05/2015 11:37 a.m., Danni Coy via Digitalmars-d wrote:


 [...]

 The Standard Library. I want to use D so I can do more with less
 hours writing code and less hours debugging code. Having a high
 quality standard library really helps this - unfortunately for me the
 first thing I needed from the standard library was xml parsing, which
 the documentation tells me is sub par and will be replaced in the
 near future, There is no indication of what I might like to use
 instead. Do I now use one of the other xml libraries floating around,
 bind a C based one or roll my own. All this eats into the efficiency
 that I am gaining by virtue of D being a really nice language.



 Ahh std.xml, it's been that way for years.
 We NEED to get that replaced. Although don't hold your breath :/


 What we *really* need, like almost everything else in D, is for somebody
 to get sufficiently provoked by the sorry state of the current std.xml
 to write something better and push it through the review process. Until
 then, further discussion is unlikely to make any difference.


 T


That's a given at this stage.
I've read the XML spec, its almost as bad as x86. Okay not quite but 
still. That's how far I got.
May 30 2015
next sibling parent reply Danni Coy via Digitalmars-d <digitalmars-d puremagic.com> writes:
so is std.xml the exception? How many other parts of the standard
library are like that?

On Sun, May 31, 2015 at 12:37 PM, Rikki Cattermole via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 31/05/2015 2:27 p.m., H. S. Teoh via Digitalmars-d wrote:

 On Sun, May 31, 2015 at 02:17:59PM +1200, Rikki Cattermole via
 Digitalmars-d wrote:

 On 31/05/2015 11:37 a.m., Danni Coy via Digitalmars-d wrote:


 [...]

 The Standard Library. I want to use D so I can do more with less
 hours writing code and less hours debugging code. Having a high
 quality standard library really helps this - unfortunately for me the
 first thing I needed from the standard library was xml parsing, which
 the documentation tells me is sub par and will be replaced in the
 near future, There is no indication of what I might like to use
 instead. Do I now use one of the other xml libraries floating around,
 bind a C based one or roll my own. All this eats into the efficiency
 that I am gaining by virtue of D being a really nice language.



 Ahh std.xml, it's been that way for years.
 We NEED to get that replaced. Although don't hold your breath :/



 What we *really* need, like almost everything else in D, is for somebody
 to get sufficiently provoked by the sorry state of the current std.xml
 to write something better and push it through the review process. Until
 then, further discussion is unlikely to make any difference.


 T


 That's a given at this stage.
 I've read the XML spec, its almost as bad as x86. Okay not quite but still.
 That's how far I got.
May 30 2015
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 31/05/2015 3:03 p.m., Danni Coy via Digitalmars-d wrote:

 so is std.xml the exception? How many other parts of the standard
 library are like that?

 On Sun, May 31, 2015 at 12:37 PM, Rikki Cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 31/05/2015 2:27 p.m., H. S. Teoh via Digitalmars-d wrote:

 On Sun, May 31, 2015 at 02:17:59PM +1200, Rikki Cattermole via
 Digitalmars-d wrote:

 On 31/05/2015 11:37 a.m., Danni Coy via Digitalmars-d wrote:


 [...]

 The Standard Library. I want to use D so I can do more with less
 hours writing code and less hours debugging code. Having a high
 quality standard library really helps this - unfortunately for me the
 first thing I needed from the standard library was xml parsing, which
 the documentation tells me is sub par and will be replaced in the
 near future, There is no indication of what I might like to use
 instead. Do I now use one of the other xml libraries floating around,
 bind a C based one or roll my own. All this eats into the efficiency
 that I am gaining by virtue of D being a really nice language.



 Ahh std.xml, it's been that way for years.
 We NEED to get that replaced. Although don't hold your breath :/



 What we *really* need, like almost everything else in D, is for somebody
 to get sufficiently provoked by the sorry state of the current std.xml
 to write something better and push it through the review process. Until
 then, further discussion is unlikely to make any difference.


 T


 That's a given at this stage.
 I've read the XML spec, its almost as bad as x86. Okay not quite but still.
 That's how far I got.




std.json I believe and maybe one or two others. But std.xml is the one 
without a real clear alternative in the D ecosystem.
May 30 2015
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Sunday, 31 May 2015 at 03:03:22 UTC, Danni Coy wrote:

 so is std.xml the exception? How many other parts of the 
 standard
 library are like that?


A few, but not many. Mostly, it's stuff that was done for D1 or 
very early D2 which hasn't been removed or replaced yet. std.xml, 
std.json, and std.stream are what come to mind. There may be a 
few others, but most of the stuff in Phobos is more recent and is 
properly maintained. Mostly, it's a question of what hasn't been 
added to the standard library yet rather than what needs to be 
replaced.

- Jonathan M Davis
Jun 02 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 3 June 2015 at 03:15:32 UTC, Jonathan M Davis wrote:

 On Sunday, 31 May 2015 at 03:03:22 UTC, Danni Coy wrote:

 so is std.xml the exception? How many other parts of the 
 standard
 library are like that?


 A few, but not many. Mostly, it's stuff that was done for D1 or 
 very early D2 which hasn't been removed or replaced yet. 
 std.xml, std.json, and std.stream are what come to mind. There 
 may be a few others, but most of the stuff in Phobos is more 
 recent and is properly maintained. Mostly, it's a question of 
 what hasn't been added to the standard library yet rather than 
 what needs to be replaced.

 - Jonathan M Davis


std.signals
Jun 02 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 03 Jun 2015 03:27:35 +0000, weaselcat wrote:


 On Wednesday, 3 June 2015 at 03:15:32 UTC, Jonathan M Davis wrote:

 On Sunday, 31 May 2015 at 03:03:22 UTC, Danni Coy wrote:

 so is std.xml the exception? How many other parts of the standard
 library are like that?


 A few, but not many. Mostly, it's stuff that was done for D1 or very
 early D2 which hasn't been removed or replaced yet. std.xml, std.json,
 and std.stream are what come to mind. There may be a few others, but
 most of the stuff in Phobos is more recent and is properly maintained.
 Mostly, it's a question of what hasn't been added to the standard
 library yet rather than what needs to be replaced.

 - Jonathan M Davis


=20
 std.signals


and there is an excellect replacement[1]!

[1] https://github.com/phobos-x/phobosx/blob/master/source/phobosx/
signal.d=
Jun 02 2015
parent reply "Jonas Drewsen" <nospam4321 hotmail.com > writes:
On Wednesday, 3 June 2015 at 04:53:05 UTC, ketmar wrote:

 On Wed, 03 Jun 2015 03:27:35 +0000, weaselcat wrote:


 On Wednesday, 3 June 2015 at 03:15:32 UTC, Jonathan M Davis 
 wrote:

 On Sunday, 31 May 2015 at 03:03:22 UTC, Danni Coy wrote:

 so is std.xml the exception? How many other parts of the 
 standard
 library are like that?


 A few, but not many. Mostly, it's stuff that was done for D1 
 or very
 early D2 which hasn't been removed or replaced yet. std.xml, 
 std.json,
 and std.stream are what come to mind. There may be a few 
 others, but
 most of the stuff in Phobos is more recent and is properly 
 maintained.
 Mostly, it's a question of what hasn't been added to the 
 standard
 library yet rather than what needs to be replaced.

 - Jonathan M Davis


 
 std.signals


 and there is an excellect replacement[1]!

 [1] 
 https://github.com/phobos-x/phobosx/blob/master/source/phobosx/
 signal.d


Nice! just what I've been looking for. I hope it works as 
expected.
Jun 03 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 03 Jun 2015 14:38:12 +0000, Jonas Drewsen wrote:


 std.signals


 and there is an excellect replacement[1]!

 [1] https://github.com/phobos-x/phobosx/blob/master/source/phobosx/
 signal.d


=20
 Nice! just what I've been looking for. I hope it works as expected.


i'm using it for several monthes now and found zero problems with it. it=20
really works exactly like it's documentation says. ;-)=
Jun 03 2015
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 31 May 2015 at 13:03, Danni Coy via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 so is std.xml the exception? How many other parts of the standard
 library are like that?


Lots. Check out std.json ;)
May 30 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-05-31 01:37, Danni Coy via Digitalmars-d wrote:


 The Standard Library. I want to use D so I can do more with less hours
 writing code and less hours debugging code. Having a high quality
 standard library really helps this - unfortunately for me the first
 thing I needed from the standard library was xml parsing, which the
 documentation tells me is sub par and will be replaced in the near
 future, There is no indication of what I might like to use instead. Do
 I now use one of the other xml libraries floating around, bind a C
 based one or roll my own.


Use the one in Tango [1] [2]. It's really fast, at least back in the D1 
days. Supports both DOM parser, SAX parser and a pull parser

[1] https://github.com/SiegeLord/Tango-D2
[2] http://siegelord.github.io/Tango-D2/ (search for XML)

-- 
/Jacob Carlborg
May 31 2015
parent reply Danni Coy via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, May 31, 2015 at 7:28 PM, Jacob Carlborg via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 2015-05-31 01:37, Danni Coy via Digitalmars-d wrote:


 The Standard Library. I want to use D so I can do more with less hours
 writing code and less hours debugging code. Having a high quality
 standard library really helps this - unfortunately for me the first
 thing I needed from the standard library was xml parsing, which the
 documentation tells me is sub par and will be replaced in the near
 future, There is no indication of what I might like to use instead. Do
 I now use one of the other xml libraries floating around, bind a C
 based one or roll my own.



 Use the one in Tango [1] [2]. It's really fast, at least back in the D1
 days. Supports both DOM parser, SAX parser and a pull parser


Wouldn't this mean basically pulling all of Tango into my project and
then having two copies of practically everything? That might be a
practical solution but you can see why that doesn't feel like a good
solution and still gives friction.
May 31 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-06-01 01:04, Danni Coy via Digitalmars-d wrote:


 Wouldn't this mean basically pulling all of Tango into my project and
 then having two copies of practically everything?


Not exactly sure what you mean. The linker will only pull in the symbols 
you're actually using. A module in Tango, compared with Phobos, doesn't 
depend on the rest of the library. There are less inter-dependencies in 
the library.

I just had a quick look. The DOM parser depends only on the pull parser. 
The pull parser depends on two functions and one exception. Should be 
trivial to replace those with the corresponding functions in Phobos if 
you only want to extract the XML parsing.


 That might be a practical solution but you can see why that doesn't feel like
a good
 solution and still gives friction.


I kind of understand that, but on the other hand, if it gets the job 
done what's the problem.

-- 
/Jacob Carlborg
May 31 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-05-28 22:22, rumbu wrote:


 - lack of a chinese or japanese calendar in the std.datetime module;


What about Tango [1]?

[1] 
http://dsource.org/projects/tango/docs/current/tango.time.chrono.Japanese.html

-- 
/Jacob Carlborg
May 29 2015
parent reply "rumbu" <rumbu rumbu.ro> writes:
On Friday, 29 May 2015 at 12:52:12 UTC, Jacob Carlborg wrote:

 On 2015-05-28 22:22, rumbu wrote:


 - lack of a chinese or japanese calendar in the std.datetime 
 module;


 What about Tango [1]?

 [1] 
 http://dsource.org/projects/tango/docs/current/tango.time.chrono.Japanese.html


The Japanese Calendar is Gregorian, so there are no major 
differences. On the contrary the Chinese one is very different 
with floating month sizes. If someone is wondering why a calendar 
is needed in a payroll calculation, it's used to determine the 
number of working days in a month :)

Tahngo was nice but not supported anymore, I expect these 
features in phobos.
May 29 2015
next sibling parent "Kagamin" <spam here.lot> writes:
On Friday, 29 May 2015 at 13:45:56 UTC, rumbu wrote:

 Tahngo was nice but not supported anymore


Two months ago it had an update that bumped tested version to 
2.067.
May 29 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-05-29 15:45, rumbu wrote:


 Tahngo was nice but not supported anymore, I expect these features in
 phobos.


It's supported in the sense that someone always makes sure it works with 
latest DMD.

-- 
/Jacob Carlborg
May 30 2015
prev sibling next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
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 :)
May 28 2015
parent "weaselcat" <weaselcat gmail.com> writes:
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.
May 28 2015
prev sibling next sibling parent "Martin Nowak" <code dawg.eu> writes:
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?


- Quality of ecosystem. It's relatively simple to run into an 
issue, that requires one to be a D expert to resolve (codegen 
bugs, ICEs, CTFE bugs, undecipherable error messages). Fairly 
problematic for learning the language, especially for people 
without C++ background.

- Lack of libraries. We're missing too many components and the 
fact that I'd have to write 3 libraries to realize a tiny project 
makes it particularly hard to get a foot in the door.

- Learning material. To much knowledge about D is implicitly 
shared among contributors and heavy users (e.g. local imports 
should be selective, or they might shadow symbols) making it 
harder to learn the language. Outdated information on dlang.org 
doesn't help either.
May 29 2015
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
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?


If you're interested in enterprise point of view, our ecosystem 
is build around .net technologies, it gets the job done, so it's 
usually hard to come up with a case for D. There is a small 
utility, which updates database in a multithreaded fashion and 
doesn't share code with the rest of the project, but it needs 
database connectivity for mssql and oracle and again D can't show 
any advantage in such use case.
May 29 2015
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 29 May 2015 at 09:33:25 UTC, Kagamin wrote:

 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?


 If you're interested in enterprise point of view, our ecosystem 
 is build around .net technologies, it gets the job done, so 
 it's usually hard to come up with a case for D. There is a 
 small utility, which updates database in a multithreaded 
 fashion and doesn't share code with the rest of the project, 
 but it needs database connectivity for mssql and oracle and 
 again D can't show any advantage in such use case.


Same here.

Our customers live in Java and .NET world. They also tend to 
choose the technology stack themselves.

C++ only appears into the scene when there is the need for some 
OS integration or performance boost. So just as JNI, P/Invoke, 
COM component.

Also there are native compilers for both eco-systems around the 
corner. .NET Native on one side and the AOT support is being 
discussed for Java 10 (ignoring the commercial options).

For the customers doing mobile projects, we tend to go with a mix 
of platform SDKs and some web help.

Overall, for the amount of C++ code that gets written, D would 
hardly make any difference and cannot compete with the 
eco-systems being used from business case point of view.
May 29 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 29 May 2015 at 10:05:08 UTC, Paulo  Pinto wrote:

 On Friday, 29 May 2015 at 09:33:25 UTC, Kagamin wrote:

 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?


 If you're interested in enterprise point of view, our 
 ecosystem is build around .net technologies, it gets the job 
 done, so it's usually hard to come up with a case for D. There 
 is a small utility, which updates database in a multithreaded 
 fashion and doesn't share code with the rest of the project, 
 but it needs database connectivity for mssql and oracle and 
 again D can't show any advantage in such use case.


 Same here.

 Our customers live in Java and .NET world. They also tend to 
 choose the technology stack themselves.

 C++ only appears into the scene when there is the need for some 
 OS integration or performance boost. So just as JNI, P/Invoke, 
 COM component.

 Also there are native compilers for both eco-systems around the 
 corner. .NET Native on one side and the AOT support is being 
 discussed for Java 10 (ignoring the commercial options).

 For the customers doing mobile projects, we tend to go with a 
 mix of platform SDKs and some web help.

 Overall, for the amount of C++ code that gets written, D would 
 hardly make any difference and cannot compete with the 
 eco-systems being used from business case point of view.


I'm using D at work successfully. However, what is lacking that 
makes it hard to convince others:

1. [medium priority]
No standard GUI ("Look Ma, there's a button that says 'Hello, 
world!', if I press it!"). You can work around that, because you 
can still call D from any GUI either as an executable, a socket 
or interface to D (via C). Still, people love GUIs. I hope 
dlangui can help here.

2. [high priority]
Uncertainty regarding ARM (iOS/Android). Deal breaker, show 
stopper. Was worrying a few years ago, but is just bad now in 
2015.

3. [constant priority]
Learning resources, learning curve. As mentioned in a comment 
above: you have to know D well to be able to make sense of error 
messages etc. You need to know D "low-level" or D's internals in 
order to take full advantage of it. A lot of concepts are 
unfamiliar to people and/or not yet common ground (ranges, 
templates, component programming), especially as inbuilt 
features. The other day I needed startswith and ctypes in Python 
and immediately got this:

https://docs.python.org/2/library/stdtypes.html
https://docs.python.org/2/library/ctypes.html

For D I get:

==> http://dlang.org/phobos/std_string.html
==> http://dlang.org/phobos/std_algorithm.html#startsWith
==> 


uint startsWith(alias pred = "a == b", Range, Needles...)(Range 
doesThisStart, Needles withOneOfThese) if (isInputRange!Range && 
Needles.length > 1 && is(typeof(.startsWith!pred(doesThisStart, 
withOneOfThese[0])) : bool) && 
is(typeof(.startsWith!pred(doesThisStart, withOneOfThese[1..$])) 
: uint));
bool startsWith(alias pred = "a == b", R1, R2)(R1 doesThisStart, 
R2 withThis) if (isInputRange!R1 && isInputRange!R2 && 
is(typeof(binaryFun!pred(doesThisStart.front, withThis.front)) : 
bool));
bool startsWith(alias pred = "a == b", R, E)(R doesThisStart, E 
withThis) if (isInputRange!R && 
is(typeof(binaryFun!pred(doesThisStart.front, withThis)) : bool));

WTF? :-)

I know, we all know that, but still it puts people off, a simple 
psychological issue. D smells of elitism and hackeritis. Python 
and Java are more like "Hey, I can do it too. Look Ma, it prints 
'Hello, world!'!!!" In other words, it doesn't make people feel 
good about themselves, there's no immediate reward. This is 
purely a marketing issue and has nothing to do with the language 
itself. But even if people are free to chose a language, they shy 
away from D.

And since we're talking about psychology, I think D is a language 
you only come to appreciate after years of programming in other 
languages. People won't adopt it as long as they feel comfortable 
- or secure - in other languages, as long as they don't see an 
immediate benefit in using D. I'm not sure if there's anything 
the D community can do about this except for keeping on keeping 
on.
May 29 2015
parent reply Dan Olson <gorox comcast.net> writes:
"Chris" <wendlec tcd.ie> writes:

 2. [high priority]
 Uncertainty regarding ARM (iOS/Android). Deal breaker, show
 stopper. Was worrying a few years ago, but is just bad now in 2015.


It is a little better now :-)

Maybe you can help Chris.  I don't develop for mobile so I don't know
that dev environment and what is needed for D to be useful in that
world.  So far for iOS we have armv7 support, all of phobos except
libcurl.  What isn't there yet is iOS sim support (coming soon), arm64
support, and nice Xcode integration.

I though it might help if I added a demo app based on Allegro 5.

https://github.com/smolt/ldc-iphone-dev

There is a list of TODOs at the bottom of the project readme.  Want to
add anything?  Also, issues can be filed, pull requests.  
-- 
Dan
Jun 01 2015
parent "w0rp" <devw0rp gmail.com> writes:
I'll add in my story.

My job is working as part of a team on a small-to-medium scale 
web application. Our application layer is implemented in Python 
and Django. This would be the place where D would fit in the 
most. So I think this comes down to an argument of why we would 
choose to use Python and Django instead of D and vibe.d. I can 
think of the following reasons.

1. Obviously, we have already written everything in Python, so we 
would have to justify the cost of moving to D quite strongly.
2. Django offers more features useful for developing a web 
application than vibe.d, like an excellent API for building SQL 
queries with an ORM. The South or first party migrations (ALTER 
TABLE, etc.) APIs in 1.7 are brilliant, and after you use them, 
you can't live without them. These APIs work well and save time.
3. Python has greater mind share, so switching to D would incur 
the cost of training everyone to use D. It's hard enough finding 
a decent Python programmer.
4. The third party libraries implement many things we need to 
use, like SSO support.
5. We use Celery a lot for task management, so to use D we would 
need similar software D could work with.
6. I must mention that the execution model makes the sites easier 
to develop. When you change a function and save the file, Django 
reloads the module, (when it doesn't break) so you can test the 
effects of your modification instantly.


I can't compare on testing web pages in Django against vibe.d, as 
I've never tried it on vibe.d. I will add that Django allows you 
to send fake HTTP requests to your 'views' for web pages, so you 
can write automated tests for the pages on your site. This level 
of testing does wonders for code quality, and catches website 
regressions quickly.

I hope that in the future some clever person could implement an 
API for generating SQL queries in an RDBMS indepent way for D, 
with support for creating ALTER TABLE statements automatically. 
I've thought about it, and it wouldn't even necessarily need to 
be ORM, as something like the "data mapper" pattern could work. 
Just something which lets you build queries for objects you can 
serialise, and generate queries needed to update the tables for 
the objects when you change them.
Jun 01 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:

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


Are you working with Euclideon / Bruce Dell? Sounds fun!

I am not using D for anything serious:

1. Partially because C++/clang is more mature and does a better 
job for real time audio. I am using my own libraries that 
provides the features D has, but C++ lacks.

2. Since not using C++ at all is not an option, I've had to spend 
more time than I've enjoyed figuring out how to do C++14 style 
meta programming, which is annoying and somewhat time consuming. 
D is better, in some areas, but lacking in others. So 
metaprograming is not a good enough reason to switch.

3. D's memory model is up in the blue, C++ has locked down on one 
model, Rust on another. I am currently starting to think that 
Rust is a more likely option than D given the direction D might 
be taking towards reference counting etc. But I am not using Rust 
either… just watching how it develops.
May 29 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 29 May 2015 at 10:40:22 UTC, Ola Fosheim Grøstad wrote:

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

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


 Are you working with Euclideon / Bruce Dell? Sounds fun!

 I am not using D for anything serious:

 1. Partially because C++/clang is more mature and does a better 
 job for real time audio. I am using my own libraries that 
 provides the features D has, but C++ lacks.

 2. Since not using C++ at all is not an option, I've had to 
 spend more time than I've enjoyed figuring out how to do C++14 
 style meta programming, which is annoying and somewhat time 
 consuming. D is better, in some areas, but lacking in others. 
 So metaprograming is not a good enough reason to switch.


This is very interesting. It kinda defeats the "D is too 
complicated" argument I often hear.


 3. D's memory model is up in the blue, C++ has locked down on 
 one model, Rust on another. I am currently starting to think 
 that Rust is a more likely option than D given the direction D 
 might be taking towards reference counting etc. But I am not 
 using Rust either… just watching how it develops.


And if D offered various models (cf. std.allocator), would you 
still prefer languages with just one model for the sake of 
simplicity and not having to worry about which model to choose?
May 29 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 29 May 2015 at 11:29:13 UTC, Chris wrote:

 This is very interesting. It kinda defeats the "D is too 
 complicated" argument I often hear.


I don't know what is typical, but I am dealing with Python, 
Javascript, Dart, C++ and Objective-C for commercial use, and 
plan on adding Swift. C++14 is by far the most taxing, due to not 
enough rigour in the language design (complications with no 
benefits!). Dart you can master in a week, and is more productive 
than C++. So I have a lower threshold for adding a "Dart-like" 
language with an IDE than a "C++-like" language for commercial 
use. My threshold for adding Swift is very low due to the 
perceived simplicity and decent tooling.


 3. D's memory model is up in the blue, C++ has locked down on 
 one model, Rust on another. I am currently starting to think 
 that Rust is a more likely option than D given the direction D 
 might be taking towards reference counting etc. But I am not 
 using Rust either… just watching how it develops.


 And if D offered various models (cf. std.allocator), would you 
 still prefer languages with just one model for the sake of 
 simplicity and not having to worry about which model to choose?


I would prefer one clean heap-model that the compiler can 
optimize easily + compiler backed stack allocation, and that most 
third party libraries are written for. Almost all my performance 
oriented allocations are on the stack or are preallocated in big 
blocks, so I'd put more emphasis on things like VLA (which is 
available as a C++ extension in clang/gcc).

There is no way a generic solution can beat a tailored solution 
when it comes to abstract datatypes and memory management, so 
having lots of options in a standard library sounds useful.

But interoperability matters more. Like, I am likely to use Swift 
for ios/osx GUI, but need a companion language for the core 
application engine. C++ is most likely today. If Rust or D makes 
integration with Swift easy then I would consider a switch. The 
bottom line is overall productivity, long term maintenance and 
risk for hitting an issue that requires "ugly unsupported hacks".

It is much more difficult to find a place for a "middle ground" 
solution than a very focused heavy duty solution or a very light 
solution that is easy to get on with. I don't think people look 
for "middle ground" solutions when the try to solve a problem.
May 29 2015
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 29 May 2015 at 14:03:19 UTC, Ola Fosheim Grøstad wrote:

 On Friday, 29 May 2015 at 11:29:13 UTC, Chris wrote:

 This is very interesting. It kinda defeats the "D is too 
 complicated" argument I often hear.


 I don't know what is typical, but I am dealing with Python, 
 Javascript, Dart, C++ and Objective-C for commercial use, and 
 plan on adding Swift. C++14 is by far the most taxing, due to 
 not enough rigour in the language design (complications with no 
 benefits!). Dart you can master in a week, and is more 
 productive than C++. So I have a lower threshold for adding a 
 "Dart-like" language with an IDE than a "C++-like" language for 
 commercial use. My threshold for adding Swift is very low due 
 to the perceived simplicity and decent tooling.


D is not perceived as a simple language, although it can be 
trivial to use sometimes. To simply get things done the languages 
mentioned above are certainly a good choice and if you develop 
for mobile phones, D is certainly not a good choice _at the 
moment_.

However, for a constantly growing long-term code base, D is my 
language of choice. It's clean (i.e. maintainable), flexible 
(many ways to tackle new problems), easily unit-testable and, of 
course, compiles to native machine code. It also interfaces to 
C(++) which is very important.


 3. D's memory model is up in the blue, C++ has locked down on 
 one model, Rust on another. I am currently starting to think 
 that Rust is a more likely option than D given the direction 
 D might be taking towards reference counting etc. But I am 
 not using Rust either… just watching how it develops.


 And if D offered various models (cf. std.allocator), would you 
 still prefer languages with just one model for the sake of 
 simplicity and not having to worry about which model to choose?


 I would prefer one clean heap-model that the compiler can 
 optimize easily + compiler backed stack allocation, and that 
 most third party libraries are written for. Almost all my 
 performance oriented allocations are on the stack or are 
 preallocated in big blocks, so I'd put more emphasis on things 
 like VLA (which is available as a C++ extension in clang/gcc).

 There is no way a generic solution can beat a tailored solution 
 when it comes to abstract datatypes and memory management, so 
 having lots of options in a standard library sounds useful.

 But interoperability matters more. Like, I am likely to use 
 Swift for ios/osx GUI, but need a companion language for the 
 core application engine. C++ is most likely today. If Rust or D 
 makes integration with Swift easy then I would consider a 
 switch. The bottom line is overall productivity, long term 
 maintenance and risk for hitting an issue that requires "ugly 
 unsupported hacks".

 It is much more difficult to find a place for a "middle ground" 
 solution than a very focused heavy duty solution or a very 
 light solution that is easy to get on with. I don't think 
 people look for "middle ground" solutions when the try to solve 
 a problem.


My approach has been similar. The GUI could be anything, the core 
is D. I don't want to rewrite core functionality in various 
languages, and with other languages I always hit a wall that says 
"Thus far shalt thou go and no further!"
May 29 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 29 May 2015 at 14:22:58 UTC, Chris wrote:

 However, for a constantly growing long-term code base, D is my 
 language of choice. It's clean (i.e. maintainable), flexible 
 (many ways to tackle new problems), easily unit-testable and, 
 of course, compiles to native machine code. It also interfaces 
 to C(++) which is very important.


Yes, C++ interfacing could prove important, if it can cover >95% 
of C++ library interfaces.

Are you using D for a constantly growing long-term code base, or 
planning to?


 There is no way a generic solution can beat a tailored 
 solution when it comes to abstract datatypes and memory 
 management, so having lots of options in a standard library 
 sounds useful.




Ugh, I said the opposite of what I meant. I don't think having 
lots of allocation options in a standard library sounds all that 
useful, since I will most likely roll my own when hitting a 
serious performance problem. Rolling your own is often the same 
amount of work as "searching for  a narrow solution" unless you 
are doing something really complicated.

I think many standard libraries could be cut down to the most 
generally useful functionality. In C++ I use std::array or my own 
data structures, I only occasionally use std::vector… In Python I 
use no more than 5% of the standard library. Generally useful 
solutions (like comprehensions) beats narrow solutions 99% of the 
time, because when you need something narrow then the pre-canned 
narrow solutions often require hacks to serve the purpose (the 
wrong kind of narrowness or "fits perfectly except it doesn't 
work when…X…").
May 29 2015
parent "Chris" <wendlec tcd.ie> writes:
On Friday, 29 May 2015 at 14:46:06 UTC, Ola Fosheim Grøstad wrote:

 On Friday, 29 May 2015 at 14:22:58 UTC, Chris wrote:

 However, for a constantly growing long-term code base, D is my 
 language of choice. It's clean (i.e. maintainable), flexible 
 (many ways to tackle new problems), easily unit-testable and, 
 of course, compiles to native machine code. It also interfaces 
 to C(++) which is very important.


 Yes, C++ interfacing could prove important, if it can cover

95% of C++ library interfaces.


 Are you using D for a constantly growing long-term code base, 
 or planning to?


I've been using D for a long-term project for quite a while now.


 There is no way a generic solution can beat a tailored 
 solution when it comes to abstract datatypes and memory 
 management, so having lots of options in a standard library 
 sounds useful.




 Ugh, I said the opposite of what I meant. I don't think having 
 lots of allocation options in a standard library sounds all 
 that useful, since I will most likely roll my own when hitting 
 a serious performance problem. Rolling your own is often the 
 same amount of work as "searching for  a narrow solution" 
 unless you are doing something really complicated.

 I think many standard libraries could be cut down to the most 
 generally useful functionality. In C++ I use std::array or my 
 own data structures, I only occasionally use std::vector… In 
 Python I use no more than 5% of the standard library. Generally 
 useful solutions (like comprehensions) beats narrow solutions 
 99% of the time, because when you need something narrow then 
 the pre-canned narrow solutions often require hacks to serve 
 the purpose (the wrong kind of narrowness or "fits perfectly 
 except it doesn't work when…X…").
May 29 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-05-29 16:03, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:


 But interoperability matters more. Like, I am likely to use Swift for
 ios/osx GUI, but need a companion language for the core application
 engine. C++ is most likely today. If Rust or D makes integration with
 Swift easy then I would consider a switch.


For Swift interfacing with C++ you would need a C or Objective-C layer. 
With the Objective-C support in D (if it will ever be merged) you could 
have a more direct interface, but it would be limited to the Objective-C 
subset.

-- 
/Jacob Carlborg
May 30 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 30 May 2015 at 10:25:19 UTC, Jacob Carlborg wrote:

 For Swift interfacing with C++ you would need a C or 
 Objective-C layer. With the Objective-C support in D (if it 
 will ever be merged) you could have a more direct interface, 
 but it would be limited to the Objective-C subset.


If D is as easier to integrate than Objective-C++ (which 
basically is C+14 with Objective-C tacked on) and with the same 
level of ARM support then that could be a real selling point. You 
would also need Android support though. (Since writing in C/C++ 
is a stepping stone to porting iOS apps to Android).
May 30 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-05-31 08:01, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:


 If D is as easier to integrate than Objective-C++ (which basically is
 C+14 with Objective-C tacked on) and with the same level of ARM support
 then that could be a real selling point. You would also need Android
 support though. (Since writing in C/C++ is a stepping stone to porting
 iOS apps to Android).


I've been trying to write a plugin for TextMate in Swift. TextMate is 
written in C++ with the GUI code in Objective-C. It's quite difficult 
and currently it's probably 50% Objective-C++ code and 50% Swift. Not 
taking in to account the C++ declarations for the TextMate code I need 
to interface with.

That Swift doesn't support exceptions is annoying too, make it even more 
difficult.

-- 
/Jacob Carlborg
May 31 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 31 May 2015 at 09:24:29 UTC, Jacob Carlborg wrote:

 I've been trying to write a plugin for TextMate in Swift. 
 TextMate is written in C++ with the GUI code in Objective-C. 
 It's quite difficult and currently it's probably 50% 
 Objective-C++ code and 50% Swift. Not taking in to account the 
 C++ declarations for the TextMate code I need to interface with.


Interesting, I haven't tried to interface with C++ from Swift 
yet. Sounds like you have gained some insights that could be 
valuable for Swift/D integration.


 That Swift doesn't support exceptions is annoying too, make it 
 even more difficult.


Yes, if your C++ code base/libraries throws, that could be a 
problem.
But it should be ok if you write your own engine that don't use 
exceptions?
May 31 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-05-31 11:44, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:


 Yes, if your C++ code base/libraries throws, that could be a problem.
 But it should be ok if you write your own engine that don't use exceptions?


I was rather in the Swift code I would have like to use exceptions. It's 
easier to bail out by throwing an exception instead of a lot of nested 
if statements. It's possible to do some form of exception handling (and 
throwing) by wrapping try/catch/finally in a Objective-C method and call 
a block for each case, then use that from Swift.

-- 
/Jacob Carlborg
May 31 2015
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 31 May 2015 at 09:24:29 UTC, Jacob Carlborg wrote:

 I've been trying to write a plugin for TextMate in Swift. 
 TextMate is written in C++ with the GUI code in Objective-C. 
 It's quite difficult and currently it's probably 50% 
 Objective-C++ code and 50% Swift. Not taking in to account the 
 C++ declarations for the TextMate code I need to interface with.


I've read a little bit about FFI and Swift now. Since Swift can 
call C using the native Objective-C type aliases (Int32, Int64 
etc) it seems that direction is not so problematic. The ideal 
would be for the D compiler to generate Swift stubs that wrap up 
D-calls as C-interfacing calls, with the necessary type 
conversions specified as UDAs?

Smaller functions could even be translated into pure Swift. You 
probably also could create some kind of standardized wrapper that 
catch exceptions and turn them into something that won't be too 
ugly on the Swift side.

Then you have the other direction, which probably is where your 
Objective-C work is most important. Where you kinda will need a 
Swift parser to generate D stubs, but in that direction you do at 
least not have to deal with exceptions.

Do the same for JNI et al, add ARM support and tune D for 
performant GC… then you have something that could become popular. 
But to get there takes a lot of focused effort…
May 31 2015
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
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.


If awareness of its existence weren't a problem, it wouldn't be a 
long list.  Mostly SPARC/Solaris and Politics (including inertia 
of the current approach).

-Wyatt
May 29 2015
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
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?


I do use it at work, but I also don't really have a collaborative 
codebase. These are usually assistant programs/scripts, our 
primary product is web-based and runs on IIS. I do QA work so not 
involved in the Android/iOS work. I've had complaints that I was 
using D and others wouldn't want to learn it to help contribute, 

on-board to contribute to my projects. I'm back to writing 
whatever I can in D.
May 29 2015
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-05-28 16:38, Manu via Digitalmars-d 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?


I have never (seriously) suggested to use D at my work and rarely even 
think about it because I feel it's hard to justify.

We're mostly developing the backend part of a web based system, with a 
lot of services. Currently we're using Ruby for basically all code. 
There's a couple services written in Go (for performance reason) and one 
or two legacy systems in Java.

We don't have a lot of the issues others have posted here. We don't need 
to run on Andriod/iOS, we don't need a GUI and our code is not as 
performance sensitive that we need to use  forceinline or SIMD.

The biggest issue I see is the lack of libraries. I have not 
investigated exactly what we would need but what I do know we need is:

* Web framework (vibe.d could be used)
* ORM
* Connection to Postgres
* A good testing framework (i.e. something like RSpec)

That's the bare minimum I can think of for now. I know there exist Dub 
packages for some of these but with Ruby it feels much more "safe" to 
use. The Ruby community is so much bigger, so many more developers are 
using the same libraries we're using compared to how it would be in D. 
It's not like Rails or RSpec are suddenly going to disappear.

The GC might be another issue, at least if you look at how many objects 
are created in Ruby. But in D it would be easier to avoid heap allocations.

-- 
/Jacob Carlborg
May 30 2015
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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?


In general, I'd say that the problems are mostly cultural or 
political. Even if D can do everything that we need, there's no 
way that we're moving a large existing codebase to it (the code 
is flaky enough as it is), and even if writing new pieces in D 
would technically work well, it would be adding yet another 
language to the mix for folks to learn. And most of the folks 
that I've worked with really don't care about learning new 
languages, or if they do, just plain getting the work done with 
what they currently have is already a big enough concern that 
they're not going to be in hurry to learn a new one. I'm more 
likely to get labeled as eccentric than to get folks to actually 
want to use D at work if I pushed it. I get labeled that way 
enough just from talking about it. And considering that we 
haven't even found the time yet to switch our codebase to 64-bit, 
I don't think that doing much with D is really on the table at 
this point.

The only technical barriers that I can think of at the moment 
that I might run into if I were to actually switch would relate 
to C/C++ interoperability and shared libraries, and AFAIK, those 
are currently good enough.

- Jonathan M Davis
Jun 01 2015
prev sibling next sibling parent reply "Kelet" <kelethunter gmail.com> writes:
For a small amount of software at work I'm able to use D. Most 
recently, I used D & vibe.d to communicate with a conveyor belt 
system for a warehouse. I'd use it more but most of our code and 
data is tied into a proprietary ecosystem (language, database, 
etc.). Slowly, we're moving away from this ecosystem toward the 
JVM, but I will use D where native code makes sense.

Thanks,
Kelet
Jun 02 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 3/06/2015 3:35 p.m., Kelet wrote:

 For a small amount of software at work I'm able to use D. Most recently,
 I used D & vibe.d to communicate with a conveyor belt system for a
 warehouse. I'd use it more but most of our code and data is tied into a
 proprietary ecosystem (language, database, etc.). Slowly, we're moving
 away from this ecosystem toward the JVM, but I will use D where native
 code makes sense.

 Thanks,
 Kelet


Okay, just so I know you haven't had to deal with one of the worst 
languages ever. It's not jade is it?
Jun 02 2015
parent reply "Kelet" <kelethunter gmail.com> writes:
On Wednesday, 3 June 2015 at 03:47:00 UTC, Rikki Cattermole wrote:

 On 3/06/2015 3:35 p.m., Kelet wrote:

 For a small amount of software at work I'm able to use D. Most 
 recently,
 I used D & vibe.d to communicate with a conveyor belt system 
 for a
 warehouse. I'd use it more but most of our code and data is 
 tied into a
 proprietary ecosystem (language, database, etc.). Slowly, 
 we're moving
 away from this ecosystem toward the JVM, but I will use D 
 where native
 code makes sense.

 Thanks,
 Kelet


 Okay, just so I know you haven't had to deal with one of the 
 worst languages ever. It's not jade is it?


No, our ecosystem revolves around a proprietary and archaic 
dialect of COBOL.

Thanks,
Kelet
Jun 02 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 3/06/2015 5:22 p.m., Kelet wrote:

 On Wednesday, 3 June 2015 at 03:47:00 UTC, Rikki Cattermole wrote:

 On 3/06/2015 3:35 p.m., Kelet wrote:

 For a small amount of software at work I'm able to use D. Most recently,
 I used D & vibe.d to communicate with a conveyor belt system for a
 warehouse. I'd use it more but most of our code and data is tied into a
 proprietary ecosystem (language, database, etc.). Slowly, we're moving
 away from this ecosystem toward the JVM, but I will use D where native
 code makes sense.

 Thanks,
 Kelet


 Okay, just so I know you haven't had to deal with one of the worst
 languages ever. It's not jade is it?


 No, our ecosystem revolves around a proprietary and archaic dialect of
 COBOL.

 Thanks,
 Kelet


Thank goodness. Nothing spew worthy.
Jun 02 2015
prev sibling next sibling parent =?UTF-8?B?IuWyqeWAiSDmvqoi?= <mio.iwakura gmail.com> writes:
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'm pretty lucky, I work at a small startup that does drones for 
agriculture and have had the freedom to pick whatever language I 
think is best for the tasks at hand. As such, we now have some 
image analysis software in the works that is 100% D (save for the 
C libraries it uses and a bit of shell script). That said though, 
it sounds like we're getting ENVI cheap, and I have an 
opportunity to take a training course on extending it with "IDL," 
so that might end up being a better fit for the project in the 
long run.

The other major project I've worked on there is a web app which I 
did in JS as there's hardly any choice in that domain.
Jun 03 2015
prev sibling next sibling parent reply "Chris Piker" <chris hoopjump.com> writes:
On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:

 [...]


I work in an academic setting, so there's alot of freedom.  About 
the only thing really holding me back is that the local 
sys-admins can't:

   $ yum install gcd

on CentOS 7.  If D compilers were available in the standard 
software distribution channels for RedHat based Linux systems, D 
would be considered mainline enough for our use.
Jun 17 2015
parent reply "lobo" <swamplobo gmail.com> writes:
On Thursday, 18 June 2015 at 01:13:10 UTC, Chris Piker wrote:

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

 [...]


 I work in an academic setting, so there's alot of freedom.  
 About the only thing really holding me back is that the local 
 sys-admins can't:

   $ yum install gcd

 on CentOS 7.  If D compilers were available in the standard 
 software distribution channels for RedHat based Linux systems, 
 D would be considered mainline enough for our use.


Can you install to $HOME ?

bye,
lobo
Jun 18 2015
parent reply "Chris Piker" <chris hoopjump.com> writes:
On Thursday, 18 June 2015 at 10:17:49 UTC, lobo wrote:

 On Thursday, 18 June 2015 at 01:13:10 UTC, Chris Piker wrote:

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

 [...]


 About the only thing really holding me back is that the local 
 sys-admins can't:

   $ yum install gcd


 Can you install to $HOME ?


I can do that, but there are other developers in our group.  We 
need to be able to build each other's software.  Java, Python and 
C are accepted as standard languages around here and seem to 
cover all our needs.  Since we have a "complete set" adding a new 
one would be met with resistance.  Having command line tools 
available through standard software distribution channels would 
soften this resistance.
Jun 18 2015
next sibling parent reply "rsw0x" <anonymous anonymous.com> writes:
On Thursday, 18 June 2015 at 16:04:05 UTC, Chris Piker wrote:

 On Thursday, 18 June 2015 at 10:17:49 UTC, lobo wrote:

 On Thursday, 18 June 2015 at 01:13:10 UTC, Chris Piker wrote:

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

 [...]


 About the only thing really holding me back is that the local 
 sys-admins can't:

   $ yum install gcd


 Can you install to $HOME ?


 I can do that, but there are other developers in our group.  We 
 need to be able to build each other's software.  Java, Python 
 and C are accepted as standard languages around here and seem 
 to cover all our needs.  Since we have a "complete set" adding 
 a new one would be met with resistance.  Having command line 
 tools available through standard software distribution channels 
 would soften this resistance.


yum install ldc
?
Jun 18 2015
parent "Chris Piker" <chris hoopjump.com> writes:
On Thursday, 18 June 2015 at 16:10:09 UTC, rsw0x wrote:

 About the only thing really holding me back is that the 
 local sys-admins can't:

   $ yum install gcd






 yum install ldc


Interesting.  With the centos, epel, and rpmforge repositories
enabled:

$ yum search ldc

gives nothing.  Looks like only the fedora folks have this one.
Plus, what problems would you have linking against code that
was compiled with gcc?
--
Chris
Jun 18 2015
prev sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 18 June 2015 at 16:04:05 UTC, Chris Piker wrote:

 On Thursday, 18 June 2015 at 10:17:49 UTC, lobo wrote:

 On Thursday, 18 June 2015 at 01:13:10 UTC, Chris Piker wrote:

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

 [...]


 About the only thing really holding me back is that the local 
 sys-admins can't:

   $ yum install gcd


 Can you install to $HOME ?


 I can do that, but there are other developers in our group.  We 
 need to be able to build each other's software.  Java, Python 
 and C are accepted as standard languages around here and seem 
 to cover all our needs.  Since we have a "complete set" adding 
 a new one would be met with resistance.  Having command line 
 tools available through standard software distribution channels 
 would soften this resistance.


If DMD is sufficient, I'm not really any problems.  Even FHS has 
your back.  Sysadmin does this:

cd /opt;
wget 
http://downloads.dlang.org/releases/2.x/2.067.1/dmd.2.067.1.linux.zip -qO
tmp.zip \
&& unzip tmp.zip \
&& rm tmp.zip \
&& echo 'export PATH="${PATH}:/opt/dmd2/linux/bin64"' >> 
/etc/profile

...and voila.  It might be kind of nice to have a "latest" 
symlink for the download (e.g. 
http://downloads.dlang.org/releases/latest/dmd.latest.zip), but 
that'd just be icing.

Alternatively, ask have them make you a group-writable volume to 
use as a --prefix for everything that you might want (we ended up 
doing this because CantOS so strongly resembles LFS when you want 
to accomplish anything useful).  Or have people add ~cpiker/bin 
(or whatever your HOME is) to their PATH in ~/.profile (or just 
add the path in your Makefiles, if you're feeling evil).

It could certainly be better, but I wouldn't personally consider 
it a blocker as things are.

-Wyatt
Jun 18 2015
parent "Chris Piker" <chris hoopjump.com> writes:
On Thursday, 18 June 2015 at 20:09:58 UTC, Wyatt wrote:

 If DMD is sufficient, I'm not really any problems.  Even FHS 
 has your back.  Sysadmin does this:
 ...


Cool! Found it:

   $ yum search dmd
   dmd.x86_64 : Digital Mars D Compiler

Hum, wheels will start turning now...  Thanks guys!
--
Chris
Jun 18 2015
prev sibling next sibling parent reply "Poyeyo" <poyeyo arcadechaser.com> writes:
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.

 [...]


Lack of a complete MySQL driver. No DECIMAL support that I know 
of. Lack of MySQL support in vibe.d.
Jul 15 2015
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 07/15/2015 12:06 PM, Poyeyo wrote:

 Lack of a complete MySQL driver. No DECIMAL support that I know of. Lack
 of MySQL support in vibe.d.


Please file any issues you may have with mysql-native here:
https://github.com/mysql-d/mysql-native

Or ping any existing issues that you may need to ping.
Jul 15 2015
parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 15 July 2015 at 18:57:35 UTC, Nick Sabalausky wrote:

 On 07/15/2015 12:06 PM, Poyeyo wrote:

 Lack of a complete MySQL driver. No DECIMAL support that I 
 know of. Lack
 of MySQL support in vibe.d.


 Please file any issues you may have with mysql-native here:
 https://github.com/mysql-d/mysql-native

 Or ping any existing issues that you may need to ping.


https://github.com/mysql-d/mysql-native/issues/39 ?
Jul 16 2015
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 07/16/2015 04:56 AM, Kagamin wrote:

 On Wednesday, 15 July 2015 at 18:57:35 UTC, Nick Sabalausky wrote:

 On 07/15/2015 12:06 PM, Poyeyo wrote:

 Lack of a complete MySQL driver. No DECIMAL support that I know of. Lack
 of MySQL support in vibe.d.


 Please file any issues you may have with mysql-native here:
 https://github.com/mysql-d/mysql-native

 Or ping any existing issues that you may need to ping.


 https://github.com/mysql-d/mysql-native/issues/39 ?


That was closed as fixed last year. Have you hit a problem with the fix?
Jul 16 2015
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 15.07.2015 um 18:06 schrieb Poyeyo:

 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.

 [...]


 Lack of a complete MySQL driver. No DECIMAL support that I know of. Lack
 of MySQL support in vibe.d.


The mysql-native driver is fully vibe.d compatible.
Jul 16 2015
parent reply "sclytrack" <sclytrack fake.com> writes:
On Thursday, 16 July 2015 at 12:04:11 UTC, Sönke Ludwig wrote:

 Am 15.07.2015 um 18:06 schrieb Poyeyo:

 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.

 [...]


 Lack of a complete MySQL driver. No DECIMAL support that I 
 know of. Lack
 of MySQL support in vibe.d.


 The mysql-native driver is fully vibe.d compatible.



What is the postgresql variant for vibe.d?

There are so many database api's for D.
Jul 16 2015
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 16.07.2015 um 14:18 schrieb sclytrack:

 On Thursday, 16 July 2015 at 12:04:11 UTC, Sönke Ludwig wrote:

 Am 15.07.2015 um 18:06 schrieb Poyeyo:

 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.

 [...]


 Lack of a complete MySQL driver. No DECIMAL support that I know of. Lack
 of MySQL support in vibe.d.


 The mysql-native driver is fully vibe.d compatible.



 What is the postgresql variant for vibe.d?

 There are so many database api's for D.


Should be https://github.com/pszturmaj/ddb
Jul 16 2015
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 16.07.2015 um 14:42 schrieb Sönke Ludwig:

 Am 16.07.2015 um 14:18 schrieb sclytrack:

 What is the postgresql variant for vibe.d?

 There are so many database api's for D.


 Should be https://github.com/pszturmaj/ddb


Unfortunately the author doesn't seem to be active anymore since about a 
year.
Jul 16 2015
prev sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
By the way.. does anyone know if Sociomantic accepts remote D jobs?
Jul 15 2015
next sibling parent "Adrian Matoga" <epi atari8.info> writes:
On Wednesday, 15 July 2015 at 16:27:56 UTC, Piotr Szturmaj wrote:

 By the way.. does anyone know if Sociomantic accepts remote D 
 jobs?


I guess it's best to ask them directly.
BTW, I was hoping maybe for a software division in Warsaw office.
Jul 16 2015
prev sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 7/15/15, Piotr Szturmaj via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 By the way.. does anyone know if Sociomantic accepts remote D jobs?


Not currently that I'm aware of. There were some exceptions, but this
is rare. You can always e-mail careers sociomantic.com to find out
more. :)
Jul 16 2015