4 ms·

A very important point for me in Scala is that now I can consider building the company stack with it. The libraries and infrastructure are really getting better

A very important point for me in Scala is that now I can consider building the company stack with it. The libraries and infrastructure are really getting better. We have Play for web applications, Spray, Scalatra and more for APIs, actors / futures / STM / Akka for concurrency, and you can easily intergrate Akka with Play and Spray, use the same patterns at different parts of your infrastructure. We have Scala.js for frontend work. Growing numbers of frameworks for Big Data. Those are maturing and being developed for industry needs, tested in production at some known companies. Don't forget it's based on solid JVM with huge amount of Java libs available. I have confidence to advise building real businesses with Scala stack and not looking like an irresponsible guy who just wants to play with the latest and shiniest stuff hazarding a company's business. I also see how Typesafe is focusing on solving bad parts: compiling time, stability, etc. You can also stay away from advanced / theoretical / crazy parts of Scala most of time. You don't need to use Scalaz, advanced type system features etc. There are also immature libraries, toys and proof-on-concepts, but you cannot blame Scala for your choice.

mason55 13y ago
I'm curious about the fact that you're using both Play & Spray. Are you using them in the same app? It seems like there's a lot of overlap between the two and that by switching to Spray as your backend you'd just be generating static HTML with Play.
- playing_colours 13y ago
  Spray (or Unfiltered at my previous project) is used for a different part of the project. It's basically used on parts where you can expect high load, lots of requests / responses and tight integration with Akka system for processing large amounts of data. Play framework was used to provide UI for our data team or end users to see statistics, do some operations and it's not bombarded by large amound of requests.
  - mason55 13y ago
    Makes sense. I'm building out on Play right now but given that my long-term goal is to have a JS view + REST endpoints I'm still not decided on whether I want to stay on the Play UI/template model or switch to something like Backbone.js + Spray.
- lmm 13y ago
  Spray is the better option for "web API"-type projects, but doesn't have the support for making a frontend UI that Play does. I understand that going forward there is a plan to port Play to run on top of Spray.
copergi 13y ago
>You can also stay away from advanced / theoretical / crazy parts of Scala most of time. The parts that make it worth using in the first place? >You don't need to use Scalaz, advanced type system features etc Might as well stick with java then. You're not getting the benefits of scala vs java, but you are still paying the costs like compile times and poor tool support.
- playing_colours 13y ago
  I didn't experience "poor tool support" with Intellij IDEA. Java performance profiler also worked well, command line too. Maybe I am not very exacting. Sticking with Java you lose both the expressive Scala features and some good frameworks without Java burden. Btw under "advanced parts" I didn't mean "everything above Java". I enjoy immutability, collections, case classes, pattern matching, first class functions, lambdas, terse syntax not considered them "advanced parts". Advanced parts are all those lenses, recursive types, type lambdas, you know.
  - anonymoushn 13y ago
    I used IntelliJ IDEA to write Scala for 2 years. Such complex operations as renaming a variable or getting a list of uses of a trait would frequently be done wrong, so I ended up checking the IDE's work every time. The Java-to-Scala tool emitted code that would never have compiled on any version of the Scala compiler. Using the IDE's auto-import feature would frequently end up importing * from a package, which would cause the file to see the wrong definition of some class name that occurs in multiple packages, so it was important to check the IDE's work even when the only task I gave it was to import a class.
    - bad_user 13y ago
      I used IntelliJ IDEA for about 1 year and I never encountered a single instance in which this IDE got a rename wrong, or a "find usages" for a type. I also never got an importing wildcard to shadow some important definition that I was using from another package and in fact it bugs me that lately I can't get IntelliJ IDEA to do wildcards imports were it can, because I don't like dozens and dozens of imports from the same package. What it does wrong is when copy/pasting code or when moving a class/trait to another file/package, it sometimes misses the imports for the implicits that the code is using. You can't really blame it, since an imported implicit is not hard-wired in the same way an explicit reference or type usage is. Depending on your perspective, this may be a feature and not a bug :-) Either way, IntelliJ IDEA gives awesome in-editor error highlighting and you also have Scala's compiler to double-check things for you, so you really don't have to double-check the IDE's work, except in cases where there are problems. > The Java-to-Scala tool emitted code that would never have compiled on any version of the Scala compiler. It's pretty hard to translate from Java to Scala and you're right that it doesn't work. On the other hand, idiomatic Java code is pretty freaking far from idiomatic Scala code and I think you should either leave that Java code as is (mixed projects are easy to configure) or you should translate it in idiomatic Scala code by hand, a task that no transpiler could do.
