www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Questionnaire

reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
1. Why your company uses  D?

   a. D is the best
   b. We like D
   c. I like D and my company allowed me to use D
   d. My head like D
   e. Because marketing reasons
   f. Because my company can be more efficient with D for some 
tasks then with any other system language

2. Does your company uses C/C++, Java, Scala, Go, Rust?

3. If yes, what the reasons to do not use D instead?

2. Have you use one of the following Mir projects in production:

   a. https://github.com/libmir/mir
   b. https://github.com/libmir/mir-algorithm
   c. https://github.com/libmir/mir-cpuid
   d. https://github.com/libmir/mir-random
   e. https://github.com/libmir/dcv - D Computer Vision Library
   f. std.experimental.ndslice

3. If Yes, can Mir community use your company's logo in a section 
"Used by" or similar.

4. Have you use one of the following Tamedia projects in your 
production:

   a. https://github.com/tamediadigital/asdf
   b. https://github.com/tamediadigital/je
   c. https://github.com/tamediadigital/lincount

5. What D misses to be commercially successful languages?

6. Why many topnotch system projects use C programming language 
nowadays?

=========================

All my current D project are finished. Probably I will use other 
languages for production this year, Java/Go/whatever. Mir 
libraries are amazing and good quality. If you use them this 
would be a good motivation for us to improve the docs and provide 
regular updates. Plus, it can be enchanted during the GSoC 2017.

Thanks,
Ilya
Feb 08 2017
next sibling parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
 Plus, it can be enchanted during the GSoC 2017.
EDIT: enhanced
Feb 08 2017
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 02/08/2017 01:27 PM, Ilya Yaroshenko wrote:
 1. Why your company uses  D?

    a. D is the best
    b. We like D
    c. I like D and my company allowed me to use D
    d. My head like D
    e. Because marketing reasons
    f. Because my company can be more efficient with D for some tasks
 then with any other system language
x. Because I'm self-employed so I get to choose the best tool for the job instead of whatever some know-nothing manager thinks "must be good because its popular". Also, all of the above.
 2. Does your company uses C/C++, Java, Scala, Go, Rust?
Not when I can help it.
 3. If yes, what the reasons to do not use D instead?
If, for whatever reason, my hands are tied and it's just not a possibility. Usually platform/framework compatibility. Or somebody above me deciding "You must use language X". (But, after having had more than enough PHP/VB/Java/C++/Python/etc in my life, I'm more inclined now to simply avoid situations that would involve such restraints. Life's too short to suffer bad tools for bad reasons.)
 2. Have you use one of the following Mir projects in production:
No. I keep hearing about Mir, but still haven't quite wrapped my head around what it is, or how/where to use it. (and that bugs me)
 3. If Yes, can Mir community use your company's logo in a section "Used
 by" or similar.
N/A
 4. Have you use one of the following Tamedia projects in your production:

    a. https://github.com/tamediadigital/asdf
    b. https://github.com/tamediadigital/je
    c. https://github.com/tamediadigital/lincount
First I've heard of them. I'll take a look.
 5. What D misses to be commercially successful languages?
A groupthink mentality and loads of bad ideas and broken reasoning. Ie, the basic requirements for anything to be popular in the computing arena. Seriously. I'm not joking. Well, that and, nobody's ever really been in a situation where they're more or less FORCED to use D. Many, heck probably most, big-name languages got big because there were enough people who didn't have much of a choice: - Earlier days of Unix/Linux dev? Hard to avoid C/C++. - Work for a company that's heavily invested in MS tools? Hard to avoid - Work for a non-MS-based enterprise? Hard to avoid Java, because that's what the higher-ups had already been sold on. - Need to use a relational DB? SQL, period. - Need client-side scripting on a web page? JavaScript, period (until just recently). - If you wanted an MVC web framework, for a short while Ruby was the only choice. I guarantee Ruby would be more popular today if that time period had been longer. It's undeniable nobody would've ever heard of Ruby were it not for Rails. - Need to run something on an affordable commodity server in the late 90's/2000's? PHP, period. Unless you paid an extra $5-$10/mo. and restricted your choice of providers - then you could use VBScript/ASP, which was basically the same exact thing as PHP, but just incompatible. - Need low-level hardware access, memory management or other direct control over performance and resource usage? Until recently, had to be C/C++. Then once onboard, stockholm syndrome sets in. Instant popularity. Coercion (and perceived coercion[1] for that matter) makes technologies popular far more than any other factor. The computing sector is NOT a marketing flaw, period. If you nail that coercion part, it doesn't matter HOW badly you do on any other technical or marketing aspect. Been proven time and time again. And if you DON'T have that coercion, you face an uphill battle no matter how good you do on technical and marketing fronts. Also been proven time and time again. [1] The "I must keep up or get left behind" thought train. See also "Cover Fire" and the Fire and Motion stuff here: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
 6. Why many topnotch system projects use C programming language nowadays?
Partly inertia, but also because there was a decade or two (that only ended a few years ago) where nearly all language designers obsessed over VMs and eliminating low-level capabilities, and in general dumbing down their languages to the point of uselessness for anyone but novices, hobbyists, and those who could afford to throw money/hardware at any and all performance/resource/scalability issues[2]. Because of that, for many C/C++ users, there simply was no realistic alternative, period. [2] I'm sure 90's Sun LOVED their JVM/Java - it virtually guaranteed "optimization" could only mean "rent/buy more hardware" - Everything else besides reducing algorithmic complexity was deliberately banned by both the language and the VM...as a self-proclaimed "feature" no less. That "feature" allegedly being for safety, but decades of security patches and exploits for every VM on the planet proved that to be a load of...male cow.
Feb 08 2017
parent reply Joakim <dlang joakim.fea.st> writes:
I'm not going to fill out the questionnaire because I'm not at a 
company and have not tried Mir, but two points about what Nick 
and Mike wrote.

On Wednesday, 8 February 2017 at 20:40:48 UTC, Nick Sabalausky 
wrote:
 Coercion (and perceived coercion[1] for that matter) makes 
 technologies popular far more than any other factor. The 
 computing sector is NOT a meritocracy, not by a longshot. That 

 nail that coercion part, it doesn't matter HOW badly you do on 
 any other technical or marketing aspect. Been proven time and 
 time again. And if you DON'T have that coercion, you face an 
 uphill battle no matter how good you do on technical and 
 marketing fronts. Also been proven time and time again.
I agree that "coercion," or more accurately the tyranny of the default, is the dominant factor in language popularity even today, but you're reaching when you apply that to web frameworks too. As you admit, rails didn't become as big as it might have because there were quickly many other web frameworks, ie languages and frameworks on the server are very competitive and that market is very fragmented, though PHP is likely the biggest. D's problem on the client is that the popular platforms are still very much tied to certain favored languages: iOS - ObjC and Swift Android non-game apps - Java Android games - C/C++ Web - Javascript Three of the four major client platforms all allow other languages (with the fourth starting to with WebAssembly), but you're often fighting the tide if you choose a non-default language so most don't bother. We can make the dev experience more pleasant on those platforms, as I believe has happened now that we support the MS toolchain on Windows, but D is unlikely to become popular without a killer app that demonstrates its suitability. That's not coercion, but something we can actually control. On Thursday, 9 February 2017 at 00:30:53 UTC, Mike wrote:
 I think the D leadership are too busy addressing broader issues 
 with the language at the moment, so this specific case is just 
 not a high priority.  Also, if it's not a priority to the them, 
 then anyone that does attempt to work on it will just suffer an 
 eternity in pull request purgatory.

 So, I would not recommend it as a project for anyone until the 
 D leadership decides to get involved.
I think this misunderstands how open source works: the whole point is that you don't need anybody's permission to go do this. Walter and Andrei, or any other OSS core team, are much more likely to approve something if you have an implementation that works well. Look at Ilya and what happened after he showed them Mir. Now, you may not want to go do this on your own if you believe it's a lot of effort, could use a design the core team may not approve, and don't want to maintain or develop your own fork indefinitely, but that's a lot of "if"s. I doubt it would be a lot of effort to strip D down like this, but I have not looked into it.
Feb 08 2017
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 02/09/2017 01:08 AM, Joakim wrote:
 I agree that "coercion," or more accurately the tyranny of the default,
 is the dominant factor in language popularity even today, but you're
 reaching when you apply that to web frameworks too.
Fair enough. It was just another example trying to make the point that "if you want to do X, then you have little choice but use Y" is, as you say, the dominant factor in language popularity. I can grant that the web framework examples are weaker examples.
 D's problem on the client is that the popular platforms are still very
 much tied to certain favored languages:

 iOS - ObjC and Swift
 Android non-game apps - Java
 Android games - C/C++

 Web - Javascript

 Three of the four major client platforms all allow other languages (with
 the fourth starting to with WebAssembly), but you're often fighting the
 tide if you choose a non-default language so most don't bother.
That's a good way of explaining it, I like that.
 We can make the dev experience more pleasant on those platforms, as I
 believe has happened now that we support the MS toolchain on Windows,
 but D is unlikely to become popular without a killer app that
 demonstrates its suitability.  That's not coercion, but something we can
 actually control.
I hope you're right, but I worry that even "killer app example" may not be enough, and that the lack of one may turn out to be just another red herring excuse for "why aren't using D". After all, I think vibe's approach to server development comes very close to "killer app" yet, far as I've seen, it doesn't appear to have proven a major win for D so far. Then again, having D in the "my secret weapon" category has certain benefits, too, so I guess I can't be TOO sour ;)
 On Thursday, 9 February 2017 at 00:30:53 UTC, Mike wrote:
 I think the D leadership are too busy addressing broader issues with
 the language at the moment, so this specific case is just not a high
 priority.  Also, if it's not a priority to the them, then anyone that
 does attempt to work on it will just suffer an eternity in pull
 request purgatory.

 So, I would not recommend it as a project for anyone until the D
 leadership decides to get involved.
