parallel

Futureboard, a Flipboard-like Scala Futures demo

I’ll write more about this shortly, but yesterday I created a little video of a demo application I call Futureboard. It’s a Scala/Swing application, but it works like Flipboard in that it updates a number of panels — in this case Java JInternalFrames — simultaneously every time you ask it to update.

The “update” process works by creating Scala futures, one for each internal frame. When you select File>Update, a Future is created for each news source, and then simultaneous calls are made to each news source, and their frames are updated when the data returns. (Remember that Futures are good for one-shot, “handle this relatively slow and potentially long-running computation, and call me back with a result when you’re done” uses.)

Here’s the two-minute demo video:

Why you should know Monix alvin June 15, 2018 - 10:42am

In this short blog post I will try, in 10 minutes or less, to present what Monix library is and convince you that it is good to know it.

Formerly known as Monifu, Monix is a library for asynchronous programming in Scala and Scala.js

How to use multiple Futures in a Scala for-comprehension

If you want to create multiple Scala Futures and merge their results together to get a result in a for comprehension, the correct approach is to (a) first create the futures, (b) merge their results in a for comprehension, then (c) extract the result using onComplete or a similar technique.

Erlang: Processes interact by one method: exchanging messages alvin June 18, 2017 - 11:25am

“Processes interact by one method, and one method only, by exchanging messages. Processes share no data with other processes. This is the reason why we can easily distribute Erlang programs over multicores or networks.”

Joe Armstrong, in his book,
Programming Erlang: Software for a Concurrent World

The Netflix “journey to asynchronous programming” alvin September 30, 2016 - 9:41am

Netflix has a good, short article on their “journey to asynchronous programming.”

Why we can easily distribute Erlang programs over multicores or networks alvin August 9, 2016 - 8:55pm

“In Erlang it’s OK to mutate state within an individual process but not for one process to tinker with the state of another process ... processes interact by one method, and one method only, by exchanging messages. Processes share no data with other processes. This is the reason why we can easily distribute Erlang programs over multicores or networks.”

Joe Armstrong, in the book Programming Erlang