YLyla92·Nov 18, 2014Submission
2 points · Open discussionReactiveX
RxJava
Java2013–2024
ReactiveX / RxJava
RxJava
RxJava – Reactive Extensions for the JVM – a library for composing asynchronous and event-based programs using observable sequences for the Java VM.
21Distinct people
27Mentions
0Explicit recommenders
48.2KGitHub stars
What to know before exploring
What it is
RxJava – Reactive Extensions for the JVM – a library for composing asynchronous and event-based programs using observable sequences for the Java VM.
GitHub
Where it is used
No documented product use was verified in the last source check.
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
- scala/scala-async · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 6:01:08 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-02-05 08:02:18 UTC to 2024-06-03 11:51:56 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 | 2 | 2 | 0 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 10 | 2 | 8 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 6 | 2 | 4 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
10 sourcesRxJava: A Java VM implementation of Reactive Extensions
3 points · Open discussionYeah I'm confused here too, I understand there might be a need for some of these, but you should be able to just rely on autoboxing of primitives to Objects like what RxJava does: https://github.com/ReactiveX/RxJava/tree/1.x/src/main/java/r...
I can maybe see an extra variation for exceptions, but that would be one more generic or a Set<? extends Exception> no?
In Java Functions: Every Java FunctionalInterface You WantJava has a few projects that get you pretty close:
http://docs.paralleluniverse.co/quasar/
https://github.com/Netflix/RxJava
In Is Java the Cobol of tomorrow and Go the Java of the future?RxJava's wiki is also pretty good: https://github.com/Netflix/RxJava/wiki
In An Introduction to Reactive ProgrammingNote that Netflix have a Java version here
https://github.com/Netflix/RxJava
They certainly have some interesting technology.
In Asynchronous JavaScript at NetflixSpeaking of the JVM, Scala has immutable data-structures. You stick one of those suckers into an AtomicReference and presto you've got a thread-safe data-structure. And for more complicated scenarios, you also have Scala-STM: http://nbronson.github.io/scala-stm/
Even though the concurrent data-structures in Java's library are efficient and well built, they remain error-prone because thread-safe operations are not composable. Working with immutable data-structures in a high concurrency scenario is the best thing since sliced bread.
I do agree with your point - sane concurrency implies using the right abstractions for the job and there are cases in which you need shared memory storage. The JVM is in fact great because it does 1:1 multithreading, because the GC is so good that it allows you to be a little wasteful and because it provides the
Read the rest
required concurrency primitives to build whatever abstraction on top that you desire.
For Scala + the JVM, just to enumerate - you've got actors by means of Akka and it's pretty capable as it's flexible and it allows you to manipulate/coordinate entire clusters of remote actors (and of course there's Quasar that does the lightweight threads thing and I'd love a comparison between the two btw), you've got the Future/Promise concept baked in and with a sane design [2], with C#'s "async" by means of a library that will be part of the standard [3], you've got great immutable data-structures that also have parallel extensions [4], you've got RxJava/RxScala for processing streams of events reactively [5], or Iteratee IO for safe processing of data streams [6], or shared transactional memory that I mentioned above [7] and of course things inherited from Java, like NIO which in spite of its flaws it's the sanest cross-platform abstraction over native APIs for async I/O, plus as I've said, the best cross-platform concurrency primitives you can get (e.g. I still get boners every time I use ReentrantReadWriteLock).
[1] http://akka.io/
[2] http://docs.scala-lang.org/overviews/core/futures.html
[3] https://github.com/scala/async
[4] http://docs.scala-lang.org/overviews/parallel-collections/ov...
[5] https://github.com/Netflix/RxJava
[6] http://www.playframework.com/documentation/2.2.x/Iteratees
[7] http://nbronson.github.io/scala-stm/
This first "Bolt" is effectively a port of .NET's Task Parallel Library to iOS / Android. Even down to the method names (trySetException).
I may be biased, but if you're writing a complex app, you'd do better to get thee to:
* https://github.com/Netflix/RxJava
* https://github.com/ReactiveCocoa/ReactiveCocoa
In Let’s Bolt: low-level libraries designed to make developing mobile apps easierFor high performance/throughput, the JVM beats both Go and Node.js. As an anecdote, I implemented a web service that was handling about 6000 requests per second of real traffic, per EC2 c1.medium server instance. In terms of dealing with concurrency, I/O, reactive stuff and everything else related, you've got:
- Actors (local or remote): http://akka.io/
- STM: http://nbronson.github.io/scala-stm/
- Futures/Promises in the standard library: http://docs.scala-lang.org/overviews/core/futures.html
- Async (e.g. C#'s async): https://github.com/scala/async
- RxJava Observables: https://github.com/Netflix/RxJava
- Iteratees: http://www.playframework.com/documentation/2.2.1/Iteratees
- Scalaz Streams: https://github.com/scalaz/scalaz-stream
And the list can go on.
In Scala – 1 Star Would Not Program AgainYou can write Java code which works similarly to your C# code by using RxJava: https://github.com/Netflix/RxJava
Or Python, via RxPy: https://github.com/Reactive-Extensions/RxPy
Or JavaScript, via RxJs: https://github.com/Reactive-Extensions/RxJS
Or Ruby, via Rx.rb: https://github.com/Reactive-Extensions/Rx.rb
Or Objective-C, via Rx.ObjC: https://github.com/Reactive-Extensions/Rx.ObjC
Your code is a good demonstration of how Rx works though, and it's nice to know it's becoming more popular.
In More functional C#