I think this misunderstands how open source works: the whole point is that you don't need anybody's permission to go do this. Walter and Andrei, or any other OSS core team, are much more likely to approve something if you have an implementation that works well. Look at Ilya and what happened after he showed them Mir.
You're right, in theory. But Mike is unfortunately very right about the whole "suffer an eternity in pull request purgatory." I fixed an issue where "///"-style doc comments resulted in excessive paragraph breaks...must've been over a year ago. Simple fix for a nagging bug. The fix worked. Caused no problems. No controversy. And to this day, just went completely ignored despite my periodic nagging about it. Eventually got tired wasting my time babysitting the constant need for rebasing and manual merge fixes just for something that proved guaranteed to be ignored. And any PRs I have managed to get through were all uphill battles the whole way. We have far too high a threshold for letting things actually happen. It didn't used to be that way, and that was a key reason why D became as good as it's gotten in the first place. So I'm not surprised people familiar with D go to lengths to avoid putting the effort into PRs that are much more major than my comparatively trivial PRs: It's proven to come with a depressingly high likelihood of turning out to be a complete waste of time. At the risk of sounding hyperbolic, I think this is D's next biggest problem after the lack of any "If you want to do X, your only real choice is D". Though I admit I might be a little biased on this particular point though.
Feb 08 2017
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/8/2017 11:09 PM, Nick Sabalausky wrote:
 I fixed an issue where "///"-style doc comments resulted in excessive paragraph
 breaks...must've been over a year ago. Simple fix for a nagging bug. The fix
 worked. Caused no problems. No controversy. And to this day, just went
 completely ignored despite my periodic nagging about it. Eventually got tired
 wasting my time babysitting the constant need for rebasing and manual merge
 fixes just for something that proved guaranteed to be ignored. And any PRs I
 have managed to get through were all uphill battles the whole way.
The PR in question: https://github.com/dlang/dmd/pull/4745 It took me a while to find it, because you were using a pseudonym that I did not recognize. There are a number of frequent contributors to D using pseudonyms, and all have this issue with varying degrees. I do not understand using pseudonyms on github. It can hardly be a privacy issue, as github doesn't hide your name. But it definitely impedes your "brand", i.e. your reputation, as it becomes divided in two. Github does not provide a "reverse phone book" where I can search for a PR under your name, nor does it provide any sort of cross reference. Searching (via github) the dmd repository for your name turns up nothing. I found it by searching the notification emails I get from github, which ironically are sent using your name rather than Abscissa (further confusing matters). I suppose I could write a cheat sheet and tape it to the wall of my office, but why not just use your name?
Feb 09 2017
next sibling parent evilrat <evilrat666 gmail.com> writes:
On Thursday, 9 February 2017 at 08:02:23 UTC, Walter Bright wrote:
 I do not understand using pseudonyms on github. It can hardly 
 be a privacy issue, as github doesn't hide your name. But it 
 definitely impedes your "brand", i.e. your reputation, as it 
 becomes divided in two. Github does not provide a "reverse 
 phone book" where I can search for a PR under your name, nor 
 does it provide any sort of cross reference. Searching (via 
 github) the dmd repository for your name turns up nothing.
One of the reasons could be simply because one is known under a nickname on a bunch of other resources where he posts to, and that now working for the reputation too - because posting something with other name could get you banned or just people looking with suspicious for any code and links posted. Now, since we on D forum and that "other" world reputation doesn't matter here or any other reasons, some will prefer just using "real" name. Some people also avoid using their work-associated emails with personal/fan projects. Because of same thing with reputation/proffesionalism/etc., (unnecesary questions from employer too? just a guess, whatever) And more, and more... Things are complicated.
Feb 09 2017
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 9 February 2017 at 08:02:23 UTC, Walter Bright wrote:
 I suppose I could write a cheat sheet and tape it to the wall 
 of my office, but why not just use your name?
It shouldn't matter who wrote it. Review the code, not the author, especially on small ones like this which new contributors might be using to test the waters.
Feb 09 2017
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Thursday, 9 February 2017 at 08:02:23 UTC, Walter Bright wrote:
 The PR in question:

   https://github.com/dlang/dmd/pull/4745

 It took me a while to find it, because you were using a 
 pseudonym that I did not recognize. There are a number of 
 frequent contributors to D using pseudonyms, and all have this 
 issue with varying degrees.
This is a fair point in its own right, but it's completely orthogonal to the issue Nick is complaining about -- which is that after some initial interest and feedback, the PR just got left alone with no decision to accept or reject it, and no indication of why. That's really a very unpleasant situation to face, regardless of whether the contributor in question is a well-known name or some complete anonymous stranger. I have a PR of my own that's been in this situation for (only!) a month now, and it's distinctly frustrating, particularly because it was a contribution that Andrei specifically called for on these forums: https://github.com/dlang/phobos/pull/5011 (... Andrei's request: https://forum.dlang.org/post/o1cqdb$245o$1 digitalmars.com) Contrast this with the experience I had the one time I submitted a (tiny, trivial) patch to rust: immediately after submitting the PR I got a message from their 'highfive' robot that included: * a friendly thank you for the PR; * the GitHub ID of a contact who I could expect to be taking responsibility for the PR, who was also assigned as a reviewer; * some helpful notes on how to add changes to the PR if requested; * a link to the contributor guidelines. By contrast with a Phobos PR it's not clear who to contact if review or decision-making is not forthcoming. There's clearly in part a scaling problem here (in terms of how many people are available in general, and in terms of how many people have expertise on particular parts of the library) but it also feels like a few simple things (like making sure every PR author is given a reliable contact or two who they can feel entitled to chase up) could make a big difference.
Feb 09 2017
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/9/2017 8:48 AM, Joseph Rushton Wakeling wrote:
 Contrast this with the experience I had the one time I submitted a (tiny,
 trivial) patch to rust: immediately after submitting the PR I got a message
from
 their 'highfive' robot that included:

   * a friendly thank you for the PR;

   * the GitHub ID of a contact who I could expect to be taking responsibility
     for the PR, who was also assigned as a reviewer;

   * some helpful notes on how to add changes to the PR if requested;

   * a link to the contributor guidelines.

 By contrast with a Phobos PR it's not clear who to contact if review or
 decision-making is not forthcoming.
Good idea! Please investigate how to get github to generate such emails. In the meantime, the PR guidelines are here: http://wiki.dlang.org/Starting_as_a_Contributor#Create_a_pull_request The teams can be found here: https://github.com/orgs/dlang/teams Please help improve the guidelines.
Feb 09 2017
parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 9 February 2017 at 19:36:52 UTC, Walter Bright wrote:
 Good idea! Please investigate how to get github to generate 
 such emails. In the meantime, the PR guidelines are here:
This is already somewhat done with the PR bot we have. The DlangBot notifies reviewers on the DMD repo, but not Phobos for some reason. All it does on Phobos is auto close bugzilla issues when a bug fix PR is pulled into master. I say enable the bot for Phobos. It would be a small task to also have the bot post the PR guidelines. I think Martin is the maintainer of the bot.
Feb 09 2017
parent reply Seb <seb wilzba.ch> writes:
On Thursday, 9 February 2017 at 19:42:03 UTC, Jack Stouffer wrote:
 On Thursday, 9 February 2017 at 19:36:52 UTC, Walter Bright 
 wrote:
 Good idea! Please investigate how to get github to generate 
 such emails. In the meantime, the PR guidelines are here:
We gave this a try a couple of months ago with Facebook's mention-bot: Example: https://github.com/dlang/phobos/pull/4318#issuecomment-241817191 Repo: https://github.com/dlang-bots/mention-bot Eventually I disabled it because people complained about the added noise.
 This is already somewhat done with the PR bot we have. The 
 DlangBot notifies reviewers on the DMD repo, but not Phobos for 
 some reason. All it does on Phobos is auto close bugzilla 
 issues when a bug fix PR is pulled into master.
It does a bit more (e.g. since a couple of weeks it can also automatically merge PR once all CI status checks pass)
 I say enable the bot for Phobos. It would be a small task to 
 also have the bot post the PR guidelines.
As mentioned above, the bot is already enabled and it receives all interesting hook events from Phobos, see e.g.: https://github.com/dlang-bots/dlang-bot/blob/master/source/dlangbot/app.d#L124
 I think Martin is the maintainer of the bot.
You can find the code here: https://github.com/dlang-bots/dlang-bot
Feb 09 2017
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Thursday, 9 February 2017 at 19:58:57 UTC, Seb wrote:
 We gave this a try a couple of months ago with Facebook's 
 mention-bot:

 Example: 
 https://github.com/dlang/phobos/pull/4318#issuecomment-241817191
 Repo: https://github.com/dlang-bots/mention-bot

 Eventually I disabled it because people complained about the 
 added noise.
It's great that you gave this a go. Seriously, people considered one small informative post in the PR to be "added noise"? :-( Out of curiosity: is it typical that it would not post until some way into the discussion (as in that example)? I could see why it would be irritating if it popped up once discussion and review had already started happening. Assuming that the bot can be relied on to be 'first responder' to any PR, I'm happy to try to draft an alternative text for it to post (and maybe also look at what texts it can link to).
Feb 09 2017
parent Seb <seb wilzba.ch> writes:
On Thursday, 9 February 2017 at 20:12:06 UTC, Joseph Rushton 
Wakeling wrote:
 Out of curiosity: is it typical that it would not post until 
 some way into the discussion (as in that example)?  I could see 
 why it would be irritating if it popped up once discussion and 
 review had already started happening.
