From the Quasar website:
Java 7 is required to run Quasar.
Quasar is a Java library that provides high-performance lightweight threads, Go-like channels, Erlang-like actors, and other asynchronous programming tools.
Quasar’s chief contribution is that of the lightweight thread, called fiber in Quasar.
Fibers provide functionality similar to threads, and a similar API, but they’re not managed by the OS. They are lightweight in terms of RAM (an idle fiber occupies ~400 bytes of RAM) and put a far lesser burden on the CPU when task-switching. You can have millions of fibers in an application. If you are familiar with Go, fibers are like goroutines. Fibers in Quasar are scheduled by one or more ForkJoinPools.
Fibers are not meant to replace threads in all circumstances. A fiber should be used when its body (the code it executes) blocks very often waiting on other fibers (e.g. waiting for messages sent by other fibers on a channel, or waiting for the value of a dataflow-variable). For long-running computations that rarely block, traditional threads are preferable. Fortunately, as we shall see, fibers and threads interoperate very well.
Fibers are especially useful for replacing callback-ridden asynchronous code. They allow you to enjoy the scalability and performance benefits of asynchronous code while keeping the simple to use and understand threaded model.
zerorpc can be used programmatically or from the command-line. It comes with a
convenient script, “zerorpc”, allowing to:
- expose Python modules without modifying a single line of code,
- call those modules remotely through the command line.
It looks like it used gevent for concurrency.
Play is a web application framework designed to make web development simpler. It is inspired by convention-based frameworks such as Ruby on Rails and Djnago. Play seems to be trying to take the best from the Java web development ecosystem and strip away some of the more cumbersome parts.
Major differences From other Java frameworks:
- Stateless: Play 2 is fully RESTful – there is no Java EE session per
- Integrated unit testing: JUnit and Selenium support is included in the core.
- API comes with most required elements built-in.
- Static methods: all controller entry points are declared as static (or
equivalently, in Scala, methods on Scala objects). After requests were made
for this to be customisable, Play 2.1 now supports other styles of
controllers, so controllers need not be static/Scala objects; however, this
is still the default.
- Asynchronous I/O: due to using JBoss Netty as its web server, Play can
service long requests asynchronously rather than tying up HTTP threads doing
business logic like Java EE frameworks that don’t use the asynchronous
support offered by Servlet 3.0.
- Modular architecture: like Rails and Django, Play comes with the concept of
- Native Scala support: Play 2 uses Scala internally, but also exposes both a
Scala API, and a Java API that is deliberately slightly different to fit in
with Java conventions, and Play is completely interoperable with Java.