On Wednesday, 16 April 2014 at 14:16:30 UTC, Bienlein wrote:
On Wednesday, 16 April 2014 at 14:06:13 UTC, Sönke Ludwig wrote:
I agree, but I also wonder why you still keep ignoring vibe.d.
It achieves exactly that - right now! Integration with
std.concurrency would be great, but at least for now it has an
API compatible replacement that can be merged later when
Sean's pull request is done.
The point is that vibe.d is a distributed solution. Nothing
wrong about that. But in a single instance of some Go program
you can >locally< spawn "as many threads as you like" with the
number of threads easily being 50.000 and more. It seems that
in the Go community people often do that without going
distributed. Looks like this makes things a lot simpler when
writing server-side applications.
Goroutines are not threads and by calling them as such you only
confuse yourself. Their D counterpart is fiber and you can
definitely spawn 50 000 fibers for single local thread.
It is not the first time you try to advocate some Go features
without first actually exploring relevant domain. All you
describe is already implemented in vibe.d
