On Fri, 2014-03-07 at 16:53 +0000, Sean Kelly wrote:
Post by Sean Kelly
68K connections is nothing. I'll start getting interested when
his benchmarks are 200K+. Event-based systems in C can handle
millions of concurrent connections if implemented properly. I'd
like to believe vibe.d can approach this as well.
There used to be a 100k problem, i.e maintaining more than 100k active,
that means regularly causing traffic, not just being dormant for a few
centuries, but so many frameworks can now support that , that it has
become a non-metric. I don't know if Spring, JavaEE, can handle this but
on the JVM Vert.x certainly, I suspect Node.js can as well. Vert.x is
caliming to be able to handle millions of active connections.
I suspect it is now at the stage that the OS is the bottle neck not the
language of the framework.
Post by Sean Kelly Post by Bienlein
I don't like Go's simplistic nature, either, but Go is not
about the language. It is about making concurrency much simpler
and allowing for many many threads. IMHO this is what gives Go
the attention. Except for Erlang no other system/language than
Go can get something similar accomplished (except Rust maybe
when it is finished, but it is not clear whether it will have
good built times like Go or D).
If you want to give D a boost, put Go-style CSP and green
threads into it as well. Then D will start to fly. Otherwise it
will have to continue competing against C++ as its sole
application area where it will always remain a niche player,
because of the market dominance of C++.
vibe.d already works this way. And there's a pull request in
place to make std.concurrency support green threads. I think
we're really pretty close. I do need to set aside some time to
start on IPC though.
I agree that as a stripped down C, Go sucks. But as a strongly typed
language, unlike C, it is not bad. But as everyone agrees (I hope), Go's
USP is CSP (*). The whole goroutines thing (and the QML capability)
keeps me using Go. And to be honest the whole interfaces model and
statically typed but duck typed is great fun.
I think what Go and Erlang do is to use green threads (or equivalent,
goroutines in Go) for the applications side and a kernel thread pool
within the runtime doing "work stealing" on the green threads. This is
more or less (ish) what the Java Fork/Join framework of Doug Lea does as
well. The upshot is that you appear to be able to have thousands of
threads in your program but maybe only a few actual kernel threads doing
(*) Rob Pike reports that he and co-workers came up with the Go model
independently of Hoare's CSP, via the Newsqueak, Alef, Limbo, Go
sequence. I see no reason to disbelieve him. Whatever the truth, Go is
now marketed as realizing CSP, not the Hoare variant of 1978 but CSP
with amendments introduced over time. It's just a pity no-one yet has a
realization of ?-calculus as well ? other than the programming language
Pict, and the Scala library PiLib.
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: This is a digitally signed message part