You emphasize two points that I would also like to add to. 1) Functional languages makes parallel programming magically easy. This is something that is mislea

You emphasize two points that I would also like to add to. 1) Functional languages makes parallel programming magically easy. This is something that is misleading as you point out. Functional languages (where you have not used mutable state) do make it easy to convert you algorithm to run on multiple cores but that doesn't translate to an algorithm that scales well with number of cores. The problem of parallelization is not one of syntax or even semantics, it is an algorithmic one. You need to have in mind the problem and how to make it scale. Just cause you didn't use state doesn't mean that the algorithm that you wrote automatically takes full advantage of parallelism to solve a problem. What functional programming does is allow you to more easily express the parallel algorithm when you have it as well as giving you more options in how to do so. But for now and maybe this is cultural inertia, coming up with parallel algorithms is hard regardless of language. This is a distinction that is often glossed over probably because those who are aware of it find it so basic as to not worth mentioning. 2) F# and Scala are quirky and complex I will give a disclaimer and say that I use F# to write machine learning stuff so I am likely extra sensitive to this kind of bashing but.. That statement makes no sense and has no real meaning. Does he mean that the semantics allow undefined behaviours ala C++ or that the syntax is overly verbose or the syntax is just plain confusing? F# syntax is not so far from ML or Haskell or even python. As for undefined behaviour, strongly I doubt that applies. Scala has a formal specification. While F# doesn't have a formal specification it does have a very thorough (good enough) informal one. I am certain that it will not have implementation dependent behaviour and its strong static type system and garbage collected nature precludes the chance for un-trapped errors so the C++ style undefined behaviour can't be the issue. F# is certainly not verbose and although Scala, being more OOP centric is a bit more wordy, both languages are quite expressive. Terse syntax is meaningless. What matters is how easy and quickly it is to correctly express an algorithm balanced with how easy it is to mentally uncompress it later (on this case F# may even sometimes be too terse! I have taken to commenting and using quite long names for complex algorithms since otherwise it takes a goodly number of minutes to decompress - especially when the code is littered with single letter variable names that the mathematics like syntaxes subconsciously promote). I will admit that where F# is clunky is the number of ways you can cast and it is a fairly big language with Active Patterns, Workflows and Async and Agents on top of the typical functional idioms. But each such feature transfers a lot of expressive power - a fair trade. To brush aside languages like Scala , F# without having spent much time on them and in such an ambiguous manner is simply not fair. It is okay that he chose Clojure (wonderful language) but did not have the time (measured in months - fair enuff) to properly investigate all the choices but to brush them aside so trivially is intellectually dishonest, to be brutally truthful.