In a production system, Scala is quite frustrating to work with because of the frequent backwards compatibility breaks, and the slow-motion build times. Not to mention the new stuff which almost but not quite duplicates the built-in Java stuff, etc. etc. It would be better just to have a better Java, not a hack on top.
Using Scala on Android requires a bit more tinkering with ProGuard than Kotlin does, and it isn't a focus of the Scala designers.
Also with Scala 2.12 going Java 8, one will be stuck with 2.11 for Android.
According to Jake Warton, they only cherry picked some parts of OpenJDK 7.
From the commits they also don't appear to ever fully support Java 8, only lambdas.
Also the way they are cherry picking features from OpenJDK 7 and some kind of lambda support.
For me, Android Java has become similar to Symbian C++ in terms of dev experience and language fork.
This is true of any language so it doesn't mean much.
Still, we went through the same thing with C++ 20 years ago. Google even used to have (still does?) a style guide saying which features to use and which ones not to use.
Instead of having to use a guide that tells me which features of a language are dangerous, I prefer a language that doesn't require such a guide in the first place.
I don't think there are any dangerous things you can do in Scala that you can't do in Kotlin. Only safe alternatives that exist in Scala but not in Kotlin.
Which is a good example on how not to write modern C++, given the things they don't allow to use and not loved that much in the C++ community.
It's an incremental improvement over Java and it fixes exactly all the complaints I have over Java and nothing more.
Also, its IDE support is just as good as Java.
But the language is not even out officially, let's see in five years how it fares. Right now, it's just a breath of fresh air over Java.
We're working on gigantic production systems currently and with good modularization compile times are not a problem for us.
It is all about Java, Scala and Clojure.
I don't think one can make any pronouncement about Kotlin's success or failures for several years.
This will of course improve for Kotlin, specially if they get some Google blessing.
EDIT: Also forgot to mention that on Swift's case, it is a first class language being pushed by the platform's owner, not a 2nd class language without any kind of consideration from the platform SDK.
And the fact that 1.0 RC was just released this month might tell you other reasons why. How many Scala jobs did you see advertised when 1.0 was released in 2004?
You can't see a future for a language that offers far more succinct code than Java, but maintains the ease of Java?
`List<Int> myNewList = myList.stream().map(i -> i +5).collect(Collectors.toList());`
In Kotlin:
`val myNewList = myList.map(it+5)`
Can you see how that can be clearer and simpler to read? Technically it is doing the same thing, but it is much simpler to reason with. On top of that, you've got improved null safety, monkey patching and type inference.
That comparison looks misleading - the .stream() and .collect() are conversions, not necessary on every call by any means.
Kotlin's approach to null safety is ad-hoc and integrated into the language in a way that makes it hard to abstract over. I think it will lead to inconsistent code as the JVM ecosystem moves on to make more use of Option-like alternatives.
Monkey patching is pure evil in any large codebase.
I think Java will likely add more and more type inference in future releases.
Don't get me wrong, syntax and sugar are important. But a language that only offers those is probably not worth the overhead, and such things are relatively easy for the "parent" language to adopt.
Besides, it's not any more magical than "_" (which has, what... eleven different meanings? [1]) and it's super convenient. Still, don't like it? Just explicitly name your closure parameter. But you'll be surprised how you will quickly stop doing that for trivial closure uses because finding names is such a pain.
You're right that Java 8 has been closing the gap, though, but note that Java 9 doesn't have any new language features that will close that gap further.
FWIW I avoid "this" as much as possible. I prefer a named self, which Scala has a nice concise syntax for.
> Besides, it's not any more magical than "_"
Like I said, "_" looks like syntax. "it" looks like an ordinary value.
> which has, what... eleven different meanings? [1]
Sort of, but it's always obvious from context. I have literally never been confused by an occurrence of "_" in 3+ years of full-time Scala programming.
You're assuming here that a lot of people have used Groovy. People generally don't even use "it" in Gradle, the most common access people have to Groovy.
You call it hype, I call it enthusiasm.
But regardless of the names we use , what I find very interesting is that Kotlin is generating such positive feelings even though it's not even 1.0. I haven't seen this happen for languages in a while (probably "ever"). What's also striking is that most of what I read about Kotlin is positive, and again, languages hardly ever generate positive feelings so widely across the board.
The positive feelings ring very false to me. Kotlin has announced a lot of features long before they were delivered, and taken a lot longer to deliver a working language than they originally claimed. It's the old "two types of languages" - most languages sound good when you talk about their features, it's only when you actually use them that the negatives become apparent.
I don't know anyone who's actually used both Kotlin and Ceylon and prefers Kotlin, and Ceylon is actually more mature (1.2 released recently, IIRC). But since King only advertises features that are actually implemented and release dates he can actually make, there's a lot more hype for Kotlin.
The bottom line is that if you like Scala, you are probably not going to like Kotlin and that's perfectly fine. Kotlin is for everyone else and it seems to be pretty successful with that audience so far.
You have to put Java in its historical context to understand how it came to be. It was a mid 1990s over-reaction against the super-complicated, super-fragile software that people were churning out with C++. It was designed as a kind of babytalk that would avoid the complexity of speaking C++. Of course we all know it was an over-reaction, leaving behind perfectly reasonable ideas like multiple return values, lambdas, and unsigned numbers in a kind of French Revolution against C++ silliness.
Scala is also an over-reaction in the other direction. It's like a cross between Perl and one of the more pragmatic ML dialects. It's easy to churn out a lot of Scala code, but hard to read someone else's or debug a Scala program. (Case in point: seeing <anonymous> for every stack frame in backtaces.) Eventually we will want to meet in the middle somewhere with regard to complexity, and Java is best positioned to do that.
It's not about will Java adopt more Scala features, it is about how will it look when it is all glued together. I think for Java it can only go for worse, since language is massive as it is right now. Adding more would only bring more confusion for the table. Also good question is how will it work with other components of same language. I am not programming in Scala, I mostly read about it and read it. Still on faculty, but few older friends of mine, who have finished faculty 3 years ago and started to work at local startup/small company all worked in Scala and they are amazed how good everything goes for the company and that couldn't but notice that "Developer Happiness" factor being pretty high. So all those things considered tells you something...
> It's easy to churn out a lot of Scala code, but hard to read someone else's or debug a Scala program
I see this argument a lot in Internet forum discussions, but I've never met anyone who actually had problem reading production level Scala code more than problem reading Java code. Sure, people love to bring on Scalaz and other extreme type-level coded Haskell-like libraries where things can get hairy, because they're solving a complex problem. These people fail to show Java-equivalent of such complex Scala code, so a conclusion that Scala was complex is invalid.
However, when comparing things solving similar problems for which we have a Java project and a corresponding similar Scala project, let's say Apache Spark and Apache Hadoop, Spark's code wins in readability hands down.
It's actually a breath of fresh air to work on scala production systems. We don't use a mono repo and compile times are negligible. We are also one of the largest scala shops in the country and despite the various styles used in different projects, it's all been very maintainable and easy to read.
My main complaint is tooling and the fact that you do need good training to onboard the folks who don't have scala experience.
I can see where you're coming from, however I noticed that people experienced in Java and some other different programming language, like Python, Ruby or C++, don't need much baby-sitting to learn Scala. I've been showing some of my Scala code to other peers who don't do Scala daily for review and I never heard a complaint "I can't understand what this code is doing". More often I hear it feels quite Pythonic, only with braces and type annotations...
Look at how Java8 implements lambdas via a Single Abstract Method (SAM) - it's syntactic sugar. Or look at the streams api and collections library - Java8 IS the hack on top of Java. Scala is built from the ground up to be a better language.
Java8 is not at all comparable with Scala. There is a giant gap in the quality of the core libraries and the quality of the language and implementations of functional features. Part of the problem is the history of the language. Bless java for the jvm but saying that scala is extrenous and that java should be improved to have those features ignores the evidence that it can't be done well ontop of what is already there.
First of all, the way lambdas are implemented at the JVM level was a big improvement on what others were doing. And Scala is actually moving in that direction, if I'm not mistaken.
And regarding streams, I prefer one clean interface to having all the collection interfaces polluted with 1000 methods. Not to mention that in scala you have those traps, like when you are applying a map over a set and you end up with less elements than expected.
I think you're the only one that prefers not having FunctionN interfaces. I remember someone releasing a library of all the separate cases in Java pretty soon after the functionality came out.
Optimizing lambdas with a JVM opcode is cool. Delaying implementing them until you can add an opcode for it is not cool. I feel like Java should have been able to implement them like Scala did, and add the optimization later if necessary.
> And regarding streams, I prefer one clean interface to having all the collection interfaces polluted with 1000 methods.
Agreed for methods that are "secondary", but I think many of those methods are fundamental to being a collection. It's very weird to me if I have to change my List into something else to do a basic list operation on it. And even for secondary operations I think a typeclass is a much more elegant way of separating those operations than having to wrap and unwrap.
> Not to mention that in scala you have those traps, like when you are applying a map over a set and you end up with less elements than expected.
Any polymorphic method will behave differently on different types - that's the whole point of polymorphism. I'd agree that map is a bad name for something with the semantics of the Scala method. Unfortunately at this point that's not realistically something we can change.
I think the best Java can hope for is "syntax as good as C#". I highly doubt Java will ever go for, say, pattern matching. Unfortunately, after the big efforts in Java 8, I don't see anything syntax-related planned for Java 9, so I guess Java developers are still in for a decade or two of autogenerated garbage.
Just module declarations.
Many of the cool stuffs seem to be planned for Java 10. :\
There is also stuff that probably can't be taken out from Java without major backwards compatibility issues. E.g. Scala has no distinction for primitive/box types, which makes it much simpler and more elegant for basic imperative/OOP programming than Java.
As for frustration working with Scala - I didn't notice, despite working on a few projects for a few years now. I've known only one programmer in my whole career who complained about introducing Scala into one project because "Scala was too complex" and guess what... he was one of the poorest Java programmers on that team at that time. Java did not save him either. Reading his Java code was probably much more frustrating than waiting 5 minutes for a full Scala build would be. Poor programmers do exist and you should not blame the tool just because someone can't properly learn how to operate it.
TBH, if you're using Scala as a slightly better Java/C#, then you're probably going to get a lot of mileage out of it. As someone who really would prefer Haskell, the problem I find is that Scala has all these tantalizing features that you really want to use but which turn out to be broken in subtle ways. Anyone who's used scalaz will know what I mean.
The absurdity of "for { ... } yield" notation is one of the first things that springs to mind. (Given that "return" is NOT special or magical in any way in a Monad and can, in fact, meaningfully be repeated in the same function.).
The other major thing is that you can arbitrarily (and subtly!) do side effects while in "monadic" notation. That nullifies most of the advantages of having a do/for-yield notation in the first place.
There's also the stack overflow issues that are rampant if you actually try to use monads seriously in Scala, etc. etc. (This boils down to the JVM not having tail-call elimination.)
Scala is basically a cocktease when it comes to FP features. It promises loads, but doesn't really deliver. These days, I'd actually probably prefer C#/Kotlin/Ceylon over Scala[1] because at least they don't lead you astray in this way. (Obviously, I'd prefer to rewrite everything in Haskell, but we have an actual existing/working system written in Scala to support, so...)
TL;DR: These days we're using Scala as a "better Java" and if that's what you want, then you probably won't be disappointed. If you're looking for FP-as-it-should-be then you will be disappointed.
[1] Assuming we're only talking about language, not the wider ecosystem.
Anyway, Scala is probably one of very few languages that combines OOP and FP and at the same time has type system sophisticated enough that it can express directly or indirectly the stuff that Haskell can - maybe more verbose and there are some rough edges like you say, but hello, here is the news: Scala is not Haskell and it had to pay some price for other useful stuff that Haskell doesn't offer.
Also, Scala creators are generally aware of some shortcomings of the current Scala type system and are working hard on improving and simplifying things (DOT calculus). So if you know how to make effects or for yield notation better and fix these subtle problems - I think the community would appreciate your help.
Yes, but my point is that Scala's unholy combination of OOP/FP has been marketed as some sort of panacea... which it definitely isn't. I think, it's actually worse in both aspects: Erlang (modulo static type checking) beats it in the OOP realm, and Haskell (and Idris, etc.) beat it in the functional.
Try to use scalaz for anything serious, and I think you'll find out what I mean. Don't get me wrong, scalaz (and shapeles, etc.) are marvels of engineering, but they aren't sufficient in practice. Nor are they for any reasonable definition of the term 'usable'. Haskell/GHC is -- and in fact it's simple and easy.
Btw, now we can also enjoy 'cats'! Let's retread the whole "mtl" and "transformers" disaster once again in Scala! Fun! (I was around for the Haskell mtl/transformers/fundeps thing and... it didn't work. Monad &c. need to be part of standard library. For sanity.)
I just think programming languages is a realm where compromise doesn't work. Maybe I'm wrong, but...
> Anyway, Scala is probably one of very few languages that combines OOP and FP
Firstly, "Combine A+B does not necessarily improve anything"[1], but...
Secondly, see, this is the problem... having a few things signify "this cannot be mutated" does not an FP language make. It's far more complicated than that -- it's about culture. The Scheme authors recognized this and named anything that was "dangerous" (side-effecting) with a bang at the end so that it would be offsensive and stand out to any code reviewer. This is what FP is all about... not just paying lip service (which I think Scala is doing currently) to immutability.
EDIT: Look, I realize that I'm being an asshole with the beneift of hindsight, but still... I'm talking about what we should aspire to. Not just accept.
[1] I think the supreme example of this is in the O'Caml object system. It's basically better than any single-dispatch system out there, but nobody[2] actually _uses_ it. Why? Because it's just simpler to do in function style.
[2] Yeah, yeah, qualifiers, formal studies, etc.
Eg doSomething is pure and doSomething() has an effect. It's shades of grey. Scala ultimately may not be Haskell, but it's useful and a much better alternative to using Java. To lean on the JVM and be able to sell Scala is better than using Java just because it's what's already there. To transition away from java toward something better is a win. It's definitely a win. I'd love to work on haskell or introduce haskell in places that i work but no way in hell would I ever succeed. Only at a startup with the smartest of smart people. You can take interested ruby developers and chop them into decent scala devs and that's good for the pitch. How the hell do you take a team of mediocre devs and get them to write your next production system in haskell?
Nono. The point is that they should be codified and forbidden in places they shouldn't be used. I cannot describe how much this matters to anyone who hasn't "absorbed" the Haskell mindset. (That's not your fault, it's mine. "More research/explanation needed" on my part.)
> ... and a much better alternative to using Java.
Yes, but it only if you use it as a "better Java". It fails _hugely_ if you try to do anything "advanced"... as in actual FP like lenses and things.
> I'd love to work on haskell or introduce haskell in places that i work but no way in hell would I ever succeed.
This is also a cultural problem. Migrate towards microservices and... there you go! Nobody actually cares what it's implemented in. (I think this is a somewhat sneaky/underhanded way to introduce it, but it... works.)
EDIT: If you want to see first-hand what I'm talking about try "monocle" or "shapeless", which -- while both being fantastically named and engineered -- fail on actual usage.
Side effects in Scala are a little less obvious than unsafePerformIO calls, but not by much. One little unmanaged println isn't going to destroy the universe. The fact that Haskell will invisibly transform your code into lazy thunks, radically altering its performance characteristics, causes a lot more trouble IME.
Stack overflow problems are real, but you can get a lot of value out of the monad functionality without hitting them, particularly these days with a lot of effects being implemented as Free monad + interpreter. I wonder if Scala.js avoids the issue?
I'd probably switch to Ceylon or Idris if either had the ecosystem to match Scala. But for the time being they don't.
> for/yield is fine. Haskell people love to get excited about the one extra flatten but it's really not a big deal.
No, it's a big deal. It pollutes everything you do in "do" / "for/yield" notation.
Part of why do notation in Haskell is so amazingly beatiful and concise is that it doesn't force this absurd amount of pointless boilerplate on you.
(We can agree that they're technically equivalent, but SYNTAX FUCKING MATTERS, YO)
My thinking here is that Martin Odersky actually understood what was going on at a technical level, but didn't appreciate what was going on at the cognitive level of the programmer... and so just implemented the mechanism.
If you compound this with the semi-recent "cats"/"scalaz" schism over Monad and Functor, thus making us reexperience the monads-tf/monads-fd schism in Haskell-land... making me think that the supremely clever people behind these projects (no sarcasm!) never experienced the pain that comes from split ecosystems. Because if they had, they wouldn't have started "cats" without getting concensus first. My point is that you cannot meaningfully talk about Monad/Functor without that type definition being a core part of the language -- which it isn't in Scala.
Listen, I appreciate that they have a more difficult problem in some sense, because they've accepted subtyping as an actual thing that's useful. But that's their problem. Subtyping generally isn't very useful[1] and they're driven by OOP ideology... which is fine per se, but don't complain when it doesn't work out -- when the problems of subtyping are well-known and have been for the last 20-30 years.
[1] Use lenses and contra-/covariant functors instead when you actually need it.
> One little unmanaged println isn't going to destroy the universe. The fact that Haskell will invisibly transform your code into lazy thunks, radically altering its performance characteristics, causes a lot more trouble IME.
Yes, it will. Because it isn't just a little "println" here and there (in practice). The deal here is: I can mechanically scan all the code for unsafePerformIO and unsafeInterleaveIO, etc. I cannot scan Scala code mechanically for unsafe things because the possibilities are almost literally infinte. It's about "permit evil selectively" vs. "forbid evil when you see it". The latter doesn't work.
making me think that the supremely clever people behind
these projects (no sarcasm!) never experienced the pain
that comes from split ecosystems. Because if they had,
they wouldn't have started "cats" without getting
concensus first.
It was created because it was impossible to work with these terrible, obnoxious (ex-)Haskell people anymore.
The main change from scalaz to cats is not the code, but the community: Friendly people behaving like adults who don't act gravely offended when people discuss potential approaches which don't look like 100% what Haskell came up with.
I think scalaz will fall out of use mid-term, because everyone is sick of their shit behavior.
You're complaining about "inclusiveness" and you say "terrible people" in the same breath. No. Fuck you, and fuck off.
Where?
> No. Fuck you, and fuck off.
That's exactly the kind of immature behavior which is not welcome in the community. Please stay in the Haskell land.
Consensus as in: Get the approval of the community or at least lobby for the inclusion of Monad/Functor/etc. in the Scala standard library. My point was that the inclusion in the standard library is key to making Monad/Functor/etc. work. If you don't have that then you end up with the sad sad situation of monad-tf/monad-fd except this time it's not Transformers[1], but the fundamental Monad/Functor/etc.
As for the rest of your comment: ... WHAT?
[1] Which, to be fair, were fairly controversial at the time.
... and this gets exponentially worse if you depend on a lot of scala libraries. That's one reason that I absolutely abhor depending on anything Scala in my own Scala projects. Now, I'm not fanatical about it, but if there's an equivalent Java library with a reasonable interface then I'll definitely prefer that.
I can understand that maintaining binary compatibility is incredibly difficult for the Scala devs, but they really should have provided an easier way to just BUILD YOUR DEPENDENCIES FROM SOURCE[1] if it cannot find suitably binary-compatible dependencies. This would also ease the adoption of scala.js with its own forks/ecosystem for e.g. scalaz hugely. In practice everything I'm depending on is going to be open source and could just be fetched + built on demand rather than me having to wait for upstream to build + publish a new version. Usually people are considerate enough to not break source-compatibility willy-nilly, but predicting what will break binary compatibility is Dark Magick... which means that few people actually do that in practice.
[1] This is one of the very few things the Haskell/Cabal ecosystem got right from the start. It allows the compiler to evolve incredibly fast by just outright ignoring binary compatibility.
Given that many dependencies are Java and there's no agreement on build tooling, it'd be hard to build all dependencies from source (I actually had a client look seriously into doing this). I mean given a maven project, the pom is included in the release and contains all the information (e.g. SCM tag) necessary to rebuild it. But not everyone's using maven.
Certainly, but that's not what I was talking about is it?
My point was that there isn't a culture (in the JVM world) of just publishing the source. If there was there would be no problems other than source-incompatibility. The culture in Haskell-land is that either a) you publish the sources or b) you deal with whatever pain may come your way.
Mostly, people have followed approach a) when it comes to things like "parse JSON fast/reliably" (aeson), but b) when it comes to "oh, this is our trading platform/strategy". Which is fine... but the ecosystem usually benefits from the a) side of things.
(Shout out to Bryan o'Sullivan.)
Java doesn't have case classes, pattern matches, covariance, or higher-kinded types. Its optional type is seriously flawed in a way that will make migration harder (it can't contain null), and the library ecosystem hasn't yet moved away from using nulls, and while its lambdas are better than before they don't hold a candle to Scala's _ style for conciseness.
Maybe Java will adopt these things in say 5 years - but why would you want to wait 5 years for them? (And conversely: you like the Java 8 features? If you were using Scala you could've had them 5 years earlier).
> In a production system, Scala is quite frustrating to work with because of the frequent backwards compatibility breaks
The backward compatibility breaks aren't very frequent now - that's a lot of what this roadmap is about.
> and the slow-motion build times.
Building can be slow - but only to the extent that you're actually using the fancy features. If you write java-like code (e.g. explicit types on everything) you get java-like build times.
> Not to mention the new stuff which almost but not quite duplicates the built-in Java stuff
You're going to have to mention it - what are you talking about?
> It would be better just to have a better Java, not a hack on top.
It's not a hack on top. It's a full-fledged language (the existence of scala.js is proof of that). The JVM was always intended to support multiple languages.
Exactly.
I'm an Android developer and while I have followed the latest OpenJDK developments on Android with interest, I don't really care much because I and my organization have already switched over to Kotlin. And since mixing Java and Kotlin files is so easy, everybody can do the transition at their own pace (we're still in the transition phase so our engineers are allowed to keep using Java if they so prefer but most of them have already switched 100% to Kotlin and they are not looking back).
It's a bit annoying to review code that mixes Java and Kotlin but it's temporary and I predict than in just a few months, the whole organization will be 100% using Kotlin. I suspect that by the time Android fully supports Java 8, we won't really care about it any more.
Too complicated for blue collar devs according to design team.
So if you want a F# or C# like language in the JVM, it won't be Java.