On 23/08/18 08:20, Nicholas Wilson wrote:
> On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote:
>> No, no and no.
>>
>> I was holding out on replying to this thread to see how the community would react. The vibe I'm getting, however, is that the people who are seeing D's problems have given up on affecting change.
>>
>> It is no secret that when I joined Weka, I was a sole D detractor among a company quite enamored with the language. I used to have quite heated water cooler debates about that point of view.
>>
>> Every single one of the people rushing to defend D at the time has since come around. There is still some debate on whether, points vs. counter points, choosing D was a good idea, but the overwhelming consensus inside Weka today is that D has *fatal* flaws and no path to fixing them.
> 
> A list, please? Now that I actually have time to fix things, I intend to do so.

Let's start with this one:
https://issues.dlang.org/show_bug.cgi?id=14246#c6

The problems I'm talking about are not easily fixable. They stem from features not playing well together.

One that hurt me lately was a way to pass a scoped lazy argument (i.e. - to specify that the implicit delegate need not allocate its frame, because it is not used outside the function call).

Shachar

On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote:

> And it's not just Weka. I've had a chance to talk in private to some other developers. Quite a lot have serious, fundamental issues with the language. You will notice none of them speaks up on this thread.
>
> They don't see the point.
>
> No technical project is born great. If you want a technical project to be great, the people working on it have to focus on its *flaws*. The D's community just doesn't do that.
>
> To sum it up: fatal flaws + no path to fixing + no push from the community = inevitable eventual death.

