Should also understand the backstory to this email.
Keep in mind that he’s talking about a significantly older version of Scala. That email is from more than five years ago. Some of the problems still exist but others have improved a lot.
well don’t keep it a secret, man. Which have improved a lot? What subset is safe to use, and what is deprecated?
We use scala in production. This email resonated with me. Not sure which problems improved a lot. Thing killing me now is our 40k scala project takes 15 minutes to compile.
Wrt “our new engineers don’t understand Scala”, that’s definitely an educational problem. I’ve barely used Scala except to write “hello world”, but I can recognize most of the “weird” concepts he mentions from their name. They are fairly common concepts in strongly typed and/or functional languages.
I think this is a symptom of the fact that 90% of undergrads can get away with using nothing but C++/Java and maybe a little Python for their entire educational career. They have little exposure to modern foundational improvements in the fundamentals of our craft.
It’s also a symptom of companies not caring about mentoring or training.
If you choose a less popular language/paradigm and open up hiring to people who do not know that language already, you should at least give them a week or two (with some easy bug fixes) to learn or have someone mentor them.
Colleges aren’t going to change from Java/C/C++ any time soon, sadly.
Scala goes beyond that.
In isolation each trait/interface is understandable. But you have many objects that implement (no joke) 20-30 interconnected traits.
The common “silly” example is the signature for map. Being able to map arrays to bit fields directly was so important that there’s now this complicated remapping mechanism, to let people write a map that takes an array but gives out a different kind of structure.
The language itself, with optional parens, implicits, custom infix operators, means that it’s increasingly difficult to say what a fragment of code does without knowing the context
What’s the map signature you’re referring to? I tried to find it and only found the straightforward map[B](f: (A) ⇒ B): Seq[B] from http://www.scala-lang.org/api/2.12.1/scala/collection/AbstractSeq.html
map[B](f: (A) ⇒ B): Seq[B]
If you click on the member in the document, there’s a “show full signature” option which shows what’s actually in the source code:
map[B, That](f: (A) ⇒ B)(implicit bf: CanBuildFrom[Seq[A], B, That]): That
You can build implicits to have mapping also build up some interesting structures.
For example, you have a CanBuildFrom implicit you can make (given an ordering) for SortedSet:
canBuildFrom[A](implicit ord: Ordering[A]): CanBuildFrom[Coll, A, SortedSet[A]]
So if you have a container, and a map to Ints you can get a SortedSet result directly.
let result: SortedSet[Int] = container.map(_.someNumber)
(the container could be an array, some tree with a map implementation, anything really).
Of course, in simpler languages, map usually just generates the same container type through its map
Sad that today I feel the STL is state of the art. Scala doesn’t compete here, I just don’t think the algorithm are there. Generic programming is still C++’s killer feature IMO and only languages like D and Rust seem compete.
I haven’t used Java or a language running on a JVM in years. I’ve read bits and pieces about Scala and other languages targeting the JVM, though, and I suppose I have one major reservation (which may be unfounded):
Scala’s view of the world seems to be very different from the classic Java model. How well does it integrate into the broader Java ecosystem? Can I just use an arbitrary Java class (e.g. String or Window or whatever) without having to deal with some sort of functional-OOP impedance mismatch? If every time I use a class I have to think whether its “functionally safe”, programming becomes a lot less fun.
Is that a real problem, or is it just my lack of knowledge?
Java to Scala interop is dead easy. There are some rough edges, e.g., when using Java collections, you need to import some implicits from the Scala standard library to get things like myHashMap += "foo" -> 1 working. It’s the other way around that’s difficult.
myHashMap += "foo" -> 1
Some of these complaints are very valid; while I want to love Scala as a language, some of the performance penalties you get are not worth it over trying to use a functional-style library in pure java, c.f. javaslang. Java 8 interfaces are to my understanding almost identical to traits, and the only thing really missing from Java is type inference (though there is a JEP for this at the local variable level).
In 2010 I chose Scala for a low-latency web service, and quickly became quite worried with the Scala collections library vs Java’s until package. The API was impressive, but definitely complex, and at the end of the day I started to doubt the performance that was claimed (despite the Great Computer Language Shootout benchmarks). I didn’t use scala after that, but the takeaway is that the niceties of a rich collections API are only worth it with zero-cost abstractions.
What’s wrong with the coding of that file?
It seems to be a UTF-8 encoded file, but it’s being served to browsers without any character encoding information by Cloudfront; as a result (some) browsers are assuming non UTF-8 encodings (according to Page Info, my Firefox claims it’s assuming windows-1252). The regular HTML pages on the site work fine because the HTML itself can and does declare a character encoding (in the <head>), even though the HTTP headers (still) have no encoding information. In short: sadly, business as usual in the wonderful world of web character encodings, where old assumptions and defaults get to live forever.
(I don’t know if Cloudfront supports sending character encoding information in the HTTP headers at all, but if it does, it hasn’t been configured here.)