4 ms·

What's the alternative, though? By offering a nicely integrated platform, I would hope the community benefits from the halo effect this has on Scala. Our goal i

What's the alternative, though? By offering a nicely integrated platform, I would hope the community benefits from the halo effect this has on Scala. Our goal is to make the whole Scala eco-system successful, but we have to pick carefully what we work on ourselves. The Scala team is absolutely interested in hearing how Scala is used. We had 800 users from all over the world show us their projects in Berlin not long ago. On the more technical side, we build 1M lines of OSS code every night to make sure we don't break anything out there, and we'll be more than happy to include more projects (https://github.com/typesafehub/community-builds https://github.com/typesafehub/community-builds). I see our role as providing the platform for others to build on (examples of extension points: compiler plugins/macros/sbt's client-server-split/abide as an extensible stylechecker). I'd love for us to work on scala-refactoring, for example, but it's not immediately a priority since the community is already doing it, and we have so many other things to do. A tool like "go fix", which is closely related to code formatting, refactoring and style checking, is on our planning horizon (as mentioned in the roadmap that sparked this discussion). > Compile times and sbt's incremental compilation support is an obvious example of this. I don't understand. You seem to be implying incremental compilation is restricted to sbt: it's not! We expose this as a service through the zinc project, which is used by the Intellij plugin (name hashing support added here: https://github.com/JetBrains/intellij-scala/commit/4831c03571f292fdb145ab7321e2b99c62c64163 https://github.com/JetBrains/intellij-scala/commit/4831c0357...) and many other build tools (e.g., gradle, maven). Also, regarding sbt: it survived because of the awesome sbt community. The core Scala team (which I lead) is shamefully still using ant, although we plan to move to sbt this year.

kasey_junk 12y ago
"What's the alternative, though?" The easiest answer to this (and what most language teams do) is not have tacit default functional stacks. Typesafe have gone the odd route, not the standard one. "I would hope the community benefits from the halo effect this has on Scala" That may or may not happen, but my experience has been the opposite. An example is Play (which I quite like). It is a very opinionated web framework, that many developers have quite rightly decided didn't match their opinions. By tying the brand of Scala with the brand of Play you make it so that I as a Scala advocate have to fight for both together, even though there are many other Scala web frameworks, and I might not even be fighting for a web project, just that the negative connotations of Play leak into the discussion either explicitly or implicitly. Think of the Ruby case, which is currently more extreme than the Scala one. If someone says they do Ruby development, it is quite natural to think they do Rails even though I'm sure there are other Ruby web frameworks and Ruby the language could be used for any number of things. This impact is even worse for something that has a really bad reputation like sbt. For many developers their first impression of Scala came from fighting sbt and that negative experience colors their whole opinion of Scala. For years I literally said some variation of "just skip sbt and use maven/gradle/ant etc." trying to get people to divorce Scala from sbt in their mind. Sbt has finally reached a point where instead of saying that I just say, "you'll get used to sbt" which is better, but I can't with a straight face say that sbt is not part and partial to the scala experience (for instance you mention some sbt work is part of the scala core teams responsibilities). If nothing else the other stacks you may encounter make use of it, so you need to have an understanding. "You seem to be implying incremental compilation is restricted to sbt: it's not!" I'm sorry if I implied that, you certainly can use zinc standalone or with other build tools besides sbt but the experience is not very polished outside of the sbt use case. "Also, regarding sbt: it survived because of the awesome sbt community" No it didn't. For years it was worse than the other alternatives and the only advantage it had was that it was the "Scala" build tool. It is now at a point where it needn't be actively avoided but when I think of all the sunk cost spent on building sbt and fighting to build with sbt it makes me irrationally angry. "The core Scala team (which I lead) is shamefully still using ant, although we plan to move to sbt this year." There is nothing shameful about this at all and I wish you'd stick with Ant for all the reasons I've mentioned above.
- adriaanm 12y ago
  Thanks for pointing all this out. I honestly don't think of the Scala brand as being tied to the Play framework. Typesafe actually pushes Play on Java more than it does Play on Scala (even though we think Scala is better suited, obviously). We try to decouple Scala from Typesafe and our technologies in two ways: we provide Java programmers with an excellent experience on akka & play, and we welcome external maintainers for any part of Scala. We happen to steward the Scala project and fund a lot of Scala core development (along with EPFL and research grants), but we're more than happy to share that responsibility with anyone who steps up, as has recently happened (baby steps) with the Scala modules that we spun out of the core for this reason. PS: The only things that make me angrier than ant are jenkins and bash. (The build systems you're not angry with are probably the ones you haven't spent enough "quality" time with.) In any case, thanks for persevering with sbt and scala! PPS: I don't think this is an odd route for a small company; how do you make money by developing just a programming language and nothing else?