The D Foundation has an Open Collective page (https://opencollective.com/dlang) with a $12,000 annual "Corporate Bronze" option that includes 3 priority bug fixes per month.  Is that not a worthwhile investment for Weka or other organizations invested in D to help address some of the problems you're encountering?  If not, is there an option that would be?

Mike

On 23/08/18 09:04, Mike Franklin wrote:
> On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote:
> 
>> And it's not just Weka. I've had a chance to talk in private to some other developers. Quite a lot have serious, fundamental issues with the language. You will notice none of them speaks up on this thread.
>>
>> They don't see the point.
>>
>> No technical project is born great. If you want a technical project to be great, the people working on it have to focus on its *flaws*. The D's community just doesn't do that.
>>
>> To sum it up: fatal flaws + no path to fixing + no push from the community = inevitable eventual death.
> 
> The D Foundation has an Open Collective page (https://opencollective.com/dlang) with a $12,000 annual "Corporate Bronze" option that includes 3 priority bug fixes per month.  Is that not a worthwhile investment for Weka or other organizations invested in D to help address some of the problems you're encountering?  If not, is there an option that would be?

I will definitely pass it on.

Shachar

On Thursday, 23 August 2018 at 05:37:12 UTC, Shachar Shemesh wrote:

> One that hurt me lately was a way to pass a scoped lazy argument (i.e. - to specify that the implicit delegate need not allocate its frame, because it is not used outside the function call).

I don't see why we just can't add support for scoped lazy parameters. It's already in the language just with a different syntax (delegates). That would probably be an easy fix (last famous words :)). I guess it would be better if it could be inferred.

--
/Jacob Carlborg

On Thursday, 23 August 2018 at 05:37:12 UTC, Shachar Shemesh wrote:
> Let's start with this one:
> https://issues.dlang.org/show_bug.cgi?id=14246#c6
>
> The problems I'm talking about are not easily fixable. They stem from features not playing well together.
>
> One that hurt me lately was a way to pass a scoped lazy argument (i.e. - to specify that the implicit delegate need not allocate its frame, because it is not used outside the function call).

The only real problem with D is that it's a language designed with
GC in mind, yet there are numerous attempts to use it without GC.
Also, supporting GC-less programming gets in the way of improving
D's GC (which is pretty damn bad by modern standards).
That's the only real technical problem.
For example, the "bug" above just means that D doesn't support RAII
(in the C++ sense). That's hardly a *fatal flaw*. Lots of languages don't
support RAII. Python, Java, C# - tons of code were written in those.
And yes, most of those just use GC to dispose of memory - other resources
are rarely used (compared to memory) and it's not a problem to manage them
manually.
You also mentioned lazy parameters allocating... GC thing again. Just
allocate then? No?
IMO, if getting the maximum number of users is the main goal, D is indeed
going the wrong way. It would be better to get rid of @nogc, betterC, dip1000,
implement write barriers and use them to improve GC. Martin Nowak (I think)
mentioned that write barriers will decrease performance of D programs by 1-5%.
Seems like a small price to pay for better GC with shorter pauses. It would also
probably be simpler technically than stuff like dip1000 and rewriting Phobos.
Of course, maximizing the number of users is not the only goal, or even the
main one. My understanding is that Walter wants a "systems language" with
"zero cost abstractions". Well, it's very well possible that D's design
precludes that.
Other than memory management, I don't see any real fundamental problems.

On 23/08/18 09:17, Jacob Carlborg wrote:
> On Thursday, 23 August 2018 at 05:37:12 UTC, Shachar Shemesh wrote:
> 
>> One that hurt me lately was a way to pass a scoped lazy argument (i.e. - to specify that the implicit delegate need not allocate its frame, because it is not used outside the function call).
> 
> I don't see why we just can't add support for scoped lazy parameters. It's already in the language just with a different syntax (delegates). That would probably be an easy fix (last famous words :)). I guess it would be better if it could be inferred.
> 
> -- 
> /Jacob Carlborg
> 

Here's the interesting question, though: is this *going* to happen?

We've known about this problem for ages now. No movement.

Some of the other problems are considerably less easy to fix. Examples:

A struct may be @disabled this(this), @disable this() and/or @disable init. Can you say that libraries..

Actually, strike that.

Can you say that the *standard* libraries work with all 8 combinations?

Shachar

On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote:
> On 22/08/18 21:34, Ali wrote:
>> On Wednesday, 22 August 2018 at 17:42:56 UTC, Joakim wrote:
>>> Pretty positive overall, and the negatives he mentions are fairly obvious to anyone paying attention.
>> 
>> Yea, I agree, the negatives are not really negative
>> 
>> Walter not matter how smart he is, he is one man who can work on the so many things at the same time
>> 
>> Its a chicken and egg situation, D needs more core contributors, and to get more contributors it needs more users, and to get more users it need more core contributors
>> 
>
> No, no and no.
>
> I was holding out on replying to this thread to see how the community would react. The vibe I'm getting, however, is that the people who are seeing D's problems have given up on affecting change.
>
> It is no secret that when I joined Weka, I was a sole D detractor among a company quite enamored with the language. I used to have quite heated water cooler debates about that point of view.
>
> Every single one of the people rushing to defend D at the time has since come around. There is still some debate on whether, points vs. counter points, choosing D was a good idea, but the overwhelming consensus inside Weka today is that D has *fatal* flaws and no path to fixing them.
>
> And by "fatal", I mean literally flaws that are likely to literally kill the language.
>
> And the thing that brought them around is not my power of persuasion. The thing that brought them around was spending a couple of years working with the language on an every-day basis.
>
> And you will notice this in the way Weka employees talk on this forum: except me, they all disappeared. You used to see Idan, Tomer and Eyal post here. Where are they?
>
> This forum is hostile to criticism, and generally tries to keep everyone using D the same way. If you're cutting edge D, the forum is almost no help at all. Consensus among former posters here is that it is generally a waste of time, so almost everyone left, and those who didn't, stopped posting.
>
> And it's not just Weka. I've had a chance to talk in private to some other developers. Quite a lot have serious, fundamental issues with the language. You will notice none of them speaks up on this thread.
>
> They don't see the point.
>
> No technical project is born great. If you want a technical project to be great, the people working on it have to focus on its *flaws*. The D's community just doesn't do that.
>
> To sum it up: fatal flaws + no path to fixing + no push from the community = inevitable eventual death.

Can you list what you or other Weka devs believe those fatal flaws to be? Because you've not listed any here, which makes you no better than some noob that comes in here, says D has to get better or it will die, then can't articulate what they mean by "better" or worse, mentions something trivial. Of course, you've actually used the language for years, so presumably you've got some real concerns, but do you really think the bug you just posted is "fatal" to the language?

If you think there are fatal flaws, you might as well list them, whether technical or the development process, or you will just be ignored like any other noob who talks big and can't back it up. You may be ignored anyway, ;) but at least you'll have made a case that shows you know what you're talking about.

On Thursday, 23 August 2018 at 06:34:04 UTC, Shachar Shemesh wrote:
> On 23/08/18 09:17, Jacob Carlborg wrote:
>> On Thursday, 23 August 2018 at 05:37:12 UTC, Shachar Shemesh wrote:
>> 
>>> One that hurt me lately was a way to pass a scoped lazy argument (i.e. - to specify that the implicit delegate need not allocate its frame, because it is not used outside the function call).
>> 
>> I don't see why we just can't add support for scoped lazy parameters. It's already in the language just with a different syntax (delegates). That would probably be an easy fix (last famous words :)). I guess it would be better if it could be inferred.
>> 
>> --
>> /Jacob Carlborg
>> 
>
> Here's the interesting question, though: is this *going* to happen?
>
> We've known about this problem for ages now. No movement.
>

It's on my todo list, however I've instead been doomed to work on higher priority things.

More generally though, some time should be spent on trying out things in the spirit of "will it blend" just to see what happens.  Putting effort towards having a more homogeneous environment in the language should in the long run pay its dividends.


> Some of the other problems are considerably less easy to fix. Examples:
>
> A struct may be @disabled this(this), @disable this() and/or @disable init. Can you say that libraries..
>
> Actually, strike that.
>
> Can you say that the *standard* libraries work with all 8 combinations?
>

The same goes for using shared, immutable and const against the standard library.

Iain

On Thursday, 23 August 2018 at 06:34:01 UTC, nkm1 wrote:
> The only real problem with D is that it's a language designed with
> GC in mind, yet there are numerous attempts to use it without GC.
> Also, supporting GC-less programming gets in the way of improving
> D's GC (which is pretty damn bad by modern standards).
> That's the only real technical problem.

I think a large part is defining what kind of users D wants to attract. There are two main groups of programmers, and there is a vast rift between those groups. One group is people who are closer to OOP programming and languages such as Java, C#, Javascript. These people are OK with things like garbage collectors and in cases where it matters, have learned to work around it (avoid allocations in hot loops, etc.). I feel like D1 was attractive for these people for having the convenience they are used to from their languages (batteries included standard library, automatic memory management), with additional features that their language/environments struggle with (C interop, native binaries), everything packed
with a very clean syntax.

The second group are the C/C++ programmers, the 'zero cost abstraction' group. For this group of programmers, any overhead is a disadvantage, garbage collector is unusable for most usecases (whether true or not, that's the perception). D1 appealed to those people, for having a clean syntax and the features they know without having to include the monster that is Boost. Battlefield was different back then too. Around D2 came the competition, be it Rust, Go, or C++17. Go is appealing more to the first group of programmers, since it has a GC, and mostly sticks to webservice usage. Rust is heavily appealing to the zero-cost abstraction group and C++17 obviously appeals to C++ folks.

Is it possible to make a language that both groups would be happy to use? Perhaps, or perhaps the gap is too wide. Is adding features like dip1000 and betterC spreading ourselves too thin? Perhaps. Perhaps there are features that aren't really used, and should be reworked or cut from the language instead (has anyone ever used contracts?).

D's not UNIX (DNU?), but the first rule of UNIX philosophy is "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new 'features'.". It may or may not be relevant here.


BTW. on the offtopic note - the thread title doesn't look too good. Imagine being a newcomer, and the first thread you see on the forum is titled "D is dead".

On Thursday, 23 August 2018 at 06:58:13 UTC, Joakim wrote:
> On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote:
>> On 22/08/18 21:34, Ali wrote:
>>> On Wednesday, 22 August 2018 at 17:42:56 UTC, Joakim wrote:
>>>> Pretty positive overall, and the negatives he mentions are fairly obvious to anyone paying attention.
>>> 
>>> Yea, I agree, the negatives are not really negative
>>> 
>>> Walter not matter how smart he is, he is one man who can work on the so many things at the same time
>>> 
>>> Its a chicken and egg situation, D needs more core contributors, and to get more contributors it needs more users, and to get more users it need more core contributors
>>> 
>>
>> No, no and no.
>>
>> I was holding out on replying to this thread to see how the community would react. The vibe I'm getting, however, is that the people who are seeing D's problems have given up on affecting change.
>>
>> It is no secret that when I joined Weka, I was a sole D detractor among a company quite enamored with the language. I used to have quite heated water cooler debates about that point of view.
>>
>> Every single one of the people rushing to defend D at the time has since come around. There is still some debate on whether, points vs. counter points, choosing D was a good idea, but the overwhelming consensus inside Weka today is that D has *fatal* flaws and no path to fixing them.
>>
>> And by "fatal", I mean literally flaws that are likely to literally kill the language.
>>
>> And the thing that brought them around is not my power of persuasion. The thing that brought them around was spending a couple of years working with the language on an every-day basis.
>>
>> And you will notice this in the way Weka employees talk on this forum: except me, they all disappeared. You used to see Idan, Tomer and Eyal post here. Where are they?
>>
>> This forum is hostile to criticism, and generally tries to keep everyone using D the same way. If you're cutting edge D, the forum is almost no help at all. Consensus among former posters here is that it is generally a waste of time, so almost everyone left, and those who didn't, stopped posting.
>>
>> And it's not just Weka. I've had a chance to talk in private to some other developers. Quite a lot have serious, fundamental issues with the language. You will notice none of them speaks up on this thread.
>>
>> They don't see the point.
>>
>> No technical project is born great. If you want a technical project to be great, the people working on it have to focus on its *flaws*. The D's community just doesn't do that.
>>
>> To sum it up: fatal flaws + no path to fixing + no push from the community = inevitable eventual death.
>
> Can you list what you or other Weka devs believe those fatal flaws to be? Because you've not listed any here, which makes you no better than some noob that comes in here, says D has to get better or it will die, then can't articulate what they mean by "better" or worse, mentions something trivial. Of course, you've actually used the language for years, so presumably you've got some real concerns, but do you really think the bug you just posted is "fatal" to the language?
>
> If you think there are fatal flaws, you might as well list them, whether technical or the development process, or you will just be ignored like any other noob who talks big and can't back it up. You may be ignored anyway, ;) but at least you'll have made a case that shows you know what you're talking about.

I'd define fatal as some that can be fixed, but breaks 100% of everyone's code, even if the change is net positive all round.

However how big a problem really is is in the eye of the beholder. An example:

Symptom: The compiler can't discard unused symbols at compile time, and so it will spend a lot of time pointlessly optimising code.

Problem: D has no notion of symbol visibility.

Possible Solution: Make all globals hidden by default unless 'export'.

Side effects: Everyone will be spending weeks to months fixing their libraries in order to only mark what should be visible outside the current compilation unit as 'export'.

Benefits: Faster compile times, as in, in the most extreme example I've built one project on github with gdc -O2 and build time went from 120 seconds to just 3!

Iain.