4 ms·

Wow! When I started working with Scala, I realized that its actor model was sort of like Erlang, but missing stuff like the supervisor tree which is rather usef

Wow! When I started working with Scala, I realized that its actor model was sort of like Erlang, but missing stuff like the supervisor tree which is rather useful. So I looked around, and discovered Akka. Shortly afterwards, Typesafe was formed by merging the groups creating Scala and creating Akka. Then, my company was moving towards a services oriented architecture that used the HTTP api as its core for accessing services. I felt that this was inefficient, especially because you couldn`t do any message queuing or event related stuff without layering it over the top of HTPP`s RPC calls. That seemed counterintutive because fire and forget messaging is a more fundamental construct than RPC. Then I discovered Spray which had already done a lot of the groundwork needed to have an HTTP composition technique for services, plus it even had a more efficient HTTP server to use when you needed to allow for HTTP RPC. And now, Typesafe has joined with Spray. This is making Scala look more and more like THE Java successor. Clojure is still a strong contender, but the Typesafe activities have really pushed Groovy out of the ring, as well as things like JRuby and Jython. I doubt that Java will ever go away, but I can see that Scala and/or Clojure will eventually supercede Java as the main development language for the JVM. And this is important because the JVM is showing signs of moving into the dominant position in the new world of massive multicore. It may never muscle out things like Erlang/Elixir or Python, but it will probably be the core dominant platform of this century.

ryanobjc 13y ago
Scala shows a lot of promise for certain. The big challenge to Scala will be Java 8. The basic problem is that Scala is too complex. Having written production code in Scala before, I am unlikely to do so again due to code complexity reasons. And we avoided all the trendy Scala stuff (akka, sbt, DSLs, etc)
- danieldk 13y ago
  Scala's complexity is a serious problem. I once overheard a conversation between two people (one of them family) who implemented a 'binding' for a distributed key-value store in Scala. One complained that he couldn't even understand the other person's code. The difference: one library treated Scala as a Java with classes, while the other was written in a very functional style using Scalaz. That complexity (or different flavors if you will) has also been a reason for me to stop writing Scala. I don't want to leave behind maintenance hells for whoever has to modify my code in five years. Java may be verbose, but its simplicity (if you avoid the big frameworks) and standardisation (JAX-RS, etc.) does help to keep things understandable and predictable. That said, I do use Akka a lot and like the Typesafe Console. Other than that, I am keeping a distance for now, and put my bets on Java 8 or Kotlin.
  - Dewie 13y ago
    > Scala's complexity is a serious problem. I once overheard a conversation between two people (one of them family) who implemented a 'binding' for a distributed key-value store in Scala. One complained that he couldn't even understand the other person's code. The difference: one library treated Scala as a Java with classes, while the other was written in a very functional style using Scalaz. I guess that's a predictable consequence of the design goal of "scalable language". Scalable to the point that people should be able to mold the language in ways that the language designers hadn't foreseen (though in this case the two styles are the two styles that the language was designed to accommodate from the get-go). Maybe people should treat it as a language with many dialects which has the benefit of having a unified ecosystem, instead of having one ecosystem for every dialect.
  - eweise 13y ago
    I know what you mean since I develop in Scala for a living. I wonder though if the complexity isn't with Scala itself but rather the abstractions that are created to enable functional style programming. I recently bought the Oreilly functional javascript book and the code also looked complicated once the author introduced unfamiliar abstractions such as trampolines.
  - memracom 13y ago
    Scala's complexity is an issue, but I would not characterize it as a big problem. In any organization that adopts Scala, you should have a coding style guide that explains what kinds of constructs are allowed. Start it out with nothing more than Java with less redundancy and then add one thing at a time, making sure that the whole team understands the construct, when to use it, and when it is overkill. The idea is to evolve your way to functional style code rather than dropping it on people's heads from day one. This requires some restraint from senior developers and it requires them to spend more time on educating internally than on coding a masterpiece. Same thing goes with Akka, start small with a simple Actor System with a supervisor tree no more than two levels. Then work your way step by step into more complex solutions where people will recognize the value of a supervisor tree. Expose the inner workings either by implementing message monitoring in Scala or by diverting the message flow externally to RabbitMQ brokers where you can more easily tap and monitor the message flow.
