Take it with a grain of salt.
They claim this isn't about the length of code, yet they select the most verbose way to use Spark and proudly display how long it is.
I mean sure, lack of event-time based processing is known limitation of Spark (and a pretty annoying one - though it is supposed to be worked on) but there are ways to write about it without code made to look bad on purpose.
EDIT: come to think of it, this whole article is "spark streaming can't do event time" written in thousands of words with contrived examples attached.
The primary argument is demonstrated through color coding different logical bits, which end up being clearly portable and elegantly distinct in dataflow.
This is demonstrated in two ways:
1. The "juicy value add" code that does the aggregation is labeled yellow, and doesn't change across all the samples with Dataflow. With Spark, it needs to be rewritten for every use case. Similarly, for all colors.
2. In Dataflow all the colors are separate. This makes expressing your logic easier. In Spark, the colors mix in dramatic ways with every demonstrated use case.
As Tyler said, all this is described in the blog post itself, but I don't blame you for missing it, since it's a really long post :)
The Datasets thing is more interesting. There is no doubt that the way they unify the Dataframe/RDD programming model is better, but it is so new (1.6 only) we certainly haven't migrated to it yet. The documentation isn't huge, either: http://spark.apache.org/docs/latest/sql-programming-guide.ht...
Spark streaming really feels operationally immature compared to a lot of other stream processing frameworks, even Dataflow. The criticism is both unsurprising and warranted.
In spite of these shortcomings, it has pretty good Kafka integration, mostly uses the same paradigm as batch and plays well with hadoop infrastructure. Makes it a decent choice for many use cases
Regardless, most of these stream processing frameworks are still very much in early days and lack a lot of the sophistication you find in custom in house systems (such as found at... Google ;-). The open source world will no doubt catch up and overtake those systems, but right now there is still enough of a gap that it is rather painful.
Spark streaming pains:
1. Backpressure & stragglers. Duh. 2. Setup & tear down is still rough, even compared to Storm. 3. The whole context singleton thing means you need a new VM for each job, which annoys the #@$@#$ out of me. 4. Error handling isn't just unclear, it's kind of disastrous. 5. You can feel its "batch" heritage in lots of places, not just the stragglers. For some that is a feature, for me, a bug, even though with Storm I use Trident. 6. When a job runs amuck, it's a pain to recover from it. Storm is no picnic either, but it is indeed better.