On Thursday, 8 October 2015 at 06:43:24 UTC, Laeeth Isharc wrote:
> In any case, we have now inconceivable amounts of computing power on tap for very affordable prices and the tools to manage it.  When a little instance is 0.7 cents an hour, and a usable one is 1.5 cents and you can scale up and down as quickly as you like, many things become possible that weren't before.  The world is only slowly beginning to figure out what, judging by what I see in finance.

It is amazing how much compute is on tap these days and we do almost nothing with it.  Forget about the cloud, just look at how powerful all these mobile devices are.  The problem is that software development has lagged leagues behind hardware development.

> Since I am foolish enough to run my own mail server, you can be sure that my sympathies are with you.

I used to do that, but what would stop them from getting into your server either?  Just as they go after email hosts, they can go after server hosts.  Unless you're running it out of your own house, which has other problems, most notably port-blocking by ISPs.

> I think people are reckless - both individuals and corporations - in what they unthinkingly cede to companies that really have few incentives to act as one might wish.  It's one thing to be the customer, and quite another to be the product.  I saw Eric Schmidt speak some years back, and he really didn't give me a feeling that we have a similar idea about what evil means!

They are reckless until they're personally hurt by it.  There will be a backlash when some scandal or hack forces people to change.  The recent ad-blocking and router security scandals are good examples, both of which have been festering for a _long_ time:

http://fortune.com/2015/09/20/apple-ad-block-ios9/
http://blog.codinghorror.com/welcome-to-the-internet-of-compromised-things/

> within the enterprise often being rather different.  Things even in quite small firms of 150+ people start being more about internal bureaucratic logic and much less about ROI.  And the problem is that it's hard to make a convincing case for something that doesn't yet exist, and yet many big things have the tiniest beginnings.  So the current enterprise technology environment discourages those little experiments that drive real innovation, as well as getting in the way of larger projects.

Interesting article along the same vein, that goes in a fairly radical direction until near the end, when it shifts course to point out how Apple is trying to account for this:

http://www.asymco.com/2015/08/31/fluid-coupling/

> The cloud, by commoditising compute, and making the price much more transparent then is a force for breaking down central structures that no longer serve their needs well.  When you can get whatever you need from Amazon today, waiting months and paying 10x more starts to seem a little stiff, and people start asking questions when before they had no choice but to grin and bear it.  Of course the questions about privacy and commercial confidentiality are there, but perhaps solutions are arriving, and business people need to be practical.  Even an overpriced internal cloud gives much more power to internal entrepreneurs than did the old way.

Heh, a more centralized external cloud allows more agility than the centralized internal IT systems that were in place before?  Perhaps.  Given all the data breaches, I don't think the problems with data security will ever go away though.

On Thursday, 8 October 2015 at 03:12:03 UTC, Martin Nowak wrote:
> We might be able to reuse the existing delegate capture mechanism to create continuations.
> Then await would "simply" rewrite the rest of the body as delegate, similar to how the foreach body can be transformed into a delegate.

Not sure how that works? What is needed is to preallocate a "continuation" that is large enough to cover all "stack allocated" state that has to be retained when the coroutine yields, at all yield points. But with reuse of memory for dead variables (like in optimized stack usage where you reuse stack memory that is dead). Then use those areas of the continuation during computation rather than the stack.

So basically all functions that may yield have to be available for static analysis before you start up the coroutine and all reachable yield points have to be analysed. So you basically have one big stack frame at the "top of the stack" as a separate object (the "continuation") and everything that has to survive a yield has to go onto that frame.

That's how I would do it anyway.

> There is some use-case for HPC code where stackless coroutines make a huge differences (used with a work stealing scheduler), for basic networking code it will only be a small difference.

The current D implementation can run out of stack. That's much less of an issue if the system/thread stack is used in combination with a fixed size preallocated "continuation".