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?
We develop tailor made CRM/ERP solutions, mostly in C# or ASP.net. On the client side, it's obvious why I can't convince anyone to use D (lack of standard GUI, lack of i18n support, unavailability on WinRT/iOS/Android) On the server side, vibe.d cannot compete with asp.net (AD/SQL/Sharepoint/Office integration, Razor syntax, IDE integration, report generation). Therefore I took advantage of a situation we encountered - payroll calculation for a big client (>50000 payrolls) took more than 6 hours to complete. So I tried to write some payroll calculation components in D. The main problems encountered were: - lack of a decimal data type - you cannot perform monetary calculation using floating point. - lack of a chinese or japanese calendar in the std.datetime module; - missing of overflow checks for integral data types;
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 ==> http://dlang.org/phobos/std_algorithm_searching.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, switching to our company language (C#) didn't help in getting 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