puniverse

quasar

Java2013–2019

puniverse / quasar

quasar

Fibers, Channels and Actors for the JVM

Systems & Infrastructure Languages & Compilers

Explore on GitHub Read Hacker News discussions

10Distinct people

27Mentions

0Explicit recommenders

4.5KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Fibers, Channels and Actors for the JVM

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:28:18 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year27 dated mentions

Observed mentions: 2013-07-23 16:57:50 UTC to 2019-12-01 12:42:39 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2013	2013-01-01 00:00:00 UTC	2014-01-01 00:00:00 UTC	8	8
2014	2014-01-01 00:00:00 UTC	2015-01-01 00:00:00 UTC	10	10
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	7	7
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	0	0
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	1	1
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	1

What Hacker News says

8 sources

pron·Dec 29, 2013

Here's my experience developing a JVM lightweight thread library[1]: 1. For the scheduler, we use the JDK's superb and battle-tested ForkJoinPool (developed by Doug Lea), which is an excellent work-stealing scheduler, and continues to improve with every release. 2. For synchronization, we've adapted java.util.concurrent's constructs (we use the same interfaces so no change to user code) to respect fibers, but users are expected to mostly use Go-like channels or Erlang like actors that are both included. 3. As for disk IO, Java does provide an asynchronous interface on all platforms, so integrating that wasn't a problem. 4. Integrating with existing libraries is easy if they provide an asynchronous (callback based) API, which is easily turned into fiber-blocking calls. If not, then ForkJoinPool does handle non-frequent blocking of OS threa

Read the rest

d gracefully. All in all, the experience has been very pleasant: callbacks are gone and performance/scalability is great. Things will get even better if Linux will adopt Google's proposal for user-scheduled OS threads, so that all code will be completely oblivious to whether the threads are scheduled by the kernel or in user space. Regarding performance, Linux does have a very good scheduler (unlike, say, OS X), but while there's little latency involved if the kernel directly wakes up a blocked thread (say, after a sleep or as a response to an IO interrupt), it still adds very significant latency when one thread wakes up another. This is very common in code that uses message passing (CSP/actors), and we've been able to reduce scheduling overhead by at least an order of magnitude over OS threads. I would summarize this as follows: if your code only blocks on IO, or blocks infrequently on synchronization, then OS threads are quite good; but if you structure your program with CSP/actors then user-space threads are only sensible way to go for the time being. [1]: https://github.com/puniverse/quasar

In The Rust standard library no longer has any scheduling baked into it

pron·Dec 13, 2013

How could I forget? I personally use runtime instrumentation all the time: https://github.com/puniverse/quasar

In About PayPal's Node vs Java “fight”

pron·Nov 10, 2013

The Quasar[1] library brings a more powerful async than C#'s to all JVM languages. [1]: https://github.com/puniverse/quasar

In Scaling Scala vs Java

pron·Nov 10, 2013

Well, it's a good thing we've got Java lightweight threads[1]. They let you write synchronous, blocking, simple code, which it transforms to asynchronous calls. It gives you this "Scala scalability" to Java (or any JVM language) without wrapping your head around functional constructs. Scalaists can think of it as an async macro that works for all JVM languages, and can span a whole call-stack rather than just a single expression. [1]: https://github.com/puniverse/quasar

In Scaling Scala vs Java

pron·Sep 16, 2013

You could also use Pulsar (https://github.com/puniverse/pulsar). It has the same API as core.async, but none of these limitations (only you would need to call Fiber/sleep or Strand/sleep instead of Thread/sleep). Other than that, !< and !!< etc. are interchangeable in Pulsar (and either could appear in a function called by the go block; they don't need to appear in the same expression). You could then also do IO in go blocks. But actually, Pulsar's main advantage is that it's simply a Clojure API for Quasar (https://github.com/puniverse/quasar), which adds all of these capabilities to Java and any other JVM language by providing true lightweight threads. core.async's advantage is that it can also be used in ClojureScript, while Pulsar only works on the JVM.

In Go Concurrency Patterns ported to Clojure

pron·Sep 10, 2013

Curiously enough, all of the features you've mentioned are doable on the JVM, even without TCO support (I know this because I've worked on implementing them in https://github.com/puniverse/quasar – well, except for the "budget-based yield" but that's a minor change). The general idea is that instead of providing the implementation baked into the VM, you inject it into the compiled code using bytecode instrumentation (at load or compile time). What truly separates BEAM from the JVM is the almost total process isolation, particularly, as you've mentioned, in the case of memory allocation and reclamation. This difference, however, entails tradeoffs – sometimes you'd want the one and sometimes the other.

In One VM to Rule Them All

pron·Aug 12, 2013

Exactly. And low-level concurrency research (snapshot algorithms, n-cas) is usually done in C or Java, and so on. BTW, Java has lightweight threads, too: https://github.com/puniverse/quasar (I'm the main author)

In Mio: A High-Performance Multicore IO Manager for GHC [pdf]

pron·Jul 23, 2013

I share the sentiment. People often mention that Go is less verbose than Java like they were talking about Clojure or something. Go is just a little less verbose than Java (other than in a hello world example), and targets the same conceptual "level" (same order of abstractions, same "distance" from the metal, although Java can get closer to metal than Go). So, sure, it feels a little more modern in some respects (and less modern in others), but when considering both languages carefully, I find I really need a magnifying to tell the two apart. If Go had offered everything that Java does, I still wouldn't have had a compelling reason to switch because the differences are just too small. But Go doesn't offer everything Java does. Like you said, Java's ecosystem dwarfs Go's. Java has dynamic linking, runtime code instrumentation, unparallele

Read the rest

d tooling, and better performance than Go. The only advantage I see Go has over Java is a shorter startup time, which makes it a reasonable choice for writing command-line programs. As for concurrency constructs, Java is far more flexible than Go, and because goroutines and channels are easy, I've ported them to Java[1] (and Clojure). Go sure is easy to get started with, but it would have to be 20 times better than it is to make me give up the JVM. In reality, it's just a recent, beginner-friendly Java without the awesomeness of the JVM. (P.S. I'm not sure Java's often mocked factory-factories aren't simply a result of the huge number of multi-million LOC programs that have been written in Java. It's just experience, and Go sure doesn't have the necessary abstractions to make engineering large systems any easier. Other recent languages -- sure -- but not Go) [1] https://github.com/puniverse/quasar

In Impressions of Go