4 ms·

Don't think it has a bright future since Rust and Kotlin share much of what brings people to Scala and are better in many ways, including and perhaps most impor

by devit 8y ago

Don't think it has a bright future since Rust and Kotlin share much of what brings people to Scala and are better in many ways, including and perhaps most importantly the fact they are improving faster than Scala.

jvican 8y ago
I challenge the fact that Rust and Kotlin are improving faster than Scala. Scala is not only more stable, but is under active development and there are lots of discussions to improve the language over time (check our SIP meetings). Kotlin doesn't even get closer to what Scala is, and Rust is for those folks with the mentality that memory management is something worth keeping track of.
- Cyph0n 8y ago
  Also, from my understanding, Kotlin is tied to the Intellij ecosystem, so open source tooling is lacking when compared to Scala.
  - pjmlp 8y ago
    More than that, if you want Kotlin/Native debugging support, you need to either buy Clion or AppCode, as it is not available on the community edition.
    - Cyph0n 8y ago
      Charging for debugger access sounds so 90s lol
      - AsyncAwait 8y ago
        They're not charging for debugger access. CLion is the only IDE where they have tie ins to GDB etc. so the Native plugin is only for that, but most Kotlin users are on the JVM, where the IDEA Community Edition is not only free, but open-source.
        Cyph0n 8y ago
        > CLion is the only IDE where they have tie ins to GDB etc. so the Native plugin is only for that Both me and the parent were referring to Native. So they are charging for a Kotlin Native debugger, no? Do they provide a GDB fork or something that can use without CLion?
        AsyncAwait 8y ago
        > Both me and the parent were referring to Native. I know. So they are charging for a Kotlin Native debugger, no? No, Kotlin Native can interface with GDB or LLDB, they're charging for CLion which provides a GUI interface atop of these. > Do they provide a GDB fork or something that can use without CLion? No need to fork, you just won't have the frontend that Clion provides.
        Cyph0n 8y ago
        > I know. So why did you refer to Kotlin on the JVM? > No, Kotlin Native can interface with GDB or LLDB, they're charging for CLion which provides a GUI interface atop of these. Cool, thanks for the response.
        AsyncAwait 8y ago
        > So why did you refer to Kotlin on the JVM? Because I was trying to explain that the only reason Kotlin/Native is tied to (paid) CLion is because that's the only IDE where JetBrains have native GDB/LLDB integration, not that they charge for a debugger, which is demonstrated by the fact that where there would be the most potential customers, (JVM Kotlin users), they don't charge anything. The only reason they charge here, is because Clion is primarily a C/C++ IDE, (which explains why they have the GDB integration there) and they want to sell that, (the C/C++ IDE), but given the debugging integration, it's also the best IDE to integrate with Kotlin/Native, (which is free, but the C++ IDE is not), where they have a free offering, (Intellij CE on the JVM), they charge nothing even for the debugging GUI for Kotlin. This is further demonstrated by the fact that their Rust plugin doesn't require CLIon for its IDE features, (even open-source IDEA will do), only if you ALSO want the debugging GUI, you have to go with CLion, a paid C++ IDE. In other words, I am trying to get this idea across that: 1. The Kotlin/Native plugin is free. 2. The only IDE Jetbrains have with GDB integration is CLion. 3. CLion is a paid IDE for C/C++, not Kotlin. 4, Kotlin/Native plugin can only work with CLion for technical reasons, see 2. 5. Because CLion is paid and Kotlin/Native plugin work only with CLion, it happens to come out to you having to pay for CLion to get the Kotlin/Native plugin working. 6. That does not mean that Kotlin/Native or the Kotlin/Native plugin themselves are paid products, they're not, nor are Jetbrains charging for access to the debugger itself.
    - nikolay_igotti 8y ago
      It is not correct, debugging via lldb is available.
      - pjmlp 8y ago
        Which is quite primitive experience versus having a GUI debugger. Something that other languages that compile to native have available without additional costs
