A Brief Comparision of Concurrency in Grand Central Dispatch (GCD) and in Scala

This is a first, brief note on the general similarities and differences in how concurrency constructs in Apple's GCD (Grand Central Dispatch) compare with similar constructs in Scala.

Both Scala and GCD require Closures / Code Blocks as well as Mutability / Immutability as the language-level foundation for their concurrency models.

• Scala has supported closures (or code blocks) and mutability declarations as basic primitives in its more general functional extension to Java.
  
• Apple has proposed the addition of elements to the C language that would bring support for code blocks and mutability to the standard C language. Apple has also modified the GCC 4.2 (C compiler) to accommodate the addition of these elements. Apple has made these modifications available under the MIT license. Apple has used these extensions in OS-X 10.6.
  

Both Scala and GCD support an event driven concurrency model.

Both Scala and GCD support "segmented programming". The segmented programming model is very popular and the accepted norm in GUI programming, where the developer implements, essentially, a series of call-backs that are called in response to various GUI events. Segmented programming model is an excellent model when we wish to support concurrent execution, as is often the case with GUI development. (For more on segmented programming model, see presentation Ulf Lange and I gave in Java One 2002.)

The major difference between GCD and Scala concurrency model is that GCD relies on dispatch/queue paradigm while Scala relies on message/actor paradigm.

I believe any complexity in using either GCD or Scala has to do primarily with learning the proper use of closures and immutability.

There are a few other things that separate GCD and Scala.

Scala is a natural evolution of Java as Java was a natural evolution of C or C++. For this reason, Scala provides familiar grounds to the Java programmer. It will be very familiar to Java programmers who are willing to learn about functional features as well as more complete static typing in Scala which helps with program conciseness. (As a Java programmer, I could not put down the first Scala book I picked up. All enhancements, modifications and changes that Scala has brought with respect to Java make sense, and the resulting conciseness in Scala proves to be a blessing when it comes to development work.)

GCD relies not only on the C language extension Apple has proposed (and the C compiler changes it has made available under a very permissive licensing model) but also on the specific APIs for GCD. These APIs are particular suited to the Objective-C and Mac OS-X environment. However, the major part of GCD API can be implemented in all environments and all of it will make sense in any Unix/Linux based system.

It would be good to see Apple's proposed changes to the C language adopted by the standards committee that looks over C.

Natural Evolution ...

C-->C++-->Java-->Scala

Any, Nothing, Scala and Java

The type verification engine in Scala outdoes the one in Java.

To enable this relative strength, Scala has defined, among other features, a closed type system, with the inclusion of "Any" and "Nothing".

"Any" is the super-type of all types. This is nothing new. Java has this, too, essentially speaking.

"Nothing" is the subtype of all types. When it comes to classic and modern type theory, there's nothing new about "Nothing" either. However, "Nothing"-ness is revolutionary new when thinking of how Java has treated types.

Java designers -- perhaps for the sake of the love of trees (I mean "trees" as a graph concept) and the love of "simplicity" of type system that characterizes OS and language designers wish to serve common programmers in general -- did not stipulate "Nothing". Had they done so, we would have had a completely different language in its characteristics from what became Java.

"Nothing" is a simple change but the consequences on the type system and language features are widespread.