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.

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++
> Windows - C# or 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.

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?

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.

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.

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.

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

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

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

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.