smrtinsert 13y ago
I don't think Scala and clojure are in competition. I perceive Scala as a practical enhancement for Java built for performance and maintainability/tooling. I see Clojure as more of an architects language, great for high level exploration of ideas. I'm learning both and really like both. I do wish that clojurescript was as easily developed as clojure is. I think scala-js seems to be the stronger of the ->js projects. Scala-js now also supports the closure compiler which makes for nice small distributions; this is compelling in the age of html5.
- brandonbloom 13y ago
  > I think scala-js seems to be the stronger of the ->js projects What makes you say that? (I'm a CLJS contributor. Just want to help improve it)
  - smrtinsert 13y ago
    I'm slightly biased in that I've played with cljs more than scala-js, but it was tough to find a productive workflow from the time I started looking into it. For example with lein-droid you run a lein command to start the android app with embedded repl and connect to it, with seesaw you can use your local repl, with clojurescript ??? Instead there seemed to be a whirlwind of finding info on lein-cljsbuild/cljs and dealing with little problems like the repl not finding jarred or external js files. also online theres all sorts of grumbles about browser repl instability so it gives you a big warning feeling even though it seems like the only way through. Ultimately I felt lost in the tooling and setup. I haven't had time to investigate clojurescript in lighttable, maybe its easier there. I just figured any editors repl and the source files should be all you need to start working productively with it. By contrast I haven't done much scalajs yet, but it builds like just another sbt project (after a local install of the scala-js project itself). I was able to clone the sample scala-js app run sbt;/packageJS and see the js file. Sure that's not updating live, but its clean and straightforward from the first time you investigate it. 5-10 minutes to "wow". Good luck, I really want clojurescript to become easier to use as I really enjoy clojure.
    - 13y ago

ryanobjc 13y ago

Scala shows a lot of promise for certain. The big challenge to Scala will be Java 8. The basic problem is that Scala is too complex. Having written production code in Scala before, I am unlikely to do so again due to code complexity reasons. And we avoided all the trendy Scala stuff (akka, sbt, DSLs, etc)

danieldk 13y ago
Scala's complexity is a serious problem. I once overheard a conversation between two people (one of them family) who implemented a 'binding' for a distributed key-value store in Scala. One complained that he couldn't even understand the other person's code. The difference: one library treated Scala as a Java with classes, while the other was written in a very functional style using Scalaz. That complexity (or different flavors if you will) has also been a reason for me to stop writing Scala. I don't want to leave behind maintenance hells for whoever has to modify my code in five years. Java may be verbose, but its simplicity (if you avoid the big frameworks) and standardisation (JAX-RS, etc.) does help to keep things understandable and predictable. That said, I do use Akka a lot and like the Typesafe Console. Other than that, I am keeping a distance for now, and put my bets on Java 8 or Kotlin.
- Dewie 13y ago
  > Scala's complexity is a serious problem. I once overheard a conversation between two people (one of them family) who implemented a 'binding' for a distributed key-value store in Scala. One complained that he couldn't even understand the other person's code. The difference: one library treated Scala as a Java with classes, while the other was written in a very functional style using Scalaz. I guess that's a predictable consequence of the design goal of "scalable language". Scalable to the point that people should be able to mold the language in ways that the language designers hadn't foreseen (though in this case the two styles are the two styles that the language was designed to accommodate from the get-go). Maybe people should treat it as a language with many dialects which has the benefit of having a unified ecosystem, instead of having one ecosystem for every dialect.
- eweise 13y ago
  I know what you mean since I develop in Scala for a living. I wonder though if the complexity isn't with Scala itself but rather the abstractions that are created to enable functional style programming. I recently bought the Oreilly functional javascript book and the code also looked complicated once the author introduced unfamiliar abstractions such as trampolines.
- memracom 13y ago
  Scala's complexity is an issue, but I would not characterize it as a big problem. In any organization that adopts Scala, you should have a coding style guide that explains what kinds of constructs are allowed. Start it out with nothing more than Java with less redundancy and then add one thing at a time, making sure that the whole team understands the construct, when to use it, and when it is overkill. The idea is to evolve your way to functional style code rather than dropping it on people's heads from day one. This requires some restraint from senior developers and it requires them to spend more time on educating internally than on coding a masterpiece. Same thing goes with Akka, start small with a simple Actor System with a supervisor tree no more than two levels. Then work your way step by step into more complex solutions where people will recognize the value of a supervisor tree. Expose the inner workings either by implementing message monitoring in Scala or by diverting the message flow externally to RabbitMQ brokers where you can more easily tap and monitor the message flow.

smrtinsert 13y ago

I don't think Scala and clojure are in competition. I perceive Scala as a practical enhancement for Java built for performance and maintainability/tooling. I see Clojure as more of an architects language, great for high level exploration of ideas. I'm learning both and really like both. I do wish that clojurescript was as easily developed as clojure is. I think scala-js seems to be the stronger of the ->js projects. Scala-js now also supports the closure compiler which makes for nice small distributions; this is compelling in the age of html5.

brandonbloom 13y ago
> I think scala-js seems to be the stronger of the ->js projects What makes you say that? (I'm a CLJS contributor. Just want to help improve it)
- smrtinsert 13y ago
  I'm slightly biased in that I've played with cljs more than scala-js, but it was tough to find a productive workflow from the time I started looking into it. For example with lein-droid you run a lein command to start the android app with embedded repl and connect to it, with seesaw you can use your local repl, with clojurescript ??? Instead there seemed to be a whirlwind of finding info on lein-cljsbuild/cljs and dealing with little problems like the repl not finding jarred or external js files. also online theres all sorts of grumbles about browser repl instability so it gives you a big warning feeling even though it seems like the only way through. Ultimately I felt lost in the tooling and setup. I haven't had time to investigate clojurescript in lighttable, maybe its easier there. I just figured any editors repl and the source files should be all you need to start working productively with it. By contrast I haven't done much scalajs yet, but it builds like just another sbt project (after a local install of the scala-js project itself). I was able to clone the sample scala-js app run sbt;/packageJS and see the js file. Sure that's not updating live, but its clean and straightforward from the first time you investigate it. 5-10 minutes to "wow". Good luck, I really want clojurescript to become easier to use as I really enjoy clojure.
  - 13y ago