On 12/5/16 3:49 PM, e-y-e wrote:
> If you don't mind me saying, I think Mir could be one of the best things
> for the future of D (along with LDC) and I'd be glad to help it on its way.

Yes, Mir is awesome! I keep on thinking of ways to make it better supported by the language and infra. -- Andrei

On Tuesday, 6 December 2016 at 13:02:16 UTC, Andrei Alexandrescu wrote:
> On 12/6/16 3:28 AM, Ilya Yaroshenko wrote:
>> On Tuesday, 6 December 2016 at 08:14:17 UTC, Andrea Fontana wrote:
>>> On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko
>>> Phobos/Druntime are pretty good for a lot of projects.
>>
>> In theory
>
> And what seem to be the issues in practice with code that is not highly specialized? -- Andrei

If code is not highly specialized there is no reason to spent resources to use C/C++/D. A company will be happy with Python, Java, C#, Go and Swift. If one need to have C/C++ programming level he can not use D because DRuntime. Only a subset of D can be used. And current problem that we have not BetterC paradigm in D specification. So, only crazy companies will consider D for large projects. Current D is successful in small console text routines.

If a system PL can not be used as C for highly specialized code, it is not a real system PL.

DRuntime and Phobos is going to compete with Java and Go. It is suicide for D, IMHO. In other hand, BetterC is a direction where D can be populated among professionals and replace C/C++.

Ilya

On Tuesday, December 06, 2016 13:36:20 Ilya Yaroshenko via Digitalmars-d- learn wrote:
> On Tuesday, 6 December 2016 at 13:02:16 UTC, Andrei Alexandrescu
>
> wrote:
> > On 12/6/16 3:28 AM, Ilya Yaroshenko wrote:
> >> On Tuesday, 6 December 2016 at 08:14:17 UTC, Andrea Fontana
> >>
> >> wrote:
> >>> On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko Phobos/Druntime are pretty good for a lot of projects.
> >>
> >> In theory
> >
> > And what seem to be the issues in practice with code that is not highly specialized? -- Andrei
>
> If code is not highly specialized there is no reason to spent resources to use C/C++/D. A company will be happy with Python, Java, C#, Go and Swift. If one need to have C/C++ programming level he can not use D because DRuntime. Only a subset of D can be used. And current problem that we have not BetterC paradigm in D specification. So, only crazy companies will consider D for large projects. Current D is successful in small console text routines.
>
> If a system PL can not be used as C for highly specialized code, it is not a real system PL.
>
> DRuntime and Phobos is going to compete with Java and Go. It is suicide for D, IMHO. In other hand, BetterC is a direction where D can be populated among professionals and replace C/C++.

While I am quite sure that there are use cases where folks would be unhappy with druntime and Phobos and want to avoid them, there are definitely companies using D with druntime and Phobos right now, and personally, I've never worked at a company where anything about druntime or Phobos would have been a showstopper in switching to D. The showstopper would be in convincing them to use a new language rather than one that they were already familiar with. C++ works for them, and they're not interested in switching. And honestly, pushing for a subset of D that didn't have the functionality in druntime and Phobos would just make it an even harder sell. At that point, they're _really_ not interested in using D. C++11/14/17 quickly and easily wins out in that fight.

So, while there are certainly folks who would prefer using D as a better C without druntime or Phobos, I think that you're seriously overestimating how many folks would be interested in that. Certainly, all of the C++ programmers that I've worked with professionally would have _zero_ interest in D as a better C.

- Jonathan M Davis

On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis wrote:
> So, while there are certainly folks who would prefer using D as a better C without druntime or Phobos, I think that you're seriously overestimating how many folks would be interested in that. Certainly, all of the C++ programmers that I've worked with professionally would have _zero_ interest in D as a better C.
>
> - Jonathan M Davis

My experience is completely orthogonal. --Ilya

On Tuesday, 6 December 2016 at 20:01:38 UTC, Ilya Yaroshenko wrote:
> On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis wrote:
>> So, while there are certainly folks who would prefer using D as a better C without druntime or Phobos, I think that you're seriously overestimating how many folks would be interested in that. Certainly, all of the C++ programmers that I've worked with professionally would have _zero_ interest in D as a better C.
>>
>> - Jonathan M Davis
>
> My experience is completely orthogonal. --Ilya

There is a theorem that all programming language discussions on the internet start with the assumption that real programming is exactly the same as the programming done by the author.

On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis wrote:
> So, while there are certainly folks who would prefer using D as a better C without druntime or Phobos, I think that you're seriously overestimating how many folks would be interested in that. Certainly, all of the C++ programmers that I've worked with professionally would have _zero_ interest in D as a better C.

I would guess that the vast majority of interest shown in Rust is from people who essentially want a better C or C++, with no runtime/GC. So, I think Ilya's point is very plausible. D with no GC, but with modules, templates, overloading, CTFE, and some other features might have been more tempting to the no-GC crowd, which includes many hardcore C++ programmers.

Those programmers who are comfortable working in a GC-ed language will likely eschew D because D's GC is really not that great.