pjmlp 8y ago
Rust will have to improve quite a bit to have something like Swing, SWT, JavaFX, which are just there for Scala devs. Kotlin is nice if all you want is a simpler Scala. Then there is Java slowly taking the more relevant features from them, while being the platform's language. Scheduled to be added next, pattern matching.
- preordained 8y ago
  Shrewd analysis. It does seem like Scala and Clojure bring much more unique value propositions as JVM languages.
lmm 8y ago
Neither of those has or intends to have HKT, and they'll never be an acceptable replacement for Scala without it. They're "improving faster" but only in that they're starting from further behind.
- steveklabnik 8y ago
  We may never get HKT directly, but associated type constructors can give you similar powers and fit into the language more naturally, along with impl Trait in traits. We’ll see how it shakes out.
- RBerenguel 8y ago
  I thought I saw HKT planned for Rust, as in, being in the works.
  - steveklabnik 8y ago
    Not directly, no. You’re probably thinking of ATC.
    - RBerenguel 8y ago
      I thought this RFC was for HKT only: https://github.com/rust-lang/rfcs/issues/324 https://github.com/rust-lang/rfcs/issues/324 this is the one I have been paying some attention (not like I use HKT that often in Scala anyway)
      - steveklabnik 8y ago
        That’s not an RFC; it’s just an issue where people talk about things. Actual RFCs are PRs to that repo that contain a design. You are right that it’s purely about HKT though.
- seanmcdirmid 8y ago
  The reason why Kotlin is gaining marketshare is specifically because they aren’t chasing after things like HKTs. Kotlin is squarely going after the better Java market and not the advanced FP one.
