Yes, Virginia, Scala is complicated!

To begin with, let me clarify that I have been a big fan and supporter of Scala for 5 years now. I have written books and articles about Scala. I also worked with many companies that started using Scala and Lift and conducted a code review of a huge number of Scala projects. I used to think that Scala is simple. It has been and continues to be a cure for many Java problems. From the point of view of “complex or even impracticable things in Java are quite simple in Scala”, Scala is a fairly simple language. Working with collections is very simple. Isolation of business logic makes programs much more supported and incredibly simple than if they were written in Java.
So why is Scala complicated? Here are the best I could come up with:

• Scala is trying to take on too much. This means that you can continue to write Java-style code, which is both a curse and a blessing. But in the long run, I think it’s still a curse. There are too many debates about contrasting OO and FP. This kind of discussion is valid if you are a small team, but they are damn bad when you try to learn to write Scala Java developers who really don’t want to learn or change. The tremendous benefits of Scala, in fact, begin to manifest when you write in the style of FP, but it is almost impossible to attract OO developers until they themselves want to write in an unusual style. In this case, smaller language features, like in Java or Ruby, are easier to adapt, narrowing the range of potential solutions.
• poor support from the IDE (and always will be). Eclipse plugin for Scala (or how else is it called there this week) - sucks. He continues to be such for the past 5 years of my work with Scala. Constantly I hear “that’s going to be better,” and yet it sucks! IntelliJ’s Scala support is acceptable to me. But those who need templates in their IDE will not find Scala support to be good enough. Firstly, the patterns / patterns in Scala are so diverse and fragmented (OO through mikshiny - the path ScalaZ), that they are, indeed, incredibly many. If you successfully write code in Emacs, Vi or TextMate, everything is fine and the transition to IntelliJ will seem like a good idea. But in case of waiting for “goodwill”, similar to that obtained from Java IDEs, dreams will be broken and never realized because of Scala's comprehensive power, which will be difficult to implement, requiring a huge amount of investment. And even Typesafe with their 3 million on the account can not guarantee this.
• Scala's type system is extremely powerful, but from your point of view, perhaps even too much. In ScalaDocs, some signatures can look very scary. Take a look at
  

  flatMap [B, That] (f: (A) ⇒ Traversable[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That 

  
  and now try to tell me that it didn't blow your brain. This method is used by beginners every day, and maybe 20 times per day. Scala documentation needs a library that hides all this complexity. The complexity that makes the flatMap method incredibly powerful. For the type system and related documentation, a simpler and more user-friendly display mode is required.
• Beginner developers who need to support more experienced programs should understand the idioms and patterns in the code. Despite the fact that in Scala business logic is placed in front positions (rather than spreading through a bunch of for loops and complex if - expressions), depending on the idioms used, the code is still not obvious and easy to read. And at the end of the day it would be nice for you to team up to discuss the code written by Scala along with all the techniques used. This is also true for Ruby on Rails, where hashmaps can virtually replace all programming paradigms. But in the Rails world, the paradigm is uniform (although not based on type checking) and easy to read. In Java, the patterns are already embedded in the IDE, so developers as they “mature” learn and become able to define them. But, unfortunately, this approach has no place to be in Scala, with its too diverse idioms, depending on the command or framework used.

There are several types of commands for which Scala is definitely a better option than Java, Ruby or some other language. Twitter is a great proof of that. They need a clear, type-safe, high-performing language and environment. And Scala gave them all this. Foursquare uses the complexity of Scala for its filtering mechanism. You must be good enough to be able to master Scala and be successful in Foursquare.
But if you have a team with skills close to the middle, the choice of Scala may not be optimal (it depends on the management ... does Scala challenging features are required to filter and improve the team?) Being a mediocre company, in terms of training, Scala will cost you a rejection of existing developers, the lack of patterns. You will need a strong technical director or architect to create patterns, rather than isolating them from books or an IDE. And the number of such medium-sized companies with fairly strong technical directors or architects, to put it mildly, is small.
So, how can you find out if Scala will be easy to adapt to your organization:

• Your company has speakers on JavaOne, OSCON, Strange Loop, QCon - Scala will be simple
• Early discussions include criteria for moving from a regular developer to an older developer — Scala will be hard
• If you have to, your developers will be able to write code in NotePad - simple
• Your developers are indifferent or say 3 “Hail Marys” when they hear the name “Zed Shaw”: Scala == Hard
• Developers follow Dean Wampler on Twitter: Scala is simple
• Your developers come to work at 9.15 and go to 6, without checking your email - Complicated

Of course, you may have your thoughts on this account. But I definitely agree with the statement that Scala for the middle team is difficult. And not only is it difficult, but it may still not bring any advantages in the near or future future. Those that could bring teams consisting of participants with 95% skill.
And a few more thoughts:

• Yes, Scala's type system is very powerful and can lead to great code beauty, as in the Scala collections.
  See stackoverflow.com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-histo and www.scala-lang.org/docu /files/collections-api/collections-impl.html
  But there is a difference between the needs of language designers / libraries and medium-sized developers. And the lack of such a division in Scala entails difficulties for the latter. Personally, I do not think I could express ideas in Lift so clearly and powerfully in any other language. Therefore, as a library designer, I love Scala. But as I, and many people who do not think Scala is complex - not average. And the 11-year-old boy writing in Scala is also not in the middle.
• Yes, an improvement in ScalaDocs, providing “simple” and “architectural” viewing can be a big victory. But this is just the starting point, but not the final one.
• I unequivocally reject the argument “excellent, then we will find more professional developers”. We have to solve the problem of “Scala is hard”, working to improve the competence of developers as a whole (some who can read type signatures, others express their programs using mathematical approaches, etc.), but we are moving away from the essence. And the point is that Scala is not as well suited to start a revolution in learning, education or hiring, as it is suitable for enhancing the professionalism of an average developer, in order to stop being difficult for him.
• I doubt that the one who reads this or my Twitter is the average developer and Paul Snively, you are far from the average, and do not even try!