The negative opinions were overblown. A lot of them were complaining that something that's impossible in other languages is hard or difficult to learn in Scala, or real but superficial problems. The language has plenty of warts and there are some bad libraries and tools out there, but all these things are superficial and transitory; the core is sound and I expect all successful future languages to have a very similar design.
To give an equally sincere response: dynamic languages are dead, and languages without higher-kinded types are dying - they're too useful to do without, and Scala shows they're practical. We're still discovering more things you can do with Scala.
I think the language we'll be using in ten or twenty years' time won't be Scala - or it will be a Scala that's changed unrecognizably from the Scala we know today. But I think that whatever language it is will have a strong type system with type inference and higher kinds and some kind of typeclass functionality and probably also traditional-OO subtyping (failing that at least Go-style delegation), will allow method calls without brackets and concise lambdas with something like "_", will have a culture of not using C libraries via FFI, and will be strictly evaluated. If you wrote a clean new version of Scala today there's a lot you'd leave out (you might end up with something that looked rather like Ceylon), but I think those things are here for good. Maybe it'll be Idris, maybe something else.
I agree completely. It might be interesting to spell out what that this core is: it is the successful marriage of ML-style functional languages with class-based OO.
The core idea of ML is this: strongly typed with parametric polymorphism and full sum and product types, type-inference, first-class functions, first-class state, (almost) first-class modules. Exceptions as first-class non-local control mechanism.
The key innovation Scala have over its predecessors Ocaml and F# which also attempted this merger is that Scala recovers ML-style functional programming as a special case of OO programming, while the predecessors when the other way, which didn't work so well.
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.
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.
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.
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".
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.
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.
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 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.
Maybe. Tooling is coming in leaps and bounds for dynamic languages. Codebases are also trending way down as companies move to "microservices". Both bode really well for dynamic languages.
I actually think the 10 year future is going to be dominated by languages where you don't need to think in terms of types at all but you get all the benefits behind the scenes.
> Tooling is coming in leaps and bounds for dynamic languages.
Yeah, but it tends to involve reimplementing a type system - if anything this is a sign of how mature and easy type systems have become. I think we may see languages with optional/best-effort typing for a while longer, but there will be no more pure dynamic languages; every new language will at the very least have a python3-style language-level standard for how to record type annotations so that tools that work with types can interoperate. And once you have that, it seems stupid not to have the language check at least the simple cases.
> Codebases are also trending way down as companies move to "microservices". Both bode really well for dynamic languages.
I think that's effect rather than cause. If you're writing a big system in (say) Ruby, microservices become the only way to achieve the required level of isolation.
> I actually think the 10 year future is going to be dominated by languages where you don't need to think in terms of types at all but you get all the benefits behind the scenes.
I thought that for a while, but types a really useful tool for thinking with. In Scala I could write Python-like code that wouldn't need any explicit types (they'd all be inferred), but instead I use types to help express the design.
I think the most cutting criticisms of Scala are the ones that pointed out your exact quote here: "If you wrote a clean new version today, there's a lot you'd leave out"
That said, the Scala community seems to be moving away from many of the dumber ideas (mostly along the lines of respecting readability over 'expressiveness').
> That said, the Scala community seems to be moving away from many of the dumber ideas (mostly along the lines of respecting readability over 'expressiveness').
I don't think it's even that. I mean the symbolic method names are an unfortunate piece of community history that can't die soon enough, but other than that a lot of warts are just failed experiments or things that we now have a better way of doing or even things where a compiler flag gets you the right behaviour but the default is the bad backward-compatible way of doing things - Scala grew organically to reach the point it's at now, and it shows.
If anything I think Typesafe/Lightbend listened to the critics too much and put too much effort into backward compatibility. The best thing for the language would be to remove a lot of old features, many of which are barely used in any case. On the plus side they've taken the positive step of modularizing the standard library and moving pieces out of the core.
The one negative that is 100% real, and is slowing language adoption, is the problems with its community. Everything else is pretty easy to fix IMO.
There are a variety of 'factions' in the Scala community, with very different agendas. They disagree about which parts of the language are useful, and which ones to outright cut out. Research language focus, vs practical use in the enterprise. From easy to learn to (here, to learn Scala, first learn category theory and Haskell). From wanting a large language with batteries included, to wanting a really tiny standard library. And many in those groups not only hate each other's guts, but will very happily claim that whatever other groups are doing is not worth using under any circumstances.
With a situation like that, it's very easy to find criticism about every single piece of the language, and every single company that has supported Scala in any way. Twitter Scala, Scalaz scala and Typesafe Scala are all different: I have never seen this level of division outside of the olden days of LISP. So of course everyone complains about it becoming too big: If you cut some features of the language, entire factions disappear. The complaints are purely political.
So it's very easy to get ideas of doom and gloom from Scala, when it's being used in production in a lot of places, to solve very real problems. Akka, Scalding, Kafka and Spark power a lot of things, but the infighting has to end, and that will take a lot of attitude changes everywhere.
I think this is even overblown. Verizon makes heavy use of Scalaz, but not all projects are done in 'scalaz' style. This works out OK. There isn't always time to onboard new folks to a fully functional style (which is the overall company culture/preference), 'typesafe scala' is certainly very pleasant to work with.
That's one of the strengths of the language. You can be productive from day one writing 'java++' style scala, and slowly move to the functional side at the speed and level of 'purity' you desire.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses."
-- Bjarne Stroustrup
I've seen many programming languages become popular (or fail to) over the years and this quote has always seemed to hold true.
With Scala there was the first wave of people working in it that claimed that it was a grand panacea for all the problems in software (as is always the case with new languages).
However, it wasn't until people started to really claim that the language was certainly doomed that it clearly was a success.
In general I have found that Stroustrups quote is, counter-intuitively, a good way to determine whether the next hot new language will really stick or not. Furthermore, I have to admit that even some of my favorite programming languages fail this test and honestly these languages are extremely unlikely to ever achieve mainstream success.
And if you really think about it, it's not so counter-intuitive. Programming languages don't show their real limitations until you are very deep in a large complicated project. The frustrations of the beginner are never the same as the frustrations of an expert and only an expert can really feel that a language is "doomed". This sense of "doom" is often just the realization of the once language X zealot who now sees that this new language is not a true panacea. But this moment of disillusionment is also the moment an idealized programming language has proven itself a practical one. The more people that feel this loss of faith in their favorite new language, the more people are building large, practical, real-world software projects with it.
If you look at stackoverflow surveys you'll notice that those using Scala are amongst the happiest users of any language and are very willing to continue using it. It's growing slowly but steadily and Spark is also driving adoption. With some exceptions most criticism seems to be coming from those who haven't had much exposure to scala and trot out the same tired old material time and again. Once you grok scala it makes more sense. It's a bit like complaining that Mandarin is hard to understand if you are English. It takes time to learn but it's worth it if you stick it out.
Nothing against Scala here at all. But I've heard that if you try to learn Mandarin as an adult westerner, you will never get to a point of conversational comfort in the language, let alone sound like you have native mastery of it: it's too complex and has tonality that westerners don't have anything to compare to. So this is a particularly poor choice of analogy if you're trying to make a case for Scala.
People say that about Mandarin, and really language learning as an adult in general, but the truth is most people don't put themselves in the situations to learn a foreign language nor do they exert the consistent effort required to acquire it.
The biggest problem with Mandarin is not the tones but the fact that you can't fall back on written language to help you out with anything at all. It's like learning two difficult languages at once. If you really want to learn it, though, it's entirely possible. All it requires is a human brain and consistent effort.
Actually, it's a good analogy because Mandarin's difficulty is also overblown. It's hard, yes, but I have no trouble being understood by the Chinese, and any Westerner living in China who makes the effort inevitably comes to that point as well.
Yes, scala is big and complex, but IMO, it remains by and large coherent. That might be the ultimate reason why scala developers from all kinds of different backgrounds didn't abandon it even after facing many of its shortcomings and bugs.
I think scala will remain a very favorable language for any team that needs all of the following three.
1, ability to do functional programming with a strong(ish) type system
2, ability to do actor based parallel/distributed programming
Can you specify what you mean by too big or too complex? As far as concurrency goes it simpler than Java. You have Futures and Akka, that's it.
You should read Java Concurrency in Practice, the entire book is explaining all the concurrency methods they have. And thats already a very good book (one of the top in my list). In Scala, I just need to read through a few pages of documentation and the rest is simply practice in mixing and matching patterns and a few configuration settings.
I use Scala frequently for internal microservices development. I also write a fair amount of Clojure. I believe that a lot of good and robust software is built in Scala, but that it suffers from a kind of complexity fetishization that offsets, for debugging purposes, a lot of the positive effects of robust typing. Compiler speed is also a problem for me personally.
Given my choice of options, I will choose to build new systems in almost any other JVM language, including stock Java 8. However, the language isn't going anywhere, and is worth learning. I find that feedback is fastest in Clojure. Your mileage, as always, may vary.
Clojure is growing steadily. It just doesn't have rocket ship growth. It is certainly mature enough to use in production systems and many companies do.
It has a few adoption issues though. The strong typing crowd don't like its dynamic typing, it's not a c-like language, and it doesn't have a large company backing it.
F# has the perception in the industry as a testing ground for good ideas for C# and a second class citizen.
Scala isn't “becoming” too big and too complex. It already is. But, if you dig deep enough into the implementation details, you will find that pretty much every production-ready language is too big and too complex.
I wonder if people are having the same experience I had when I first encountered Scala.
I was the newest dev on a team that had an existing code base that was built around Spray, Akka, and Slick. And they wrapped an Actor around Slick so it "fit better". I've written tons of asynchronous code (Java, C++, Linux, and Windows) so that wasn't what got me. It was just how the original devs spent so much time making everything was an actor. Even in areas that didn't need to be.
At that point having never seen Scala, I just attributed it to the language vs the use of libraries.
Having now spent time with just the language, I like it. Just my introduction was jarring because of all the "everything must be asynchronous" nature of the code base I "learned" on.
i've read a lot of negative opinions on scala, that it's becoming too big and too complex
and honestly, i was kinda sorta, waiting for it to fail or fall out of favor
this doesnt seem to be happening, on the contrary, scala seem to be getting more popular, compared to language which i favored (like clojure or f#)
are the negative opinions wrong, overblown, or is scala really heading for failure, what am i missing, what did i see wrong