NO. Just don't use features that you don't understand or like, but
don't punish happy D users by demanding a crippled D version.


On Sunday, 21 December 2014 at 22:21:21 UTC, Vic wrote:
> ...

I assume in order for your company to be happy in using D, you'd want it work, right? That is all I'm saying as well, lots of git examples and commercial projects using D.
And I'm not saying to remove *any* features at all. I'm saying *MOVE* some features, tbd. For example Linux has Kernal and GNU, who cares where in git they sit, right? (but GNU needs a working Kernal).

The example I linked(do you have it?) is like a more modern/younger language GO has exceptions. Or w/ GC, DI/IOC a 'generic' GC that makes you happy. But it does not make you sad to have an eco system, right?

Anyway, you have to hear maintainers start saying/doing things to make things more maintainable before you can worry, since I am not a committer my opinions ads up to 0 basically in open source world. (if I was, I'd fork it until 'CW' catches up and backports it).

Vic


On Monday, 22 December 2014 at 01:08:00 UTC, ZombineDev wrote:
> NO. Just don't use features that you don't understand or like, but
> don't punish happy D users by demanding a crippled D version.
>
>
> On Sunday, 21 December 2014 at 22:21:21 UTC, Vic wrote:
>> ...

"Ola Fosheim Grøstad" " wrote in message news:aimenbdjdflzgkkteruk@forum.dlang.org...

> Hardly, you have to be specific and make the number of issues covered in the next release small enough to create a feeling of being within reach in a short time span. People who don't care about fixing current issues should join a working group focusing on long term efforts (such as new features, syntax changes etc).

Saying it will work doesn't make it so.

> That's good, people should not expect experimental features or unpolished implementations to be added to the next release. What goes into the next release should be decided on before you start on it.

That's nice an all, but if you can't get developers to work on the features you've decided on then all you end up doing is indefinitely postponing other contributions.

I do agree that work should be polished before it is merged, but good luck convincing Walter to stop merging work-in-progress features into master. I've been on both sides of that argument and neither way is without drawbacks, with the current contributor energy we have available. 

>People have already suggested you to actually try vibe.d at least once before repeating "CSP is necessary for easy async" mantra.

I was trying to point out in some previous thread that the value of CSP is that concurrent things from the code looks like >>sync<< calls (not async, but sync). The statement above again says async and not sync (in "CSP is necessary for easy async mantra."). So, I'm not sure the point was understood.

Asynchronous programming is very difficult to get right and also inherently difficult. Programming with channels where things look like >>synchronous calls<< make concurrent programming immensely easier than with asynchronous programming. If you have done asynchronous programming for some years and then only spend 1/2 h looking at concurrency in Go you will grasp immediately that this is a lot lot simpler. All cores are being made used of very evenly out of the box and are constantly under high load. You have to work very hard for long time to achieve the same in Java/C/C++/C#/whatever, because the threading model is conventional. With CSP-style concurrency in Go it is a lot easier to write concurrent server side applications and whatever you do can hold 40'000 network connections out of the box. Yes, you can do that with vibe.d as well. But for Go you only need to learn a drop simple language and you can start writing your server application, because all you need for concurrency is in the language.

One idea would be to add a drop dead simple abstraction layer for vibe.d to provide the same and sell D as a language for server side development like Go. There is a need for a unique selling point. Let's say the guys at Docker had chosen D, because it had that already. Then they would realize that they also can use D for general purpose programming and be happy. But first there has to be a unique selling point. The selling point of a better C++ has not worked out. You have to accept that and move on. Not accepting that time moves on is not an option.

>Sorry, but wrong and wrong. Go has a model of concurrency and parallelism that works very well and no other language has, so Go has technical merit.

The technical merit is in the concurrency model as already said in the statement above. And currently is the time of server side software development. When C++ was started it was time for some better C. That time is over. Things change constantly and there is nothing you can do about that. You can accept that things have moved on and make use of the new chance of server side programming as a new selling point or continue living in the past. Go might be simplistic. So add CSP-style channels to D and you can overtake Go in all respects very easily. Besides, Haskell also has channel-based inter-process communication. If that is not academical/scientiic backing then I don't know.

On Monday, 22 December 2014 at 08:22:35 UTC, Daniel Murphy wrote:
> "Ola Fosheim Grøstad" " wrote in message news:aimenbdjdflzgkkteruk@forum.dlang.org...
>
>> Hardly, you have to be specific and make the number of issues covered in the next release small enough to create a feeling of being within reach in a short time span. People who don't care about fixing current issues should join a working group focusing on long term efforts (such as new features, syntax changes etc).
>
> Saying it will work doesn't make it so.

You need a core team, the core team needs to be able to cooperate on the most important features for the greater good. Then you have outside contributors with special interests, perhaps even educational (like a master student) that could make great long term contributions if you established work groups headed by people who knew the topic well.

More importantly: it makes no business sense to invest in an open source project that shows clear signs of being mismanaged. Create a spec that has business value, manage the project well and people with a commercial interest will invest. Why would I contribute to the compiler if I see no hope of it ever reaching a stable release that is better than the alternatives from a commercial perspective?

On Monday, 22 December 2014 at 10:30:47 UTC, Ola Fosheim Grøstad wrote:
> More importantly: it makes no business sense to invest in an open source project that shows clear signs of being mismanaged. Create a spec that has business value, manage the project well and people with a commercial interest will invest. Why would I contribute to the compiler if I see no hope of it ever reaching a stable release that is better than the alternatives from a commercial perspective?

It is not clear that the core team wants commercial investment, that's merely my guess of how D might become more polished and popular.  AFAICT, Andrei and Walter hope to get to a million users mostly through volunteers, which is a pipe dream if you ask me, though they don't appear to be against commercial involvement.  As you say, without presenting a more organized front, maybe such commercial investment is unlikely.

On Monday, 22 December 2014 at 01:08:00 UTC, ZombineDev wrote:
> NO. Just don't use features that you don't understand or like, but
> don't punish happy D users by demanding a crippled D version.
>
>
> On Sunday, 21 December 2014 at 22:21:21 UTC, Vic wrote:
>> ...

That is a valid argument if feature are orthogonal. When they aren't, it is just rhetorical bullshit.

On Mon, 22 Dec 2014 08:51:15 +0000
Bienlein via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> But for Go you only need to learn a drop simple language and you can start writing your server application, because all you need for concurrency is in the language.
i can assure you that "concurency in the language" is not the only thing one needs to know before "start writing a server". you keep telling that everything else in Go is so cheap to learn, so only CSP matters. oh, really? Go can magically do all header parsing, database management and other things for me? or we talking about "echo" servers?

Go is just hyped, that's all. there is NOTHING hard in creating simple HTTP(S) server with templated pages, forms and data processing with vibe.d. hey, it even has a sample of such server out of the box! it's dead easy. and vibe.d can utilize threads to use all CPU cores (you will lost some handyness here, but hey: don't use global variables! ;-).

even adding the whole Go to D will not make D overtake Go. Go is hyped. D is not. that's all.

On Monday, 22 December 2014 at 21:46:48 UTC, ketmar via Digitalmars-d wrote:

>i can assure you that "concurency in the language" is not the only
>thing one needs to know before "start writing a server". you keep
>telling that everything else in Go is so cheap to learn, so only CSP
>matters. oh, really? Go can magically do all header parsing, database
>management and other things for me? or we talking about "echo" servers?

Go does have good libraries for networking and support for REST, WS, messaging systems, bindings to other messaging systems, and all that stuff. I remember that even Walter or Andrei acknowledged that themselves somewhere in a post in this forum. To me Go is too simplistic. Everytime I try to like it I can't resist to say "No, I can't continue with this. It's just too minimalistic.". But they have a true selling point which is developing server side software and they have the batteries included for that.

What I'm saying is that being good at everything is good, but only a true selling point would receive people's attention. That's the way it is. Making D fit for server side development is a suggestion of mine. It seems to me something that has traction and will continue to have so unless the Internet dies a sudden death. There might be other even better ideas what could be selling points, but continuing with being good at everything and hoping that one day a big spender will come along might in the end not work out and result in a great loss of time. I don't want to appear harsh. It only seems to me that I wasn't able to bring my point across.

Cheers, Bienlein

On Tuesday, 23 December 2014 at 07:57:22 UTC, Bienlein wrote:
> What I'm saying is that being good at everything is good, but only a true selling point would receive people's attention. That's the way it is. Making D fit for server side development is a suggestion of mine.

Yes, responsive servers such as game servers would be a nice niche, but good auto-vectorization support is needed to perform well even there.

Interactive applications and game clients need a lot more support both in terms of platforms/frameworks, portability and tooling.