6 ms·

Its fascinating process where if you're a hot new language you attract a lot of people that like shiny new things. When the next hot new language comes along an

by rb808 9y ago

Its fascinating process where if you're a hot new language you attract a lot of people that like shiny new things. When the next hot new language comes along and those people move on - have you attracted enough of the secondary wave to keep alive? Its going to be interesting to watch Scala adoption in the next few years.

devit 9y 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 9y 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 9y ago
    Also, from my understanding, Kotlin is tied to the Intellij ecosystem, so open source tooling is lacking when compared to Scala.
    - pjmlp 9y 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 9y ago
        Charging for debugger access sounds so 90s lol
        AsyncAwait 9y 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 9y 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 9y 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 9y 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 9y 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 9y ago
        It is not correct, debugging via lldb is available.
        pjmlp 9y 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 9y 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 9y ago
    Shrewd analysis. It does seem like Scala and Clojure bring much more unique value propositions as JVM languages.
- lmm 9y 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 9y 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 9y ago
    I thought I saw HKT planned for Rust, as in, being in the works.
    - steveklabnik 9y ago
      Not directly, no. You’re probably thinking of ATC.
      - RBerenguel 9y 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 9y 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 9y 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 9y 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 9y 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.
rb808 9y ago
BTW I really like playing with Scala, but I also really like Go, OCaml, Clojure, Kotlin, Elixir as well. As well as the traditional Java/Python/C++ I feel like I'm drowning in choice. I didn't realize so much of Apache ecosystem had moved to Scala which is huge.
mi100hael 9y ago
I believe they have. There are quite a few mentions of Kotlin in the comments here, but I've personally seen far more Scala in business settings.

by rb808 9y ago

devit 9y 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 9y 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 9y ago
  Also, from my understanding, Kotlin is tied to the Intellij ecosystem, so open source tooling is lacking when compared to Scala.
  - pjmlp 9y 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 9y ago
      Charging for debugger access sounds so 90s lol
      - AsyncAwait 9y 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 9y 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 9y 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 9y 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 9y 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 9y ago
      It is not correct, debugging via lldb is available.
      - pjmlp 9y 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 9y 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 9y ago
  Shrewd analysis. It does seem like Scala and Clojure bring much more unique value propositions as JVM languages.
lmm 9y 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 9y 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 9y ago
  I thought I saw HKT planned for Rust, as in, being in the works.
  - steveklabnik 9y ago
    Not directly, no. You’re probably thinking of ATC.
    - RBerenguel 9y 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 9y 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 9y 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 9y 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 9y 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.

rb808 9y ago

BTW I really like playing with Scala, but I also really like Go, OCaml, Clojure, Kotlin, Elixir as well. As well as the traditional Java/Python/C++ I feel like I'm drowning in choice. I didn't realize so much of Apache ecosystem had moved to Scala which is huge.

mi100hael 9y ago

I believe they have. There are quite a few mentions of Kotlin in the comments here, but I've personally seen far more Scala in business settings.