7 ms·

Was excited to check out Linkedin using Play but then the reasons highlighted in the article almost let me down. I am comparing to Python frameworks and Node a

by ratpik 14y ago

Was excited to check out Linkedin using Play but then the reasons highlighted in the article almost let me down. I am comparing to Python frameworks and Node and everything mentioned there has been available in the Python stack for a while and now Node (extra points for realtime websockets stuff). As per the post Play boasts of: Rapid iteration, Reactive (only for the server not the client), Open, Supported, Flexible, Java & Scala Maybe I would consider Java & Scala just for the enterprise community scale but definitely not the only one for functional paradigms or rapid iterations. Everything else is there in other modern web frameworks in Python, Javascript & even perhaps Ruby. Probably a new thing for Java but why the choice? Is LinkedIn constrained to use the JVM?

ikailan 14y ago
LinkedIn isn't constrained to the JVM, as they had some apps running on CRuby 1.8 and node.js, but they do heavily favor the JVM. JVM interop DOES help with much of their existing codebase which is Java heavy.
- ratpik 14y ago
  Yeah I agree to interoperability. Makes it much simpler to have the same Java stack across the distribution. Either way, that's a big boost to Play framework!
  - ikailan 14y ago
    It's been a while, but there was a lot of use of Groovy on Grails a few years ago for exactly this reason. I was a strong advocate of JRuby when we did run Ruby code, but it didn't get very far.
dxbydt 14y ago
>... Scala...definitely not for functional paradigms I am sorry, what ?
- ratpik 14y ago
  Typed out too soon. Meant it is a good reason but not the only language with that reason unless you wish to stick to the JVM.
- chimeracoder 14y ago
  I could probably copy-paste this comment from any one of the many other Scala discussions where this has come up, but in short: Scala isn't functional; Scala is proper (pure) OO in a way that Java never was. Scala doesn't support top-level functions (only singleton objects), which doesn't exactly prevent it from being functional, but certainly suggests that the primary paradigm is still object-orientation. It just so happens that pure OO, when properly done, happens to embody a lot of features similar to functional programming - Smalltalk is the easiest example of this (eg. the similarities between Smalltalk message passing and Haskell's implicit currying are very clear). The reason for this is that it's trivial to create a good object system in a purely functional language, so the FP-OO relationship isn't an either-or so much as a 'special case' (ie, OO can be seen as a 'special case' of FP). The converse isn't so true; it's hard and clumsy to build a truly functional paradigm within an OO paradigm. What GP probably meant is that Scala isn't a good choice for those who are coming from an FP background, since they'll likely notice that Scala seems very OO by comparison (because it is). Even on the JVM, there are other languages (ie, Clojure) which embody functional paradigms more transparently. On the other hand, Scala is a decent choice for OO programmers who want to get a taste of functional programming (or who want to incorporate those paradigms into their code), because Scala allows several aspects of the FP paradigm to come through as well.
  - slurgfest 14y ago
    Is there any objective basis for saying that Clojure is "better" than Scala?
    - chimeracoder 14y ago
      Not "better" as a language - "better" at exhibiting functional paradigms more transparently. I've fixed the wording.
brown9-2 14y ago
Probably a new thing for Java Not really. I don't see what features Play Framework has that are revolutionary or things that no other framework running on the JVM/Java wasn't able to do before. "Rapid iteration" is the kind of "feature" that every framework claims to allow. No one advertises they allow "slow iteration".
- slurgfest 14y ago
  To be fair, if a framework was totally uninterested in fast iteration or couldn't even remotely claim it, then they would simply say nothing rather than offering "slow iteration".
- eloisant 14y ago
  I believe The biggest differentiator in Play 2 is the reactive programming. Even if you look outside the JVM, NodeJS is the only other web framework providing that level of non-blocking http. Rapid iteration is probably obvious for PHP, Rails or Django, but on the JVM (or .net), it's pretty rare to see a framework that really supports it well.
  - brown9-2 14y ago
    The JVM has plenty of non-blocking IO available - what do you think Play's support of it is built on top of? See Netty, for example.
    - platypii 14y ago
      Right, but that's what I like about Play. They took Netty, and they took Akka and all the other really nice reactive stuff and integrated it very cleanly. With Akka you get most of the concurrency benefits you would get from a language like Erlang, but with the benefits of having access to the entire JVM ecosystem.
brikis98 14y ago
LinkedIn is primarily a JVM shop. We believe that type-safe languages like Java and Scala are a good choice for building performant and reliable systems that scale to huge numbers of users as well as huge numbers of developers. We aren't constrained to the JVM - for example, we use node.js for our mobile server - but it has significant advantages and we have years of investment in it. Unfortunately, we found developer productivity in the Java/Scala world to be a huge problem. We also found that most Java/Scala web stacks, based on servlets, were far behind other web frameworks (RoR, Django, etc) in terms of keeping up with the requirements of modern web development. Play helps on both fronts: it dramatically improves developer productivity and handles all the requirements of a modern web stack (MVC, web sockets, powerful routing, easy JSON handling, DRY form handling, etc). Is it better than RoR, Django, Node? In some ways yes (e.g. Play's reactive programming model is dramatically better than JavaScript's callback mess), in some ways no (e.g. it's hard to compete with dynamic/interpreted languages for pure reload time). Is it better than everything else in the Java/Scala world? We think so.
- smrtinsert 14y ago
  Developer productivity is really broad. Can you elaborate? Most modern webapps I work on end up as json services and the backend are just java pojo services that can be unit and int tested - tdd with java is extremely fast in my experience. the whole servlets/jsp/jsf thing is dead imo, is that where you guys were losing time?
  - chaostheory 14y ago
    If I were to guess, it would be configuration, more specifically the myriad number of choices and combinations of it. Spring's strength and weakness is the power of customizing it.
  - brikis98 14y ago
    We had Java services that produced JSON, some that used JSPs, and a variety of others. TDD works in some cases, but if you ever wanted to do manual testing - for example, actually see the UI you were working on with real data - that meant redeploying the server after every change. Play makes this dramatically faster/easier. TDD is better with Play as well: the plugin support, strong test tools, and sbt's ~test command are amazingly productive.

