Hacker News Reader

Comment by eklavya | Hacker News Reader

I have been using Scala commercially for 3 years now. Never have I come across someone who didn't like it. Java veterans almost cry with joy after using Scala. I don't know if I live in a Scala bubble but I don't believe that's likely. And "Java will almost be Scala" nonsense never gets old it seems. It's as stupid as "Go is almost Haskell" (but they both have lambdas!!).

View on HN

It's not "nonsense" or "stupid" to think that Java will adopt more Scala features over time.

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.

Eventually we're all dead. I don't think Scala will be the best language to use in 10 or 20 years' time. I do think it's the best language to use today (and I won't be leaving it until I see an alternative with higher-kinded types, dependent types, strict evaluation, and project/dependency management as good as maven).

We are all eventually going to die...

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...

On side note: Lambdas and full generics were considered in first drafts of Oak (later Java). C++ did not have lambdas those days. They were dropped from Java because of project deadline pressure and no time to do them right, not some ideology.

> 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.

Java guy here. Not a fan of Scala and I've written a bunch. Love me some Kotlin though lately. Scala just feels like a language shit show. Everything from editor tooling, to the compiler, to the overly complex millions of different ways to do one thing aspect about the language pisses me off.

Kotlin borrowed like 80% of mostly used Scala features and magically these features are ok in Kotlin, while in Scala they lead to millions of different ways to do one thing. Interesting.

Actually, most people who complain about Kotlin do so because they think Kotlin didn't borrow enough features from Scala. It's tough to satisfy everyone :-)

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.

I'm a fan of both actually. In my view they are targeting two different use cases. Kotlin is aiming for heavier Java interop using a smaller runtime. This is a big deal for Android. Scala on the other hand is a more independent language, with much less emphasis on interop.

Scala was nice when it was the only alternative to Java but Kotlin has been slowly gaining some pretty solid momentum as a candidate for Java's replacement.

Assuming it's really gaining momentum over Scala I won't understand why. What Kotlin has over Scala? Compile times? After coding for 1 hour I compile once to check if Intellij and I missed something. Are those 3-4 minutes too much time?

Right now, I would say the only thing it has is momentum on Android, given JetBrains relation to Studio.

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.

No Android will switch to newer OpenJDK so Scala 2.12 would be a valid target.

Spend some time reading the Android source code.

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.

ever is a strong word. I know that at the moment they use some parts of OpenJDK 7, but If they need to comply the Java (tm) caused by licensing, they will be forced (sooner or later) to actually don't use a deprecated JVM. As I know OpenJDK will be depracted on 2024. so it will take some time, but it will come.

Given the rumors of ChromeOS and Android becoming one OS, by 2024 it will hardly matter.

2.12 doesn't include any (non-gated) changes though, so you can keep the same codebase and cross-build for 2.12 (for performance) and 2.11. So we're talking what, at least 3 years ("Aida", either 2.13 or 3.0) before Java 8 becomes a blocker for source-level features, at which point I imagine Android will have an answer.

I doubt Google team will change, given their attitude regarding Java 8, as demonstrated at both Google IO 2014 and 2015.

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.

Well, that's the thing. If you have a small amount of code, the compile times are never a problem. Try compiling something like Apache Spark. It will be somewhere between 30-60 minutes depending on your disk speed, CPUs, etc. etc. The incremental builds are faster, but never less than 2 or 3 minutes for any change. You could potentially avoid this with the REPL, or use inotify to trigger a background compilation, but none of those really works all the time.

And yet it was written in Scala. That shows how little the compile times offset the goodies of using Scala.

At the time Spark was started, Java didn't have lambdas or closures, making the equivalent Java code for functional-programming-style ML code much more verbose. Whether the same decision would be made today is an open question (and probably depends on who you ask). A lot of other frameworks have made different decisions, such as keeping the core of the project in Java and supporting other languages as shims on top (in my opinion a more sensible decision...)

