On 8/23/18 9:22 AM, Shachar Shemesh wrote:

> On the other hand, look at ConnectedSocket.connect:
> https://weka-io.github.io/mecca/docs/mecca/reactor/io/fd/ConnectedSocket.connect.html 
> 
> 
> Why do I need two forms? What good is that? Why is the second form a template? Answer: Because in D, structs can't inherit, and I cannot define an implicit cast. What I'd really want to do is to have SockAddrIPv4 be implicitly castable to SockAddr, so that I can pass a SockAddrIPv4 to any function that expects SockAddr.
> 
> Except what I'd _really_ like to do is for them to be the same thing. I'd like inheritance. Except I can't do that for structs, and if I defined SockAddr as a class, I'd mandate allocating it on the GC, violating the whole point behind writing Mecca to begin with.

So interestingly, you are accepting the sockaddr by VALUE. Which eliminates any possibility of using inheritance meaningfully anyway (except that depending how you define SockAddr, it may include all the data of the full derived address, sockaddr is quirky that way, and NOT like true inheritance).

You CAN use inheritance, just like you would with classes, but you have to pass by reference for it to make sense

struct SockAddr
{
   int addressFamily; // forget what this really is called
   ...
}

struct SockAddrIPv4
{
   SockAddr base;
   ref SockAddr getBase() { return base; }
   alias getBase this;
   ...
}

Now, you can pass SockAddrIPv4 into a ref SockAddr, check the address family, and cast to the correct thing. Just like you would with classes and inheritance. You can even define nice mechanisms for this.

e.g.:

struct SockAddr
{
   ...
   ref T cast(T)() if (isSomeSockaddr!T)
   {
      assert(addressFamily == T.requiredAddressFamily);
      return *cast(T*)&this;
   }
}

> To summarize: Weka isn't ditching D, and people aren't even particularly angry about it. It has problems, and we've learned to live with them, and that's that.

This sounds more like what I would have expected, so thank you for clarifying.

> The general consensus, however, is that these problems will not be resolved (we used to file bugs in Bugzilla. We stopped doing that because we saw nothing happens with them), and as far as the future of the language goes, that's bad news.

Bugs do get fixed, there is just no assigned timeframe for having them fixed. An all volunteer workforce has this issue.

It took 10 (I think) years for bug 304 to get fixed. It was a huge pain in the ass, but it did get fixed.

I wouldn't stop filing them, definitely file them. If they are blocking your work, complain about them loudly, every day. But not filing them doesn't help anyone.

I'm not saying all bugs you file will be fixed, but all bugs you *don't* file will definitely not be fixed.

-Steve

On Thursday, 23 August 2018 at 13:22:45 UTC, Shachar Shemesh wrote:

> Because in D, structs can't inherit,

Forgive me if I'm not helping, but if you are willing to create a little infrastructure, I think you can create polymorphic structs with the technique described at https://theartofmachinery.com/2018/08/13/inheritance_and_polymorphism_2.html.  See https://gitlab.com/sarneaud/xanthe/blob/master/src/game/player.d#L18 for a concrete example.

> I can't do that for structs, and if I defined SockAddr as a class, I'd mandate allocating it on the GC, violating the whole point behind writing Mecca to begin with.

There are other ways to allocate memory for classes, without the GC.  Do any of the techniques described at https://wiki.dlang.org/Memory_Management#Explicit_Class_Instance_Allocation give you an alternative?

> The general consensus, however, is that these problems will not be resolved (we used to file bugs in Bugzilla. We stopped doing that because we saw nothing happens with them), and as far as the future of the language goes, that's bad news.

I've fixed 4 bugs in the past 2 weeks:  https://github.com/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3AJinShil+archived%3Afalse+is%3Aclosed+Fix

But I admit they were quite simple.  I agree, the more difficult bugs tend to not get fixed.  I've tried to fix a few of them, but they were beyond my current abilities.  Again, you might have more success if you put some financial incentive behind them.

Mike

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

> To sum it up: fatal flaws + no path to fixing + no push from the community = inevitable eventual death.
>
> With great regrets,
> Shachar

I want to jump in for the sake of someone from the outside coming in and reading this to say that I disagree. I don't know a whole lot about the type of development you're doing, because that's not my line of work, and you obviously know that area well. However, for scripting tasks (as Dicebot mentioned) D is great. It is also great for real but smaller projects (5,000-20,000 lines). I don't think there's a better choice right now for data science/scientific programming, where you have many small jobs going on repeatedly, and those are large and growing areas.

Weka is an awesome project, but I don't know that most people considering D should use your experience as the basis of their decision. At least in my areas, I expect considerable growth in the usage of D over the next 10 years. Maybe it won't see much traction as a C++ replacement for large projects like Weka.

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 completely agree with this opinion

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