We enabled it at this point and thus the mention-bot hasn't had a comment for this PR. This was simply the first PR I found.
 Assuming that the bot can be relied on to be 'first responder' 
 to any PR
Yes, It safely be relied on this fact (it uses Vibe.d). Moreover, the dlang-bot updates its comment on every new PR event.
 I'm happy to try to draft an alternative text for it to post 
 (and maybe also look at what texts it can link to).
Thanks a lot for pushing this! Let's move this discussion over to the dlang-bot: https://github.com/dlang-bots/dlang-bot/pull/44
Feb 11 2017
prev sibling next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 9 February 2017 at 16:48:16 UTC, Joseph Rushton 
Wakeling wrote:
 which is that after some initial interest and feedback, the PR 
 just got left alone with no decision to accept or reject it, 
 and no indication of why.
This is why I only contribute to Phobos to be quite honest. I count ten active reviewers with pull rights on Phobos. The other repos, tools: one dmd: three druntime: three dlang.org: two
Feb 09 2017
prev sibling parent reply Jon Degenhardt <jond noreply.com> writes:
On Thursday, 9 February 2017 at 16:48:16 UTC, Joseph Rushton 
Wakeling wrote:
 There's clearly in part a scaling problem here (in terms of how 
 many people are available in general, and in terms of how many 
 people have expertise on particular parts of the library) but 
 it also feels like a few simple things (like making sure every 
 PR author is given a reliable contact or two who they can feel 
 entitled to chase up) could make a big difference.
Regarding the scaling problem - Perhaps the bug system could be used to help engage a wider community of reviewers. Specifically, update the bugzilla ticket early in the PR lifecycle as an alerting mechanism. This idea comes from my experiences so far. I've found any number of bugs and enhancements in the bug system that directly interact with things I'm implementing. I typically add myself to CC list so I hear about changes. In many of these cases I'd be willing to help with reviewing. However, when a PR associated with the issue is created, the ticket itself is normally not updated until after the review is finished and the PR closed, to late to help out. Of course, someone like myself, a part-timer to the community at best, should not be a primary reviewer. However, for specific issues, it's often the case that I've studied the area of code involved. If there is a wider set of people in a similar situation perhaps this might help engage a wider set of people. --Jon
Feb 09 2017
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/9/2017 1:45 PM, Jon Degenhardt wrote:
However, when a PR
 associated with the issue is created, the ticket itself is normally not updated
 until after the review is finished and the PR closed, to late to help out.
It normally is. I do it for all mine and for others I notice that have not so.
Feb 09 2017
prev sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 02/09/2017 03:02 AM, Walter Bright wrote:
 It took me a while to find it, because you were using a pseudonym that I
 did not recognize. There are a number of frequent contributors to D
 using pseudonyms, and all have this issue with varying degrees.
[...]
 I suppose I could write a cheat sheet and tape it to the wall of my
 office, but why not just use your name?
Partly because I just like online handles. Also, brevity: "Sabalausky" is a bit of a monster and also tends to intimidate the crap out anyone trying to pronounce it (and very understandably so). "Abscissa" is shorter than my last name alone, easier to spell, plus I've been using it for about 20 years, so it's kind of just habit now and almost just as much a name to me online as "Nick". Not that it's much easier to pronounce (except for those well-versed in uncommonly-used math terminology), but it's probably at least a little less panic-inducing, pronunciation-wise ;) And online (in general anyway), I like that "Abscissa" is less uniquely-identifiable than my name - unlike my name, there actually ARE other people going by "Abscissa". I like having my online identity split into multiple ones, and I like the lack of clarity as to which "Abscissa" fellas are the same ones: It creates privacy in a frontier that is increasingly "privatized big brother". Reliably-unique real names like mine are a data miner's dream - may as well be going by my social security number. Unlike "Abscissa", anyone going by "Nick Sabalausky" is either me or somebody deliberately impersonating me. In any case, your point is certainly a valid one. I've adjusted my newsreader to include Abscissa along with my real name, so hopefully that will at least help.
Feb 12 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/8/2017 11:09 PM, Nick Sabalausky wrote:
 And any PRs I have managed to get through were all uphill battles the whole
way.
You have contributed 5 PRs to dmd: https://github.com/dlang/dmd/pulls?q=is%3Apr+author%3Aabscissa 1 is open (it's controversial) 1 closed (today by me) 3 merged 1 in 6 days 2 in 1 day Overall, I think you've done well. https://github.com/dlang/druntime/pulls?q=is%3Apr+author%3Aabscissa 5 PRs, 3 merged. https://github.com/dlang/phobos/pulls?q=is%3Apr+author%3Aabscissa 14 PRs, 1 merged. (I didn't check all the reviews, but the ones I did looked fair.) --- In any case, shouldn't it be an uphill battle to merge things? There are a lot of things that need to be satisfied to merge something. Being too hasty leads to legacy code that we come to regret, angry people whose code was broken, and technical debt. Check out our current list of regressions: https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=213638&query_format=advanced Hasty merges wind up there, and usually someone other than the one who broke it has to fix it.
Feb 09 2017
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Thursday, 9 February 2017 at 09:49:53 UTC, Walter Bright wrote:
 In any case, shouldn't it be an uphill battle to merge things? 
 There are a lot of things that need to be satisfied to merge 
 something. Being too hasty leads to legacy code that we come to 
 regret, angry people whose code was broken, and technical debt.
There's a difference between it being an uphill battle because review and feedback are careful, cautious, in-depth and strict (as they should be!), versus it being an uphill battle because no feedback or interest is being offered and PRs are left to bitrot. :-( I accept that there are a lot of things that need to be satisfied to merge something. Personally speaking, I'm willing to endure any number of rebases and conflict-fixes, so long as I'm getting feedback and engagement that allows my PR to become better code. It's when I'm _not_ getting any indicators as to what needs to be satisfied that things become problematic.
Feb 09 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/9/2017 8:55 AM, Joseph Rushton Wakeling wrote:
 On Thursday, 9 February 2017 at 09:49:53 UTC, Walter Bright wrote:
 In any case, shouldn't it be an uphill battle to merge things? There are a lot
 of things that need to be satisfied to merge something. Being too hasty leads
 to legacy code that we come to regret, angry people whose code was broken, and
 technical debt.
There's a difference between it being an uphill battle because review and feedback are careful, cautious, in-depth and strict (as they should be!), versus it being an uphill battle because no feedback or interest is being offered and PRs are left to bitrot. :-(
That certainly does happen, but it isn't quite the case with Nick's PRs.
 I accept that there are a lot of things that need to be satisfied to merge
 something.  Personally speaking, I'm willing to endure any number of rebases
and
 conflict-fixes, so long as I'm getting feedback and engagement that allows my
PR
 to become better code.  It's when I'm _not_ getting any indicators as to what
 needs to be satisfied that things become problematic.
There's a lot going on needing attention, and sometimes a bit of championing is needed by their proponents. Also, please keep in mind that the smaller and more focussed a PR is, the more likely it'll have a quick resolution.
Feb 09 2017
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Thursday, 9 February 2017 at 19:53:37 UTC, Walter Bright wrote:
 There's a lot going on needing attention, and sometimes a bit 
 of championing is needed by their proponents.
Yes, but it could be good to examine what can be done to more pro-actively look at open PRs that have had no recent follow-up. It's not really going to work that well if attention gets given substantially on the basis of who's most eagerly seeking it. People like that metaphor "It's the squeaky wheel that gets the grease", but as a first aid trainer once pointed out to me, the quieter patient may be the one more in need of immediate attention.
 Also, please keep in mind that the smaller and more focussed a 
 PR is, the more likely it'll have a quick resolution.
Unfortunately my current one is large with good reason. But I think you'll find I also provided very detailed commit messages to explain and justify all my changes ;-)
Feb 09 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/9/2017 12:29 PM, Joseph Rushton Wakeling wrote:
 Yes, but it could be good to examine what can be done to more pro-actively look
 at open PRs that have had no recent follow-up.
*Anyone* in this community can step up and do that.
Feb 09 2017
next sibling parent Daniel Kozak via Digitalmars-d-announce writes:
Dne 9.2.2017 v 21:43 Walter Bright via Digitalmars-d-announce napsal(a):

 On 2/9/2017 12:29 PM, Joseph Rushton Wakeling wrote:
 Yes, but it could be good to examine what can be done to more 
 pro-actively look
 at open PRs that have had no recent follow-up.
