Hacker News Reader

Comment by dschiptsov | Hacker News Reader

Simplification instead of piling up, clarifying and redoing right, as understanding grows, instead of adding extensions (like crippled lambdas to Java) and reduction to closest approximation to the [unattainable] optimum (smallest possible, well balanced set of mutually complementing each other features, like in R5RS) in general - is the right way.

I hope Swift will eventually stop piling up features and will try to get back to the right fundamentals too.)

View on HN

Have you all seen Kotlin?

Yes, it's like they reinvent all the things that were considered but discarded in Scala and believe they found something nobody ever thought about before.

I am not sure that Kotlin competes with Scala in any way. They are trying to remove the pain from Java by providing a concise and safe language (see the quotes from their website below). What are "all the things" they reinvented that were discard in Scala?

> Kotlin is a pragmatic programming language for JVM and Android that combines OO and functional features and is focused on interoperability, safety, clarity and tooling support.

> Being a general-purpose language, Kotlin works everywhere where Java works: server-side applications, mobile applications (Android), desktop applications.

Kotlin competes with Scala in that they are both alternatives to Java.

> What are "all the things" they reinvented that were discard in Scala?

Extension methods, properties, special syntax for everything, final by default, short constructor syntax, trying to put band-aid around Java's broken collection types, ...

Thank you. I appreciate the list.

I'd love to learn more about Java's broken collection types. What's broken about them?

The pattern of throwing exceptions for operations deemed "unsupported", an API that requires massive workarounds to keep alive in Java 10, no support for immutable collections, unmodifiable views are a complete clusterfuck, no persistent collections etc.

Every single description of Kotlin in your comment could just as easily be describing Scala.

At least they care about 1st class support on Android Studio, instead of InteliJ + sbt + missing support from Android tooling.

If you feel that something is missing people would likely be happy to receive bug reports/feature requests.

They are full aware of it:

"Android Studio should currently not be used for development with sbt and Scala. Chances are, however, that it's a good fit for a Gradle + Scala setup."

http://scala-on-android.taig.io/editor/android-studio/

Using InteliJ instead of Android Studio means not being able to use the latest tooling even from the stable version, as InteliJ is always some versions behind.

Using Gradle + Scala implies a few configuration steps that tend to break at each new Android Studio release, versus the out of the box experience from Kotlin.

I have never seen this documentation and it seems to be wildly outdated.

Which issues did you experience with Android Studio?

No out of the box integration even for basic stuff.

I expect no more hurdles than just using Java official Android tools.

Yes. It has awful nullable unions rather then monadic options/maybes.

Yes, it's awful. It's the opposite of that; it's removing general abstractions that Scala got right and replacing them with zillions of special cases.

Ceylon is what you should be looking at.

I would do more things in Ceylon if it wasn't plagued by performance problems. So far the only way I've found is to avoid any of the few libraries written in Ceylon and just use Java libraries but if you're going to do that then Kotlin's interop is far more appealing.

How so? Kotlin's interop isn't actually any better as far as I can see?

Reply on news.ycombinator.com