RAII is nowadays described as C++ nicest , more important and most powerful feature
D again, missed the opportunity on that one

Between Go, Rust, Ocaml, native C# and Scala ...
D needs a more serious and ambitious roadmap

The pragmatic approach, described in the main blog post, is not good enough, for a language that have a small community like D

On Thu, Aug 23, 2018 at 09:51:43PM +1200, rikki cattermole via Digitalmars-d wrote:
> On 23/08/2018 9:45 PM, Mihails wrote:
> > On Thursday, 23 August 2018 at 09:30:45 UTC, rikki cattermole wrote:
> > > Whoever acts as a project manager would need to be given the ability to override W&A as far as process is concerned. They shouldn't be able to create said process, but should be able to enforce it.
> > 
> > Good luck getting W&A to agree to it, especially when there is yet another "critical D opportunity" on the table ;)
> 
> No. They have power for as long as we the community say that they do. We are at the point where they need a check and balance to keep everybody going smoothly. And I do hope that they listen to us before somebody decides its forkin' time.

And the nice thing about D being open source is that should the situation escalate to the point where the community simply cannot get along with W&A anymore, forking is always an option.  (Hopefully it won't come to that, though. AFAIK there was a fork during the D1 fiasco with Tango vs. Phobos, but that fork has since basically died. Maintaining a language is a lot of work, and not everyone has the persistence to stick with it for the long haul.)


T

-- 
Guns don't kill people. Bullets do.

On Thursday, 23 August 2018 at 09:09:40 UTC, Shachar Shemesh wrote:
> On 23/08/18 09:58, Joakim wrote:
>> Because you've not listed any here, which makes you no better than some noob
>
> Here's one: the forum does not respond well to criticism.

Well, I'm D hobbyist and of course it's not a perfect language and you have some valid points, but on the other hand I think it's very disrespectful to come into a community and say the product that people are working mainly as volunteers and without any payment "is dead".

Matheus.

On Thursday, 23 August 2018 at 07:37:07 UTC, Iain Buclaw wrote:
> 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!

So your example of a fatal flaw is that D could be 100X faster at compilation instead of just 10X than most every other native language out there?! C'mon.

On Thursday, 23 August 2018 at 09:09:40 UTC, Shachar Shemesh wrote:
> On 23/08/18 09:58, Joakim wrote:
>> Because you've not listed any here, which makes you no better than some noob
>
> Here's one: the forum does not respond well to criticism.

Sounds more like you don't respond well to criticism, as the point stands that your original post was content-free.

> Here's an incredibly partial list:
>
> * Features not playing well together.
>
> Despite what Joakim seems to think, I've actually brought up an example in this thread.

Despite what you seem to think, perhaps because you didn't read what I wrote very closely, I noted your bugzilla link in my post you're quoting and asked you if you really thought it was fatal.

> Here is another one:
>
> functions may be @safe, nothrow, @nogc, pure. If it's a method it might also be const/inout/immutable, static. The number of libraries that support all combinations is exactly zero (e.g. - when passing a delegate in).

Yes, this is a known problem with D: why do you think it's fatal?

> * Language complexity
>
> Raise your hand if you know how a class with both opApply and the get/next/end functions behaves when you pass it to foreach. How about a struct? Does it matter if it allows copying or not?
>
> The language was built because C++ was deemed too complex! Please see the thread about lazy [1] for a case where a question actually has an answer, but nobody seems to know it (and the person who does know it is hard pressed to explain the nuance that triggers this).

By this rationale, C++ should be dead by now. Why do you think it's fatal to D?

> * Critical bugs aren't being solved
>
> People keep advertising D as supporting RAII. I'm sorry, but "supports RAII" means "destructors are always run when the object is destroyed". If the community (and in this case, this includes Walter) sees a bug where that doesn't happen as not really a bug, then there is a deep problem, at least, over-promising. Just say you don't support RAII and destructors are unreliable and live with the consequences.
>
> BTW: Python's destructors are unworkable, but they advertise it and face the consequences. The D community is still claiming that D supports RAII.

Maybe they're not critical to everyone else? How much time or money exactly has Weka spent on getting this issue and other "critical" bugs fixed? It is fairly laughable for a company that raised $42 million to complain that a bunch of unpaid volunteers aren't fixing bugs fast enough for them:

https://www.crunchbase.com/organization/weka-io

> * The community
>
> Oh boy.
>
> Someone who carries weight needs to step in when the forum is trying to squash down on criticism. For Mecca, I'm able to do that [2], but for D, this simply doesn't happen.

As Walter pointed out, "the forum" is not some D hive mind: it's a community filled with differing opinions. As I've faced what I felt to be unthinking criticism on another issue I raised only indirectly related to D, I know somewhat of what you're talking about, but honestly, there is a lot of criticism of D and its process too here.

Anybody on the internet is free to criticize any opinion you post online, you need to get a thicker skin. I really don't see much "squashing" going on, and I've previously argued against deleting/banning even those who voiced their criticism of D in uncouth ways:

https://forum.dlang.org/post/tzubjgtuiyfnmnglwywu@forum.dlang.org

Walter generally has a light touch with deletions/bans.

> This is a partial list, but it should give you enough to not accusing me of making baseless accusations. The simple point of the matter is that anyone who's been following what I write should already be familiar with all of the above.

I see, so every single bug you've ever posted to the forum in the past was a fatal flaw? If so, I question your judgement. If not, I was simply looking for some prioritization, which flaws were "fatal" and why.

> The main thing for me, however, is how poorly the different D features fit together (my first point above). The language simply does not feel like it's composed of building blocks I can use to assemble whatever I want. It's like a Lego set where you're not allowed to place a red brick over a white brick if there is a blue brick somewhere in your building.

This is a common criticism of D. You may be right that it will be "fatal." All I was looking for was substantive claims like this.

On Thursday, 23 August 2018 at 09:16:23 UTC, Mihails 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. D would really benefit from a project manager, which I think Martin Nowak has tried to do, and which the companies using D and the community should get together and fund as a paid position. Maybe it could be one of the funding targets for the Foundation.
>>
>> If the job was well-defined, so I knew exactly what we're getting by hiring that person, I'd contribute to that.
>
> Didn't intend to chime in, but no, that was not what I have meant at all.

I never said that's what you "meant," it was my own suggestion to make things better.

On Thursday, 23 August 2018 at 09:26:46 UTC, rikki cattermole wrote:
> On 23/08/2018 9:09 PM, Shachar Shemesh wrote:
>> functions may be @safe, nothrow, @nogc, pure. If it's a method it might also be const/inout/immutable, static. The number of libraries that support all combinations is exactly zero (e.g. - when passing a delegate in).
>
> Indeed that combination is horrible. It does deserve a rethink, but it probably doesn't warrant changing for a little while since its more of a polishing than anything else (IMO anyway).


I think that tends to be where D's biggest failing tends to be is the polish.

I started using D before these features existed, I also continue to use despite these features existing, like many I try to use them but end up falling back to not. But these things tend to be a big part of the D marketing.

I would classify the --dip1000 work as a polishing effort, but it also opens the doors to more areas that need polish, and most likely won't get it before --dip1000 is considered done.

I would also disagree with the community being hostile to criticism. Explanation and workarounds are usually given, not hostility. There is a huge resistance to change, but that should be expected and continue to increase. It is usually just sad how long it takes for change to happen when it needs to.

Tangent:

Sem versions may be easy to implement, but they have no value without practice. Practice isn't so easy to manage. We may not be following the sem version spec but it wouldn't add value to current practice. There is a patch release and there is a breaking changes and feature release. If we don't get the management of breaking changes correct, sem versioning is broken anyway.

On Thursday, August 23, 2018 9:03:24 AM MDT Ali via Digitalmars-d wrote:
> RAII is nowadays described as C++ nicest , more important and
> most powerful feature
> D again, missed the opportunity on that one

D was designed to have RAII, and it does. It's just that the implementation is buggy (which is obviously a serious problem), so depending on what your program is doing, it's not going to work correctly. It's not like we opted to not have RAII in D, and I'm sure that it will be fixed at some point. So, while it can certainly be argued that we've dropped the ball by not getting it fully fixed by now, I don't really see how it could be termed a missed opportunity.

- Jonathan M Davis

On 23/08/18 17:01, Steven Schveighoffer wrote:

> If they are blocking your work, complain about them loudly, every day. But not filing them doesn't help anyone.

The economics don't add up.

If a bug is blocking my work, there are two options:
1. I work around it, at which point it is no longer blocking my work (grep mecca for DMDBUG)
2. Work actively (in our case, get Johan to do so) until it does not.

Waiting for the community to fix a bug in D that is blocking Weka will get Weka kicked out of the market. There is no value proposition. We simply have to work faster than that.

The problem is that once I do work around a bug, I no longer have the resources to continue complaining about it. I need to move on. My main job is to develop for Weka, not develop D itself.

So telling me to keep filing them is simply a non-starter. I've got bugs that simply don't reproduce in watered down examples. I will not spend two days just to create a test case that demonstrates the bug outside the Weka code base. If nothing else, my boss won't allow me to spend that time.

Oh, and our code base over 300,000 lines. Don't say "dustmite". It is unable to process the code.

> 
> I'm not saying all bugs you file will be fixed, but all bugs you *don't* file will definitely not be fixed.

So far, my experience is that it has about the same chances of being fixed both ways, and not filing takes less effort.

I'm reminded of a friend of mine, who kept hoping to win the lottery despite never buying a ticket. His reasoning was that the chances of winning are not much changed by buying a ticket.

Shachar