*Anyone* in this community can step up and do that.
This obviously does not work :(
Feb 09 2017
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Thursday, 9 February 2017 at 20:43:00 UTC, Walter Bright wrote:
 *Anyone* in this community can step up and do that.
Anyone can make observations and proposals, but not everyone has the authority to effect change. I appreciate how frustrating it must be to have people saying, 'Hey, do this! Do that!' without necessarily volunteering their own efforts in support, but organizational improvements so very often fail unless they are eagerly pursued at a leadership level.
Feb 09 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/9/2017 1:06 PM, Joseph Rushton Wakeling wrote:
 On Thursday, 9 February 2017 at 20:43:00 UTC, Walter Bright wrote:
 *Anyone* in this community can step up and do that.
Anyone can make observations and proposals, but not everyone has the authority to effect change.
Anyone can proactively look at, review, analyze, etc. any PR.
 I appreciate how frustrating it must be to have people saying, 'Hey, do this!
 Do that!' without necessarily volunteering their own efforts in support, but
 organizational improvements so very often fail unless they are eagerly pursued
 at a leadership level.
There are 29 people with commit privileges on Phobos: https://github.com/orgs/dlang/teams/team-phobos What do you suggest? What are you willing to step up and do?
Feb 09 2017
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Thursday, 9 February 2017 at 23:44:31 UTC, Walter Bright wrote:
 I appreciate how frustrating it must be to have people saying, 
 'Hey, do this! Do that!' without necessarily volunteering their
 own efforts in support, but organizational improvements so very
 often fail unless they are eagerly pursued at a leadership
 level.
Before I respond, just wanted to say: I hope the above didn't come over as a personal attack, it wasn't meant as one. I was speaking in general about my experience of what can best influence change.
 There are 29 people with commit privileges on Phobos:

   https://github.com/orgs/dlang/teams/team-phobos

 What do you suggest? What are you willing to step up and do?
I'm painfully aware that I have limited ability to commit time and energy right now. I think that's one reason have been pushing this discussion: because my time is limited, when I _do_ find time to craft some code and send it to Phobos or elsewhere, it's quite precious to me, and I try to take a lot of care over it. It's not very nice to feel that this time is wasted because no one is paying attention to the results, and it's not very nice to feel that this is a situation that is just accepted. So, that said, what would I suggest? Well, 29 people with commit privileges is less than 4 currently-open PRs per person. Let's be conservative and suppose 10 of them are regularly active. What I would suggest is it takes one or two people with authority (important caveat, more on this in a moment) to periodically nudge those 10+ people about any PRs that (i) do not have an assigned reviewer with commit rights or (ii) do have an assigned reviewer but haven't had any activity in more than, say, 2 weeks. This doesn't need to be orders (impossible in a volunteer project) -- just encouraging requests for help and awareness-raising to make sure that no PR falls behind. Then in turn, the 10+ people with commit rights need to be actively encouraging appropriate people to review the PRs they are responsible for, with the sense that it strongly matters that no PR author feels they're being abandoned (a feeling which needs to be encouraged by the top people: if the people with commit rights aren't nudging the reviewers on a particular PR, they need to be nudged themselves). The authority bit matters because the one or two people at the top need to be able to field the questions that the 10+ with commit rights can't decide for themselves -- in a way that helps them understand the principles behind those decisions so that they can apply them themselves, confident that they're not going to be knocked back if the apply the same principles in future. Basically, the role of the senior authority figure here is to support the people with commit rights in learning how to make decisions which won't need to be countermanded. No one person scales, but 10 people who understand 95% of that one person's thought _can_ -- and they can pass on that understanding to others. Of course, I understand that I might be suggesting things that have been tried and have not worked out. But you asked for my suggestions, so ... that's what seems important to me.
Feb 10 2017
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 02/09/2017 04:49 AM, Walter Bright wrote:
 On 2/8/2017 11:09 PM, Nick Sabalausky wrote:
 And any PRs I have managed to get through were all uphill battles the
 whole way.
You have contributed 5 PRs to dmd: https://github.com/dlang/dmd/pulls?q=is%3Apr+author%3Aabscissa 1 is open (it's controversial) 1 closed (today by me)
Well, I suppose I brought that one on myself by complaining about it being ignored :/
      3 merged
          1 in 6 days
          2 in 1 day

 Overall, I think you've done well.
Note that those quickly merged ones were several years ago, back before the battles to get anything accepted reached ridiculous levels.
 In any case, shouldn't it be an uphill battle to merge things?
No. There should be appropriate checks and reviews, yes. But, no, every little fix and improvement shouldn't feel like trying to get somewhere in a year-long tabs vs spaces debate or making a big-budget sales pitch to Indecisives Anonymous.
Feb 09 2017
parent Mike <none none.com> writes:
On Thursday, 9 February 2017 at 17:45:15 UTC, Nick Sabalausky 
wrote:

 No. There should be appropriate checks and reviews, yes. But, 
 no, every little fix and improvement shouldn't feel like trying 
 to get somewhere in a year-long tabs vs spaces debate or making 
 a big-budget sales pitch to Indecisives Anonymous.
Yep! There are currently 165 poor sinners in DMD PR purgatory. The oldest is going on 5 years, waiting on someone to make a decision whether to use "-version", "-versions", "-dversion", or "-version=?". Then, it would have to be rebased, and languish again for another indeterminate amount of time. I wouldn't be at all surprised if the original contributor has moved on; I would have 4 years ago. Mike
Feb 09 2017
prev sibling next sibling parent reply Mike <none none.com> writes:
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko 
wrote:
 1. Why your company uses  D?
We don't use D.
 2. Does your company uses C/C++, Java, Scala, Go, Rust?
C/C++. Currently exploring Rust.
 3. If yes, what the reasons to do not use D instead?
* The powers that be in my company are the kind of C programmers that can't understand why anyone would want to use C++ (i.e. Electrical engineers that write software). Suggesting D would be an exercise in futility, unless I can create a notable project in D in my spare time that demonstrates its advantages and appeal to the masses. I tried to do this 2 years ago, but D failed me, primarily due to https://issues.dlang.org/show_bug.cgi?id=14758 * Our customers don't use D. Some of our products are libraries and tools that our customers use. It doesn't make sense to program them in D if our customers don't use D. Though, if D had a minimal runtime, we could write them in D and distribute them with bindings to other languages. * For us, binary size efficiency and minimal runtime are important features. D is not pay-as-you-go; many heavy-weight features are opt-out instead of opt-in. In contrast Rust has "minimal runtime" as one of its pillars making it a much better alternative language choice for us than D.
 2. Have you use one of the following Mir projects in production:
No
 3. If Yes, can Mir community use your company's logo in a 
 section "Used by" or similar.
N/A
 4. Have you use one of the following Tamedia projects in your 
 production:
No
 5. What D misses to be commercially successful languages?
I believe D has the potential to bury all other emerging languages out there, but only if it drops its historical baggage. At the moment, I'm of the opinion that D will remain an obscure language until someone forks D and takes it in a different direction (unlikely), or the D Foundation decides to "reboot" and start working on D3 with a new, updated perspective (more unlikely).
 6. Why many topnotch system projects use C programming language 
 nowadays?
Which topnotch system projects? * C is the lowest common denominator. All modern languages that I'm aware of can interface with C. If one wants to write a library for mass adoption, the best way to do so is to write it in C and create bindings for other languages. D could be a good substitute for this if it had a "minimal runtime" philosophy. * C is a simple, efficient, and powerful language. Some equate language complexity and heavy runtimes to bloat and inefficiency. Some see too much language complexity as an impediment to productivity. C creates the appearance of simplicity with efficiency. * "Minimal Runtime" is the building block of systems programming. If this is not a core feature of a language, it will never compete with C. Systems programmers in my field need to incrementally opt-in to features in a pay-as-you-go fashion to make precise tradeoffs for their unique requirements and hardware platforms. Rust is the only modern language that I'm aware of that's getting this right. * You may also be interested Dan Sak's recent talk "extern c: Talking to C Programmers about C++": https://www.youtube.com/watch?v=D7Sd8A6_fYU&t=2631s
Feb 08 2017
next sibling parent reply bpr <brogoff gmail.com> writes:
On Wednesday, 8 February 2017 at 21:41:24 UTC, Mike wrote:
 Suggesting D would be an exercise in futility, unless I can 
 create a notable project in D in my spare time that 
 demonstrates its advantages and appeal to the masses.  I tried 
 to do this 2 years ago, but D failed me, primarily due to 
 https://issues.dlang.org/show_bug.cgi?id=14758
