concurrency

Simple concurrency with Scala Futures (Futures tutorial)

Table of Contents1 - Problem2 - Solution3 - Run one task, but block4 - Run one thing, but don’t block, use callback5 - The onSuccess and onFailure callback methods6 - Creating a method to return a Future[T]7 - How to use multiple Futures in a for loop8 - Discussion9 - A future and ExecutionContext10 - Callback methods11 - For-comprehensions (combinators: map, flatMap, filter, foreach, recoverWith, fallbackTo, andThen)12 - See Also13 - The Scala Cookbook

This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 13.9, “Simple concurrency with Scala Futures.”

Back to top

Problem

You want a simple way to run one or more tasks concurrently in a Scala application, including a way to handle their results when the tasks finish. For instance, you may want to make several web service calls in parallel, and then work with their results after they all return.

Back to top

Solution

A Future gives you a simple way to run an algorithm concurrently. A future starts running concurrently when you create it and returns a result at some point, well, in the future. In Scala, it’s said that a future returns “eventually.”

Modern garbage collection

From the article: “The reality is that Go’s GC does not really implement any new ideas or research. As their announcement admits, it is a straightforward concurrent mark/sweep collector based on ideas from the 1970s. It is notable only because it has been designed to optimise for pause times at the cost of absolutely every other desirable characteristic in a GC.

What is a Future in Scala?

In the Scala Standard Library, a Future is a data structure used to retrieve the result of some concurrent operation. This result can be accessed synchronously (blocking) or asynchronously (non-blocking).

~ from the akka.io docs

(For more information, here’s my Scala Futures example.)

Why we can easily distribute Erlang programs over multicores or networks

“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

What is “Functional Programming”?

Table of Contents1 - Defining “Functional Programming”2 - A working definition of “pure function”3 - Note 1: Higher-Order Functions are a great FP language feature4 - Note 2: Recursion is a by-product5 - Proof: Wikipedia’s FP definition6 - Proof: A wonderful quote from Mary Rose Cook7 - That’s great ... but why immutable values?8 - Summary9 - See also

Note: This is an excerpt from my forthcoming book on Scala and functional programming. (No one has review this text yet. All mistakes are definitely my own.)

Back to top

Defining “Functional Programming”

It’s surprisingly hard to find a consistent definition of functional programming. As just one example, some people say that functional programming (FP) is about writing pure functions — which is a good start — but then they add something else like, “The programming language must be lazy.” Really? Does a programming language really have to be lazy (non-strict) to be FP? (The correct answer is “no.”)

I share links to many definitions at the end of this lesson, but I think you can define FP with just two statements: