Why we love Scala at Coursera

I worked deeply with both static and dynamic languages as well. I do feel that it's easier to refactor in scala than ruby, especially in large projects.

In ruby, you have to have close to 100% test coverage because if you don't you can't have any confidence when you refactor. For example, in ruby project, even a simple delegation call needs to be tested, otherwise you may break it without knowing it when you rename the method delegated to.

You don't need to write such test in a Scala project because there is no business logic in a simple delegation and the compiler will check the rename for you, actually the IDE will do the rename refactor perfectly for you.

In general, some of the unit tests devs wrote in Ruby projects are not to test against business logic but to test type matching. For type related refactoring, they actually have to refactor both the code and unit tests. The dilemma here is that if you are changing your unit tests, how confident you are that they are still covering your refactor?

Look at it the other way. In fact, you can do a blind test. Try writing in a strongly, (well[0]) statically-typed language for a while, and count the number of times your code fails to compile due to a type error.

Each of those would likely have been a runtime error in a language like Python.

Just earlier today, I had to write a short Python script (I normally write Go), and I was bitten by this. I'm used to the compiler telling me up-front when I try to concatenate a string and an integer, or when I misspell a variable name.

Yes, there are other ways around this (and proofreading your code before you write it is a good practice, in addition to tests). But static typing can make development much faster[1].

Even if you claim that you would have caught all of those bugs in unit/integration/system tests (which I simply don't believe - no real-world project has test coverage that's that good), it's much better to catch bugs at compile-time, because (unless you're writing C++) your tests take much longer to run than your code does to compile.

[0] I qualify this to rule out C, which has weak typing as well as memory management issues to complicate things, and Java, which just has a terrible type system period.

[1] In some sense this is all a moot point, because any difference in development speed and/or code correctness between statically-typed and dynamically-typed languages is dwarfed by one's familiarity with the languages in question. The only real way to test this directly would be to use a statically-typed language that allows disabling of all compile-time type checks as a compiler flag or pragma, but few languages do this in a way that'd be straightforward to do a meaningful blind test.

Good to see some love for Scala after all the recent rants. Unfortunately, I think it's going to be short lived. Most shops where Scala would be an option will soon have a production release of JDK8 available to them, at which point Scala's tradeoffs really only become acceptable to those who already have significant investment in the language or who think category theory is a reasonable companion to an industrial language.

Well, so what? Simon Marlow, Haskell's lead compiler developer in recent years, quit, leaving arguably a much larger gap than @paulp leaving Tyepsafe since SPJ is wrapped up in leading some English education initiative.

Anyway, shit happens, gaps are filled. Languages, once established, are larger than any one developer, no matter how brilliant the individual may be.

It's worth noting that @paulp is as active as ever in Scala, working on his new collections library and contributing to Scala now from the outside -- he may have left Typesafe but has not in anyway left Scala. As he says, he has a "sickness" for language perfection, and fortunately for we Scala users, Scala is the target of his illness ;-)