I read this comment from you on another thread too, and (caveat: I'm not working in such resource constrained domains as you are) it seems sensible. It seems like it may be a good GSOC project to modify dmd as you suggest elsewhere. Have you considered trying to find someone to do that?
 I believe D has the potential to bury all other emerging 
 languages out there, but only if it drops its historical 
 baggage.
  At the moment, I'm of the opinion that D will remain an 
 obscure language until someone forks D and takes it in a 
 different direction (unlikely), or the D Foundation decides to 
 "reboot" and start working on D3 with a new, updated 
 perspective (more unlikely).
I'd love to see a D3, but that seems unlikely, and more unlikely if D2 languishes. It seems though that your issues are with the implementation, not the language itself, so if you got your wishes below
 Instead I suggest following through on things like
 https://issues.dlang.org/show_bug.cgi?id=12270 and considering 
 this proposal
 (http://forum.dlang.org/post/psssnzurlzeqeneagora forum.dlang.org) instead.
wouldn't you be mostly satisfied with D2?
Feb 08 2017
parent Mike <none none.com> writes:
On Wednesday, 8 February 2017 at 22:52:36 UTC, bpr wrote:
 On Wednesday, 8 February 2017 at 21:41:24 UTC, Mike wrote:
 Suggesting D would be an exercise in futility, unless I can 
 create a notable project in D in my spare time that 
 demonstrates its advantages and appeal to the masses.  I tried 
 to do this 2 years ago, but D failed me, primarily due to 
 https://issues.dlang.org/show_bug.cgi?id=14758
I read this comment from you on another thread too, and (caveat: I'm not working in such resource constrained domains as you are) it seems sensible. It seems like it may be a good GSOC project to modify dmd as you suggest elsewhere. Have you considered trying to find someone to do that?
First, for that to happen, the D leadership would need to chime in with a plan on how they want to address this problem. Second, for me to allocate any more of my resources, I'd have to be convinced that their plan is a good solution to the problem. A -betterC switch is not at all attractive to me. I think the D leadership are too busy addressing broader issues with the language at the moment, so this specific case is just not a high priority. Also, if it's not a priority to the them, then anyone that does attempt to work on it will just suffer an eternity in pull request purgatory. So, I would not recommend it as a project for anyone until the D leadership decides to get involved.
 I'd love to see a D3, but that seems unlikely, and more 
 unlikely if D2 languishes. It seems though that your issues are 
 with the implementation, not the language itself, so if you got 
 your wishes below

 Instead I suggest following through on things like
 https://issues.dlang.org/show_bug.cgi?id=12270 and considering 
 this proposal
 (http://forum.dlang.org/post/psssnzurlzeqeneagora forum.dlang.org) instead.
wouldn't you be mostly satisfied with D2?
Correct, my issue is not really with the language, but with its implementation. Resolving issue 12270 and implementing my proposal for decoupling the compiler and druntime would prompt me to further explore D. I'd also like to see how the recent DIP25 and DIP1000 could be leveraged. I'm looking forward to an article on the topic, or Walter's talk at DConf2017 before I dedicate any of my time to it. At first glance, however, it seems like a lot of attribute patchwork. It's become apparent to me that D just hasn't been designed with bare-metal systems programming in mind, so I'm skeptical that even if issue 12270 and my decoupling proposal were implemented, I'd still run into other disappointments. But I'd at least be willing to give it another try, and would be thrilled to be proven wrong. Mike
Feb 08 2017
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 8 February 2017 at 21:41:24 UTC, Mike wrote:
 * "Minimal Runtime" is the building block of systems 
 programming.
  If this is not a core feature of a language, it will never 
 compete with C.  Systems programmers in my field need to 
 incrementally opt-in to features in a pay-as-you-go fashion to 
 make precise tradeoffs for their unique requirements and 
 hardware platforms.  Rust is the only modern language that I'm 
 aware of that's getting this right.
Whiley is in early stages, but I believe they have optional Rust-like memory management implemented (proof-of-concept?) to enable embedded programming situations. http://whiley.org/2016/05/28/reference-lifetimes-in-whiley/ It isn't a production ready language, but well worth following.
Feb 09 2017
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 08 Feb 2017 21:41:24 +0000
schrieb Mike <none none.com>:

 On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko 
 wrote:
 1. Why your company uses  D?  
We don't use D.
 2. Does your company uses C/C++, Java, Scala, Go, Rust?  
C/C++. Currently exploring Rust.
 3. If yes, what the reasons to do not use D instead?  
* The powers that be in my company are the kind of C programmers that can't understand why anyone would want to use C++ (i.e. Electrical engineers that write software).
I always felt like C is the better designed language when compared to C++. Of course C misses many features of C++ and C also has some badly designed features (preprocessor, header/include system, function pointer syntax, array [n] not attached to the type but to the variable identifier). But among some useful features C++ also adds much more noise on top of the already existing C misfeatures: ugly template syntax, iostreams/pipe syntax, operator overloading for controversial operators, c++ namespaces, multiple inheritance, ... Of course C has limited means for abstraction and therefore is not suitable for certain projects. But the language feels 'cleaner' imho, C++ sources files using templates and similar features are often hard to read. But OTOH I'm an electrical engineer as well ;-) -- Johannes
Feb 09 2017
parent Mike <none none.com> writes:
On Thursday, 9 February 2017 at 10:38:11 UTC, Johannes Pfau wrote:

 But OTOH I'm an electrical engineer as well ;-)
Haha! Then this (https://www.youtube.com/watch?v=D7Sd8A6_fYU&feature=youtu.be&t=2389) is for you ;-) "What we know is that C code will compile all sorts of bugs, more so than most languages, and C programmers know this and accept this. This is the world that they live in. So it breeds a very unfortunate mindeset which is: 'Let's just get the code to compile so we can get to the real work which is debugging.'" -- Dan Saks But you're right, C++ is a very complex language and can easily turn into a monstrosity if not done tastefully. Mike
Feb 09 2017
prev sibling next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko 
wrote:
 All my current D project are finished. Probably I will use 
 other languages for production this year, Java/Go/whatever.
Noooo... I Guess I'll have to try to convince you to help with DCompute once the necessary compiler stuff gets merged into LDC.
Feb 08 2017
prev sibling next sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko 
wrote:
 1. Why your company uses  D?

   a. D is the best
   b. We like D
   c. I like D and my company allowed me to use D
   d. My head like D
   e. Because marketing reasons
   f. Because my company can be more efficient with D for some 
 tasks then with any other system language
I use D only privately so far.
 2. Does your company uses C/C++, Java, Scala, Go, Rust?
I've seen C, C++, and Java being used.
 3. If yes, what the reasons to do not use D instead?
Nobody ever heard of the language (this holds true pretty much in every discussion I have on the topic)
 2. Have you use one of the following Mir projects in production:

   a. https://github.com/libmir/mir
   b. https://github.com/libmir/mir-algorithm
   c. https://github.com/libmir/mir-cpuid
   d. https://github.com/libmir/mir-random
   e. https://github.com/libmir/dcv - D Computer Vision Library
   f. std.experimental.ndslice
No.
 3. If Yes, can Mir community use your company's logo in a 
 section "Used by" or similar.
N/A
 4. Have you use one of the following Tamedia projects in your 
 production:

   a. https://github.com/tamediadigital/asdf
   b. https://github.com/tamediadigital/je
   c. https://github.com/tamediadigital/lincount
I've used asdf for configuration files[1][2], it works very well for shortening development time.
 5. What D misses to be commercially successful languages?
My two cents: - "Name" backing by a well-known (i.e. internationally famous) corporation/foundation - Viral marketing ("spread the D") - Fix or removal of all the little things that may make someone go "ugh, wtf?". I'm looking at you, `shared`, and your missing memory barriers[5], or you, `std.parallelism.taskPool`, and your non-daemon "daemon" threads[6]. Privately I can work around them since it's my own time, but I don't expect many people in big companies (see first point) with a deadline to want to put up with that. - Tooling, though that's been getting better - Phobos without GC (where possible) - std.experimental.allocator -> std.allocator and promote it as *the* memory management interface for D. Seriously. With it I can even allocate and pass delegates to C in an intuitive way (see [3] and [4]).
 6. Why many topnotch system projects use C programming language 
 nowadays?
Don't know if the premise holds, but if it does I'd wager it's because people who *do* write topnotch (system) software can do so in *any* (system) language that's asked of them - since in the end the topnotch comes from the person writing the code, not the language ("ignorance (of a language) can be remedied, stupid is forever") - and C has the de facto corporate monopoly of being asked to write in. [1] https://git.ucworks.org/UCWorks/dagobar/tree/master [2] https://git.ucworks.org/UCWorks/tunneled/tree/master [3] https://git.ucworks.org/UCWorks/dagobar/blob/master/source/libuv.d#L125 [4] https://git.ucworks.org/UCWorks/dagobar/blob/master/source/libuv.d#L159 [5] https://dlang.org/faq.html#shared_guarantees [6] https://issues.dlang.org/show_bug.cgi?id=16324
Feb 08 2017
prev sibling next sibling parent Dsby <dushibaiyu yahoo.com> writes:
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko 
wrote:
 1. Why your company uses  D?

   a. D is the best
   b. We like D
   c. I like D and my company allowed me to use D
   d. My head like D
   e. Because marketing reasons
   f. Because my company can be more efficient with D for some 
 tasks then with any other system language
a,d
 2. Does your company uses C/C++, Java, Scala, Go, Rust?
We use the C++ alaso. we have C++ for writeing the Client by Qt.
 3. If yes, what the reasons to do not use D instead?
No reasons to use D instead.
 2. Have you use one of the following Mir projects in production:

   a. https://github.com/libmir/mir
   b. https://github.com/libmir/mir-algorithm
   c. https://github.com/libmir/mir-cpuid
   d. https://github.com/libmir/mir-random
   e. https://github.com/libmir/dcv - D Computer Vision Library
   f. std.experimental.ndslice
No.
 3. If Yes, can Mir community use your company's logo in a 
 section "Used by" or similar.

 4. Have you use one of the following Tamedia projects in your 
 production:

   a. https://github.com/tamediadigital/asdf
   b. https://github.com/tamediadigital/je
   c. https://github.com/tamediadigital/lincount
a, we use the asdf in hunt.
 5. What D misses to be commercially successful languages?
Not has distinct orientation。 and update slow。
 6. Why many topnotch system projects use C programming language 
 nowadays?
The GC。 and if not GC , D only has a little.
Feb 08 2017
prev sibling next sibling parent Chris Wright <dhasenan gmail.com> writes:
On Wed, 08 Feb 2017 18:27:57 +0000, Ilya Yaroshenko wrote:
 1. Why your company uses D?
You might have specified that this questionnaire is only for people who use D at work. I use D for small utilities to help in development. For instance, I used vibe.d to compare performance with other frameworks when I had performance concerns.
 2. Does your company uses C/C++, Java, Scala, Go, Rust?
We use Java, Kotlin, and some C/C++.
 3. If yes, what the reasons to do not use D instead?
On the client side, we're building for Android. Some of it is native, and it would not be a natural fit to use D (minor modifications in Android platform code that's written in C/C++). We use Swagger and Thrift for service definitions. Thrift supports D; Swagger does not. We use AWS. There is no AWS client library for D and it would not be cost- effective to implement one. If we want people to learn a new programming language for the JVM, they probably know Java already, and the rest of the ecosystem is identical. With D, the ecosystem is entirely difficult. Java has NullPointerException, while D has a segmentation fault. It's easy to catch NPE and harder to handle a segmentation fault, even if you are just trying to log and exit. The "die on error" trend has me worried that it will be difficult to run services with reasonable uptime, and the people saying that we shouldn't even try to log anything in the face of an error worry me even more. I can't run systems in production if I'm not allowed to log errors. The runtime doesn't even promise to make an effort to let me catch an Error.
 2. Have you use one of the following Mir projects in production:
No.
 4. Have you use one of the following Tamedia projects in your
 production:
I've never even heard of them before. Have they ever thought of going into advertising?
 5. What D misses to be commercially successful languages?
The backing of a large organization. The example of Go shows me that a language can become successful despite its technical attributes with the backing of a large organization.
Feb 08 2017
prev sibling next sibling parent Satoshi <satoshi rikarin.org> writes:
 1. Why your company uses  D?
I can use D only for very small apps in my job. My own project use D because it was the best language what I found when I started developing OS from scratch 5 years ago.
 2. Does your company uses C/C++, Java, Scala, Go, Rust?
We use C/C++, Java
 3. If yes, what the reasons to do not use D instead?
Replacement as C++: There is problem to find and hire C++ programmers so how could we find D programmers... Nobody here wants to learn new programming language... Many of ours projects/libraries are already written in C/C++. Replacement as Java: Making GUI apps in D (with Qt) is pain in the a$$. We need good IDE, Drag'n'Drop GUI builder and framework with stuff like in Java or .NET first.
 2. Have you use one of the following Mir projects in production:
No
 4. Have you use one of the following Tamedia projects in your 
 production:
No
 5. What D misses to be commercially successful languages?
Native GUI IDE with D'n'D interface builder Framework with all stuff in (like .NET) Maybe more understandable documentation with more examples. More syntactic sugar in D? Like maybe monad, tuples, etc.
 6. Why many topnotch system projects use C programming language 
 nowadays?
Small and fast programs with no runtime.
Feb 09 2017
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko 
wrote:
 1. Why your company uses  D?

   a. D is the best
   b. We like D
   c. I like D and my company allowed me to use D
   d. My head like D
   e. Because marketing reasons
   f. Because my company can be more efficient with D for some 
 tasks then with any other system language
My company doesn't use D.
 2. Does your company uses C/C++, Java, Scala, Go, Rust?
My company uses what the customers ask for, we don't get to choose that much. iOS projects - Objective-C, Swift Java projects - Java, Scala, Clojure Web Projects - JavaScript on frontend with a Java or .NET stack on backend Android projects - Java Hybrid development across iOS and Android - Cordova, Ionic Traversal to all projects, C++ as infrastructure language for performance reasons or integration of C and C++ libraries.
 3. If yes, what the reasons to do not use D instead?
Customers don't ask for it on their RPF to allow its use.
 2. Have you use one of the following Mir projects in production:

   a. https://github.com/libmir/mir
   b. https://github.com/libmir/mir-algorithm
   c. https://github.com/libmir/mir-cpuid
   d. https://github.com/libmir/mir-random
   e. https://github.com/libmir/dcv - D Computer Vision Library
   f. std.experimental.ndslice
No, as they don't follow on the typical enterprise computing projects we work on.
 3. If Yes, can Mir community use your company's logo in a 
 section "Used by" or similar.

 4. Have you use one of the following Tamedia projects in your 
 production:

   a. https://github.com/tamediadigital/asdf
   b. https://github.com/tamediadigital/je
   c. https://github.com/tamediadigital/lincount
No, I wasn't aware of their existence.
 5. What D misses to be commercially successful languages?
A GC that can compete with Java and .NET ones. The IDE tooling at the same level of the InteliJ and Visual Studio. Above all, a killer project that makes customers ask us about employees with D skils. As an example, Docker and Kubernetes success means our devops guys are slowly improving their Go skills in the newly introduced internal training.
 6. Why many topnotch system projects use C programming language 
 nowadays?
Due to existing tooling, libraries and that for many companies using a managed language + C, is good enough and allows for cheaper developers. Also many developers born after memory safe system languages lost the market to UNIX + C, think that C was the first one to exist for system programming.
 =========================

 All my current D project are finished. Probably I will use 
 other languages for production this year, Java/Go/whatever. Mir 
 libraries are amazing and good quality. If you use them this 
 would be a good motivation for us to improve the docs and 
 provide regular updates. Plus, it can be enchanted during the 
 GSoC 2017.

 Thanks,
 Ilya
Feb 09 2017
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko 
wrote:
 2. Have you use one of the following Mir projects in production:

   a. https://github.com/libmir/mir
   b. https://github.com/libmir/mir-algorithm
   c. https://github.com/libmir/mir-cpuid
   d. https://github.com/libmir/mir-random
   e. https://github.com/libmir/dcv - D Computer Vision Library
   f. std.experimental.ndslice
I wasn't going to comment, since I'm not part of the target group, but I have enough familiarity with commercial usage to give you an answer to this question. Why would someone in an "enterprise" situation want to use Mir? If you create a nice R package to make Mir functionality available to Rcpp users, and you provide new functionality not currently available in other R packages (with good performance to boot), you will see commercial usage. But it has to be a package they can install from CRAN/Github/Bitbucket using the R package manager. They're not going to mess around with Dub. The same is true for Matlab/Octave/Python. Make extensions that others can use within their current workflow, and they will use it. Leave it as a Dub package and they won't touch it. You've done a lot of good work, but it's kind of a dead end to target the standalone D program market right now.
Feb 09 2017
parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 9 February 2017 at 16:33:18 UTC, bachmeier wrote:
 Make extensions that others can use within their current 
 workflow, and they will use it. Leave it as a Dub package and 
 they won't touch it. You've done a lot of good work, but it's 
 kind of a dead end to target the standalone D program market 
 right now.
+1!
Feb 09 2017
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko 
wrote:
 1. Why your company uses  D?

   a. D is the best
   b. We like D
   c. I like D and my company allowed me to use D
   d. My head like D
   e. Because marketing reasons
   f. Because my company can be more efficient with D for some 
 tasks then with any other system language
I'm the only person I personally know who uses D. I mainly use it for personal projects. I like it because the other languages I more often use, like R or Python, are just not sufficient for some purposes. I've tried C++, but I like D a lot more.
 2. Does your company uses C/C++, Java, Scala, Go, Rust?
Not my group, but I imagine other parts.
 3. If yes, what the reasons to do not use D instead?

 2. Have you use one of the following Mir projects in production:

   a. https://github.com/libmir/mir
   b. https://github.com/libmir/mir-algorithm
   c. https://github.com/libmir/mir-cpuid
   d. https://github.com/libmir/mir-random
   e. https://github.com/libmir/dcv - D Computer Vision Library
   f. std.experimental.ndslice
Not in production, but in personal projects.
 5. What D misses to be commercially successful languages?
I would probably say libraries is most important. Mir is a great advance. I've been applauding your work all the way through. There are two things that I think Mir needs most (and we've talked about them before as things you were thinking about) and then a third is a nice-to-have 1) A higher level layer with more convenient syntax for Mir-Glas 2) Lapack support (eigenvalues, svd, & cholesky/qr decompositions) 3) D compute support (would be nice to easily offload big computations to GPU) Other stuff I would find useful: 1) R integration (I know someone's done work on this, but it's hard to find and I don't remember if it works on Windows. Really just needs a champion) 2) Stan (http://mc-stan.org/) interface
 =========================

 All my current D project are finished. Probably I will use 
 other languages for production this year, Java/Go/whatever. Mir 
 libraries are amazing and good quality. If you use them this 
 would be a good motivation for us to improve the docs and 
 provide regular updates. Plus, it can be enchanted during the 
 GSoC 2017.
I agree on GSOC 2017, but you should provide some sort of guidance or support. I hope Mir gets more attention!
Feb 09 2017
next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 9 February 2017 at 17:28:47 UTC, jmh530 wrote:

 Other stuff I would find useful:
 1) R integration (I know someone's done work on this, but it's 
 hard to find and I don't remember if it works on Windows. 
 Really just needs a champion)
