Typesafe acquires Spray.io | Hacker News Reader

Typesafe acquires Spray.io

marketwired.com

74 pointsocto_t22 comments

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.

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)

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.

> 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.

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.

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.

What about libraries? What if you have to start trying to understand what's going on in Slick? I had two friends who were pairing and were trying to figure out how to get something done. They are both strong java developers and both had scala experience. However, they started diving in and got lost in even understanding what was going on.

I believe it was Dijkstra that said (paraphrasing) source code is meant to communicate to humans first and only incidentally machines.

I've seen this, too, but Scala's complexity does become more manageable with time. Slick seems to make a trade-off for a very nice API, at the cost of complex underlying code — which you sometimes need to understand when you want to use Type mappers and such.

There's several Scala libraries that are on the border of "too clever". One is Play's Iteratees: it's a really nice concept, they take a few days to wrap your mind around. Trying to get a Java programmer to understand them borders on a lost cause.

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.

> 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)

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.

cljs-build is very good for non-interactive workflows, but I agree that the REPL situation is less than ideal. I mostly develop in a CLJ REPL and then only test in the browser with auto-refresh, in a more traditional web-app style.

The browser REPL is the biggest offender, but luckily there is now https://github.com/cemerick/austin which is a huge improvement in usability, stability, and features. Give that a try!

I think it is really interesting how Typesafe is basically acquiring everything good/interesting in the Scala space. It makes for a very different ecosystem than say ruby or clojure or go.

I think this is actually a good approach for making Scala something that larger companies will rely on, while benefitting smaller shops and individual developers.

Now, if only Typesafe would either build or buy a scala compiler that is as fast as go's. If they did, I would be a scala developer like yesterday.

The most interesting things in the Scala space are at http://typelevel.org.

The Scala space is somewhat divided, I'd say.

I think that's impossible. One of the reasons Google developed Go was to be able to compile its large code base quickly. Compilation speed was built into the language from the beginning. Meanwhile, Scala continues to add every feature under the sun without a thought to compilation speed. I can't see them removing enough language features to improve compilation speed enough to catch up to Go (although I wish they would).

> I can't see them removing language features to improve compilation speed (although I wish they would).

That's why Scala 2.11 removes features from the core compiler.

http://docs.scala-lang.org/scala/2.11/

it's a bandaid

I often wonder if Typesafe has lost focus -- take their relatively new Typesafe Activator product bundle. It comes with its own flimsy web-based editor instead of a proper IDE, while Typesafe is investing in the Scala IDE Eclipse plugin at the same time. Same counts for some basics -- library versioning/compatibility in Scala is still a huge mess, and same thing can be said for the compiler's performance (especially combined with an IDE).

On the other hand, I do hope the Spray acquisition will improve the Typesafe stack, especially Play: it can really use some of Spray's patterns and its high performance.

Spray fits nicely in with Akka and I expect HTTP to just become another Akka feature (the way the new IO is, which included assistance from Spray devs IIRC). I wouldn't be surprised to see https://github.com/eligosource/eventsourced moved into Akka more directly at some point too.

That is already happening. We are moving Eventsourced into Akka to become "akka-persistence":

https://groups.google.com/forum/#!msg/eventsourced/B2Nx4HJB-...

Typesafe continues to show that they understand the needs of the scala development community. I couldn't be more impressed with their work. Furthermore, their great work basically makes it impossible to work with anything not supported by typesafe, because everything else will eventually become unsupported.

Reply on news.ycombinator.com