by ratpik 14y ago

ikailan 14y ago

LinkedIn isn't constrained to the JVM, as they had some apps running on CRuby 1.8 and node.js, but they do heavily favor the JVM. JVM interop DOES help with much of their existing codebase which is Java heavy.

ratpik 14y ago
Yeah I agree to interoperability. Makes it much simpler to have the same Java stack across the distribution. Either way, that's a big boost to Play framework!
- ikailan 14y ago
  It's been a while, but there was a lot of use of Groovy on Grails a few years ago for exactly this reason. I was a strong advocate of JRuby when we did run Ruby code, but it didn't get very far.

dxbydt 14y ago

>... Scala...definitely not for functional paradigms I am sorry, what ?

ratpik 14y ago
Typed out too soon. Meant it is a good reason but not the only language with that reason unless you wish to stick to the JVM.
chimeracoder 14y ago
I could probably copy-paste this comment from any one of the many other Scala discussions where this has come up, but in short: Scala isn't functional; Scala is proper (pure) OO in a way that Java never was. Scala doesn't support top-level functions (only singleton objects), which doesn't exactly prevent it from being functional, but certainly suggests that the primary paradigm is still object-orientation. It just so happens that pure OO, when properly done, happens to embody a lot of features similar to functional programming - Smalltalk is the easiest example of this (eg. the similarities between Smalltalk message passing and Haskell's implicit currying are very clear). The reason for this is that it's trivial to create a good object system in a purely functional language, so the FP-OO relationship isn't an either-or so much as a 'special case' (ie, OO can be seen as a 'special case' of FP). The converse isn't so true; it's hard and clumsy to build a truly functional paradigm within an OO paradigm. What GP probably meant is that Scala isn't a good choice for those who are coming from an FP background, since they'll likely notice that Scala seems very OO by comparison (because it is). Even on the JVM, there are other languages (ie, Clojure) which embody functional paradigms more transparently. On the other hand, Scala is a decent choice for OO programmers who want to get a taste of functional programming (or who want to incorporate those paradigms into their code), because Scala allows several aspects of the FP paradigm to come through as well.
- slurgfest 14y ago
  Is there any objective basis for saying that Clojure is "better" than Scala?
  - chimeracoder 14y ago
    Not "better" as a language - "better" at exhibiting functional paradigms more transparently. I've fixed the wording.

brown9-2 14y ago

Probably a new thing for Java Not really. I don't see what features Play Framework has that are revolutionary or things that no other framework running on the JVM/Java wasn't able to do before. "Rapid iteration" is the kind of "feature" that every framework claims to allow. No one advertises they allow "slow iteration".

slurgfest 14y ago
To be fair, if a framework was totally uninterested in fast iteration or couldn't even remotely claim it, then they would simply say nothing rather than offering "slow iteration".
eloisant 14y ago
I believe The biggest differentiator in Play 2 is the reactive programming. Even if you look outside the JVM, NodeJS is the only other web framework providing that level of non-blocking http. Rapid iteration is probably obvious for PHP, Rails or Django, but on the JVM (or .net), it's pretty rare to see a framework that really supports it well.
- brown9-2 14y ago
  The JVM has plenty of non-blocking IO available - what do you think Play's support of it is built on top of? See Netty, for example.
  - platypii 14y ago
    Right, but that's what I like about Play. They took Netty, and they took Akka and all the other really nice reactive stuff and integrated it very cleanly. With Akka you get most of the concurrency benefits you would get from a language like Erlang, but with the benefits of having access to the entire JVM ecosystem.

brikis98 14y ago

LinkedIn is primarily a JVM shop. We believe that type-safe languages like Java and Scala are a good choice for building performant and reliable systems that scale to huge numbers of users as well as huge numbers of developers. We aren't constrained to the JVM - for example, we use node.js for our mobile server - but it has significant advantages and we have years of investment in it. Unfortunately, we found developer productivity in the Java/Scala world to be a huge problem. We also found that most Java/Scala web stacks, based on servlets, were far behind other web frameworks (RoR, Django, etc) in terms of keeping up with the requirements of modern web development. Play helps on both fronts: it dramatically improves developer productivity and handles all the requirements of a modern web stack (MVC, web sockets, powerful routing, easy JSON handling, DRY form handling, etc). Is it better than RoR, Django, Node? In some ways yes (e.g. Play's reactive programming model is dramatically better than JavaScript's callback mess), in some ways no (e.g. it's hard to compete with dynamic/interpreted languages for pure reload time). Is it better than everything else in the Java/Scala world? We think so.

smrtinsert 14y ago
Developer productivity is really broad. Can you elaborate? Most modern webapps I work on end up as json services and the backend are just java pojo services that can be unit and int tested - tdd with java is extremely fast in my experience. the whole servlets/jsp/jsf thing is dead imo, is that where you guys were losing time?
- chaostheory 14y ago
  If I were to guess, it would be configuration, more specifically the myriad number of choices and combinations of it. Spring's strength and weakness is the power of customizing it.
- brikis98 14y ago
  We had Java services that produced JSON, some that used JSPs, and a variety of others. TDD works in some cases, but if you ever wanted to do manual testing - for example, actually see the UI you were working on with real data - that meant redeploying the server after every change. Play makes this dramatically faster/easier. TDD is better with Play as well: the plugin support, strong test tools, and sbt's ~test command are amazingly productive.