Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"

[via Digitalmars-d-announce]

On Saturday, 28 March 2015 at 11:52:34 UTC, Sönke Ludwig wrote:
> You can access TLS from an event callback just as easy as from 
> a fiber.

Yes, but it is much easier to verify that you don't hold onto 
references to TLS if get rid of arbitrary call stacks when moving 
to a new thread.

> And why can't you do the same with fibers and schedule the 
> fibers accordingly?

You could, but that's even more work since you then need to 
encode progress in a way the scheduler can use to estimate when 
the task can complete and when it must complete.

> It's you who brought up the randomization argument. Tasks are 
> assigned to a more or less random thread that is currently in 
> the scheduling phase, so that your constructed situation is 
> simply *highly* unlikely.

I don't understand how randomization can help you here.

> They *do* get balanced over threads, just like requests get 
> balanced over instances by the load balancer, even if requests

A good load balancer measure back-pressure (load information from 
the instance) and fire up new instances.

> are not moved between instances. But IMO it doesn't make sense 
> to go further with this argument with some actual benchmarks. 
> It's not at all as clear as you'd like what the effects on 
> overall performance and on average/~maximum latency are in 
> practice for different applications.

This is something you can do on paper. A language feature should 
support a wide set of applications.