On Saturday, 20 December 2014 at 12:21:49 UTC, Dicebot wrote:

> CSP is not superior to message passing for concurrent server programming and D already beats Go in this domain, it is purely marketing crap. Stop repeating same statement over and over again with no technical data to back it up. Or just go and implement CSP if you want it so much - I doubt anyone would object merging it if it is already implemented.

A different approach would be to use D's existing multi-threading model and develop a first class actor system for it like Akka for Scala/Java. But that would be a big effort and competing with Akka would be difficult anyway. So, again, an idea to think of might be to add CSP to D.

People have already suggested you to actually try vibe.d at least once before repeating "CSP is necessary for easy async" mantra. How about actually doing so? vibe.d + std.concurrency gives you pretty much standard actor model - it lacks more complicated schedulers and network message passing but fundamentals are all there.

On Saturday, 20 December 2014 at 12:50:02 UTC, Dicebot wrote:
> People have already suggested you to actually try vibe.d at least once before repeating "CSP is necessary for easy async" mantra. How about actually doing so? vibe.d + std.concurrency gives you pretty much standard actor model - it lacks more complicated schedulers and network message passing but fundamentals are all there.

CSP-style programming in D needs to be drop-dead simple as in Go to take off. You need to know about channels and the go command to spawn a thread and that's it. That's why Go was that successful. Vibe.d might be a well written system, but nobody will learn D and thereafter vibe.d. It is either laughable simple as in Go or it will not be noticed. The simplicity of channels and goroutines as in Go created the excitement. The same simplöicity is needed for any other language. The whole thing can be implemented with vibe.d, but at the surface there must only by goroutines and channels and nothing more.

On Saturday, 20 December 2014 at 12:39:01 UTC, Bienlein wrote:
> This way a lot of people out there have built server side systems with Go in record time. All the startups using Go are proof for this.

I would be wary of extrapolating best practices from what startups do.
Startups succeed when they bet on the right market or propose something new and needed. I suspect technological choices play little part here, and that's why most companies using Go are startups: they could use almost anything and have the same outcome.

Successful rewrites from hyped language X to hyped language Y as pictured in blogs can also be misleading: almost all rewrites are rewrites of problematic systems in the first place, hence successful especially rewrites of young programs.

On Saturday, 20 December 2014 at 13:56:01 UTC, ponce wrote:
> On Saturday, 20 December 2014 at 12:39:01 UTC, Bienlein wrote:
>> This way a lot of people out there have built server side systems with Go in record time. All the startups using Go are proof for this.
>
> I would be wary of extrapolating best practices from what startups do.
> Startups succeed when they bet on the right market or propose something new and needed. I suspect technological choices play little part here, and that's why most companies using Go are startups: they could use almost anything and have the same outcome.
>
> Successful rewrites from hyped language X to hyped language Y as pictured in blogs can also be misleading: almost all rewrites are rewrites of problematic systems in the first place, hence successful especially rewrites of young programs.


That is why I seldom buy into hype driven development.

Usually on our teams if a specific technology wasn't explicitly requested by the customer, whoever is bringing it in has to answer what is the business value to the customer.

On Saturday, 20 December 2014 at 14:06:51 UTC, Paulo Pinto wrote:
>
> That is why I seldom buy into hype driven development.
>
> Usually on our teams if a specific technology wasn't explicitly requested by the customer, whoever is bringing it in has to answer what is the business value to the customer.

I think D clearly has some value for the business:
- highly expressive/productive,
- developer morale, "feel-smart" effect for better or worse
- high reuse
- lower bug counts when compared to C++

But much like there is hidden costs, those aspects can go unnoticed as "hidden cost savings".

On Saturday, 20 December 2014 at 14:06:51 UTC, Paulo Pinto wrote:

>That is why I seldom buy into hype driven development.

Okay, so Docker is hype? Have you seen the impact of it? Every Java magazine has articles about Docker. And that is not because Java people had an interest in it, because it is written in Go. It is because of its business value.

Have a look at all the job offers for Go developers here: http://www.golangprojects.com. All those jobs are the result of some hype.

First, thank you all the committers for a 'gifted free' lang that we use to build a company, we could have used any lang, we chose D.

My point is on 'management' more than on 'software'. On management, *EVERY* project is resource constrained, so imo, D should figure out what resources it has at hand. Based on that prioritize what can be maintained and what can't be maintained and hence marked as deprecated (so those that do care for it can move it downstream). It's painful to kill many scared cows. I used example or CLR and JRE team size relative to their 'features surface area'.

