Hacker News Reader

Comment by __sr__ | Hacker News Reader

Is it me, or does the article feel like it is written by someone who didn’t actually bother to learn Kotlin. Instead they learnt the bare minimum syntax and tried to write Java in Kotlin.

The author complains a lot about how Kotlin is different from Java. Err.. it is a new language — it is supposed to be different — otherwise why bother?

> I have my favorite set of JVM languages. Java in /main and Groovy in /test are the best-performing duo for me. In summer 2017 my team started a new microservice project, and as usual, we talked about languages and technologies. There are a few Kotlin advocating teams at Allegro, and we wanted to try something new, so we decided to give Kotlin a try.

The opening lines set the tone for the article. The author tried Kotlin because other people wanted to — not because he found it interesting. Most people learn a new language by writing a toy project or two. They don’t start with a real project. And of course it will take time to get used to a new language and be as productive in it as as you were in the old one. The friction is always there, no matter which language you are switching to.

I am sorry, but I can’t take this article seriously — I feel that it’s written for the sole purpose of venting author’s frustrations.

View on HN

I feel the same way: author wants Java and was hoping only for a better Java: compatible with most patterns, tools, even libraries, but addressing some of his pet frustrations. When Kotlin did not satisfy his hopes he got disappointed. Understandably, but I do not see it as the Kotlin problem.

The other problem I have with this post is that it did not state desires/hopes up front. The intro only mentions compile-time null-safety and less boilerplate (for which many languages are better than Java), then adds his desires throughout the text. Thus his complaints seem not a thought through list of failures to satisfy specific desires, but just randomly throwing rocks at vague targets. My 2c.

> a better Java: compatible with most patterns, tools, even libraries, but addressing some of his pet frustrations.

But is this a main pitch of Kotlin?..

Being compatible doesn't mean that compatibility is the path of least friction, especially when it clashes with good design.

A good example of that tension is the final/open thing: Wonky frameworks abuse inheritance and force you to use open all over the place, but Effective Java suggests you should make every class/method final unless you specifically design it to be extended.

> The author complains a lot about how Kotlin is different from Java. Err.. it is a new language — it is supposed to be different — otherwise why bother?

Kotlin advocates try to have it both ways. If it's a full new language, to be evaluated as a full language, then why would you adopt it when it's missing important features compared to Scala? The narrative is that it's a set of small enhancements to Java that are easier to pick up than Scala, but the reality doesn't live up to that.

> then why would you adopt it when it's missing important features compared to Scala

Such as?

There are a lot of things I miss. Case objects, macros, string contexts, (built-in) options as single-element collections, tuples, built-in either, abstract/self types, implicits, etc. We can argue about "importance" or even if those are good things, but we can't pretend that there aren't many missing features. Granted these days I appreciate Kotlin more than Scala, but that is more about tooling and backing.

> We can argue about "importance" or even if those are good things, but we can't pretend that there aren't many missing features.

I don't think anyone would deny that Scala has the most features of anything, it's purely a question of importance. Important missing features is more interesting to discuss than purely missing features.

I've found myself more missing features from C++ when working in kotlin - specifically constexpr & static_assert.

Meh, importance of language features becomes just too subjective. I consider several of the things I mentioned as important, but not important enough for me to choose the language.

At the concrete/immediate level, a nice way to do error handling when you want errors to include a detail message (i.e. a Result/Either-like) - most languages that offer Option-like types let you use a type like that the same way, but in Kotlin the nice ?. syntax only works for "null". Even Java checked exceptions are a better answer for that use case than anything in Kotlin.

