On 3/27/2015 5:48 AM, Dejan Lekic wrote:
> 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.

This style of programming does take some getting used to for one that is used to traditional loop programming (like me). But it is like learning a new language - once you learn what byLine, join, etc., do, it is pretty simple to see what is happening.

Am 27.03.2015 um 19:56 schrieb Walter Bright:
> On 3/27/2015 5:15 AM, Sönke Ludwig wrote:
>> 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.
>
> It's awesome that vibe has that! How about replacing the fiber support
> in druntime with that?

It's actually based on the fiber support in Druntime. It would definitely be great to get the event loop and the scheduler into Druntime/Phobos, too. But it needs to be integrated in many places at the same time (core.sync.*, std.concurrency, std.stdio, std.socket etc.) to avoid bad surprises for users. We'd need to decide how to cut that work into manageable pieces.

Fortunately there is now already an event loop abstraction written in pure D [1], which should be integrated first, because the fiber scheduler itself isn't worth much without an event loop.

[1]: https://github.com/etcimon/libasync

On Friday, 27 March 2015 at 19:11:58 UTC, Walter Bright wrote:
> On 3/27/2015 5:48 AM, Dejan Lekic wrote:
>> 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.
>
> This style of programming does take some getting used to for one that is used to traditional loop programming (like me). But it is like learning a new language - once you learn what byLine, join, etc., do, it is pretty simple to see what is happening.

Sean Parent's advice for "no raw loops" comes to mind. https://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning With that rule, basically a one-line body for foreach becomes acceptable.

Your own description of component programming was also very good. Also Andrei's description of generic algorithms as being something like the final destination of programming, etc.

You start with the same old code you might be used to from other languages, and then slowly learn to write generic code and propose new algorithms.

On 03/26/2015 09:47 PM, Walter Bright wrote:
>
> It seems to me that every significant but one feature of Go has a pretty
> much direct analog in D

I'm no Go expert, but AIUI, Go seems to be one of those languages that considers *lacking* certain features to *be* a feature. Ie the whole "minimalism" approach to language design. For people who value that (not for me personally though), it's a feature D doesn't offer and deliberately doesn't try to.

On Friday, 27 March 2015 at 20:20:07 UTC, Nick Sabalausky wrote:
> On 03/26/2015 09:47 PM, Walter Bright wrote:
>>
>> It seems to me that every significant but one feature of Go has a pretty
>> much direct analog in D
>
> I'm no Go expert, but AIUI, Go seems to be one of those languages that considers *lacking* certain features to *be* a feature. Ie the whole "minimalism" approach to language design. For people who value that (not for me personally though), it's a feature D doesn't offer and deliberately doesn't try to.

there's a difference between minimalism and blatantly not adopting core advances in language design over the past 40 years.

On 3/27/2015 1:20 PM, Nick Sabalausky wrote:
> I'm no Go expert, but AIUI, Go seems to be one of those languages that considers
> *lacking* certain features to *be* a feature. Ie the whole "minimalism" approach
> to language design. For people who value that (not for me personally though),
> it's a feature D doesn't offer and deliberately doesn't try to.

That's right. What a minimal language does is transfer the work from the compiler to the programmer. Obviously, I prefer to transfer the work to the compiler.

After all, if you're going to be spending 8 hours a day programming, investing a few more hours to learn the language is nothing compared with the time savings from using a more powerful one.

On 3/27/2015 1:35 PM, weaselcat wrote:
> there's a difference between minimalism and blatantly not adopting core advances
> in language design over the past 40 years.

Yes, and there's also a difference between gratuitous complexity and finding the underlying simplicity.

It's a tricky thing finding the sweet spot.

On Friday, 27 March 2015 at 20:58:44 UTC, Walter Bright wrote:
> On 3/27/2015 1:35 PM, weaselcat wrote:
>> there's a difference between minimalism and blatantly not adopting core advances
>> in language design over the past 40 years.
>
> Yes, and there's also a difference between gratuitous complexity and finding the underlying simplicity.
>
> It's a tricky thing finding the sweet spot.

I don't disagree, but Go is definitely not in that sweet spot - it's crippled by its benevolent dictators for the sake of being crippled.

On Fri, 27 Mar 2015 16:11:41 +0000, Ola Fosheim Grøstad wrote:

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

but it is broken! the whole point of async i/o servers is that such servers spend most of their time waiting for i/o. and if you need to do some lengthy calculations, you either spawns a "real thread" and commands it to wake you up when it is finished, or asking external server to do the job (and wake you when it is finished).

what moving fibers from thread to thread does is bringing in state copying (we want our threads fairly isolated, aren't we? so either copying, or ownership management).

the whole thing of cooperative multitasking is to be... cooperative. in several years some Shiny New Async Framework will use "no transferring fibers between worker threads" as Spectacular Invention.

On Friday, 27 March 2015 at 22:32:32 UTC, ketmar wrote:
> On Fri, 27 Mar 2015 16:11:41 +0000, Ola Fosheim Grøstad wrote:
>
>> 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?
>
> but it is broken! the whole point of async i/o servers is that such
> servers spend most of their time waiting for i/o. and if you need to do
> some lengthy calculations, you either spawns a "real thread" and commands
> it to wake you up when it is finished, or asking external server to do
> the job (and wake you when it is finished).
>
> what moving fibers from thread to thread does is bringing in state
> copying (we want our threads fairly isolated, aren't we? so either
> copying, or ownership management).
>
> the whole thing of cooperative multitasking is to be... cooperative. in
> several years some Shiny New Async Framework will use "no transferring
> fibers between worker threads" as Spectacular Invention.

as an outsider to the web-scale world,
this entire thing seems like a half-baked fork reimplementation