Much of Scalas complexity comes from trying to encode ML features using subtyping and class-based OO. So I think the jury is still out on whether Scala represents a successful marriage. There are other ways to add first-class modules (objects) to ML, the most interesting is probably the new "1ML" paper. Personally I would rather have OOP encoded in a functional language and not the other way around. This would avoid many of Scala's warts such as a nominal core (e.g. Function1-22), methods not first-class, pattern matches that runtime cast etc.

Depends on the criteria of success. Maybe OO and typed FP can be merged successfully in more than one way.

I agree that that 1ML is interesting. Some of the warts come from JVM/Java compatibility. In what sense would you argue that OOP can be successfully encoded on top of a typed lambda-calculus? Finally, the relative simplicity of DOT [1] indicates that Scala's core is not that complicated.

[1] N. Amin et al., The Essence of Dependent Object Types. http://infoscience.epfl.ch/record/215280/files/paper.pdf

The criteria of success for me is simplicity and generality. The part of OOP I am interested in is first-class modules, being able to package up types and functions acting on those types into records. Dotty is not the core of the current version of Scala. It does look interesting, but personally I would prefer an approach that does not use subtyping. My point is only that Scala does not represent the last word in FP+OOP.

I didn't say Scala represents the last word, I said it's a "successful marriage" of "ML-style functional languages with class-based OO". I implicitly assumed that subtyping is part of of class-based OO.

I expect Scala to gravitate more towards DOT in the future, as early mistakes in Scala's design will be ironed out.

It might be interesting to see how the form of OOP that you are interested in can be expressed in DOT, for example by removing subtyping form D_{<:}. Have a go at it!

I didn't mean to imply you had said it was the last word. The form of OOP that I would be interested in would probably use row polymorphism instead of subtyping. It might indeed be possible to encode this in DOT.

I think understanding the expressivity of the DOT approach vis-a-vis the more conventional 1ML approach should be interesting.

1ML is based on F-omega, which has higher kinds but not dependent sums or products, while D_{<:} has path-dependent products but no apparent higher kinds, if I understand the paper correctly.

I think they model higher kinds as a special case of path-dependent types.

Record and row types are already under consideration for Dotty.

Interestingly though, Scala's model is basically Javascript, with a sound type system. As much as classes have been discredited as the fundamental structure of a system's architecture, they still prove their usefulness in Java and all the dynamic languages, and now a new crop of languages, like Swift, Rust, and Kotlin. So, I'd suggest that the Scala route may well be the path forward, especially post-DOT.

Huh? Scala has nothing remotely resembling Javascript's weird prototype thing.

True, there's nothing in Scala that's like the dynamic inheritance/delegation of JS. But I'd say that in practice, people use Javascript's prototype functionality to implement static class- or mixin-based OOP.

Well sure, but I'd say Scala's model is more similar to any of Java, Python, Ruby or C++ than it is to Javascript. So I don't see that it's a "Javascript model".

The "path forward" is purely a socioeconomic one and quite unrelated to any technical argument.

Not true. The rise of Scala itself is probably the clearest counterexample; there is no socioeconomic case for it, it's succeeded purely on its technical merits.

Quite a bit of Scala's design was influenced by the goal of Java/JVM compatibility. This was clearly a purely "socioeconomic" decision. Without this compromise, Scala would never have taken off.

I disagree. There are any number of failed JVM languages, and no non-JVM equivalent of Scala that I'm aware of. The biggest effect of the JVM on Scala was a "free" high-quality (and high-performance), multithreaded, garbage-collecting runtime (contrast with OCaml) which is an engineering-driven decision.

Scala's success has technical and socio-economical causes. Here are some more non-technical factors.

- The existence of a reasonably well-funded organisation (Typesafe/Lightbend) stewarding Scala was well-received.

- Typesafe/Lightbend's independence also helped, in the sense that I cannot see a Scala-like language succeeded if it had come from e.g. Oracle.

- Scala's open-sourcing of everything helped.

- The well-executed and well-timed Scala-MOOC also helped a great deal.

