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

Windows projects - C#, VB.NET

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

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.

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.

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.

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!

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!

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.

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.

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.

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.