THthreeseed·Aug 6, 2015
Go's channels/threading model already exists in Java:
https://github.com/puniverse/quasar
In A little Golang waypuniverse
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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 11:34:28 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
| 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
7 sources> 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 Go