- Odersky's fame and track-record helped too.

None of those might have driven your Scala adoption (or mine), but they might have helped others to shift their dev towards Scala.

You realize that all of that (except the last point) happened after Scala got traction?

That depends on what you mean by tracking. Typesafe was founded in 2011. Scala really took off around 2013 in my entirely unscientific observation.

I think watching one of the many talks about this topics would answer your assumptions with facts.

The "new" 1ML paper is already old, and nothing ever happened. (Which is the core issue of ML: Cool papers, but nothing ever ships.)

What talks are you referring to? Can you tell me what I have written that you disagree with? The first 1ML paper was last year, that's not "old" relative to Scala, which first appeared in 2004.

For instance in http://www.infoq.com/presentations/data-types-issues at 26:26 the topic of mapping modular to functional vs. functional to modular is presented. It wasn't some arbitrary decision, but based on the lessons learned earlier.

Since then, DOT has been proven to be sound, dotc can bootstrap itself, and large subsets of "Scala 2" can already be compiled with dotc.

Dotc also sports a very interesting design with its mini-phases + phase-fusion approach, denotations, less desugaring, and a more immutable AST. The speed improvements have been very promising even though no performance tuning has happened so far.

TASTY is on track as a standard IR to express code as an entity that can be produced by different compilers and compiled to different targets like (JVM, JS, ...).

SBT recently gained a compiler interface to drive compilation with dotc, and dotc gained support for producing Scala.js IR.

What happened to 1ML since the paper was published?

He is comparing Scala to OCaml, whose module system dates back to 1995, not any current research. My point was that Scala is not the only way to do first-class modules. Subtyping is my biggest issue with Scala and he admits that (variance) is "hard to get your head around" in that talk. 1ML is a research project, which probably would get a lot more funding if it talked about "objects" and "classes".

It's not the only way to do first-class modules, it's just the only currently known way where both modular and functional sides are actually useful without introducing completely separate sub-languages.

Of course it's a lot harder than building one side and then claiming that the other side sucks because the whole paradigm sucks (but we still wanted some research grants (looking at you, OCaml)).

Scala's OO+FP approach allows me to appreciate both sides where they have their strengths. This is in contrast to languages like Haskell which can declare that FP is the best thing ever (because that's the only way to write programs in Haskell ("but, but, you can do these terrible contortions and write things that look like OOP in Haskell" – let's just skip that point, it doesn't add anything to the debate)).

   it's just the only currently known way where
   both modular and functional sides are actually 
   useful without introducing completely separate
   sub-languages.

This isn't true anymore and 1ML was my counterexample. I sympathise with your point that Scala is a working shipping product.

I prefer to try that myself before coming to such a conclusion. Where is the 1ML compiler? I only found some outdated proof-of-concept 45kB interpreter with version 0.1.

Regarding

   would get a lot more funding 

somebody once said that objects vs modules is like working class vs ruling class: objects do all the work, modules get all the credit.

In case people were wondering, the 1ML project can be found here: https://www.mpi-sws.org/~rossberg/1ml. The key idea here is that ML-style modules (which in the past were though to need a separate module language) can be coded up into System F-omega (the "workhorse of modern compilation").

I don't think any of the 3 main guys behind it (Russo, Dreyer, Rossberg) works on modules all that much right now. That may explain the relatively tardy speed of development.

I like the quote :)

I actually find non-fatal exceptions to be a poor fit in Scala - much better to have errors be values. I predict successors will not bother with exceptions at all. Even for Java interop, in a language with union types all you'd need is a special marker type Thrown(t: Throwable). I'm kind of surprised Ceylon didn't take this route.

Exceptions are probably the least canonical part of (the sequential part of) the ML-Scala continuum. Maybe it will fall by the wayside. With HKTs monadic error handling becomes relatively painless. I have no strong opinion on this matter.

I think sequential programming won't be the deciding factor. Error handling becomes more difficult when concurrency is involved. It's unclear whether the monadic approach scales to concurrency. The Erlang experience seems to suggest that more complicated approaches might be appropriate.