Me. The latest version is here: https://bitbucket.org/bachmeil/embedr It's Linux-only because that's all I know or use. Others that I work with use it on Windows and OS X trivially with Docker, but for someone that understands development on those OSes, it shouldn't take much to get it working natively. Everything is handled internally by the R package manager, and the package itself has functions to take care of all steps for compilation. I don't promote it because I don't have time to run an open source project properly. However, I am happy to help in any way if someone else wants to use it. I am flexible on the license, so that's not an issue.
Feb 09 2017
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Thursday, 9 February 2017 at 18:34:44 UTC, bachmeier wrote:
 On Thursday, 9 February 2017 at 17:28:47 UTC, jmh530 wrote:

 Other stuff I would find useful:
 1) R integration (I know someone's done work on this, but it's 
 hard to find and I don't remember if it works on Windows. 
 Really just needs a champion)
Me. The latest version is here: https://bitbucket.org/bachmeil/embedr It's Linux-only because that's all I know or use. Others that I work with use it on Windows and OS X trivially with Docker, but for someone that understands development on those OSes, it shouldn't take much to get it working natively. Everything is handled internally by the R package manager, and the package itself has functions to take care of all steps for compilation. I don't promote it because I don't have time to run an open source project properly. However, I am happy to help in any way if someone else wants to use it. I am flexible on the license, so that's not an issue.
There's a possibility of some commercial need for R <-> D where I'm working, so hopefully we'll be able to help here.
Feb 09 2017
parent bachmeier <no spam.net> writes:
On Thursday, 9 February 2017 at 18:38:32 UTC, John Colvin wrote:
 On Thursday, 9 February 2017 at 18:34:44 UTC, bachmeier wrote:
 On Thursday, 9 February 2017 at 17:28:47 UTC, jmh530 wrote:

 Other stuff I would find useful:
 1) R integration (I know someone's done work on this, but 
 it's hard to find and I don't remember if it works on 
 Windows. Really just needs a champion)
