6 ms·

Based on my admittedly limited experience in the JVM world, your needs sounds like Scala's sales pitch. What factored in to your decision to develop Kotlin, rat

Based on my admittedly limited experience in the JVM world, your needs sounds like Scala's sales pitch. What factored in to your decision to develop Kotlin, rather than going with Scala?

pron 11y ago
The two languages have completely different philosophies. Kotlin is a strict adherent of the Java philosophy[1], a "blue collar language" that adopts only tried-and-true features, with PL research being a non-goal. Scala OTOH, adopts almost every new PL concept, and PL research is very much one of its goals. A quick look at Scala's list implementation will show you how different those languages are. Kotlin is a modern Java; Scala is a Haskell/OOP/macros combo. Yet, I think many of Scala's users will find that Kotlin gives them all they need, in a much simpler, more readable and maintainable language. If, however, you're aching to write type-safe monad transformers, you're bound to be disappointed by Kotlin. [1]: http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java.pdf http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java....
- adriaanm 11y ago
  As the Scala tech lead, I'm glad to learn we've finally adopted "almost every new PL concept!" I guess by now everyone will recognize your username and adjust for bias accordingly, but still, how about sticking to the facts?
  - rattray 11y ago
    As someone who doesn't follow such things (eg; I don't recognize the "pron" or "adriaanm" usernames, and haven't used Scala or any other JVM language), I found your comment to be a turn-off towards using Scala. That's not the kind of mature tone I'd look for from the tech lead of an open-source language. That said, it is good to know that "pron" was incorrect/exaggerating when they said Scala adopts a lot of PL concepts; thanks for setting the record straight (though I'm still just not sure where Scala stands on that after reading this).
    - virtualwhys 11y ago
      FYI, pron's the author of a would be competing project to Scala's Akka (i.e. competing for share of distributed computing market on the JVM), and takes every opportunity to danger-danger-dragons-be-there on Scala related threads/comments. Saying that, there is always some truth in what pron brings to the table, it's sort of a higher kinded trolling ;-) As for Scala and PL concepts, sure, plenty on offer if that's of interest, but not at all a requirement in using the language. A great example of a highly successful project based on the non-FP-centric aspects of Scala is Spark. See their high performance computing style guide [1], no monad transformers there... [1] https://github.com/databricks/scala-style-guide https://github.com/databricks/scala-style-guide
      - ninjakeyboard 11y ago
        What is a pron? That's like a shrimp?
        saryant 11y ago
        pron is the author of the GGGP post to the one you replied to.
      - pron 11y ago
        FYI, I had taken "every opportunity to danger-danger-dragons-be-there" Scala — on record — years before I even dreamed of the database company that would one day have an open-source project which would end up competing with Akka (I'm talking 2009/10, while Quasar was first conceived in mid 2013). It was after leading an attempt to adopt Scala at a large organization, which failed because of what I saw as Scala's bait-and-switch marketing: it presented itself as "a better Java" while it really was (and is) a strict-Haskell-with-OOP-and-macros-and-more. We needed a car and got a helicopter. While some would consider a helicopter superior to a car, I think everyone would agree it imposes a completely different set of tradeoffs. So yeah, for a good while I was telling people, listen, it's a helicopter, so make sure a helicopter is what you want (the Scala community’s response was, what is this FUD? Can’t you see it's got wheels?! You can drive it on the ground if you want; you don’t have to take off! To which I responded, but you still can’t take it to a car garage for maintenance, to which their response was, you’re a stupid biased troll!). I don't remember when was the last time I participated in a Scala thread, but that community doesn’t forget. So if I'm damned if I don't, I might as well do: Spark is a good example for a project that would have been better off using Kotlin. They wouldn't have missed any Scala features, would have had better build times, better IDE support and better Java interop (of course, Kotlin wasn’t mature enough to even be considered when that project started). In fact, using Kotlin would have saved them writing 95% of that style-guide[1], which reads like instructions on how to drive a helicopter on the ground without accidentally taking off (Perhaps ironically, that style guide drew derision from the Scala community, who said, you're in a helicopter for fuck's sake! Why won't you take off?!) [1]: No implicits, no multiple argument lists, no Try, no infix notation, no non-math operators, no recursion, no being-fancy-with-monads, no Scala concurrent collections, no Scala collections, no for loops. They don't mention dynamics and structural types, but I think it goes without saying that they're off-limits, too.
badlogic 11y ago
I can't speak for JetBrains, but from my own experience with Java, Scala and Kotlin, Java interop in Kotlin is a lot better. Scala also offers a lot more features than Kotlin, which is great for highly experienced programmers, but usually means having to subset Scala for mixed experience teams. Kotlin seems to strike a better balance in terms of approachability and expressiveness, and hence being better suited for teams of different experience levels.
- hellofunk 11y ago
  Where would Clojure fit into this mix? How would its interop compare with Scala or Kotlin, as well as its performance?
  - pjmlp 11y ago
    Clojure devs don't seem to care about performance. Just check how the JVM gets the blame for what is essentially Clojure initialization time. There are some in the community trying to improve the situation, but those are kind of forks like Skummet.
    - KirinDave 11y ago
      > Clojure devs don't seem to care about performance. Ridiculous. Clojure devs care a lot about performance. We just care more about correctness.
    - hellofunk 11y ago
      By "performance" I think you specifically mean "startup time." I think there is a big difference between startup time and runtime performance. It is well-known and fully acknowledged by the Clojure community that starting up a Clojure environment and REPL takes a while. But are you also suggesting there is a problem with Clojure runtime performance?
      - pjmlp 11y ago
        I got that understanding given how performance improvements get postponed version after version. Apparently they will be coming on 1.8.
hhariri 11y ago
Scala was our primary candidate, but there were issues back then, namely in terms of compiler performance and also tooling. Tooling isn't easy for Scala, and I believe compiler speed, Kotlin is already faster than Scala in terms. Also, we want to continue to provide support for JDK 6 thru 8.
- mahmoudimus 11y ago
  There's still issues with Scala today.

Based on my admittedly limited experience in the JVM world, your needs sounds like Scala's sales pitch. What factored in to your decision to develop Kotlin, rather than going with Scala?

pron 11y ago

The two languages have completely different philosophies. Kotlin is a strict adherent of the Java philosophy[1], a "blue collar language" that adopts only tried-and-true features, with PL research being a non-goal. Scala OTOH, adopts almost every new PL concept, and PL research is very much one of its goals. A quick look at Scala's list implementation will show you how different those languages are. Kotlin is a modern Java; Scala is a Haskell/OOP/macros combo. Yet, I think many of Scala's users will find that Kotlin gives them all they need, in a much simpler, more readable and maintainable language. If, however, you're aching to write type-safe monad transformers, you're bound to be disappointed by Kotlin. [1]: http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java.pdf http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java....

adriaanm 11y ago
As the Scala tech lead, I'm glad to learn we've finally adopted "almost every new PL concept!" I guess by now everyone will recognize your username and adjust for bias accordingly, but still, how about sticking to the facts?
- rattray 11y ago
  As someone who doesn't follow such things (eg; I don't recognize the "pron" or "adriaanm" usernames, and haven't used Scala or any other JVM language), I found your comment to be a turn-off towards using Scala. That's not the kind of mature tone I'd look for from the tech lead of an open-source language. That said, it is good to know that "pron" was incorrect/exaggerating when they said Scala adopts a lot of PL concepts; thanks for setting the record straight (though I'm still just not sure where Scala stands on that after reading this).
  - virtualwhys 11y ago
    FYI, pron's the author of a would be competing project to Scala's Akka (i.e. competing for share of distributed computing market on the JVM), and takes every opportunity to danger-danger-dragons-be-there on Scala related threads/comments. Saying that, there is always some truth in what pron brings to the table, it's sort of a higher kinded trolling ;-) As for Scala and PL concepts, sure, plenty on offer if that's of interest, but not at all a requirement in using the language. A great example of a highly successful project based on the non-FP-centric aspects of Scala is Spark. See their high performance computing style guide [1], no monad transformers there... [1] https://github.com/databricks/scala-style-guide https://github.com/databricks/scala-style-guide
    - ninjakeyboard 11y ago
      What is a pron? That's like a shrimp?
      - saryant 11y ago
        pron is the author of the GGGP post to the one you replied to.
    - pron 11y ago
      FYI, I had taken "every opportunity to danger-danger-dragons-be-there" Scala — on record — years before I even dreamed of the database company that would one day have an open-source project which would end up competing with Akka (I'm talking 2009/10, while Quasar was first conceived in mid 2013). It was after leading an attempt to adopt Scala at a large organization, which failed because of what I saw as Scala's bait-and-switch marketing: it presented itself as "a better Java" while it really was (and is) a strict-Haskell-with-OOP-and-macros-and-more. We needed a car and got a helicopter. While some would consider a helicopter superior to a car, I think everyone would agree it imposes a completely different set of tradeoffs. So yeah, for a good while I was telling people, listen, it's a helicopter, so make sure a helicopter is what you want (the Scala community’s response was, what is this FUD? Can’t you see it's got wheels?! You can drive it on the ground if you want; you don’t have to take off! To which I responded, but you still can’t take it to a car garage for maintenance, to which their response was, you’re a stupid biased troll!). I don't remember when was the last time I participated in a Scala thread, but that community doesn’t forget. So if I'm damned if I don't, I might as well do: Spark is a good example for a project that would have been better off using Kotlin. They wouldn't have missed any Scala features, would have had better build times, better IDE support and better Java interop (of course, Kotlin wasn’t mature enough to even be considered when that project started). In fact, using Kotlin would have saved them writing 95% of that style-guide[1], which reads like instructions on how to drive a helicopter on the ground without accidentally taking off (Perhaps ironically, that style guide drew derision from the Scala community, who said, you're in a helicopter for fuck's sake! Why won't you take off?!) [1]: No implicits, no multiple argument lists, no Try, no infix notation, no non-math operators, no recursion, no being-fancy-with-monads, no Scala concurrent collections, no Scala collections, no for loops. They don't mention dynamics and structural types, but I think it goes without saying that they're off-limits, too.

badlogic 11y ago

I can't speak for JetBrains, but from my own experience with Java, Scala and Kotlin, Java interop in Kotlin is a lot better. Scala also offers a lot more features than Kotlin, which is great for highly experienced programmers, but usually means having to subset Scala for mixed experience teams. Kotlin seems to strike a better balance in terms of approachability and expressiveness, and hence being better suited for teams of different experience levels.

hellofunk 11y ago
Where would Clojure fit into this mix? How would its interop compare with Scala or Kotlin, as well as its performance?
- pjmlp 11y ago
  Clojure devs don't seem to care about performance. Just check how the JVM gets the blame for what is essentially Clojure initialization time. There are some in the community trying to improve the situation, but those are kind of forks like Skummet.
  - KirinDave 11y ago
    > Clojure devs don't seem to care about performance. Ridiculous. Clojure devs care a lot about performance. We just care more about correctness.
  - hellofunk 11y ago
    By "performance" I think you specifically mean "startup time." I think there is a big difference between startup time and runtime performance. It is well-known and fully acknowledged by the Clojure community that starting up a Clojure environment and REPL takes a while. But are you also suggesting there is a problem with Clojure runtime performance?
    - pjmlp 11y ago
      I got that understanding given how performance improvements get postponed version after version. Apparently they will be coming on 1.8.

hhariri 11y ago

Scala was our primary candidate, but there were issues back then, namely in terms of compiler performance and also tooling. Tooling isn't easy for Scala, and I believe compiler speed, Kotlin is already faster than Scala in terms. Also, we want to continue to provide support for JDK 6 thru 8.

mahmoudimus 11y ago
There's still issues with Scala today.