From what I observed it's close enough to Java that people can easily switch and are willing to. There's also enough brevity with the language to be at ease with it daily (not as much as Scala) where it may be enough that perhaps people might not want to invest time to go all the way to Scala.

One of the things I love about Scala is that you don't have to "go all the way" though - you can start by writing Java-like code using Java libraries, and move on to writing Kotlin-like code as and when you want to, and move on to more advanced features than that as and when you want to.

> One of the things I love about Scala is that you don't have to "go all the way" though

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.

Unfortunately it's impossible to combine that with seamless Java interoperability, because so many Java features are dangerous (null, exceptions, pervasive mutability, all of the methods on Object, finalizers, low-level thread manipulation) or at least cumbersome (use-site variance and the resulting existential types, control flow constructs built into the language syntax).

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.

> Google even used to have (still does?) a style guide saying which features to use and which ones not to use.

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.

To me, the benefit is what Kotlin has less than Scala.

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.

It's worth noting that typesafe are prioritizing reducing compile time but it's a 32 pass compiler (!)

We're working on gigantic production systems currently and with good modularization compile times are not a problem for us.

Here in Germany I am yet to see any job posting about it.

It is all about Java, Scala and Clojure.

Well Kotlin isn't even officially released yet (1.0 candidate came out last week) so no company is probably using it for production yet.

And even after that, it wouldn't be reasonable for any big company to adopt a language that's not at least at version 1.1 or 1.2.

I don't think one can make any pronouncement about Kotlin's success or failures for several years.

I wouldn't be so sure. A bunch of Android developers are severely hurt from being stuck with Java 7. I'd expect many production apps to be written in Kotlin pretty soon, about as fast as the switch from Objective-C to Swift went.

Scala is also an option and currently looks better on the cv.

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.

It's a trivial conversion from Java to Kotlin, as opposed to Scala or Clojure, so I wouldn't expect people to be hiring explicitly for it.

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?

I wouldn't've described Scala as "gaining momentum" in 2004 either. Kotlin may eventually be successful (I don't think it should be; IMO Ceylon does everything that Kotlin does and does it better, but that's just, like, my opinion man), but the present hype is certainly premature.

I agree - Kotlin is gaining momentum in hype. Give it a couple of years and we'll see how it actually moves. Ceylon does not do Java interop as well as Kotlin does, IMO.

I'm tired of the Kotlin hype (particularly with it unreleased, and so rarely used in production). Many of its features are already part of modern Java, and its language features are very ad-hoc. I can easily see a future for Scala (it offers more radical improvements that Java will never adopt), and maybe see a future for Ceylon (it's a very clean design and the union types are a genuine innovation). I can't see one for Kotlin.

> I can't see one for Kotlin.

You can't see a future for a language that offers far more succinct code than Java, but maintains the ease of Java?

I think Java will close the succinctness gap with Kotlin. And I don't think Kotlin will be able to maintain ease as it evolves, because the design is very ad-hoc.

I don't see any syntactic features in Java 9 that will close that gap further, but I guess we'll see.

Many features are part of Java, but they are much more succinct. For example, if I've got a List of Integers and I want to add 5 to each one, then in Java I'd have to do something like:

`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.

Is "it" some kind of magic value? So much for Kotlin being simpler / more readable than Scala. At least _ looks like syntax.

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.

"it" is a magic value that was introduced in Groovy, so a lot of people are familiar with it. You got used to "this" being a magic value, "it" is a pretty easy concept to grasp.

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.

[1] http://stackoverflow.com/a/8001065/162410

> You got used to "this" being a magic value, "it" is a pretty easy concept to grasp.

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.

> ... was introduced in Groovy, so a lot of people are familiar with it

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.

> I'm tired of the Kotlin hype (particularly with it unreleased, and so rarely used in production)

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.

Do you not remember when Java itself came out?

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.

Reply on news.ycombinator.com