Also, I'm pleased that 'no' is said at times (but ... we are still adding things right, w/o saying: and if we add that, what are 2 features we can move downstream?'. Last I'm hearing is Andreii will gift C++ compatibility, etc into core. **: reason to split up forum into users and public comitters so people like me don't panic)
Cheers,
Vic
ps:
Second smaller thing I 'elude' to but don't verbalize in that argument is my personal preference for a smaller language. Less is better/faster. I proposed to move those deprecated  features 'downstream', just like Linux Kernel and Linux GNU are separated (but can't exist w/o each other). To build an eco system.
(here is comments on C++ having more features, one of the reasons I like smaller
http://harmful.cat-v.org/software/c++/linus
I do see 'featuritis' http://bit.ly/1wzVPMR as a way to doom projects in a compound way )

As to Walter (yes I used Wacom c compiler) saying No, I think he is to nice and 99.5% is not good enough, I'd like him to be a mean
- http://www.brainyquote.com/quotes/quotes/l/linustorva141511.html
and start removing things. The list of candidates is long, GC has been brought up as something that can be moved downstream.
D could have reference counters in base classes, but end users could INJECT a 3rd party GC mechanism they like. It's same thing, but downstream. Also I showed example of Go exceptions being downstream.
I'm not saying these 2 (our of 100) are not nice features, I'm saying if 'we' were forced, they could be moved downstream. You can just open Andreii's D book table of contents and find over weight things - if you are motivated to do that.


On Friday, 19 December 2014 at 16:44:59 UTC, Joakim wrote:
> On Friday, 19 December 2014 at 15:11:30 UTC, Tobias Pankrath wrote:
>> On Friday, 19 December 2014 at 14:58:07 UTC, Joakim wrote:
>>> On Friday, 19 December 2014 at 14:38:02 UTC, Tobias Pankrath wrote:
>>>>> As for Walter already saying "no" a lot, given how many features D has, obviously one can still wish he went from 99% "no" to 99.5%. ;)  You don't need to be around the D community forever to feel that D still has too many features that made it in.
>>>>
>>>> Care to name a few and justify why exactly those features should be gone?
>>>
>>> No, as that's not really my problem.  I was simply trying to clarify the argument others have made, that the language seems overstuffed and overwhelming, which I have experienced at times but I'm not personally complaining about.>
>>
>> It is a worthless claim to make that there is too much of something, if you cannot come up with an concrete example. "I've got that gut feeling, that" is not even remotely an argument and just kills time of everyone in this discussion.
>>
>> If we want to discuss the future of the language, it's totally pointless to do it in an abstract way. “We need to make the language more stable“ is not a goal or something, it is totally unclear what that actually means, why this is important in the first place, how we can say that we have accomplished it or what we need to do to realise that goal.
>
> I have no dog in this fight.  I was merely pointing out to Walter and Mike that it's possible to say "no" a lot and still have others wish you had said "no" even more. :) There's no particular feature that I wish wasn't there, though of course there are many features that many wish were implemented or worked together better, as deadalnix points out.
>
> When Vic suggested a split into a stable core and an experimental layer, I suggested documenting the perceived stability of various features instead, so that users could have a guide for what features might be more problematic without having to do a deep-dive in bugzilla to figure it out for themselves.  I didn't back a split or have not suggested removing features.

On Saturday, 20 December 2014 at 12:13:42 UTC, Daniel Murphy wrote:
> It would be easy to define such a list, but it would be near-impossible to force contributors to follow it.

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

> Refusing to accept contributions outside the goals would most likely result in less contributions, not more focused contributions.

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.

On Saturday, 20 December 2014 at 15:14:28 UTC, Bienlein wrote:
> On Saturday, 20 December 2014 at 14:06:51 UTC, Paulo Pinto wrote:
>
>>That is why I seldom buy into hype driven development.
>
> Okay, so Docker is hype? Have you seen the impact of it? Every Java magazine has articles about Docker. And that is not because Java people had an interest in it, because it is written in Go. It is because of its business value.
>
> Have a look at all the job offers for Go developers here: http://www.golangprojects.com. All those jobs are the result of some hype.

I wasn't talking about Go specifically, rather the adoption of technologies in the going up slope of the hype curve in the IT fashion world.