开发者

List of evented / asynchronous languages

开发者 https://www.devze.com 2022-12-22 03:47 出处:网络
I\'m working on a system than has to be pretty scalable from the beginning. I\'ve started looking at / playing around with asynchronous/evented approaches to writing serverside code. I\'ve played arou

I'm working on a system than has to be pretty scalable from the beginning. I've started looking at / playing around with asynchronous/evented approaches to writing serverside code. I've played around with both ruby's EventMachine and node.js.

EventMachine is cool, but doesn't have asynchronous file I/O, which I need. The interface is kind of strange, too.

Node.js is awesome, but it's... uhh.. it's java开发者_如何学Pythonscript.

Can the greater Stack Overflow community help me out by listing other languages that have strong asynchronous support? To qualify, the language would need to support both closures and have libraries for asynchronous file io, http, etc. It would be nice to have something like node.js that was written in a stronger language than javascript.

Lisp? Python has twisted, right?


Erlang may be the language with the highest intrinsic scalability for server-side code (it manages multiprocessing for you, mostly by doing async, cooperative task switching "under the covers") -- if you can stomach its peculiar syntax and (often) peculiar semantics.

Python has twisted (very general purpose for all networking tasks), tornado (for server-side async specifically), and stackless (widely used in MMP online games), not to mention the old but usable asyncore that's in the standard library (and the even-older "Medusa" that sits on top of asyncore to enrich its functionality).

Go has very light "stackless" goroutines and channels for synchronization purposes when needed.


I would recommend that you take another look at node.js. One of the biggest problems with using libraries to do event-based programming in an object-oriented programming language (rather than using an event-based programming language in the first place), is that usually all the other existing libraries are not event-based, and it is really awkward to mix event-based and synchronous I/O. In fact, it is pretty much impossible, or more precisely, it is possible but destroys all the benefits of using event-based I/O in the first place. (Note that pretty much any third-party library you use (and the libraries that they use, and so forth), including the standard and core libraries of the language itself, must be event-based, to actually reap the benefits. Otherwise, you'll spend most of your project's time writing asynchronous wrappers around existing libraries.)

Now, if using event-based libraries is such a bad thing, then why do I recommend node.js? Simple: ECMAScript doesn't have any synchronous I/O libraries (because of the simple fact that it doesn't have any I/O libraries at all), so the mixing problem simply doesn't arise. (Actually, it has some I/O libraries, like XmlHttpRequest or Web Sockets, but guess what: those are already all event-based.)

node.js implements all I/O libraries itself, all event-based, without backwards-compatibility or legacy requirements.

Otherwise, every language or platform has some event-based or asynchronous I/O libraries: Ruby has EventMachine and Rev, .NET has Rx, the JVM has NIO, Unix systems have kqueue/epoll, C has libev and libeio (on top of which node.js and Rev are built), Perl has AnyEvent (built on top of libev by the same author) and so on.


F# has asynchronous workflows, which are a tremendous way to write async code.


Since you have expressed interest in Lisp, you might want to consider Clojure - a Lisp dialect for the JVM with a strong focus on concurrency. Pretty much anything can be run asynchronously by running it in an agent. Of course, it also provides painless access to the entire Java ecosystem.

0

精彩评论

暂无评论...
验证码 换一张
取 消