On Wednesday, 25 March 2015 at 22:30:15 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 25 March 2015 at 21:00:37 UTC, Andrei Alexandrescu wrote:
>> https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/
>>
>> Andrei
>
> Downplaying other languages makes the D crowd look desperate...
>
> Go has stability, is production ready and has an ecosystem with commercial value.
>
> D lacks all of these atm...

Not to mention that Go is in GCC for a very long time already... :)

I never liked the language much (I think Erlang or Scala are definitely better choices than Go), but it is in a much better shape than D (unless you want to use stable D1).

On Friday, 27 March 2015 at 12:15:03 UTC, Sönke Ludwig wrote:
> Am 27.03.2015 um 11:11 schrieb Walter Bright:
>> On 3/27/2015 2:57 AM, Russel Winder via Digitalmars-d-announce wrote:
>>> Aren't "green threads" now given the label fibres?
>>
>> My understanding of fibers is they are all in one thread. Go's green
>> threads can be in multiple threads, the same thread, and even moved from
>> one thread to another.
>>
>>> And I think Vibe.d
>>> has an implementation for these – but I do not know for certain.
>>
>> I don't know, either.
>
> It has, that is more or less the original selling point. It also keeps an internal thread pool where each thread has a dynamic set of reusable fibers to execute tasks. Each fiber is bound to a certain thread, though, and they have to, because otherwise things like thread local storage or other thread specific code (e.g. the classic OpenGL model, certain COM modes etc.) would break.
>
> Apart from these concerns, It's also not clear to me that moving tasks between threads is necessarily an improvement. There are certainly cases where that leads to a better distribution across the cores, but in most scenarios the number of concurrent tasks should be high enough to keep all cores busy anyhow. There are also additional costs for moving fibers (synchronization, cache misses).

I've always wondered whether thread-local fibers with a stop-the-world (or at least part of the world) load balancer that can move them would be a good model. You could get away without a lot of synchronisation e.g. tls could be fixed-up from the scheduler thread while all the others are stopped.

Perhaps there are good reasons why not, I don't know enough to say...

On Wednesday, 25 March 2015 at 21:00:37 UTC, Andrei Alexandrescu wrote:
> https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/
>
> Andrei

If Go community is what they believe they are - intelligent. They would not blame D community for this article, but the person who wrote it. - It is not tagged "Opinion" for no reason !!

My personal opinion about the article - people may hate D equally for being "too pragmatic". That `source.byLine.join.to!(string);` line for example, takes much longer time to understand than 20 lines of Go code. Any D newbie with knowledge of some modern language will struggle understanding (and being 100% sure that he/she understands!) that line of D code.

I could give a big list of things where Go has advantage over D. What I found pathetic is that Go community used list of established open-source projects done in Go. :) But OK, we expected that, did we?

On Friday, 27 March 2015 at 12:15:03 UTC, Sönke Ludwig wrote:
> distribution across the cores, but in most scenarios the number of concurrent tasks should be high enough to keep all cores busy anyhow. There are also additional costs for moving fibers (synchronization, cache misses).

It is a complete disaster to not move fibers between threads if you want good latency.

On Friday, 27 March 2015 at 14:18:33 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 27 March 2015 at 12:15:03 UTC, Sönke Ludwig wrote:
>> distribution across the cores, but in most scenarios the number of concurrent tasks should be high enough to keep all cores busy anyhow. There are also additional costs for moving fibers (synchronization, cache misses).
>
> It is a complete disaster to not move fibers between threads if you want good latency.

Only if execution time between fibers is very unevenly distributed and/or their amount is low.

On Friday, 27 March 2015 at 14:47:08 UTC, Dicebot wrote:
> On Friday, 27 March 2015 at 14:18:33 UTC, Ola Fosheim Grøstad wrote:
>> On Friday, 27 March 2015 at 12:15:03 UTC, Sönke Ludwig wrote:
>>> distribution across the cores, but in most scenarios the number of concurrent tasks should be high enough to keep all cores busy anyhow. There are also additional costs for moving fibers (synchronization, cache misses).
>>
>> It is a complete disaster to not move fibers between threads if you want good latency.
>
> Only if execution time between fibers is very unevenly distributed and/or their amount is low.

No... E.g.:

On the same thread:
1. fiber A receives request and queries DB (async)
2. fiber B computes for 1 second
3. fiber A sends response.

Latency: 1 second even if all the other threads are free.

On Friday, 27 March 2015 at 12:48:04 UTC, Dejan Lekic wrote:
> My personal opinion about the article - people may hate D equally for being "too pragmatic". That

Yeah, well, both the D/Go communities use the term "pragmatic" to gloss over underwhelming design issues in D/Go, and makes a point of how D/Go is deliberately not being a research language, yet still claim that D/Go bring novel features... although neither D or Go bring anything new to the table. I.e.just about all the major concepts in D/Go are 30-50 years old...

It is mostly a case of inexperienced programmers not knowing PL history becoming fanbois of new languages. Kind of like the OS wars of the 1990s.

On Friday, 27 March 2015 at 15:28:31 UTC, Ola Fosheim Grøstad wrote:
> No... E.g.:
>
> On the same thread:
> 1. fiber A receives request and queries DB (async)
> 2. fiber B computes for 1 second
> 3. fiber A sends response.
>
> Latency: 1 second even if all the other threads are free.

This is a problem of having blocking 1 second computation in same fiber pool as request handlers -> broken application design. Hiding that issue by moving fibers between threads is just making things worse.

On Friday, 27 March 2015 at 15:54:31 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 27 March 2015 at 12:48:04 UTC, Dejan Lekic wrote:
>> My personal opinion about the article - people may hate D equally for being "too pragmatic". That
>
> Yeah, well, both the D/Go communities use the term "pragmatic" to gloss over underwhelming design issues in D/Go, and makes a point of how D/Go is deliberately not being a research language, yet still claim that D/Go bring novel features... although neither D or Go bring anything new to the table. I.e.just about all the major concepts in D/Go are 30-50 years old...

It need not be new, it needs to be good. That's all. I don't understand this obsession people have with new things, as if they were automatically good only because they are new. Why not try square wheels? Uh, it's new, you know.

> It is mostly a case of inexperienced programmers not knowing PL history becoming fanbois of new languages. Kind of like the OS wars of the 1990s.

On Friday, 27 March 2015 at 16:06:55 UTC, Dicebot wrote:
> On Friday, 27 March 2015 at 15:28:31 UTC, Ola Fosheim Grøstad wrote:
>> No... E.g.:
>>
>> On the same thread:
>> 1. fiber A receives request and queries DB (async)
>> 2. fiber B computes for 1 second
>> 3. fiber A sends response.
>>
>> Latency: 1 second even if all the other threads are free.
>
> This is a problem of having blocking 1 second computation in same fiber pool as request handlers -> broken application design. Hiding that issue by moving fibers between threads is just making things worse.

Not a broken design. If I have to run multiple servers just to handle an image upload or generating a PDF then you are driving up the cost of the project and developers would be better off with a different platform?

You can create more complicated setups where multiple 200ms computations cause the same latency when the CPU is 90% idle. This is simply not good enough, if fibers carry this cost then it is better to just use an event driven design.