4 ms·

Ok, so here is my response. I'll probably focus a bit on the things you think are not as interesting. Not because I dislike your opinion, or disagree with it,

Ok, so here is my response. I'll probably focus a bit on the things you think are not as interesting. Not because I dislike your opinion, or disagree with it, but because I think it might be interesting to share my view how and why even uninteresting feature X might add value in the end. > Union/Intersection types. Any simplification of the type system with regards to type members. Agree. I think it will be very interesting to see how many ugly LUBs will go away due to that. Also, having first-class support for type lambdas will make some people's lives vastly easier. > Any removal of special XML features. I guess it's the right thing to do, but I'll probably miss that feature ... not sure if it is possible to achieve feature parity with string interpolation. > Any fixing of the travesty that is the collections library. Yes, I agree that a lot of work could be done there. > "The type system will have theoretical foundations that are given by a minimal core calculus." A type system being theoretically sound doesn't interest me. What does this provide me in practice? I think the benefit is that it might free the time of compiler developers, because they might be able to skip the step of figuring out whether code X should compile or not. And if we know the type-system is sound, the chance of having code that throws ClassCastExceptions in unexpected places gets smaller. But I guess the main benefit is easier reasoning, both for language developers and language users, which leads to less edge cases and feature interactions down the road. > Macros/Reflection (not that it isn't actually important, but unless Macros are central to your paradigm like in Lisp, they are a hack, who cares how hacky they are). I'll come back to this in a minute. > Things that are missing: Structs. Structs. Real f'n Structs (granted this may be a JVM limitation but I'd trade nearly everything for them). Absolutely agree on that. But this really depends on the VM, there is not much Scala can do to work around the lack of value types (see the limitations of AnyVal). I really hope Oracle manages to ship those things with JDK 10. > Because the only reason I can think of for having giant sized tuples is in a code generation scheme most likely for an ORM system. Code generation in an ORM system is generally a bad idea and it bothers me that an ORM system seems to have the ear of the language designers. ORMs are the vietnam of computer science, but I think that the need to represent properties of a database in code is not restricted to just ORMs. Especially when you have multiple consumers of databases, it's often hard to correct the database schema without having to touch multiple projects in different languages for different customers. I don't see that having better tuples would be a crutch to get around bad database design. I think that especially with first-class union and intersection types, better tuples will get vastly more useful and will reduce the current fragmentation in the library space (tuples vs. HLists, etc.). > [...] I would much prefer that the defacto standard was removed so that any solutions they came up with in the tooling space were of necessity workflow agnostic. I think this is the huge opportunity macros give us. Eugene Burmako gave a talk recently about scala.meta and one of his examples was showing how people can build IDE-independent rewriting, reformatting and refactoring functionality using Scala's macro features. > The single most important next step for the Scala community is to come up with an idiomatic style. Agree. While a lot still needs to happen here, I think there was quite some progress in the last years. From my point of view it seems as if the style of Scala code out there is slowly converging. While the adoption of the recommendations in the style guide was good in my opinion, I think the upcoming framework for configuring compiler warnings and the possibilities of scala.meta to build "go fix" like tools will certainly make an impact. > Finally, Typesafe the company and Scala the community need clearer boundaries. Agree. From what I have heard, I think the right people are aware of these concerns now. > It is troubling to me that the Akka/Play/Sbt/Slicks of the world get obvious preferential treatment when it comes to language prioritization. Can you expand on that?

kasey_junk 12y ago
By picking tacit standards for the messaging, web, build, orm stacks etc Typesafe introduces a chilling effect on other projects in those functional spaces. This chilling effect causes there to be less choice and competition which causes quality degradation in the long term. For instance, I don't think sbt would have survived it's dreadful beginnings if it weren't for the tacit backing of the core Scala team and to be honest I think the Scala community would have been better off with sbt dying young. Further, by assuming that those stacks are the tacit standards it decreases the diversity of opinions for the language designers to hear about how the community is using their language. For instance Play is very opinionated about how web projects should be created. But it isn't actually the only way people are using Scala for web deployments. Further, once the core team starts to assume that people are using those stacks they can fob off problems onto them instead of centrally fixing the root cause problems. Compile times and sbt's incremental compilation support is an obvious example of this. Finally, just my own opinion is that they've drawn the lines about what will be Typesafe and what will be "the community" in weird places. Refactoring tools seem like a very central requirement of the language yet that is left to the community. An ORM on the other hand has been elevated.
- adriaanm 12y ago
  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

By picking tacit standards for the messaging, web, build, orm stacks etc Typesafe introduces a chilling effect on other projects in those functional spaces. This chilling effect causes there to be less choice and competition which causes quality degradation in the long term. For instance, I don't think sbt would have survived it's dreadful beginnings if it weren't for the tacit backing of the core Scala team and to be honest I think the Scala community would have been better off with sbt dying young. Further, by assuming that those stacks are the tacit standards it decreases the diversity of opinions for the language designers to hear about how the community is using their language. For instance Play is very opinionated about how web projects should be created. But it isn't actually the only way people are using Scala for web deployments. Further, once the core team starts to assume that people are using those stacks they can fob off problems onto them instead of centrally fixing the root cause problems. Compile times and sbt's incremental compilation support is an obvious example of this. Finally, just my own opinion is that they've drawn the lines about what will be Typesafe and what will be "the community" in weird places. Refactoring tools seem like a very central requirement of the language yet that is left to the community. An ORM on the other hand has been elevated.

adriaanm 12y ago
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.