Me. The latest version is here: https://bitbucket.org/bachmeil/embedr It's Linux-only because that's all I know or use. Others that I work with use it on Windows and OS X trivially with Docker, but for someone that understands development on those OSes, it shouldn't take much to get it working natively. Everything is handled internally by the R package manager, and the package itself has functions to take care of all steps for compilation. I don't promote it because I don't have time to run an open source project properly. However, I am happy to help in any way if someone else wants to use it. I am flexible on the license, so that's not an issue.
There's a possibility of some commercial need for R <-> D where I'm working, so hopefully we'll be able to help here.
I believe you have my email address. Send me a message if something comes up. I redid everything a few months ago, so if you looked at an earlier version, this is much improved. Getting it to work on Windows/OS X or integrating Dub is something that can be done in an afternoon by someone with the appropriate background.
Feb 09 2017
prev sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 9 February 2017 at 17:28:47 UTC, jmh530 wrote:
 I would probably say libraries is most important. Mir is a 
 great advance. I've been applauding your work all the way 
 through. There are two things that I think Mir needs most (and 
 we've talked about them before as things you were thinking 
 about) and then a third is a nice-to-have
 1) A higher level layer with more convenient syntax for Mir-Glas
 2) Lapack support (eigenvalues, svd, & cholesky/qr 
 decompositions)
 3) D compute support (would be nice to easily offload big 
 computations to GPU)
number 3 is in the pipeline. LDC should be able to produce .ptx and .spv (the intermediate formats for CUDA and OpenCL respectively, with host code all at the same time!) RealSoon™ (I hope by the end of the month). From there it's all just plain D API bashing, which will be easily automated with .mangleof and templates. I am hoping to give a DConf talk about this.
Feb 09 2017
prev sibling next sibling parent Claude <no no.no> writes:
 1. Why your company uses  D?
My company does not use D. If I had the time, I really think I could integrate D into our build system, probably forcing it a bit: "Oh and by the way, that new library I wrote happens to be written in D..." (We have Vala in our build system, how worse could it be?). I use it for personal projects.
 2. Does your company uses C/C++, Java, Scala, Go, Rust?
We use C/C++/assembly for system stuff. And Java for Android applications. We run Linux or Android on ARM embedded systems.
 3. If yes, what the reasons to do not use D instead?
Nobody knows about D. Most system developers use C here, half of them don't like C++ and scorn Java. And most of them don't know about D apart from my close colleagues which probably must hate it without having even used it, just because I always bring it up in any unrelated conversation at lunch.
 2. Have you use one of the following Mir projects in production:
No, but it could be very useful for DSP routines. I hope Mir (and D) to have the success it deserves.
 4. Have you use one of the following Tamedia projects in your 
 production:
No.
 5. What D misses to be commercially successful languages?
I don't know, I'm not a sales-person at all. I also like D because it's got that "made by developers for developers" thing. I'm an idealist, I'd prefer D to be successful because of its cheer intrinsic value as a programing language, rather than because we throw big money at it.
 6. Why many topnotch system projects use C programming language 
 nowadays?
For history reasons. And because of its simplicity (and tooling etc), and its "system" trait. I don't buy the "C compiles bugs" argument. Every languages in the world produce bugs [1]. I noticed the hardest and most insiduous bugs could always be avoided if the software was more carefully designed upfront, especially for real-time or concurrent software. I use C a lot, it's my favorite language with D, though I'm not a proselyte. I use C++ only as "C with class". [1] http://jonathanwhiting.com/writing/blog/games_in_c/
Feb 10 2017
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko 
wrote:
 1. Why your company uses D?
The only other real alternative (everyone using it) in my field was C++, and I have worked in a variety of C++ codebases. For me it's not a productive language and lead to inflexible programs that I don't even like. However, this is subtle enough that you don't see it while on the job. Was it risky to choose D? I don't think so, especially when the less risky choice is costing precious productivity day to day.
 2. Does your company uses C/C++, Java, Scala, Go, Rust?
Only D. I fear of becoming monoglot programmer. :)
 3. Have you use one of the following Mir projects in production:
 4. Have you use one of the following Tamedia projects in your 
 production:
Nope.
 5. What D misses to be commercially successful languages?
Targetting iOS or Web would be nice. Other than that, I think we need to "reframe" the competition who easily took a moral high-ground against us (not mentionning D, saying it's old, etc) and repeat our key advantages: D is productive, fast, already there (no vapor) and you _kind of already know it_(yeah, kind of). Being familiar is key to cater to C++ people - a difficult and busy audience. Rust has convinced people that they don't want a GC, it is the most common argument against D. _It does not make any goddamn sense_ considering the number of real-time systems with no GC problem. So why people don't even think they could try D? I think it really is a cool kid thing, D should present itself as evergreen, and not an "old" thing.
 6. Why many topnotch system projects use C programming language 
 nowadays?
Because of when they were created? Those that haven't been replaced by topnotch systems in C++ (and in language X later, hopefully X = D).
Feb 10 2017
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 2/8/17 7:27 PM, Ilya Yaroshenko wrote:
 1. Why your company uses  D?

   a. D is the best
   b. We like D
   c. I like D and my company allowed me to use D
   d. My head like D
   e. Because marketing reasons
   f. Because my company can be more efficient with D for some tasks then
 with any other system language
Will probably stop on this question as the rest is not applicable. I do not use D at my company and the reason is that any language to get a use need to pass stringent sorting criteria that I don't even appreciate fully. The language that have green light I believe are C++, Go, Java, Python (under heavy pressure to switch to Go) Anyhow when trying to sell D to any company the only case I can make a good offer is having these attributes: 1) It's a new project, not extension of an existing behemoth code base 2) Fairly unique - i.e. cannot be just a bunch of existing libraries glued together with some business logic. 3) Needs native performance at least in some areas of the project. Now let's imagine a company considers technology X and I want to propose D instead. Let's look at possibilities: C++ - they are not afraid of creating their own stack and performance-minded. This is probably the only case where selling D is easy. However these days selling them Rust would be much easier. Rust - they value native speed, safety and afraid of GC. D's state of GC would only confirm their fears and D's safety is mostly opt-in/ relies on GC/not supported enough. Java - they love VM safety and GC, most likely invested in Java ecosystem. Here the better sell would be Scala or Kotlin etc. (VisualStudio). The current state of D's IDE will make them cry like little babies, no selling here. Go - they value simplicity and robust run-time (Go's GC breaks news with sub-milisecond pauses on large heaps). The sheer complexity of D is enough for it to be a hard sell, D's GC is coup de grace. Scripting languages - they don't care for elaborate type systems and willing to trade performance for flexibility. Selling easy templates to them is like giving candies to kids with diabeties. Trying to lure with performance hits a brick wall because e.g. NodeJS/LuaJIT have fast JITs already and they don't care going beyond that level. --- Dmitry Olshansky
Feb 10 2017
parent reply bachmeier <no spam.net> writes:
On Friday, 10 February 2017 at 23:02:38 UTC, Dmitry Olshansky 
wrote:
 Go - they value simplicity and robust run-time (Go's GC breaks 
 news with sub-milisecond pauses on large heaps). The sheer 
 complexity of D is enough for it to be a hard sell, D's GC is 
 coup de grace.
I have never understood the appeal of Go. With respect to the GC, there's this: https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e#.o6pxesvuw With respect to "simplicity", I found it to be easy to learn a language that makes it hard to get stuff done. I've never understood the argument that programming in Go is simple. Clearly others have their own view.
Feb 10 2017
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 2/11/17 5:04 AM, bachmeier wrote:
 On Friday, 10 February 2017 at 23:02:38 UTC, Dmitry Olshansky wrote:
 Go - they value simplicity and robust run-time (Go's GC breaks news
 with sub-milisecond pauses on large heaps). The sheer complexity of D
 is enough for it to be a hard sell, D's GC is coup de grace.
I have never understood the appeal of Go. With respect to the GC, there's this: https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e#.o6pxesvuw
Has nothing new to say, yes GO's GC fragments heap, is slower at allocation and adds "read/write barriers from hell". But it does optimize for short pauses, which in turn avoids ugly spikes in server workloads and that is priceless. I have had the pleasure of trying to "tune away" the GC spikes of Java cluster software - it's not pleasant.
 With respect to "simplicity", I found it to be easy to learn a language
 that makes it hard to get stuff done. I've never understood the argument
 that programming in Go is simple. Clearly others have their own view.
I agree with your view on this one. Go puts both advanced and novice programmers on the same ground - both have to write dumb code with little to no abstraction. In my limited time with Go I found it futile to abstract away even the most trivial patterns such as map-reduce with concurrency. --- Dmitry Olshansky
Feb 11 2017
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko 
wrote:
 1. Why your company uses  D?

   a. D is the best
   b. We like D
   c. I like D and my company allowed me to use D
   d. My head like D
   e. Because marketing reasons
   f. Because my company can be more efficient with D for some 
 tasks then with any other system language
A. My on the way to be legalized personal (dictatorship :) ) business is using D and vibed. I'm developing a platform like pinterest but different audience (local). I'm in Ghana (West Africa) so I bearly know any D coder. It did not use php (the short path) for long term performance and clean code base... D is just the right tool for it. I'm more of a practical coder (immediate solution) than GC, safe, betterC advocate.
 2. Does your company uses C/C++, Java, Scala, Go, Rust?
Nope. Not interested
 3. If yes, what the reasons to do not use D instead?

 2. Have you use one of the following Mir projects in production:

   a. https://github.com/libmir/mir
   b. https://github.com/libmir/mir-algorithm
   c. https://github.com/libmir/mir-cpuid
   d. https://github.com/libmir/mir-random
   e. https://github.com/libmir/dcv - D Computer Vision Library
   f. std.experimental.ndslice

 3. If Yes, can Mir community use your company's logo in a 
 section "Used by" or similar.