simon_o 8y ago
That's true. More importantly, Rust and Kotlin work on improving things that matter to users, not on features that read nicely in a paper, but are largely irrelevant in the grand scheme of things. Just compare Rust's announcement on tooling (https://www.ncameron.org/blog/dev-tools-in-2018/ https://www.ncameron.org/blog/dev-tools-in-2018/) with the state in Scala, where pretty much every promised improvement has been "around the corner" for the last 5 years. :-/ Not sure much how much can or will change here, given the departures of experienced tooling contributors in 2017.
eweise 8y ago
I would bet on Scala over Kotlin for the server side. Java is starting to incorporate Kotlin features so in a few years there won't be that much different. Kotlin reminds me of Coffeescript. It was a much nicer javascript but then Javascript just incorported coffeescript features.

by devit 8y ago

jvican 8y ago

I challenge the fact that Rust and Kotlin are improving faster than Scala. Scala is not only more stable, but is under active development and there are lots of discussions to improve the language over time (check our SIP meetings). Kotlin doesn't even get closer to what Scala is, and Rust is for those folks with the mentality that memory management is something worth keeping track of.

Cyph0n 8y ago
Also, from my understanding, Kotlin is tied to the Intellij ecosystem, so open source tooling is lacking when compared to Scala.
- pjmlp 8y ago
  More than that, if you want Kotlin/Native debugging support, you need to either buy Clion or AppCode, as it is not available on the community edition.
  - Cyph0n 8y ago
    Charging for debugger access sounds so 90s lol
    - AsyncAwait 8y ago
      They're not charging for debugger access. CLion is the only IDE where they have tie ins to GDB etc. so the Native plugin is only for that, but most Kotlin users are on the JVM, where the IDEA Community Edition is not only free, but open-source.
      - Cyph0n 8y ago
        > CLion is the only IDE where they have tie ins to GDB etc. so the Native plugin is only for that Both me and the parent were referring to Native. So they are charging for a Kotlin Native debugger, no? Do they provide a GDB fork or something that can use without CLion?
        AsyncAwait 8y ago
        > Both me and the parent were referring to Native. I know. So they are charging for a Kotlin Native debugger, no? No, Kotlin Native can interface with GDB or LLDB, they're charging for CLion which provides a GUI interface atop of these. > Do they provide a GDB fork or something that can use without CLion? No need to fork, you just won't have the frontend that Clion provides.
        Cyph0n 8y ago
        > I know. So why did you refer to Kotlin on the JVM? > No, Kotlin Native can interface with GDB or LLDB, they're charging for CLion which provides a GUI interface atop of these. Cool, thanks for the response.
        AsyncAwait 8y ago
        > So why did you refer to Kotlin on the JVM? Because I was trying to explain that the only reason Kotlin/Native is tied to (paid) CLion is because that's the only IDE where JetBrains have native GDB/LLDB integration, not that they charge for a debugger, which is demonstrated by the fact that where there would be the most potential customers, (JVM Kotlin users), they don't charge anything. The only reason they charge here, is because Clion is primarily a C/C++ IDE, (which explains why they have the GDB integration there) and they want to sell that, (the C/C++ IDE), but given the debugging integration, it's also the best IDE to integrate with Kotlin/Native, (which is free, but the C++ IDE is not), where they have a free offering, (Intellij CE on the JVM), they charge nothing even for the debugging GUI for Kotlin. This is further demonstrated by the fact that their Rust plugin doesn't require CLIon for its IDE features, (even open-source IDEA will do), only if you ALSO want the debugging GUI, you have to go with CLion, a paid C++ IDE. In other words, I am trying to get this idea across that: 1. The Kotlin/Native plugin is free. 2. The only IDE Jetbrains have with GDB integration is CLion. 3. CLion is a paid IDE for C/C++, not Kotlin. 4, Kotlin/Native plugin can only work with CLion for technical reasons, see 2. 5. Because CLion is paid and Kotlin/Native plugin work only with CLion, it happens to come out to you having to pay for CLion to get the Kotlin/Native plugin working. 6. That does not mean that Kotlin/Native or the Kotlin/Native plugin themselves are paid products, they're not, nor are Jetbrains charging for access to the debugger itself.
  - nikolay_igotti 8y ago
    It is not correct, debugging via lldb is available.
    - pjmlp 8y ago
      Which is quite primitive experience versus having a GUI debugger. Something that other languages that compile to native have available without additional costs

pjmlp 8y ago

Rust will have to improve quite a bit to have something like Swing, SWT, JavaFX, which are just there for Scala devs. Kotlin is nice if all you want is a simpler Scala. Then there is Java slowly taking the more relevant features from them, while being the platform's language. Scheduled to be added next, pattern matching.

preordained 8y ago
Shrewd analysis. It does seem like Scala and Clojure bring much more unique value propositions as JVM languages.

lmm 8y ago

Neither of those has or intends to have HKT, and they'll never be an acceptable replacement for Scala without it. They're "improving faster" but only in that they're starting from further behind.

steveklabnik 8y ago
We may never get HKT directly, but associated type constructors can give you similar powers and fit into the language more naturally, along with impl Trait in traits. We’ll see how it shakes out.
RBerenguel 8y ago
I thought I saw HKT planned for Rust, as in, being in the works.
- steveklabnik 8y ago
  Not directly, no. You’re probably thinking of ATC.
  - RBerenguel 8y ago
    I thought this RFC was for HKT only: https://github.com/rust-lang/rfcs/issues/324 https://github.com/rust-lang/rfcs/issues/324 this is the one I have been paying some attention (not like I use HKT that often in Scala anyway)
    - steveklabnik 8y ago
      That’s not an RFC; it’s just an issue where people talk about things. Actual RFCs are PRs to that repo that contain a design. You are right that it’s purely about HKT though.
seanmcdirmid 8y ago
The reason why Kotlin is gaining marketshare is specifically because they aren’t chasing after things like HKTs. Kotlin is squarely going after the better Java market and not the advanced FP one.

simon_o 8y ago

That's true. More importantly, Rust and Kotlin work on improving things that matter to users, not on features that read nicely in a paper, but are largely irrelevant in the grand scheme of things. Just compare Rust's announcement on tooling (https://www.ncameron.org/blog/dev-tools-in-2018/ https://www.ncameron.org/blog/dev-tools-in-2018/) with the state in Scala, where pretty much every promised improvement has been "around the corner" for the last 5 years. :-/ Not sure much how much can or will change here, given the departures of experienced tooling contributors in 2017.

eweise 8y ago

I would bet on Scala over Kotlin for the server side. Java is starting to incorporate Kotlin features so in a few years there won't be that much different. Kotlin reminds me of Coffeescript. It was a much nicer javascript but then Javascript just incorported coffeescript features.