10 Things I Hate About Scala

  • View

  • Download

Embed Size (px)


I love Scala, I really do. I find Scala both more productive and more fun then any of the many languages I have worked with before. There are many reasons to use to Scala; however, I will not be talking about them. Instead, in this talk I will cover some of the things I find annoying or disappointing in Scala. For each I will explain the issue, why it is so, whether or not it is likely to ever change, and what, if anything, we can do about it in the mean time. The issues covered will include: Limitations on type inference Type Erasure Binary incompatibility Limitations on overloading Standard library quality And more The lecture is geared towards those who have written between 10 and 10 millions lines of Scala code.

Text of 10 Things I Hate About Scala

  • 1. 10 Things I Hate About Scala

2. About MeMeir MaorChief Architect @ SparkBeyondAt SparkBeyond we leverage the collectivehuman knowledge to solve the world's toughestproblems 3. 1. Type Inference LimitationsPop Quiz: What does the following expressionreturn?List("foo").toSet.head.headscala> List("foo").toSet.head.head:8: error: value head is not a member of type parameter BList("foo").toSet.head.head^ 4. Why?def toSet[B >: A]: immutable.Set[B] =to[immutable.Set].asInstanceOf[immutable.Set[B]]The required type should affect type inference:val a: Set[Any] = List("foo").toSetBut not break Set Invariance:val aSet: Set[String] = Set("foo")val b: Set[Any] = aSetAs we want to use [A] in both variant and co-variant positions:val s=Set("foo")List("foo","bar").filter(s) 5. Type Inference Cont.Make up test:math.sqrt(Some(1).getOrElse(1)):8: error: type mismatch;found : AnyValrequired: Doublemath.sqrt(Some(1).getOrElse(1))^ 6. WorkaroundsUse to[Set] instead of toSet:List("foo").to[Set].head.headExplicitly state type parameter [Int]:math.sqrt(Some(1).getOrElse[Int](1))Assign a variable to force a concrete type sooner. 7. Fixing the root causeRequires adding Back-tracking after failure(less efficient)Not planned for upcoming release 8. 2. Type ErasureList(foo) match {case x: List[Int] => 1case x: List[_] => 2} 9. Structural Type Erasureval z: Any = "foo"z match {case x: { def noSuchMethod() : Int } => "???"case _ => "OK"} 10. Type Erasure WhyOdersky did it. (in Java)Prevents generation of extra classes andoverhead.Refied Types (like reflection) enable breakingtype safety 11. Type Erasure - Workaroundsdef foo[T](a: T)(implicit ev: TypeTag[T]) = {ev.tpe vcase None => val d = op; this(key) = d; d} 21. override def add(elem: Int): Boolean = {require(elem >= 0)if (contains(elem)) falseelse {val idx = elem >> LogWLupdateWord(idx, word(idx) | (1L 1 === 1res0: Boolean = truescala> 1 === "foo":14: error: could not find implicit value for parameter F0:scalaz.Equal[Object]1 === "foo"^ 30. 8. Explicit method return typesThere are (too) many cases you must define an explicitmethod return type: Explicitly call return in a method (even at the end) Recursive methods A method is overloaded and one of the methods callsanother. The calling method needs a return typeannotation. The inferred return type would be more general thanyou intended, e.g. Any 31. WhySome cases are difficult to inferNeed simple rules for requiring explicit typesSimple rules are overly broad 32. 9. Compile time Scala compilation lines/sec is~10X slower than Java More functionality per line can shrink thedifference to 3X-5X range (benchmarks vary wildly) 33. Solution / Mitigations: SBT - for incremental compile (new flag) Supply explicit return types An area of continuous improvement in Scala 34. 10. REPL Is Differentval a = (1, 2)println(a.getClass)println(a.getClass.getSuperclass)Compiling and running normally:class scala.Tuple2$mcII$sp Specializationclass scala.Tuple2From Repl:a: (Int, Int) = (1,2)class scala.Tuple2class java.lang.Object 35. Final ThoughtsScala is definitely production gradeHappily been using in production for 3 yearsUndergoing constant improvementYou can take an active part in improving Scala 36. Thank YouJoin Us