6 ms·

Well the thing is that Ceylon offers fantastically smooth interop with both Java and JavaScript. That's one of it's main selling features for most people.

mike_hearn 11y ago
Right, but by "interop" I didn't just mean the ability to call into Java code and vice-versa, although I admit that's the traditional definition. Scala can do that too. What I meant is, Kotlin raised the bar in the interop department to new heights: it uses the same collection types, so there's no conversion between Java and some other SDK, but still manages to enhance them via compiler magic and extensions. It has an auto-converter tool so nobody has to waste time rewriting code that already works in order to use the new features. It can use annotation processors, etc. Of course it also pays a fairly steep price to get that.
- justthistime_ 11y ago
  > but still manages to enhance them via compiler magic and extensions The thing is that Scala tried to do that for years, and after years of battling subtle, leaky abstractions, they picked a different design. It feels like Kotlin designers are completely unaware of what other languages tried and keep repeating all the mistakes ...
  - mike_hearn 11y ago
    Hardly. The Kotlin designers specifically call out Scala's mistakes when discussing why they do things differently. In my experience it works well. I've yet to encounter anything surprising or leaky. Actually the abstractions it provides are fairly thin: you can normally look at Kotlin code and understand quickly what it compiles down to. It may be that in the end, Kotlin succeeds where Scala struggled, simply because the Kotlin designers do a better job.
    - justthistime_ 11y ago
      Well, I don't think what you say is based on reality if you look at all the broken, half-designed stuff they are trying to ship. (Not understanding (yet) why some design decisions are bad, doesn't mean they aren't bad.) It feels like they are digging through Scala's graveyard of discarded ideas without even realizing it. Most of what they try to do differently has already been considered in the past and has been rejected by the Scala developers for good reasons – years ago. Kotlin's struggles are a good example that knowing how to build IDE support for existing languages doesn't give you the skills to design a programming language from scratch. The Kotlin designers specifically call out Scala's mistakes when discussing why they do things differently. Yes, I have to give them that. They (and their "fans") excel at PR, marketing and FUD.
      - udalov 11y ago
        Could you please give a few examples of "all the broken, half-designed stuff they are trying to ship"?
        justthistime_ 11y ago
        - extension methods - property syntax + magic identifier - reified - immutable wrappers around mutable collections - const - multiple redundant ways of defining generic upper bounds - companion objects + syntax - operator/infix rules - constantly changing nullability rules
        monkeyfacebag 11y ago
        What's broken about extension methods? I have zero experience Scala and about a week's worth of experience with Kotlin, but so far I'm finding extension methods to be pretty straightforward and useful. What am I missing?
        justthistime_ 11y ago
        Extremely poor cost/benefit ratio.

mike_hearn 11y ago

Right, but by "interop" I didn't just mean the ability to call into Java code and vice-versa, although I admit that's the traditional definition. Scala can do that too. What I meant is, Kotlin raised the bar in the interop department to new heights: it uses the same collection types, so there's no conversion between Java and some other SDK, but still manages to enhance them via compiler magic and extensions. It has an auto-converter tool so nobody has to waste time rewriting code that already works in order to use the new features. It can use annotation processors, etc. Of course it also pays a fairly steep price to get that.

justthistime_ 11y ago
> but still manages to enhance them via compiler magic and extensions The thing is that Scala tried to do that for years, and after years of battling subtle, leaky abstractions, they picked a different design. It feels like Kotlin designers are completely unaware of what other languages tried and keep repeating all the mistakes ...
- mike_hearn 11y ago
  Hardly. The Kotlin designers specifically call out Scala's mistakes when discussing why they do things differently. In my experience it works well. I've yet to encounter anything surprising or leaky. Actually the abstractions it provides are fairly thin: you can normally look at Kotlin code and understand quickly what it compiles down to. It may be that in the end, Kotlin succeeds where Scala struggled, simply because the Kotlin designers do a better job.
  - justthistime_ 11y ago
    Well, I don't think what you say is based on reality if you look at all the broken, half-designed stuff they are trying to ship. (Not understanding (yet) why some design decisions are bad, doesn't mean they aren't bad.) It feels like they are digging through Scala's graveyard of discarded ideas without even realizing it. Most of what they try to do differently has already been considered in the past and has been rejected by the Scala developers for good reasons – years ago. Kotlin's struggles are a good example that knowing how to build IDE support for existing languages doesn't give you the skills to design a programming language from scratch. The Kotlin designers specifically call out Scala's mistakes when discussing why they do things differently. Yes, I have to give them that. They (and their "fans") excel at PR, marketing and FUD.
    - udalov 11y ago
      Could you please give a few examples of "all the broken, half-designed stuff they are trying to ship"?
      - justthistime_ 11y ago
        - extension methods - property syntax + magic identifier - reified - immutable wrappers around mutable collections - const - multiple redundant ways of defining generic upper bounds - companion objects + syntax - operator/infix rules - constantly changing nullability rules
        monkeyfacebag 11y ago
        What's broken about extension methods? I have zero experience Scala and about a week's worth of experience with Kotlin, but so far I'm finding extension methods to be pretty straightforward and useful. What am I missing?
        justthistime_ 11y ago
        Extremely poor cost/benefit ratio.