On Fri, 2014-03-07 at 16:53 +0000, Sean Kelly wrote: […] > 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. > > 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 the work. (*) 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. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
