BAbased2·Dec 1, 2019
In Quasar: High-perf, lightweight threads, Go-like chan, Erlang-like actors 4 Javapuniverse
quasar
Java2013–2019
puniverse / quasar
quasar
Fibers, Channels and Actors for the JVM
10Distinct people
27Mentions
0Explicit recommenders
4.5KGitHub stars
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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM 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
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
27 sourcesIn order to implement all the Scala language magic the generated byte code is sometimes far away from what the equivalent Java code byte code would look like.
This isn't a problem for most people but it is an issue for anyone who uses stuff like byte code instrumentation - take a look at this issue for example: https://github.com/puniverse/quasar/issues/45
It's not a criticism of Scala (the language is just a LOT richer so has to cater for more sophistication).
But the difference matters to me which is why I prefer Kotlin over Scala and I'm prepared to miss out on some of that sweet Scala magic.
In Google scored points with its community by supporting KotlinGo's channels/threading model already exists in Java:
https://github.com/puniverse/quasar
In A little Golang way> For multithreading : Quasar supports Kotlin (I'm waiting for quasar to support android though)
Have you opened up an issue on Quasar's repo (https://github.com/puniverse/quasar) so Parallel Universe can track this for a possible milestone?
In Ask HN: Has anyone here programmed in Kotlin? What do you think about it?Thanks. I think Erlang is the grandfather of languages using the actor pattern and at the same time Joe realized that POSIX threads does not belong to business logic code and it can be done without leaking the number of actual OS threads to the user's codebase. On the top of that Joe also implemented the message passing to avoid the shared memory that is a serious problem from the safety point of view for applications with threads. One thread can take down the entire process execution. Addressing these in Erlang made it possible to write the first commercial system with extra high availability and fault tolerance.
JVM is obviously great a VM, and Scala brings most of the Erlang (and many other languages) features to the table. I am not sure about the fault tolerance. I need to look into how Akka implements the actors.
> Concurrency means
Read the rest
synchronizing and sending messages between
> processes.
I think in Erlang you can do only async sending and when the receiving process wakes up it gets it through one of the means you mentioned.
http://bartoszmilewski.com/2009/02/10/message-passing-sync-o...
> Erlang can't cope with this load btw.
This is what I am curious about. I have seen only one big system written in Erlang that was massive big. WhatsApp was also running in Erlang and they achieved something like 1M connection/server. That was impressive. I am wondering how could you do that with Akka?
> https://github.com/puniverse/quasar
I am following the development of these, starting to use it in Clojure soon, I am curious how it works out. Personally I prefer Aleph on the JVM for Clojure projects but wanna see what is happening in Quasar & co.
https://github.com/ztellman/aleph
Erlang's processes are actually better than threads for many use cases, yes. But the thing is that with 1:1 multi-threading you can build many abstractions on top and for example on top of the JVM frameworks using Erlang's model like Akka [1] and Quasar [2] are very popular. Either way, you can't compare Erlang with platforms whose notion of parallelism involves POSIX's fork, but lo and behold, I'm comparing it with Java because I can.
MOST problems are not easily parallelizable and you'll end up with concurrency. Concurrency means synchronizing and sending messages between processes. For example sending messages between processes means opening a socket of some sort, serializing the data you want to send and deserializing it on the consumer's side. That's extremely inneficient and there's no way you can end up with a pipeline of tens of m
Read the rest
illions of messages per second, but with 1:1 multi-threading you can [3]. Erlang can't cope with this load btw.
One other thing I like about working with threads is the user-friendliness. Yes, skipping over the perils of multi-threading which you can sort of avoid by using better libraries, you can easily do things like number crunching using "parallel collections", combine actors with reactive streams and futures, or fake asynchronous I/O by blocking threads. People nowadays tend to underestimate the utility of blocking threads, but it's pretty cool having an interface like `def fetchData: Future[Result]` that could be implemented on top of Netty (asynchronous I/O) or with JBDC (blocking I/O), only suffer a very small penalty and your process to still be able to reach 80% of CPU utilization.
So I think OCaml getting multi-threading support is a pretty big deal.
[1] http://akka.io/
[2] https://github.com/puniverse/quasar
[3] https://lmax-exchange.github.io/disruptor/
Blatant self-promotion here, but Java's got fibers (aka lightweight threads, aka goroutines), too: https://github.com/puniverse/quasar
BTW, I don't like the term green threads because they have a connotation of being scheduled onto a single OS threads, while fibers/lightweight threads employ parallelism.
In Gotchas from Two Years with NodeHave you tried modern Java development and deployment lately?
It's really not that bad -- projects like https://github.com/puniverse/capsule, Oracle's http://openjdk.java.net/jeps/208 and reference implementation of such JEP, http://docs.oracle.com/javase/8/docs/technotes/guides/deploy... have made Java deployment a breeze.
Last, but certainly not least, the state of the art tooling for Java, the world class GC (and advanced ones like G1), the breadth and depth of its incredible ecosystem, the performance monitoring and extension API, the innovative Quasar library (https://github.com/puniverse/quasar) for concurrency alongside the features and additions in Java 8 pretty much make Java a serious contender for new projects.
If you haven't explored modern Java, I suggest you give it another look.
In Interview with Go’s Russ Cox and Sameer Ajmani> -Goroutines
https://github.com/puniverse/quasar (I'm the main author)
> Built-in, effective templating
So does Java (and for a long time): http://docs.oracle.com/javase/7/docs/api/javax/annotation/pr...
> and most of the performance problems were not GC-bound
The author's complaints were about GC pauses, and besides, Java is faster even for non-GC bound tasks.
> Go is simply easier/faster to start with
Maybe, but just a little, and mostly because Java has (too?) many libraries to choose from.
Even if the differences you highlight are indeed true (a point on which I disagree), those differences are, at best, quite small, while the advantages in Java's favor are much bigger, certainly in those areas that matter to the author.
In The ups of downs of porting 50k lines of C++ to GoIn Quasar[1] -- a library that adds true fibers (just like Go's goroutines) to the JVM -- we've decided to go with copying stacks as well (this is the current, and original, implementation). Of course, Java doesn't have pointers into the stack, so there's no need to fix any pointers when copying, and the implementation can be in pure Java.
[1]: https://github.com/puniverse/quasar
In How Stacks Are Handled in Gohttps://github.com/puniverse/quasar looks pretty nice, assuming you can't use erlang for whatever reason.
In Why I'm Productive in ClojureYou might want to check out Quasar. (https://github.com/puniverse/quasar) While it might not be something built into Kotlin, I would assume that Kotlin's interop with Java would make it easy to use. There's also a library called Pulsar for Clojure that wraps Quasar nicely. (written by the developers who are making Quasar)
In Kotlin: Statically typed programming language targeting the JVM and JS> And because the JVM does global stop-the-world garbage collection, which makes soft real-time implausible because of the unpredictability of GC affecting your actors. Erlang has per-process heaps.
Not quite. Every environment needs some shared memory semantics. In Erlang that's done with ETS tables, which don't undergo GC at all. Java's GCs are so good now, that, if shared data structures are used sparingly, would still give you better performance than BEAM. Plus, you have commercial pauseless GCs, as well as hard realtime JVMs.
> Basically the Erlang VM was created for this use case while the JVM was not, and its not something you can just add with a library. edit: Also the lightweightness of Erlang processes compared to Java threads[1] and hot code upgrades.
The JVM is so versatile, though, that all this can actually be added as a lib
Read the rest
rary, including true lightweight threads and hot code swapping (see Quasar[1]).
Nevertheless, BEAM was indeed designed with process isolation in mind, and on the JVM, actors might interfere with one another's execution more so than on BEAM, but even on BEAM you get the occasional full VM crashes. If total process isolation is not your main concern, you might find that Java offers more than Erlang, all things considered.
[1]: https://github.com/puniverse/quasar
Well, the JDK's ArrayList, for example, will box ints into Integers, but there are primitive int lists that won't. With Go, AFAIK, the problem is exactly the same. Can you write, say, a heap or a read-black tree that can store wither ints and strings, that will embed the ints? Also, value types are making it into the JVM in Java 9. I don't think that will solve the packed representation in a generic data structure problem, but neither does Go. OTOH, Java does optimizations that Go never can. For example, Java can inline interface calls, which Go can't (and due to the way Go defines interfaces, method calls are slower than Java even when not inlined in either).
Having said that, there are things about Go that I like better than Java: 1) no implicit primitive promotions (widening conversions), 2) a small standalone executable, 3) excellent
Read the rest
start up time. The latter two make Go suitable for quick, small programs, like command line tools etc.
However, there are more things I like about Java the Go doesn't have: 1) dynamic linking, 2) final variables, 3) concurrent data structures, 4) awesome monitoring and profiling tools, 5) generics, 6) state-of-the-art GC, 7) a polyglot VM (I also prefer Java's exceptions and explicit interface implementation, but these are minor considerations). So whenever I need serious, long-running, server-side software, I'd stick with Java over Go. Particularly now that Java has fibers (goroutines)[1] (I'm the main author).
[1]: https://github.com/puniverse/quasar
Actually, the closest we've got is Quasar[1] (I'm the main author). It's got true lightweight threads (goroutines), as well as selectable channels. On top, it's got actors, complete with selective receives and hot code-swapping.
It is much more actively maintained than Kilim, more general, and has better performance to boot. Also, Quasar fibers interoperate very nicely with plain threads. Blocking operations (such as channel receive) block the thread if you're running in a plain thread, and the fiber if you're running in a fiber.
In fact, we've even had time-sliced preemptive scheduling, which we've taken out because it didn't give performance benefits to fibers that block a lot, and for computations that don't, there's full blown threads (which Go doesn't have).
[1]: https://github.com/puniverse/quasar
In Tell HN: Lois - Golang like channels for JavaShowing the 15 most recent of 27 sources. Enable JavaScript to search and browse every indexed mention.