namelezz 13y ago
Do you know how to handle compiling time in a large project? I know Twitter uses Scala in prod so there must be a way. I am wondering how they handle that.
- playing_colours 13y ago
  Very good question. At work we didn't do anything special to tackle on this issue. On the microlevel I would consider checking this article http://www.chrisstucchio.com/blog/2014/bondage_and_discipline.html http://www.chrisstucchio.com/blog/2014/bondage_and_disciplin... if it can help. On macrolevel, the obvious thing is that you can separate your projects. I also have some expectations for upcoming Scala release. But that's a really good question to ask anyone from Twitter and Co.
  - namelezz 13y ago
    Awesome. Thank you for the tips.

mason55 13y ago

I'm curious about the fact that you're using both Play & Spray. Are you using them in the same app? It seems like there's a lot of overlap between the two and that by switching to Spray as your backend you'd just be generating static HTML with Play.

playing_colours 13y ago
Spray (or Unfiltered at my previous project) is used for a different part of the project. It's basically used on parts where you can expect high load, lots of requests / responses and tight integration with Akka system for processing large amounts of data. Play framework was used to provide UI for our data team or end users to see statistics, do some operations and it's not bombarded by large amound of requests.
- mason55 13y ago
  Makes sense. I'm building out on Play right now but given that my long-term goal is to have a JS view + REST endpoints I'm still not decided on whether I want to stay on the Play UI/template model or switch to something like Backbone.js + Spray.
lmm 13y ago
Spray is the better option for "web API"-type projects, but doesn't have the support for making a frontend UI that Play does. I understand that going forward there is a plan to port Play to run on top of Spray.

copergi 13y ago

>You can also stay away from advanced / theoretical / crazy parts of Scala most of time. The parts that make it worth using in the first place? >You don't need to use Scalaz, advanced type system features etc Might as well stick with java then. You're not getting the benefits of scala vs java, but you are still paying the costs like compile times and poor tool support.

playing_colours 13y ago
I didn't experience "poor tool support" with Intellij IDEA. Java performance profiler also worked well, command line too. Maybe I am not very exacting. Sticking with Java you lose both the expressive Scala features and some good frameworks without Java burden. Btw under "advanced parts" I didn't mean "everything above Java". I enjoy immutability, collections, case classes, pattern matching, first class functions, lambdas, terse syntax not considered them "advanced parts". Advanced parts are all those lenses, recursive types, type lambdas, you know.
- anonymoushn 13y ago
  I used IntelliJ IDEA to write Scala for 2 years. Such complex operations as renaming a variable or getting a list of uses of a trait would frequently be done wrong, so I ended up checking the IDE's work every time. The Java-to-Scala tool emitted code that would never have compiled on any version of the Scala compiler. Using the IDE's auto-import feature would frequently end up importing * from a package, which would cause the file to see the wrong definition of some class name that occurs in multiple packages, so it was important to check the IDE's work even when the only task I gave it was to import a class.
  - bad_user 13y ago
    I used IntelliJ IDEA for about 1 year and I never encountered a single instance in which this IDE got a rename wrong, or a "find usages" for a type. I also never got an importing wildcard to shadow some important definition that I was using from another package and in fact it bugs me that lately I can't get IntelliJ IDEA to do wildcards imports were it can, because I don't like dozens and dozens of imports from the same package. What it does wrong is when copy/pasting code or when moving a class/trait to another file/package, it sometimes misses the imports for the implicits that the code is using. You can't really blame it, since an imported implicit is not hard-wired in the same way an explicit reference or type usage is. Depending on your perspective, this may be a feature and not a bug :-) Either way, IntelliJ IDEA gives awesome in-editor error highlighting and you also have Scala's compiler to double-check things for you, so you really don't have to double-check the IDE's work, except in cases where there are problems. > The Java-to-Scala tool emitted code that would never have compiled on any version of the Scala compiler. It's pretty hard to translate from Java to Scala and you're right that it doesn't work. On the other hand, idiomatic Java code is pretty freaking far from idiomatic Scala code and I think you should either leave that Java code as is (mixed projects are easy to configure) or you should translate it in idiomatic Scala code by hand, a task that no transpiler could do.

namelezz 13y ago

Do you know how to handle compiling time in a large project? I know Twitter uses Scala in prod so there must be a way. I am wondering how they handle that.

playing_colours 13y ago
Very good question. At work we didn't do anything special to tackle on this issue. On the microlevel I would consider checking this article http://www.chrisstucchio.com/blog/2014/bondage_and_discipline.html http://www.chrisstucchio.com/blog/2014/bondage_and_disciplin... if it can help. On macrolevel, the obvious thing is that you can separate your projects. I also have some expectations for upcoming Scala release. But that's a really good question to ask anyone from Twitter and Co.
- namelezz 13y ago
  Awesome. Thank you for the tips.