On Tuesday, 6 December 2016 at 22:13:54 UTC, bpr wrote:
> Those programmers who are comfortable working in a GC-ed language will likely eschew D because D's GC is really not that great.

So someone working with Ruby is not going to want to work with D because of GC performance? I wonder what percentage of Ruby programmers have thought about garbage collection ever. I could see an argument that there are existing frameworks or some other reason to prefer another language, but it is highly unlikely that GC would be the reason that both C++ and Ruby programmers would not want to use D.

On Tuesday, December 06, 2016 22:13:54 bpr via Digitalmars-d-learn wrote:
> On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis
>
> wrote:
> > So, while there are certainly folks who would prefer using D as a better C without druntime or Phobos, I think that you're seriously overestimating how many folks would be interested in that. Certainly, all of the C++ programmers that I've worked with professionally would have _zero_ interest in D as a better C.
>
> I would guess that the vast majority of interest shown in Rust is from people who essentially want a better C or C++, with no runtime/GC. So, I think Ilya's point is very plausible. D with no GC, but with modules, templates, overloading, CTFE, and some other features might have been more tempting to the no-GC crowd, which includes many hardcore C++ programmers.

Sure, there are folks who would prefer not to have to deal with the GC but throw out the runtime and std lib? You lose out on too much for it to be at all worth it for many folks. At that point, C++11/14/17 looks far more appealing, especially as it continues to improve. And @nogc and sane memory use largely solves the GC problem for many programs. There are some places where we need to improve the situation (like with lambdas and the GC), but for most programs, it's totally workable as-is without giving up on all of the features provided by the runtime and Phobos.

If you really need absolute pedal-to-the-metal performance and can't afford to ever have the GC stop the world, you still don't need to actually throw away the runtime and std lib. You're just a lot more restricted in what you can do with them. So, tossing out druntime and Phobos entirely seems rather extreme. It may very well make really good sense for a subset of D programs, but I have a hard time believing that it's anything more than a small subset.

> Those programmers who are comfortable working in a GC-ed language will likely eschew D because D's GC is really not that great.

We get plenty of folks who aren't big C/C++ programmers who are interested in D. Yes, the majority seem to have a C++ background, but we also get folks from C#, python, ruby, etc.

- Jonathan M Davis

On Tuesday, 6 December 2016 at 22:13:54 UTC, bpr wrote:
> On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis

> I would guess that the vast majority of interest shown in Rust is from people who essentially want a better C or C++, with no runtime/GC. So, I think Ilya's point is very plausible. D with no GC, but with modules, templates, overloading, CTFE, and some other features might have been more tempting to the no-GC crowd, which includes many hardcore C++ programmers.
>
> Those programmers who are comfortable working in a GC-ed language will likely eschew D because D's GC is really not that great.


I don't really get the issue with D's GC, Phobos and DRuntime. JavaScript is really popular and getting really popular everyday (I mean Nodejs). Same as Python, PHP, Ruby (startups), etc. But they are not exactly betterC. Most of them don't even give native code speed.

When using D, I just want to get my app working and running. That is why more packages (vibe.d, mail, request, mysql-lited, etc) matter to me. The level you are trying to raise D is way over-kill IMO :). It's good though for those who need it. But most of us don't judge languages that way.

My 2 cents: for most applications, hotspots tend to be in a tiny percentage of the code (ie 90/10 rule where 10% of code accounts for 90% execution time, although my experience in large projects is even more unbalanced) ; throwing away druntime or GC for the whole codebase based on performance concerns amounts to (evil) early optimization.

It's far more productive to use a profiler and carefully optimize only the parts that need to be (possibly using betterc, @nogc, ldc and optimized compiler flags for those hotspots only).

What could be done better would be to remove friction when linking in
shared objects produced by dmd and ldc (eg, extern(D) functions have
different number of underscores in dmd vs ldc).

On that note, even if dmd is 50x slower than ldc for certain blas mir routines, it's still valuable to have mir supported by dmd as we can always swap in the slow parts during production runs, but we'd benefit with fast compile time during development time,



On Tue, Dec 6, 2016 at 3:08 PM, aberba via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote:

> On Tuesday, 6 December 2016 at 22:13:54 UTC, bpr wrote:
>
>> On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis
>>
>
> I would guess that the vast majority of interest shown in Rust is from
>> people who essentially want a better C or C++, with no runtime/GC. So, I think Ilya's point is very plausible. D with no GC, but with modules, templates, overloading, CTFE, and some other features might have been more tempting to the no-GC crowd, which includes many hardcore C++ programmers.
>>
>> Those programmers who are comfortable working in a GC-ed language will likely eschew D because D's GC is really not that great.
>>
>
>
> I don't really get the issue with D's GC, Phobos and DRuntime. JavaScript is really popular and getting really popular everyday (I mean Nodejs). Same as Python, PHP, Ruby (startups), etc. But they are not exactly betterC. Most of them don't even give native code speed.
>
> When using D, I just want to get my app working and running. That is why more packages (vibe.d, mail, request, mysql-lited, etc) matter to me. The level you are trying to raise D is way over-kill IMO :). It's good though for those who need it. But most of us don't judge languages that way.
>