4 ms·

I believe a lot of the lack of adoption has to do with how hard it tends to be setting up the environment for Scala dev on Android. Whereas, Kotlin aims to make

I believe a lot of the lack of adoption has to do with how hard it tends to be setting up the environment for Scala dev on Android. Whereas, Kotlin aims to make it as easy as possible by working hand in hand with Android Studio/IntelliJ.

harryh 11y ago
I certainly agree that Typesafe (the company behind Scala) has hugely underinvested in tooling. The fact that they still (afaik) recommend sbt as a build tool is telling.
- andreaferretti 11y ago
  I happen to find sbt one of the few build tools (together with lein) that are decent enough. Do you have any particular reason for your dislike?
  - harryh 11y ago
    It doesn't work with large codebases. Or even very well with medium sized ones.
    - dragonwriter 11y ago
      > It doesn't work with large codebases. This type of general conclusion isn't, by itself, particularly useful in discussion; a lot more useful would be presenting a summary of the specific facts and experiences that lead you to this conclusion.
    - saryant 11y ago
      What size are we talking? I've had no issues with SBT on a 20k line codebase.
    - eeperson 11y ago
      I'm using it on a 100k line codebase without issue. What problems are you having?
      - merb 11y ago
        i'm loving sbt, but still on projects above > 100 dependencies it gets really really slow to download it, while with gradle (even i dislike it) it is way way faster.
        eeperson 11y ago
        This is probably SBT's greatest weakness and Gradle's biggest strength, relatively. I've never run in to this personally, probably because I'm use Nexus[1] as a repository cache. My understanding is that the underlying problem is a limitation of the dependency resolution library they use, Ivy[2]. Gradle used to use this but at some point wrote their own dependency resolution library. There are some improvements in recent versions of SBT but you have do a little configuration. See here[3] for more details. [1] http://www.sonatype.com/nexus/product-overview http://www.sonatype.com/nexus/product-overview [2] http://ant.apache.org/ivy/ http://ant.apache.org/ivy/ [3] https://www.typesafe.com/blog/improved-dependency-management-with-sbt-0137 https://www.typesafe.com/blog/improved-dependency-management...
        merb 11y ago
        I also thought of introducing Nexus, but since we are only 3 Devlopers (yet, we searching though) it didn't too much sense. I also I hoped for Nexus 3 (but since I'm waiting over half a year now, we might introduce Nexus 2). Oh and we also using the Cache, when working on newer sbt projects.
- caoilte 11y ago
  sbt isn't very good for copy&paste build masters, which was pretty much all of us who had to setup Ant and Maven projects. It demands a certain amount of investment in learning its core concepts, but OMIGOD it's sooooo good once you know what you're doing. I've extracted so much common setup to hierarchies of plugins that I can setup our company's most common usecases for new projects in 3 or so lines of code.
  - kasey_junk 11y ago
    One of the big problems I had with it (stopped using it about a year ago) was that they changed those core concepts so frequently. I had code routinely stop working during point releases. I couldn't justify spending that much time on my build code.
incepted 11y ago
Scala's runtime also disqualifies it from anything but toy projects on Android (something like 50k methods). This document goes in greater details: https://docs.google.com/document/d/1ReS3ep-hjxWA8kZi0YqDbEhCqTt29hG8P44aA9W0DM8/edit?hl=en&forcehl=1 https://docs.google.com/document/d/1ReS3ep-hjxWA8kZi0YqDbEhC...
- harryh 11y ago
  Isn't it fairly easy to slim down the runtime at build time to only the methods you're using? I was under the impression that this was possible, though I've never actually done it so what do I know....
  - eeperson 11y ago
    Yes, it is. This is commonly accomplished with a tool called ProGuard. Doing this comes with some other trade offs but it is easy to do.
- justthistime_ 11y ago
  Just because they didn't do their research doesn't mean it's not a no-brainer. > it requires build complexity All languages benefit from not having to deploy their standard library on every iteration, not only Scala.

harryh 11y ago

I certainly agree that Typesafe (the company behind Scala) has hugely underinvested in tooling. The fact that they still (afaik) recommend sbt as a build tool is telling.

andreaferretti 11y ago
I happen to find sbt one of the few build tools (together with lein) that are decent enough. Do you have any particular reason for your dislike?
- harryh 11y ago
  It doesn't work with large codebases. Or even very well with medium sized ones.
  - dragonwriter 11y ago
    > It doesn't work with large codebases. This type of general conclusion isn't, by itself, particularly useful in discussion; a lot more useful would be presenting a summary of the specific facts and experiences that lead you to this conclusion.
  - saryant 11y ago
    What size are we talking? I've had no issues with SBT on a 20k line codebase.
  - eeperson 11y ago
    I'm using it on a 100k line codebase without issue. What problems are you having?
    - merb 11y ago
      i'm loving sbt, but still on projects above > 100 dependencies it gets really really slow to download it, while with gradle (even i dislike it) it is way way faster.
      - eeperson 11y ago
        This is probably SBT's greatest weakness and Gradle's biggest strength, relatively. I've never run in to this personally, probably because I'm use Nexus[1] as a repository cache. My understanding is that the underlying problem is a limitation of the dependency resolution library they use, Ivy[2]. Gradle used to use this but at some point wrote their own dependency resolution library. There are some improvements in recent versions of SBT but you have do a little configuration. See here[3] for more details. [1] http://www.sonatype.com/nexus/product-overview http://www.sonatype.com/nexus/product-overview [2] http://ant.apache.org/ivy/ http://ant.apache.org/ivy/ [3] https://www.typesafe.com/blog/improved-dependency-management-with-sbt-0137 https://www.typesafe.com/blog/improved-dependency-management...
        merb 11y ago
        I also thought of introducing Nexus, but since we are only 3 Devlopers (yet, we searching though) it didn't too much sense. I also I hoped for Nexus 3 (but since I'm waiting over half a year now, we might introduce Nexus 2). Oh and we also using the Cache, when working on newer sbt projects.
caoilte 11y ago
sbt isn't very good for copy&paste build masters, which was pretty much all of us who had to setup Ant and Maven projects. It demands a certain amount of investment in learning its core concepts, but OMIGOD it's sooooo good once you know what you're doing. I've extracted so much common setup to hierarchies of plugins that I can setup our company's most common usecases for new projects in 3 or so lines of code.
- kasey_junk 11y ago
  One of the big problems I had with it (stopped using it about a year ago) was that they changed those core concepts so frequently. I had code routinely stop working during point releases. I couldn't justify spending that much time on my build code.

incepted 11y ago

Scala's runtime also disqualifies it from anything but toy projects on Android (something like 50k methods). This document goes in greater details: https://docs.google.com/document/d/1ReS3ep-hjxWA8kZi0YqDbEhCqTt29hG8P44aA9W0DM8/edit?hl=en&forcehl=1 https://docs.google.com/document/d/1ReS3ep-hjxWA8kZi0YqDbEhC...

harryh 11y ago
Isn't it fairly easy to slim down the runtime at build time to only the methods you're using? I was under the impression that this was possible, though I've never actually done it so what do I know....
- eeperson 11y ago
  Yes, it is. This is commonly accomplished with a tool called ProGuard. Doing this comes with some other trade offs but it is easy to do.
justthistime_ 11y ago
Just because they didn't do their research doesn't mean it's not a no-brainer. > it requires build complexity All languages benefit from not having to deploy their standard library on every iteration, not only Scala.