Proper immutable types for e.g. collections. If you're writing in a functional style as Kotlin encourages, you want to be able to write functions that accept lists that are required to be immutable, not just lists that the function isn't going to mutate itself. (Scala's collections get a lot wrong but a thing they get right is that e.g. scala.collection.List is a mutable-or-immutable interface that offers only read methods, and then scala.collection.mutable.List and scala.collection.immutable.List are subtypes for mutable and immutable. Kotlin offers the equivalent of scala.collection.List but not the equivalent of scala.collection.immutable.List)

Better support for operations that need to happen in particular contexts - i.e. custom command-like objects. Kotlin has a bunch of syntaxes that could be reused for this - .?, async/await, and plain old collection iteration all need similar syntax, but there's no way to overload a syntax like that for your custom type. (Scala gets this right: for/yield works for options, for async, for plain old collections and more, but also works for user-defined types).

And ultimately, higher-kinded types. (More concretely: the ability to write utility functions like "traverse" that will work the same for various different context-like types).

Re immutable: If you're doing functional why does this matter? "true" immutable vs. just an immutable view should only matter if the object is retained by the function it's passed to, but now we're talking object state rather than pure functions.

Re "command-like" objects: I'm not following, can you give an example of something you can do in Scala here that you can't in Kotlin?

> Re immutable: If you're doing functional why does this matter? "true" immutable vs. just an immutable view should only matter if the object is retained by the function it's passed to, but now we're talking object state rather than pure functions.

For the same reason that being able to write val rather than var matters. With perfect discipline you can write pure functional code in any language, but in practice (and in codebases that likely have some non-functional sections, particularly if you're interoperating with Java) being able to be 100% sure that a given value is really immutable rather than 99.9% sure makes a huge difference.

> Re "command-like" objects: I'm not following, can you give an example of something you can do in Scala here that you can't in Kotlin?

There are lots of different use cases for this stuff, but one I was working with today was database transactions. I have operations that should only happen inside a database transaction, and want to enforce that at the type level, but I want to be able to compose several of those functions in a single database transaction, so I don't want to just have each one run its own transaction. So what I do is have a custom type, something like MustHappenInTransaction[A], which is actually just an alias for an existing library type (Free), and I automatically get the ability to use the for/yield syntax to compose these, and can use existing library functions to operate on it almost as if it were a plain value, but still safely (e.g. traverse rather than map on a sequence). I have no way to "get the A out" except for my doTransaction() function (what's why I say it's a command-like object), so the function will definitely happen in a transaction, but I can still do normal function composition, extract out common subfunctions, and all that.

You can't do that in Kotlin because there's no equivalent to "do notation" or "for comprehension" that you can use for user-defined types, and there are no higher-kinded types so you can't implement generic helper functions like traverse (there's no way to write the type signature it should have).

You can do something like this:

    class MyTransaction {
        fun begin() {}
        fun commit() {}
    }

    fun MyTransaction.query() {}
    fun MyTransaction.update() {}

    inline fun <R> transaction(tblock: MyTransaction.() -> R): R {
        val t = MyTransaction()
        t.begin()
        try {
            return t.tblock()
        } finally {
            t.commit()
        }
    }

    fun test() {
        // update() doesn't compile, no such method
        val hello = transaction {
            query()
            update()
            query()
            "Hello"
        }
        println("$hello") // prints "Hello"
    }

Does that not work for your usage for some reason? Is there a problem with this approach I'm not seeing?

I must admit I don't entirely understand how your approach works, but it seems like it requires all the functions you want to use in transactions to live on MyTransaction (even if only as extension methods)? I want to be able to write normal functions including quite high-level ones that take some business objects and return MustHappenInTransaction[SomeOtherBusinessObject], and pass these return values through generic methods that don't know anything about transactions specifically.

    typealias MustBeInTransaction = MyTransaction.() -> Unit
    
    fun makeObject(i: Int): MustBeInTransaction {
        return { /* do something with i or whatever in a transaction */ }
    }
    
    fun test() {
        var genericArray = arrayOf(1, 2, 3).map { makeObject(it) }
        //genericArray.forEach { it() } // fails to compile
        transaction {
            genericArray.forEach { it() }
        }
    }

Like that?

It just dawned on me that Kotlin receivers[1] and extension methods[2] are basically the equivalent to Scala implicit params and conversions respectively. Although it appears that receivers can only really be used with anonymous functions. This appears to be similar to implicit function types proposed for Dotty[3]. So the Dotty equivalent to the above would be:

    type MustBeInTransaction = implicit MyTransaction => Unit

    def makeObject(i: Int): MustBeInTransaction = {
        return { /* do something with i or whatever in a transaction */ }
    }
    
    def test(): Unit = {
        var genericArray = Array(1, 2, 3).map(makeObject)
        //genericArray.forEach { _() } // fails to compile
        transaction {
            genericArray.forEach { _() }
        }
    }

EDIT - I just noticed that this is almost exactly the same as the example used in the function types link below

[1] https://stackoverflow.com/questions/45875491/what-is-a-recei...

[2] https://kotlinlang.org/docs/reference/extensions.html

[3] https://www.scala-lang.org/blog/2016/12/07/implicit-function...

It is interesting to see that is possible in Kotlin. I just learned a lot about receivers (as an aside, do you know where I can find better documentation? The best I could find was a stack overflow post).

I think this issue with this is what happens when you combine DB transactions with async queries with errors and null handling? It seems like you have to combine 4 different mechanisms in order to do this (receivers, async/await, try/catch, if(null)). Is there some way to do this all with receivers? It seems like they don't really compose.

The 'command' version in Scala could be written roughly the same way for any combination of the 4 features (the types would just change). For example you could write your original example as:

    def test() {
        // update() compiles but doesn't do anything to the DB
        val helloDBOperation = for {
            result1 <- query()
            _ <- update()
            result2 <- query2()
        } yield "Hello"
        

        println("$hello") // prints "Hello"
    }

The 'command' version in Scala could be written roughly the same way for any combination of the 4 features (the types would just change). For example you could write a Scala version of your original example as:

    def test(): Unit = {
        // update() compiles but doesn't do anything to the DB
        val helloDBOperation = for {
            _ <- query()
            _ <- update()
            _ <- query2()
        } yield "Hello"
        
        val hello = db.run(helloDBOperation)
        println("$hello") // prints "Hello"
    }

This would look almost exactly the same no matter which combination of the 4 features you use.

EDIT - it looks like I somehow also accidentally replied to you with an earlier version of this comment. Unfortunately , I didn't notice until it was too old to delete or edit. Please ignore the other comment that is very similar to this one. Sorry about the confusion.

> as an aside, do you know where I can find better documentation? The best I could find was a stack overflow post

https://kotlinlang.org/docs/reference/type-safe-builders.htm...

It's more designed to build DSLs or similar, so you'll find more documentaion/examples in that area of the docs.

> I think this issue with this is what happens when you combine DB transactions with async queries with errors and null handling? It seems like you have to combine 4 different mechanisms in order to do this (receivers, async/await, try/catch, if(null)). Is there some way to do this all with receivers? It seems like they don't really compose.

It's just a closure with a compiler-added paremeter. It can be nullable if you want and exceptions work the same as any other closure. If you want async/await you'd use coroutines. I think coroutines and receivers mix just fine, you'd just make the type a suspending lambda with receiver, but I've never tried.

> https://kotlinlang.org/docs/reference/type-safe-builders.htm.... > > It's more designed to build DSLs or similar, so you'll find more documentaion/examples in that area of the docs.

Thanks for the link. However, I feel like that still doesn't give a lot of detail. Can you have multiple receivers? Can receivers be generic? Can receiver resolution be controlled by other arguments?

> It's just a closure with a compiler-added paremeter. It can be nullable if you want and exceptions work the same as any other closure. If you want async/await you'd use coroutines. I think coroutines and receivers mix just fine, you'd just make the type a suspending lambda with receiver, but I've never tried

Sorry I didn't mean to imply that Kotlin was incapable expressing all of these things together. I meant it would be desirable to express all of these things with the same tools. It seems like the you would have to express these with several different paradigms and be aware of how they interact. That also means you would need more boilerplate because you have to abstract each of these things separately.

Yeah, like that. But if code like that is permitted, is there anything that stops me writing a method that stashes a MyTransaction.() in a variable and then using it in another method long after the transaction it's supposed to represent has been closed?

  For the same reason that being able to write val rather than var matters. With perfect discipline you can write pure functional code in any language, but [...]

Strongly agree with you there. This is one of the main gripes I've got with many languages. People just have a "well don't do it" attitude and refuse to see the benefit in the possibility of forbidding mutation. A very important point here is the realization that while the part about discipline might be true, it isn't just your discipline the whole codebase might hinge on, either.

This is the exact reason why making it easy to do the right thing is a very important part of API design; simply by making hacks more laborious than the sane thing to do, you effectively prevent them most of the time.

If you truly need an immutable list there's no shortage of them available. It's more a "is this such a strong, common need that everyone must have it?"

So far I've never needed guaranteed immutability, I've just used kotlin's List (which is an immutable view). If that's the only thing anyone gets then it's functionally guaranteed immutable even though it's not sitting on an immutable implementation.

It's not a case of need versus not; it's that all your lists being mutable creates an extra cognitive drag on everything you do. It's one extra possibility to think about when debugging and trying to understand what's going on when something "impossible" happens (which is what a lot of bugs look like when you're investigating them), right when you can least afford to spare any extra brainpower.

(Kerrigan: Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.)

Sounds like the arrow for kotlin. I think eventually we will see all these things inside kotlin proper but kotlin is pragmatism of idealism not the reverse like scala so in good time for now we have Arrow.

> I think eventually we will see all these things inside kotlin proper but kotlin is pragmatism of idealism not the reverse like scala so in good time for now we have Arrow.

This is an absurd anti-intellectual non-argument. Saying "pragmatism" isn't an argument; if there were actual use cases where the kotlin design was better that would be one thing, but there aren't; it's just inconsistent for no real reason.

There's only immutable List in Scala. Seq or Map would be better examples (they actually come in three versions).

> Kotlin has a bunch of syntaxes that could be reused for this - .?, async/await

Kotlin seems to have reused the hell out of the poor :

> then why would you adopt it when it's missing important features compared to Scala?

What important features are missing?

Why would you use Java when you could use C++ which has a ton of extra features? Or Haskell which has a lot of neat abstractions? Or Python which is super easy to use? Or Lisp which is extremely flexible?

Simple, they all serve a particular purpose. Scala serves a particular purpose, so does Kotlin.

I have found Kotlin to be an easy to use modern language which the JVM ecosystem was IMO lacking. That said, I am not a Kotlin advocate. I’d use if I had to choose from the JVM languages. Otherwise there are plenty of other languages and ecosystems to choose from.

No one likes small enhancements over an existing language in a new language - it is usually not worth switching over. Remember D? IMO, Kotlin developers have made sensible choices in most cases while retaining full Java interop - something I consider an achievement.

> Why would you use Java when you could use C++ which has a ton of extra features? Or Haskell which has a lot of neat abstractions? Or Python which is super easy to use? Or Lisp which is extremely flexible?

Because C++ and Python aren't safe enough, Haskell is too hard to learn, and Lisp is too flexible to maintain. Or maybe you weigh the factors differently and wouldn't use Java, and would pick one of those languages instead.

> Simple, they all serve a particular purpose. Scala serves a particular purpose, so does Kotlin.

I disagree with this as a language design philosophy. Your language may end up being better suited for some purposes than others, but I find languages that aim to be general-purpose tend to work out better than languages that design for a small niche. Scala in particular was explicitly designed to be a "scalable language" that could be used for both large and small programs - and my experience is that it manages that. (Indeed I'd say it doesn't make sense to adopt it as a language if it's not replacing the majority of your stack - there's more to learn in Scala than in most languages, but if you can replace two languages with Scala then that's still less to learn overall).

> No one likes small enhancements over an existing language in a new language - it is usually not worth switching over. Remember D?

Exactly - I think Kotlin has largely made the same mistake as D or CoffeScript, of not being willing to make a big enough break from the existing language in the space. And yet at the same time we see that it's not so easy for a Java user to pick up, either.

> Because C++ and Python aren't safe enough

I wonder what langauages are used in aircraft jets, military, space industry, pace makers ... etc

Often "C" but with enough additional tooling on top to qualify as a distinct language (by which I mean: you can't just pick up a random C library - or a random C programmer - and expect to be able to work with them in that environment). Sometimes Ada. Sometimes others. Sometimes a heterogeneous stack that might include Python in some non-safety-critical parts.

> If it's a full new language, to be evaluated as a full language, then why would you adopt it when it's missing important features compared to Scala?

For all the features it has that Scala doesn't of course, many of which may not be part of the core language (compile times, tooling, backing, simplicity, compile-time null safety, coroutines, quality native compilation, Android support, etc).

The claims about null-safety are pure FUD; once you get past thinking about the literal string enn-you-ell-ell, Kotlin and Scala are exactly as null-safe as each other in all the ways that matter (e.g. as shown in the article, Java interop in Kotlin has exactly the same null-safety issues as in Scala).

Java interop in well-designed Kotlin or Scala is pushed to the edges of the application and fenced off. Kotlin makes null safety a much more practical proposition at that point where Scala doesn't. To be frank, Kotlin's null-handling is one of the bigger reasons I think lesser-skilled developers should use it over Java.

And Scala's is good enough, but it's not as good as Kotlin's. Scala has plenty of other beams in its eye to deal with before getting on anybody else, though (this week's shitfire: developers thinking implicits are a good idea, much as it's been for the last five years...).

> Kotlin makes null safety a much more practical proposition at that point where Scala doesn't.

Nonsense. Putting Option() around any Java-interop calls is no harder than putting explicit "?" types on their return types.

I think it's rather significantly different. The range of inputs to a function in Scala are Some[T], None, and null, whereas in Kotlin they become T and null. Kotlin also uses annotations that exist in libraries--and it understands a lot of them--to turn T! into T or T? directly when it can, which Scala doesn't.

Can you explain how this is so similar to Scala in a way that leaves it up to you to be contemptuous and spit stuff like "nonsense" at people looking to discuss the topic in good faith?

> The range of inputs to a function in Scala are Some[T], None, and null

null is not a legitimate value in Scala. There is no reason to ever use it in a legitimate program; in a situation where you would use null in Kotlin, you use None in Scala. The languages are exactly equivalent (except that Kotlin has confusing inconsistent behaviour when you start nesting possibly-absent types, particularly in the presence of generics), people just get confused because they fixate on the literal source string "null" (and Kotlin marketing encourages this confusion). If you really can't stop yourself from typing n-u-l-l for some reason, use wartremover.

> Kotlin also uses annotations that exist in libraries--and it understands a lot of them--to turn T! into T or T? directly when it can, which Scala doesn't.

Those annotations are often unchecked and therefore unreliable, in the cases where they're even present at all (which are unlikely to be the cases where you need to interop with Java - popular mainstream libraries have them, but those are precisely the libraries for which there tends to be a native Kotlin/Scala replacement available). In any case, the original article is talking about the case where there aren't such annotations.

> Can you explain how this is so similar to Scala in a way that leaves it up to you to be contemptuous and spit stuff like "nonsense" at people looking to discuss the topic in good faith?

Sorry. I've seen enough bad faith from Kotlin people on this topic (and when talking about Scala generally) that I find myself unable to assume good faith.

> then why would you adopt it when it's missing important features compared to Scala?

A useful IDE, much faster compile time, lower cognitive load in daily usage.

"Kotlin advocates try to have it both ways"

Kotlin is a new language. Several of its deficiencies are a result of primarily targeting the JVM. There are no universal Kotlin "advocates" claiming otherwise, and that is fundamental a distracting strawman.

As to Kotlin -vs- "other language", Kotlin has fantastic, broad tooling (being designed by a very competent tooling company gave it quite a speedy start). In an instant it beats out most competitors that force much more of a compromise.

Scala has way to many features to be loved and most people that actually know Scala will tell you most users of Scala are not taking advantage of its features or abusing the ones they know. Go on the other hand a very popular language ( yeah yeah ) probably due to its small feature set

> > I have my favorite set of JVM languages. Java in /main and Groovy in /test are the best-performing duo for me. [...] we decided to give Kotlin a try.

> The opening lines set the tone for the article

He also wrote:

> we decided to stick with Groovy in /test (Spek isn’t as good as Spock).

If they were going to switch from the legacy language for /main code (i.e. from Java to Kotlin), why didn't they also switch from the legacy language for /test code too (i.e. from Apache Groovy to Kotlin) instead of dismissing it with "Spek isn't as good as Spock". And if they use Gradle, why not switch from Groovy to Kotlin for build scripts also.

This was my first take on swift as an Obj-C dev back in 2014. I did an app extension in swift, basically just trying to write Obj-C code in swift (force cast and force unwrap all the things!). I didn't like it, I felt like it got in the way, and probably would've given a list of things like the author that are just lang differences.

Needless to say after my 2nd round with swift it clicked, and then clicked again and again in different ways as the months rolled on. Never looked back.

No thats exactly how it's written. It's written by someone who is so stuck in java land and never bothered learning any other language or paradigms.

It is just you. Edit: and some hundred others. (using my karma as stats counter)

Reply on news.ycombinator.com