Seems like an awful lot of rules to hold in one's head. Scala just looks like a giant tumor of complexity to me.
There's a difference between true complexity (i.e. complecting or that lead to accidental bugs) and things just being unfamiliar. I try to stay away from the former, while not shying away from the later - since I've picked up Scala about 3 years ago, my knowledge expanded with a lot of useful abstractions that help me do my job better, abstractions that weren't natural or popular or properly implemented in the other languages I worked with. This isn't to say that Scala doesn't have true complexity in it, but then again, what language doesn't?
b) The compiler internals are reportedly a mess[2]--likely due at least in part to the extreme number of different syntax variants.
c) I find rule 4.1 in OP interesting ("SHOULD avoid concurrency like the plague it is"). According to Odersky's Coursera course[3], one of the main advantages of functional programming as enabled by Scala is easy, safer concurrency (reduced/absent mutable shared state). Yet here we see a presumably seasoned Scala veteran basically saying that this is a failure and we should avoid concurrency whenever possible because it results in too many bugs.
1. http://www.infoworld.com/article/2609013/java/scala-founder-...
a) There is a lot of work going on at the foundations of the language – most of the stuff is unlikely to be felt by users.
b) Compilers are hard, there is very likely no "nice" compiler out there (except for toy languages). This has almost nothing to do with syntax variants. Nevertheless, there are multiple groups which are working on improving the codebase.
c) Concurrency is hard to get right, especially "traditional" approaches like synchronizing, locks, etc. If it's not necessary, don't use it. Otherwise use the right abstractions for your problem, as mentioned in the next paragraphs.
i.e.
> 2.1. MUST NOT use "return"
> 1.1. SHOULD enforce a reasonable line length
> 1.5. Names MUST be meaningful
*(x, xs, xss, ns, are meaningful names by the way)*
> 3.3. SHOULD NOT apply optimizations without profilingFor example, if you write Java, most (or similar, or even more complex) rules apply.
In any case, I chose Java as an example because (sadly) it's what I'm forced to use in my day job, with some Scala side-projects (thankfully!). But I didn't mean to single Java out: a lot of the advice applies in general to software design, regardless of language. You know, "choose the right abstraction", "beware concurrency", "name things wisely", etc.
Scala can be complex (on paper), but in practice it doesn't have to be.