Bear Bibeault wrote:Two thoughts:
They're locking themselves out from a lot of existing enterprises that aren't going to change their deployment strategies anytime soon. And even small guys -- like the one I'm doing some work for -- that don't have a dedicated IT staff, aren't going to risk moving off something that they know works and is up and running. If I tried to get him to adopt heroku or something similar, he'd think I'd gone crazy.
But that balances with new and upcoming companies that are looking to use the latest bleeding edge stuff. It remains to be seen how all that will shake out.
That's the case with a lot of "cutting edge" software. Eventually if young hip new projects keep picking it up, it'll be the older safer technology in a few years. Yes, some enterprises aren't going to pick it up immediately, but some enterprises are still successful using COBOL. Different organizations have different needs, and Play is targeting a different market for now.
IIRC, someone has adapted play to work within WARs and JEE. I think you could definitely have such a thing, but most likely if you're the same organization that is unwilling to move from JEE containers, you may also have issues moving frameworks. I think these kinds of backports are probably a better way to go for larger adoption than to veer the central core of the framework.
The practical bit, is we're seeing clients pick up and use Play *beside* their JEE applications, even large more conservative organizations. Perhaps the path to success is longer, but hopefully the *life* of the framework is also longer because it's forward thinking.
Bear Bibeault wrote:
Josh Suereth wrote:I'm not certain it'll block *scala* adoption.
But Scala adoption is, in my opinion, most definitely tied to the "killer app" that's going to make people want to use it. It's not going to go much of anywhere just because developers think it's cool. Given the relatively minor foothold that Play has attained, and the general dissatisfaction I hear with Lift, it doesn't exist yet.
I hear a lot of "Scala is the next Java" from a lot of its fans, but few that I know are actually using it for anything but play-ware (small 'p').
What, in your mind, is the compelling use case that's going to make corporate decision-makers allow Scala into the enterprise (big or small)? The enthusiasm of the developers for the language isn't going to count for much in any company except the very small or startup where developers are calling the shots. And those are not the companies that will wag the dog.
I think we may be able to agree to disagree here. I don't see Scala as requiring a killer app. It's powerful enough to compelling *on its own*. Play migrated to an all scala-backend *from* a java/scala backend. Why? Because of the language. Akka is implemented in Scala *because* of the language (although is supports a Java API).
SO here are what I see Scala's killer features *for corporate decision makers*
1. Reduced code size in general. Helps limit the number of bugs just by virtual of having less code (statistical correlation)
2. Improves the development code speed of the "top-tier" programmers (circumstantial evidence)
3. "lower-tier" programmers code abilities/speed *appears* unaffected (circumstantial evidence)
4. Multi-core program is easier in Scala, not because Java can't handle it, but because Scala embraces patterns and defaults that work well with lots of threads. Its libraries take a similar approach. So, while Scala's future's APi can be used in Java, it's far more elegant (and harder to screw up) in Scala. This means on *average* using Scala and its paradigms should help leverage more power from your machines.
5. Type safety. Unlike dynamically-typed languages, Scala can help a large team maintain a code-bases (refactor safely, etc.) and write less
testing code for similar levels of coverage. This means better working code with less effort. It also means, IDEs can be far more helpful.
Basically, Scala helps improve developer speed, reduce codes (through reduced code size) and push developers towards multi-core friendly paradigms (taking better advantage of hardware).
In terms of the killer *language* features for *developers* (more concrete) -> In order of how important I find them on a daily basis.
1. expression oriented/typeinferred syntax. Everything returns something. The compiler attempts to figure out what, if it can.
2. Pattern matching (A lot of languages fail to have this, and it's be far the most used language feature for me on daily code)
3. Closures (This is less compelling as other languages add them, however the way they exist in Scala is fairly elegant and simple to understand).
4. Collections library. Scala's standard collection library is *WAY* better than any other language I've used in terms of being productive and getting info out of data. Once you learn it, you wont' want to use another.
5. Implicits. Scala's implicit system allows you take the "edge" off an API by allowing defaults to be specified once within a scope and not again until configuration is necessary.
6. traits. Scala allows a limited form of mutliple inheritance, that among some surprising things, allows an encoding of virtual/extension classes that works well with FP code. See "cake" pattern as used by Precog.
7. type system - Scala's type system is more advanced than a lot of other languages. It features the union of some really-tough-to-join ideas. In certain tricky situations, Scala can express some nice behavior that would be rather ugly in "more popular" statically typed languages (like C#/Java).
Of course, this is my opinion and some of the points are "circumstantial" in my experience. Would love to hear your thoughts.