kasey_junk 12y ago

"What's the alternative, though?" The easiest answer to this (and what most language teams do) is not have tacit default functional stacks. Typesafe have gone the odd route, not the standard one. "I would hope the community benefits from the halo effect this has on Scala" That may or may not happen, but my experience has been the opposite. An example is Play (which I quite like). It is a very opinionated web framework, that many developers have quite rightly decided didn't match their opinions. By tying the brand of Scala with the brand of Play you make it so that I as a Scala advocate have to fight for both together, even though there are many other Scala web frameworks, and I might not even be fighting for a web project, just that the negative connotations of Play leak into the discussion either explicitly or implicitly. Think of the Ruby case, which is currently more extreme than the Scala one. If someone says they do Ruby development, it is quite natural to think they do Rails even though I'm sure there are other Ruby web frameworks and Ruby the language could be used for any number of things. This impact is even worse for something that has a really bad reputation like sbt. For many developers their first impression of Scala came from fighting sbt and that negative experience colors their whole opinion of Scala. For years I literally said some variation of "just skip sbt and use maven/gradle/ant etc." trying to get people to divorce Scala from sbt in their mind. Sbt has finally reached a point where instead of saying that I just say, "you'll get used to sbt" which is better, but I can't with a straight face say that sbt is not part and partial to the scala experience (for instance you mention some sbt work is part of the scala core teams responsibilities). If nothing else the other stacks you may encounter make use of it, so you need to have an understanding. "You seem to be implying incremental compilation is restricted to sbt: it's not!" I'm sorry if I implied that, you certainly can use zinc standalone or with other build tools besides sbt but the experience is not very polished outside of the sbt use case. "Also, regarding sbt: it survived because of the awesome sbt community" No it didn't. For years it was worse than the other alternatives and the only advantage it had was that it was the "Scala" build tool. It is now at a point where it needn't be actively avoided but when I think of all the sunk cost spent on building sbt and fighting to build with sbt it makes me irrationally angry. "The core Scala team (which I lead) is shamefully still using ant, although we plan to move to sbt this year." There is nothing shameful about this at all and I wish you'd stick with Ant for all the reasons I've mentioned above.

adriaanm 12y ago
Thanks for pointing all this out. I honestly don't think of the Scala brand as being tied to the Play framework. Typesafe actually pushes Play on Java more than it does Play on Scala (even though we think Scala is better suited, obviously). We try to decouple Scala from Typesafe and our technologies in two ways: we provide Java programmers with an excellent experience on akka & play, and we welcome external maintainers for any part of Scala. We happen to steward the Scala project and fund a lot of Scala core development (along with EPFL and research grants), but we're more than happy to share that responsibility with anyone who steps up, as has recently happened (baby steps) with the Scala modules that we spun out of the core for this reason. PS: The only things that make me angrier than ant are jenkins and bash. (The build systems you're not angry with are probably the ones you haven't spent enough "quality" time with.) In any case, thanks for persevering with sbt and scala! PPS: I don't think this is an odd route for a small company; how do you make money by developing just a programming language and nothing else?