Not having need for any of them ATM.
 4. Have you use one of the following Tamedia projects in your 
 production:

   a. https://github.com/tamediadigital/asdf
   b. https://github.com/tamediadigital/je
   c. https://github.com/tamediadigital/lincount
No. You were maintaining the s3 lib which is now frozen. But that's my take. Performance is tomorrow's problem.
 5. What D misses to be commercially successful languages?
To me, is not the technical detail but what I can do with it. Its libs. Image and video processes, storage apis (minio, s3, swift, etc.), db libraries. Real-world everyday problems.
 6. Why many topnotch system projects use C programming language 
 nowadays?

 =========================
No comment
 All my current D project are finished. Probably I will use 
 other languages for production this year, Java/Go/whatever. Mir 
 libraries are amazing and good quality. If you use them this 
 would be a good motivation for us to improve the docs and 
 provide regular updates. Plus, it can be enchanted during the 
 GSoC 2017.
Lack of An improved and tested s3 compatible api is much the deal breaker at the moment for me. Object storage (cloud) is the way forward. Docker, k8s, etc. are all the driving forces. S3 being the pioneer in object storage has moved most of them to support s3 apis (Minio for instance is a driving force for using Go lang in containerized storage and computing.). I rather urge community to focus [some] attention on everyday demands. And take them by storm with D. Its not a lang problem ... JavaScript is top cus its useful (not efficient).
 Thanks,
 Ilya
Feb 11 2017
prev sibling next sibling parent Igor Shirkalin <mathsoft inbox.ru> writes:
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko 
wrote:
1. a + d + new projects
2. C++ + Python
3. Beacause of D strength with LDC
4. Have you use one of the following Mir projects in production:
No. The lack of numeric methods. To Ilya personally: if you try to realize primitive and fast Gauss you see you don't need anything from Mir. It is good work for diplom work.
...
 5. What D misses to be commercially successful languages?
IDE only. But I have found Visual D pretty enough. D reminds me Watcom C++. Debugging tools are for loosers :)
...
Igor Shirkalin
Feb 11 2017
prev sibling next sibling parent Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 08/02/2017 à 19:27, Ilya Yaroshenko a écrit :
I can answer for the product on which I am working (Home Design 3D), 
others are video games made with Unity which is imposed by the editor.

On Home Design 3D the development teams have the choice of technologies 
to use, but we have to convince our boss. There is an history, any 
developer on previous teams knows the D language, we are now 2 on 6 that 
having few basics.

 1. Why your company uses  D?

   a. D is the best
   b. We like D
   c. I like D and my company allowed me to use D
   d. My head like D
   e. Because marketing reasons
   f. Because my company can be more efficient with D for some tasks then
 with any other system language
We don't use D.
 2. Does your company uses C/C++, Java, Scala, Go, Rust?
C++11, other languages as Java or objective-C can be used for OS specifics (Android and iOS).
 3. If yes, what the reasons to do not use D instead?
There is a lot of obstacles to migrate to D or at least using it partially in our product or for tools. Here is the list sorted by difficulties: 1. The team isn't enough familiar with the D language 2. It seems too hard to use it with our actual C++ dependencies (QtQuick, boost geometry, and a lot of other C/C++ libraries) 3. We don't have enough feedback on how it can be used on all our targeted platforms (Android, iOS, Windows x86 and x64, MacOS) 4. Due to some differences with the c++ major refactoring will be necessary after a translation to have the same performances (GC will impact a lot the resources management) 5. The quality of the possible integration with a complete production ecosystem is unknown. IDE : Debugging, refactoring Platforms : Compatibility with Stores (and there tools such as crash reporting,...) 6. D isn't as mature as C++, so there is fewer articles on internet that can help on particular subjects. And no body will give code examples in D, so even for test we would have to port it. This will globally impact the productivity.
 2. Have you use one of the following Mir projects in production:

   a. https://github.com/libmir/mir
   b. https://github.com/libmir/mir-algorithm
   c. https://github.com/libmir/mir-cpuid
   d. https://github.com/libmir/mir-random
   e. https://github.com/libmir/dcv - D Computer Vision Library
   f. std.experimental.ndslice
Nop
 3. If Yes, can Mir community use your company's logo in a section "Used
 by" or similar.

 4. Have you use one of the following Tamedia projects in your production:

   a. https://github.com/tamediadigital/asdf
   b. https://github.com/tamediadigital/je
   c. https://github.com/tamediadigital/lincount

 5. What D misses to be commercially successful languages?
I think that it start with a bigger adoption, but it can be addressed directly, so it have to easy to take into. IMO documentation IDE friendly-ness,... will help newbie to start. After tools necessary to have stable and effective products are critical, debugger (code and memory), profiler,... On this point to IMO the ergonomic is important (not every developer want to use command line and a lot would prefer UI). I also think that it depends who is the target, because Java developers will be certainly more reticent to come to D if tools don't have good UI than C/C++ developers that works mostly under linux. Personally I develop only under Windows and having a great integration between D tools with UI is one of the most important thing. I want an IDE that is ready for use after installation, with dub integrated, unit tests UI, compilers and debuggers configured and ready for cross compilation.
 6. Why many topnotch system projects use C programming language nowadays?
IMO the fact that C is one of the first language helps a lot, languages that came after few or any are system languages. I find that C/C++ didn't evolve a lot for many years and it start to come better with C++11, 14 and 17. Maybe D have put some pressure. I don't know a lot of languages but I think that D have the potential to be a much better system language than C++, and it should be else nobody will migrate if the win isn't enough.
 =========================

 All my current D project are finished. Probably I will use other
 languages for production this year, Java/Go/whatever. Mir libraries are
 amazing and good quality. If you use them this would be a good
 motivation for us to improve the docs and provide regular updates. Plus,
 it can be enchanted during the GSoC 2017.

 Thanks,
 Ilya
Feb 12 2017
prev sibling next sibling parent Arun Chandrasekaran <aruncxy gmail.com> writes:
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko 
wrote:
 1. Why your company uses  D?

   a. D is the best
   b. We like D
   c. I like D and my company allowed me to use D
   d. My head like D
   e. Because marketing reasons
   f. Because my company can be more efficient with D for some 
 tasks then with any other system language
We don't use D. But IMO, D is the best PL with it's amazing compile time features (templates, templates everywhere and still it can be maintainable).
 2. Does your company uses C/C++, Java, Scala, Go, Rust?
 3. If yes, what the reasons to do not use D instead?
1. For algorithms: We develop biometric algorithms and create shared objects and DLLs. We need these to be used on variety of Go. D makes it impossible to convince teams that develop algorithms. 2. For applications/solutions: An year ago we evaluated D (to replace C++) for one of our large scale distributed solution (map-reduce for biometrics). But ended up developing it in C++ for the following reasons: a) Lack of high quality libraries like Boost/Qt. With the horrible template syntax of C++, people created Boost and helped shape C++ what it is now. D is pleasant to program with and I'm wondering why there is no such comprehensive set of libraries in D. b) GC. We fill pretty much the entire RAM (>=128 GB) with data and operate on it. The end-to-end system latency must be in milliseconds and also provide high throughput. Not really an option with D's current state of GC. c) IDE support. d) We have already got used to the warts of C++, Java and we know how to avoid them. It is fair for us to ask the team to learn D, but not *ignore X and get used to it* as well. D tries to compete and satisfy all paradigms (recently trying to catch-up with Rust's safety feature) which is good from a language point of view. But it could also focus on fixing it's base.
 2. Have you use one of the following Mir projects in production:
No.
 4. Have you use one of the following Tamedia projects in your 
 production:
No.
 5. What D misses to be commercially successful languages?
a) Good quality libraries b) Cross platform IDE c) Corporate backup c) Vibrant community. IMHO, the lack of good quality libraries can be directly attributed to the lack of critical mass of topnotch brains in the community.
 6. Why many topnotch system projects use C programming language 
 nowadays?
a) Good quality libraries b) Small run-time c) Cross platform IDE d) People are already familiar with C/C++
Feb 15 2017
prev sibling parent rumbu <rumbu rumbu.ro> writes:
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko 
wrote:
 1. Why your company uses  D?

   a. D is the best
   b. We like D
   c. I like D and my company allowed me to use D
   d. My head like D
   e. Because marketing reasons
   f. Because my company can be more efficient with D for some 
 tasks then with any other system language
No, my company does not use D.
 2. Does your company uses C/C++, Java, Scala, Go, Rust?
 3. If yes, what the reasons to do not use D instead?
- no decimal data type; - no i18n; - no GUI; - IDE support; - lack of "batteries included" experience; We are following D for long time. The initial idea was "Look, and was replaced by phobos, my team lost the interest, I'm the only one right now using D for pet projects.
 2. Have you use one of the following Mir projects in production:

   a. https://github.com/libmir/mir
   b. https://github.com/libmir/mir-algorithm
   c. https://github.com/libmir/mir-cpuid
   d. https://github.com/libmir/mir-random
   e. https://github.com/libmir/dcv - D Computer Vision Library
   f. std.experimental.ndslice
Most of the apps we develop are in the financial domain. Didn't find any use.
 3. If Yes, can Mir community use your company's logo in a 
 section "Used by" or similar.

 4. Have you use one of the following Tamedia projects in your 
 production:

   a. https://github.com/tamediadigital/asdf
   b. https://github.com/tamediadigital/je
   c. https://github.com/tamediadigital/lincount

 5. What D misses to be commercially successful languages?
- IDE; - IDE; - IDE;
 6. Why many topnotch system projects use C programming language 
 nowadays?
I truly don't know.
 Thanks,
 Ilya
Feb 16 2017