Persuade me to keep Scala

[SamS]

Hi All.

For the past 2 weeks I have been evaluating scala as a "full stack" solution at work. What I mean by that is that I have used Scala successfully in the past in mixed java/scala projects using maven, where I have written maybe 20% of the code in Scala, purely because I like the language and its conciseness over Java.

Recently I convinced the CTO to let us develop our new (greenfield) flagship product purely in Scala. I've spent 2 weeks now putting the infrastructure in place / bootstrapping the project. And I'm about to give up. As a last ray of hope I need some coxing and back rubbing and the clever minds here to tell me all the following problems are just me being stupid. Otherwise I worry that I cannot justify moving all 10 developers over next week.

1. SBT. Simple? Please rename it to ComplicatedBuildTool in 0.14 so at least you know what to expect because its anything but simple :) I've spent probably 2 days just learning this and trying to configure it to work in a multi module way, and just when I was satisfied I had it all good, sbteclipse doesn't play nice with play's eclipsify. Arghhh.
2. Binary compatibility. I'm sure some people don't care but right now I have some dependencies that require 2.10 and others that won't work in 2.10. So I have had to dump off casbah (mongo driver), Jackson (the scala module won't work). I'm now using the Java mongo driver and writing my own wrappers. I'm using Jackson without the Scala modules and sticking with Arrays only in my domain objects. Doesn't anyone see binary compatibility as a major issue? I think Java takes it too far but I don't think Scala yet has the size of community to be changing these things between versions because lots of projects are too small right now to be maintaining multiple versions.
3. The drift away from "standard" java deployment. Maybe I'm looking in the wrong places, but the frameworks that have grabbed my attention all do configuration and deployment in their own way. Specifically, neither play nor spray deploy in a standard WAR format (or maybe they can and I've missed it? - I know spray can run on top of a servlet container actually). Maybe you'll argue WAR's are crap, or this way allows faster, lower level frameworks, but it's throwing away all the learned knowledge and standard deployment practices.

On the plus side, the scala-ide nightlies are getting better and better and for "day to day" development I am now very contented.

Any advice? I worry that Scala (well specifically the frameworks around it) are just too complicated for average developers like me.

[Nils Kilden-Pedersen]

On Thu, Nov 15, 2012 at 11:49 AM, SamS <samsp...@gmail.com> wrote:

1. SBT. Simple? Please rename it to ComplicatedBuildTool in 0.14 so at least you know what to expect because its anything but simple :) I've spent probably 2 days just learning this and trying to configure it to work in a multi module way, and just when I was satisfied I had it all good, sbteclipse doesn't play nice with play's eclipsify. Arghhh.

I'm using Ant, because I knew it and didn't have the time to spend learning SBT. 

1. Binary compatibility. I'm sure some people don't care but right now I have some dependencies that require 2.10 and others that won't work in 2.10. So I have had to dump off casbah (mongo driver), Jackson (the scala module won't work). I'm now using the Java mongo driver and writing my own wrappers. I'm using Jackson without the Scala modules and sticking with Arrays only in my domain objects. Doesn't anyone see binary compatibility as a major issue? I think Java takes it too far but I don't think Scala yet has the size of community to be changing these things between versions because lots of projects are too small right now to be maintaining multiple versions.

"Don't do that". Seriously, it's a slight hassle, but just stick with the right version numbers. I'm on 2.9 and probably will be for quite a while.

 

1. The drift away from "standard" java deployment. Maybe I'm looking in the wrong places, but the frameworks that have grabbed my attention all do configuration and deployment in their own way. Specifically, neither play nor spray deploy in a standard WAR format (or maybe they can and I've missed it? - I know spray can run on top of a servlet container actually). Maybe you'll argue WAR's are crap, or this way allows faster, lower level frameworks, but it's throwing away all the learned knowledge and standard deployment practices.

I'm using Scalatra, which currently is just a nicer syntax around servlets, and deploying on Jetty.

 

On the plus side, the scala-ide nightlies are getting better and better and for "day to day" development I am now very contented.

Any advice? I worry that Scala (well specifically the frameworks around it) are just too complicated for average developers like me.

It's not, but you have to control yourself somewhat. Stick with one version and pick the right libraries and you should be fine.

 

[Erik Osheim]

On Thu, Nov 15, 2012 at 09:49:06AM -0800, SamS wrote:
> 1. SBT. Simple? Please rename it to ComplicatedBuildTool in 0.14 so at

> least you know what to expect because its anything but simple :) I've spent
> probably 2 days just learning this and trying to configure it to work in a
> multi module way, and just when I was satisfied I had it all good,
> sbteclipse doesn't play nice with play's eclipsify. Arghhh.

That's a good point to make... since Typesafe is encouraging people to
use SBT and Play it would make sense for them to figure out a way for
those to interact (or at least warn people). I haven't used sbteclipse
or eclipsify so I can't really comment though.

> 2. Binary compatibility. I'm sure some people don't care but right now I

> have some dependencies that require 2.10 and others that won't work in
> 2.10. So I have had to dump off casbah (mongo driver), Jackson (the scala
> module won't work). I'm now using the Java mongo driver and writing my own
> wrappers. I'm using Jackson without the Scala modules and sticking with
> Arrays only in my domain objects. Doesn't anyone see binary compatibility
> as a major issue? I think Java takes it too far but I don't think Scala yet
> has the size of community to be changing these things between versions
> because lots of projects are too small right now to be maintaining multiple
> versions.

I don't think this is a fair criticism. 2.10 isn't even released yet,
so of course you can't assume that all your dependencies will be
available there. Maybe there were some great new features or libraries
you felt you couldn't pass up in 2.10 (I have certainly released some
2.10-only stuff) but part of using 2.10 right now is accepting the bad
with the good.

> 3. The drift away from "standard" java deployment. Maybe I'm looking in

> the wrong places, but the frameworks that have grabbed my attention all do
> configuration and deployment in their own way. Specifically, neither play
> nor spray deploy in a standard WAR format (or maybe they can and I've
> missed it? - I know spray can run on top of a servlet container actually).
> Maybe you'll argue WAR's are crap, or this way allows faster, lower level
> frameworks, but it's throwing away all the learned knowledge and standard
> deployment practices.

This is a great question to bring to the Play and Spray folks directly.
While I personally prefer to avoid things like Tomcat they are
certainly something that a lot of Java developers understand and want
to use.

Personally I think the Scala experience is getting better, and that it
would be a mistake to back off. If trying to use 2.10.0-RC2 is too
difficult then I'd recommend dropping down to 2.9.2 and waiting until
2.10.0 releases and all your deps are updated to it.

And don't sell yourself short... everyone hits this kind of pain when
getting a project started!

Good luck,

-- Erik

[Sam (Stephen Samuel)]

I take the point about 2.10. I'm using it because some dependency (I forget which) that I couldn't do without needed it. I'm going to drop back to 2.9.2 right now and take it from there.

I'm also going to ditch play I think, if it cannot work with sbteclipse it is no use to me. But now I need a replacement for play, and not lift.

--
-Sam

[Vlad Patryshev]

mvn+2.9.2 seems to be a pretty safe choice as of today.

Thanks,
-Vlad

[Adam Crain]

Two points which may be relevant:

1) If you have to avoid Lift/Play, Wicket benefits nicely from Scala.

2) I tend to use the scala-maven-plugin with most of my projects because of the limitless plugin support. XML hell, but sometimes the devil you know is a safer choice.

good luck,

Adam

[Oliver Ruebenacker]

Hello,

If you don't like any the Scala-targeted web frameworks, I suppose
you could build a Scala application on top of a Java framework such as
Java Server Faces.

Take care
Oliver

On Thu, Nov 15, 2012 at 1:16 PM, Sam (Stephen Samuel)
<samsp...@gmail.com> wrote:

--
IT Project Lead at PanGenX (http://www.pangenx.com)

"Stagnation and the search for truth are always opposites." - Nadezhda
Tolokonnikova

[Rex Kerr]

On Thu, Nov 15, 2012 at 12:49 PM, SamS <samsp...@gmail.com> wrote:

Hi All.

For the past 2 weeks I have been evaluating scala as a "full stack" solution at work. What I mean by that is that I have used Scala successfully in the past in mixed java/scala projects using maven, where I have written maybe 20% of the code in Scala, purely because I like the language and its conciseness over Java.

Recently I convinced the CTO to let us develop our new (greenfield) flagship product purely in Scala.

Er, wait, why?  You have a bunch of Java developers, yes?  So they know Java well (in addition to Scala).

Why not develop using as much Scala as makes sense, and as much Java as makes sense?  (And as much C++ as makes sense, and as much Python as makes sense, and as much Bash shell as makes sense, etc. etc..)

It seems to me that the key concession from the CTO is a commitment that Scala development expertise will be maintained at an adequate level to support and improve the bulk of the code, and you've already won there.  So just use Scala where you get the biggest advantage, and if it starts becoming a major liability, use Java instead, or code in Scala but use Java libraries.  (Using Java libraries from Scala is easier than using Java libraries from Java most of the time.)

For instance, if SBT is hard to learn, use Maven.  (Play + SBT problem solved, also; unless Eclipse-without-SBT is useless.)  If X, whatever X is, requires Scala 2.10, drop it and use the Java equivalent and Scala 2.9.

(Also, you shouldn't need to maintain multiple versions of Scala projects since Scala is pretty conservative about what JVM it targets.  So all you need to do is decide when you can upgrade everything, and then go for it.  For deployment, Scala just looks like another of many libraries.)

  --Rex


 

[Juha Heljoranta]

On Thursday, November 15, 2012 09:49:06 SamS wrote:
> 1. SBT. Simple? Please rename it to ComplicatedBuildTool in 0.14 so at

> least you know what to expect because its anything but simple :) I've

sbt is simple as long as your project structure is simple, IMHO.

I'd recommend studying these:
http://davidb.github.com/scala-maven-plugin/
http://gradle.org/docs/current/userguide/scala_plugin.html

And hybrid approach might be better to start with if you have strong Java
background.

> 2. Binary compatibility. I'm sure some people don't care but right now I

> have some dependencies that require 2.10 and others that won't work in
> 2.10. So I have had to dump off casbah (mongo driver), Jackson (the scala

Yes, this is perhaps the biggest problem with Scala.
I'd recommend staying with 2.9.x until 2.10 and all needed libraries are
ready.

> 3. The drift away from "standard" java deployment. Maybe I'm looking in

> the wrong places, but the frameworks that have grabbed my attention all
> do configuration and deployment in their own way. Specifically, neither
> play nor spray deploy in a standard WAR format (or maybe they can and I've

Scala is different. I'd say it is safe to expect the same from many Scala
frameworks.

Just pickup some existing Java web framework, if you need one, and implement
internals using Scala.

Also, Reddit has few threads relating to Scala web frameworks.
http://www.reddit.com/r/scala/search?q=web&sort=relevance&restrict_sr=on


Cheers,
Juha

[and...@officenet.no]

My advice is:

 

- Stay with Maven. Although sbt seems faster it is by no means as stable, has good IDE-integration, predictable and tested as Maven

- Don't be fooled into thinking you cannot use good JAVA-libraries and have to move everything to Scala-based stack

- Deal with fragileness of scala-versions by having a cup of coffee and ask your selv every time there is a new Scala-version; Is the alternative (JAVA) any better?

 

--
Andreas Joseph Krogh <and...@officenet.no>      mob: +47 909 56 963
Senior Software Developer / CTO - OfficeNet AS - http://www.officenet.no
Public key: http://home.officenet.no/~andreak/public_key.asc

 

[HamsterofDeath]

Am 15.11.2012 18:49, schrieb SamS:

Hi All.

For the past 2 weeks I have been evaluating scala as a "full stack" solution at work. What I mean by that is that I have used Scala successfully in the past in mixed java/scala projects using maven, where I have written maybe 20% of the code in Scala, purely because I like the language and its conciseness over Java.

Recently I convinced the CTO to let us develop our new (greenfield) flagship product purely in Scala. I've spent 2 weeks now putting the infrastructure in place / bootstrapping the project. And I'm about to give up. As a last ray of hope I need some coxing and back rubbing and the clever minds here to tell me all the following problems are just me being stupid. Otherwise I worry that I cannot justify moving all 10 developers over next week.

1. SBT. Simple? Please rename it to ComplicatedBuildTool in 0.14 so at least you know what to expect because its anything but simple :) I've spent probably 2 days just learning this and trying to configure it to work in a multi module way, and just when I was satisfied I had it all good, sbteclipse doesn't play nice with play's eclipsify. Arghhh.

i'm using scala since 2 years for small projects and all i use is my ide for compilation^^
if the projects get bigger, what i'm going to do is
a) set up the project with all its details in my ide (200 modules, 1000 dependencies, whatever)
b) compile it all in a huge batch with ant :). just smash it all together. i never understood why someone should do anything more complex. it just slows you down.

1. Binary compatibility. I'm sure some people don't care but right now I have some dependencies that require 2.10 and others that won't work in 2.10. So I have had to dump off casbah (mongo driver), Jackson (the scala module won't work). I'm now using the Java mongo driver and writing my own wrappers. I'm using Jackson without the Scala modules and sticking with Arrays only in my domain objects. Doesn't anyone see binary compatibility as a major issue? I think Java takes it too far but I don't think Scala yet has the size of community to be changing these things between versions because lots of projects are too small right now to be maintaining multiple versions.

i guess the solution for now is to not switch immediately. take a look at reality: there are many projects still using java6 or even java5. that's the opposite problem. also, the binary problem will probably be solved at some point.

1. The drift away from "standard" java deployment. Maybe I'm looking in the wrong places, but the frameworks that have grabbed my attention all do configuration and deployment in their own way. Specifically, neither play nor spray deploy in a standard WAR format (or maybe they can and I've missed it? - I know spray can run on top of a servlet container actually). Maybe you'll argue WAR's are crap, or this way allows faster, lower level frameworks, but it's throwing away all the learned knowledge and standard deployment practices.

that's because it's an all on one solution. you can just use any java framework.

On the plus side, the scala-ide nightlies are getting better and better and for "day to day" development I am now very contented.

Any advice? I worry that Scala (well specifically the frameworks around it) are just too complicated for average developers like me.

try intellij, use ant :)

[Alex Cruise]

On Thu, Nov 15, 2012 at 10:49 AM, HamsterofDeath <h-s...@gmx.de> wrote:

try intellij, use ant :)

FWIW, IDEA + Maven + Scala is solid for my team.  Our project is aggressively (obsessively, compulsively) modularized, we have a mixed Scala/Java source tree, and we've never disliked Maven enough to make it worthwhile to climb the SBT learning curve again and again. :)

The huge variety of useful Maven plugins is pretty nice too...

But yes, the most important piece of advice is: disregard 2.10, acquire 2.9.  

If you absolutely need to build a WAR, you'll have to skip a lot of the new-hotness Scala HTTP frameworks, many of which are async-based.  Of course, you can always mix and match whatever Java web frameworks you might be able to stomach.

If you have any specific detailed questions that you don't feel like asking thousands of people, feel free to email me directly. :)

-0xe1a

 

[Geir Hedemark]

On 2012, Nov 15, at 7:39 PM, and...@officenet.no wrote:
> My advice is:
>
> - Stay with Maven. Although sbt seems faster it is by no means as stable, has good IDE-integration, predictable and tested as Maven

I don't agree with this. We have a nicely working stack based on SBT, and there are absolutely no stability issues. We have all the IDE integration we need. We switched a little more than a year ago, haven't looked back since.

We switched because the maven scala compiler plugin was way too slow. Might have changed now, but sbt is just as good. There is no reason for us to switch back.

> - Don't be fooled into thinking you cannot use good JAVA-libraries and have to move everything to Scala-based stack
> - Deal with fragileness of scala-versions by having a cup of coffee and ask your selv every time there is a new Scala-version; Is the alternative (JAVA) any better?

I will second this, though.

yours
Geir

[and...@officenet.no]

+1.

 

Having used IDEA + Maven + Scala for 3+ years I really can recommend that combination for productivity, especially in teams.

[Sonnenschein]

Sam:

SBT-multi-modules + play + eclipsify:
For the time being, just use play projects for the submodules, too. Then eclipsify does work. But they'll have independent plugins for play and normal sbt modules soon.

Mongo + Scala:
No need for 2.10. Give Subset a try. We're using it on top of mongo-java driver.

Deployment:
Don't bother JEE. Akka will do it seemlessly for you.

Good luck

Peter

[Brian Schlining]

1. SBT. Simple? Please rename it to ComplicatedBuildTool in 0.14 so at least you know what to expect because its anything but simple :) I've spent probably 2 days just learning this and trying to configure it to work in a multi module way, and just when I was satisfied I had it all good, sbteclipse doesn't play nice with play's eclipsify. Arghhh.

Maven! WIth typesafe's zinc compiler (https://github.com/typesafehub/zinc), recent releases of the scala-maven-plugin and maven-shell (mvnsh) you can get fast, sbt-like compilation cycles (See http://hohonuuli.blogspot.com/2012/11/fast-scala-compilation-with-maven.html). 

-- 
Brian Schlining

[Juha Heljoranta]

On Thursday, November 15, 2012 11:14:00 Sonnenschein wrote:
> Deployment:
> Don't bother JEE. Akka will do it seemlessly for you.

Could you clarify? In general JEE and application servers (like JBoss) have
tons of useful stuff for deployment.

AFAIK, Akka is slightly similar to Jetty (or any other embeddable container)
from deployment point of view. Or did I miss something?

Cheers,
Juha

[Razvan Cojocaru]

We’ve been using it all successfully for a few months for a few projects, some plain backend (sbt) some play and kind of the same way you got there as well.

 

There are some things to take into account.

 

1.       Take it easy on the multi-projects. It is not easy to setup and work with multi-projects

2.       Have multiple projects each be artifacts, built independently and published on an artifactory and used that way

3.       Sbt can be a hair-pulling experience if you don’t do things exactly as described… yes, take it easy and don’t test features you don’t really need

4.       Play works fairly well

 

In Eclipse, modify the generated play projects manually and just include the other projects directly – that way you can avoid multi-projects issues for development. You can also include other projects as manually or ant-built JAR files too, eh? That’s what we ended up doing to use some Java code from a play app…

 

Yes – use 2.9 for now.

 

We have deployed play apps as J2EE servlets in Weblogic, in production – there is a project on github you can use and with a bit of hacking, it works just fine.

 

Cheers,

Razie

[Marius Danciu]

For item 3 LIFT works well on standard jee deployments. I don't really know why typeface chose play .. for me Lift would ha e been a far better choice. But hey, you don't have to use all typeface stack .... just because they also put framworks/libraries there it doesn't mean that those are the best choice in any context.

[Simon Ochsenreither]

Hi Sam,

SBT.

 

I would suggest just asking on the IRC or on the appropriate mailing list to get help on SBT. I think they will be happy to get you started with the configuration.
SBT's incremental compiler will be available in the next releases of Maven, Ant(?) and Gradle, but I'm unsure about the details. But if I'm interpreting it correctly, you plan to use Play. Short story here: You pretty much have to use SBT for Play, most of the interactive/hot-reload/developer-friendly stuff needs it.
If you do something different, you can also choose Maven, Ant, Gradle etc. (I use SBT, because from my experience, it "just works".)
 

The drift away from "standard" java deployment. Maybe I'm looking in the wrong places, but the frameworks that have grabbed my attention all do configuration and deployment in their own way. Specifically, neither play nor spray deploy in a standard WAR format (or maybe they can and I've missed it? - I know spray can run on top of a servlet container actually). Maybe you'll argue WAR's are crap, or this way allows faster, lower level frameworks, but it's throwing away all the learned knowledge and standard deployment practices.

As far as I now, the issue is that the Servlet standard implemented by most containers lacks the asynchronous features used by modern frameworks like Play. As soon as Java catches up, I'm pretty sure that Play will support the appropriate standards out-of-the-box. More information: https://play.lighthouseapp.com/projects/82401/tickets/8-war-packaging There is also a plugin for Play to run in a standard WAR container with support for Servlet 2.5/3.0: https://github.com/dlecan/play2-war-plugin/

Any advice? I worry that Scala (well specifically the frameworks around it) are just too complicated for average developers like me.

 

Don't worry too much. Ask for help if you think you are stuck with an issue. Pretty much all APIs of Play exist both in a Java version and in a Scala version, so you always have a working fallback which can be used from both Scala AND Java.

In general, I think Scala is easier than Java for all tasks possible in Java. There are just a lot of things which are completely impossible in Java, but possible in Scala and that's probably where scary/unfamiliar/foreign looking Scala code comes from.

The difference is that Scala allows you to get hard problems solved in the language itself, while Java forces you to step out of the language and add bytecode-enhancement libraries/annotation pre-processors/java agents/... to your toolset.

Hope I could help a bit,

bye!

Simon

PS: Sorry, small correction. :-)

[yossarian]

...SBT. Simple? Please rename it to ComplicatedBuildTool in 0.14 so at least ...

As an aside, Martin called it "Scala build tool" in one of the coursera lectures... 

[Antti Holvikari]

On Thursday, November 15, 2012 7:49:07 PM UTC+2, SamCook wrote:

Hi All.

1. SBT. Simple? Please rename it to ComplicatedBuildTool in 0.14 so at least you know what to expect because its anything but simple :) I've spent probably 2 days just learning this and trying to configure it to work in a multi module way, and just when I was satisfied I had it all good, sbteclipse doesn't play nice with play's eclipsify. Arghhh.

Hi – I feel your pain.

I'm the author of abt, the alternative build tool for scala projects. I think you should give it a try. The name is somewhat misleading as it's not really a build tool in itself, but an example scala project which has zinc, ivy and redo bundled. If you know bash, or any other scripting language, you're good to go. It's easy to learn, and very fast.

https://github.com/anttih/abt

[virtualeyes]

This is a great reply, as everything the OP has asked is summarized here:

"SBT-multi-modules + play + eclipsify"

Play documentation provides details on how to build sub projects, but the easiest way to make them play nice with eclipse is to create a directory structure like so:

/project (contains Build.scala, build.properties, and plugins.sbt)

/module1

/module2

/module3

where each module is a PlayProject (you could define sbt RootProject and Project modules, but the road is a bit rockier with that approach, imo).

Some bleeding edge snippets sans scala 2.10:

plugins.sbt > 

addSbtPlugin("play" % "sbt-plugin" % "2.1-SNAPSHOT")

build.properties >

sbt.version=0.12.1

~/.sbt/plugins/plugins.sbt >

addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.1.0")

and a multi module Build.scala attached

Im blazing in production with a multi module play 2.1 snapshot app on scala 2.9.2 (grab the 9/14/2012 snapshot version, the last release prior to switch to scala 2.10)

Good luck, once you have something to work with, it's not that complex (sbt is of course challenging beyond the simple case, I certainly am only scratching the surface)

[Alexandru Nedelcu]

Hi Sam,

I'm also learning Scala right now and at my job I have one module of a bigger app that's built on top.

On Thursday, November 15, 2012 7:49:07 PM UTC+2, SamCook wrote:

1. SBT. Simple? Please rename it to ComplicatedBuildTool in 0.14 so at least you know what to expect because its anything but simple :) I've spent probably 2 days just learning this and trying to configure it to work in a multi module way, and just when I was satisfied I had it all good, sbteclipse doesn't play nice with play's eclipsify. Arghhh.

I felt the same way initially. On the other hand SBT is a very pragmatic tool, so much so that I kept using it instead of Maven. On the other hand the latest version of the Maven plugin is kick-ass, as it got incremental compilation if you want that.

I don't know what you're saying about working with multiple-modules in SBT - for me it was easier to configure it to work with multiple sub-projects, compared to Maven. Maybe my needs are far simpler than yours, but if it helps take a look at how I've split this small/personal project in multiple sub-projects:

    https://github.com/alexandru/shifter
 

1. Binary compatibility. I'm sure some people don't care but right now I have some dependencies that require 2.10 and others that won't work in 2.10. So I have had to dump off casbah (mongo driver), Jackson (the scala module won't work). I'm now using the Java mongo driver and writing my own wrappers. I'm using Jackson without the Scala modules and sticking with Arrays only in my domain objects. Doesn't anyone see binary compatibility as a major issue? I think Java takes it too far but I don't think Scala yet has the size of community to be changing these things between versions because lots of projects are too small right now to be maintaining multiple versions.

Well, Scala 2.10 is at release candidate so it's not supported by anybody except for projects that are on the cutting-edge of the cutting-edge. If you were complaining about Scala 2.9.2 being incompatible with some project (which happens), then I would understand, but my advice would be to drop the dependencies that want Scala 2.10 - as those dependencies are probably unreliable anyway.
 

1. The drift away from "standard" java deployment. Maybe I'm looking in the wrong places, but the frameworks that have grabbed my attention all do configuration and deployment in their own way. Specifically, neither play nor spray deploy in a standard WAR format (or maybe they can and I've missed it? - I know spray can run on top of a servlet container actually). Maybe you'll argue WAR's are crap, or this way allows faster, lower level frameworks, but it's throwing away all the learned knowledge and standard deployment practices.

I also don't like this, especially since Jetty is so kick-ass. But for Play 2.0, have you tried this plugin?
https://github.com/dlecan/play2-war-plugin

Personally I don't like WARs, but I would like an executable fat JAR that includes everything needed and that you could deploy with a simple transfer over SSH.
Right now Play 2.0 can create a ZIP with all dependencies needed, I wonder why that ZIP isn't a JAR.

On the plus side, the scala-ide nightlies are getting better and better and for "day to day" development I am now very contented.

Personally I keep it simple. I work with Emacs and recently I installed Ensime, which can supercharge Emacs with many things you get out of IDEs, like Intellisense. Working without an IDE is painful though because IDEs are so good at hiding complexity that it creates a vicious circle - libraries designed by people using IDEs end up being unusable without an IDE because of all the unnecessary API complexity.
 

Any advice? I worry that Scala (well specifically the frameworks around it) are just too complicated for average developers like me.

Don't chew more than you can swallow.

It's too much having to learn a new language + new libraries + new IDEs + new build tools, while at the same time migrating an app, with features and fixes that should have been done yesterday, as commonly happens. Nobody can do that. And you shouldn't provide guarantees to your CEO if you're not experienced.

Start with something small, like a small component. Use Maven if SBT gives you the shivers. Start with familiar and light Java libraries, with some light wrappers on top. Don't worry about writing "idiomatic" code in places where shit needs to get done, etc...

[Seth Tisue]

On Fri, Nov 16, 2012 at 3:21 AM, yossarian <mark....@yahoo.com> wrote:
> As an aside, Martin called it "Scala build tool" in one of the coursera
> lectures...

I suggest "Scalable build tool".

--
Seth Tisue | Northwestern University | http://tisue.net
developer, NetLogo: http://ccl.northwestern.edu/netlogo/

[Michael Swierczek]

On Thu, Nov 15, 2012 at 3:55 PM, Marius Danciu <marius...@gmail.com> wrote:

For item 3 LIFT works well on standard jee deployments. I don't really know why typeface chose play .. for me Lift would ha e been a far better choice. But hey, you don't have to use all typeface stack .... just because they also put framworks/libraries there it doesn't mean that those are the best choice in any context.

I'm pretty confident that the people at TypeSafe picked Play over Lift because Play can be used mostly as a Java framework.  You can use it as almost all Java, all Scala, or a hybrid.  That makes the transition easier for existing companies and community projects that already have a lot of competent Java developers.  The last time I looked, Lift was all Scala.  You can use SBT by reading the manual ( a lot ) without any understanding of Scala.  You only need to understand a tiny subset of Scala syntax to make the page templates in Play.  Otherwise, you can do almost all of your work with Java.

 
-Mike

[Marius Danciu]

Well historically we've seen Java developers ramping up with Lift quite fast. In fast I started to use Lift while I was quite a beginner in Scala and it worked great ... learning Lift and Scala in parallel. You can use Java code with Lift as Scala allows you to .... but  it's really easy to write web apps in Scala using Lift idioms and leverage a clean template system. Allowing Java code to implement the framework API is not going to help much with the migration towards Scala ... at least I would stay way from such usage patterns.

[virtualeyes]

hmmmm, according to Pollack, he refused to work with TypeSafe, and not the other way around. Play would seem the safer bet, MVC, relatively straight forward to get started with/learn.

Lift, not sure, I'm curious to try, but Play Scala has overall been really, really, good, so not in any rush to explore right now

[Michael Swierczek]

On Fri, Nov 16, 2012 at 10:00 AM, Marius Danciu <marius...@gmail.com> wrote:

Well historically we've seen Java developers ramping up with Lift quite fast. In fast I started to use Lift while I was quite a beginner in Scala and it worked great ... learning Lift and Scala in parallel. You can use Java code with Lift as Scala allows you to .... but  it's really easy to write web apps in Scala using Lift idioms and leverage a clean template system. Allowing Java code to implement the framework API is not going to help much with the migration towards Scala ... at least I would stay way from such usage patterns.

I suspect for everyone or almost everyone on this mailing list, the prospect of a pure Scala solution is fine or even preferred.  But if you have to sell a CTO or reluctant colleagues on switching completely to a new language, a hybrid solution could be better.  

-Mike
 

[Oliver Ruebenacker]

Hello,

On Fri, Nov 16, 2012 at 10:49 AM, Michael Swierczek
<mike.sw...@gmail.com> wrote:
>
> On Fri, Nov 16, 2012 at 10:00 AM, Marius Danciu <marius...@gmail.com>
> wrote:
>>
>> Well historically we've seen Java developers ramping up with Lift quite
>> fast. In fast I started to use Lift while I was quite a beginner in Scala
>> and it worked great ... learning Lift and Scala in parallel. You can use
>> Java code with Lift as Scala allows you to .... but it's really easy to
>> write web apps in Scala using Lift idioms and leverage a clean template
>> system. Allowing Java code to implement the framework API is not going to
>> help much with the migration towards Scala ... at least I would stay way
>> from such usage patterns.
>>
>
> I suspect for everyone or almost everyone on this mailing list, the prospect
> of a pure Scala solution is fine or even preferred. But if you have to sell
> a CTO or reluctant colleagues on switching completely to a new language, a
> hybrid solution could be better.

Our CTO says he has never seen a Java developer who learned about
Scala and didn't get hooked. :)

I already got hooked before he joined. We had a Java Server Faces
app deployed to Tomcat 6, and I started to insert Scala classes to see
how that goes. Except for some glitches with Scala-IDE for Eclipse
(and the glaring lack of a "find all references" function), that went
rather smoothly. Then we switched to Play 2, building a new app in
pure Scala (if there is such a thing as pure Scala, as we are still
using Java libraries)

As a Java developer, it is fairly easy to learn enough Scala to do
everything you can do in Java. The hard part is understanding code
produced by advanced Scala hackers.

Take care
Oliver

[Geir Hedemark]

On 2012, Nov 15, at 6:49 PM, SamS wrote:

Recently I convinced the CTO to let us develop our new (greenfield) flagship product purely in Scala. I've spent 2 weeks now putting the infrastructure in place / bootstrapping the project. And I'm about to give up. As a last ray of hope I need some coxing and back rubbing and the clever minds here to tell me all the following problems are just me being stupid. Otherwise I worry that I cannot justify moving all 10 developers over next week.

1. SBT. Simple? Please rename it to ComplicatedBuildTool in 0.14 so at least you know what to expect because its anything but simple :) I've spent probably 2 days just learning this and trying to configure it to work in a multi module way, and just when I was satisfied I had it all good, sbteclipse doesn't play nice with play's eclipsify. Arghhh.

We had a consultant in to bootstrap our sbt build when we moved to sbt. We could do maven ourselves, sbt was too big an investment.

2. Binary compatibility. I'm sure some people don't care but right now I have some dependencies that require 2.10 and others that won't work in 2.10. So I have had to dump off casbah (mongo driver), Jackson (the scala module won't work). I'm now using the Java mongo driver and writing my own wrappers. I'm using Jackson without the Scala modules and sticking with Arrays only in my domain objects. Doesn't anyone see binary compatibility as a major issue? I think Java takes it too far but I don't think Scala yet has the size of community to be changing these things between versions because lots of projects are too small right now to be maintaining multiple versions.

No, I don't see binary compatibility as a major issue. We are still on 2.9, and we will continue to be on 2.9 until all the libraries we need to use are on 2.10. We will not even consider libraries that are not available on 2.9 (probably immature), which are not well documented (again, probably immature) and which do not have a sensible plan for moving forward which does not contain "rewrite the thing from scratch".

Them are the breaks. The same thing applies to java, by the way, except most libraries tend to work with all versions of java/the jvm, as long as you stay away from some big-name enterprise solutions.

3. The drift away from "standard" java deployment. Maybe I'm looking in the wrong places, but the frameworks that have grabbed my attention all do configuration and deployment in their own way. Specifically, neither play nor spray deploy in a standard WAR format (or maybe they can and I've missed it? - I know spray can run on top of a servlet container actually). Maybe you'll argue WAR's are crap, or this way allows faster, lower level frameworks, but it's throwing away all the learned knowledge and standard deployment practices.

Yup. The wisdom of the new-uns is that standard web applications do not scale into asynchronous behaviour. The thing is, neither do most developers until you teach them. You have to consider the benefits and drawbacks for your particular team.

We are deploying war files, not because it is particularly easy for us to do so, but because that is what worked when we built our scala stack way back, when play2 was still a thought at the back of someones mind only. We are looking at moving to play at some point in the future because of the developer round-trip-time improvements. Asynchronous behaviour can go hang - we mostly don't need it. We are holding off because the documentation is still not good enough. Perhaps the upcoming play2 book from manning can help that.

On the plus side, the scala-ide nightlies are getting better and better and for "day to day" development I am now very contented.

We use intellij, and most of the scala people hereabouts seem to agree with us. We went for the professional edition because of some non-scala-related features, but you really only need community edition.

If you want to talk to someone who is part of a team that is using scala, with spring (prepare for yells of "unclean" and "burn the witch"), building a war archive, using sbt, please feel free to email me. Hell, if you buy me a coffee if you meet me you can even have a hello-world-version of our application, warts and all - without any promise of support if it doesn't work out for you.

Geir

[Som Snytt]

On Fri, Nov 16, 2012 at 5:34 AM, Seth Tisue <se...@tisue.net> wrote:

On Fri, Nov 16, 2012 at 3:21 AM, yossarian <mark....@yahoo.com> wrote:
> As an aside, Martin called it "Scala build tool" in one of the coursera
> lectures...

I suggest "Scalable build tool".

If this is the official poll, the other day I thought of "sabbath", as a nod to "sabbus."

I also considered "shabbat", as a nod to "shazam!"

The version that can be configured in a one-liner build script but uses scalaz to do it would be called "shabazz."

[Sonnenschein]

In my experience, 'Tons of useful stuff' doesn't automatically mean that you really need those tons. It usually means that you get overflood and overburden with them. Maybe you just need *some* and all what you need is included in Play/Akka. So just tell us what you are missing and let the experts clarify what alternatives exist...

[Sonnenschein]

Sam, which direction did you take finally? Did you find the solution for eclipsify?

[Sam (Stephen Samuel)]

Hi guys,

First of all thanks for all the replies. Every single one was helpful and courteous.

As a result what I've ended up doing is this:

Recommended a switch to intellij. Eclipse + Maven + Scala IDE Plugin is not ready for prime time imo. I was forever getting errors which forced a full clean (such as unable to find files that existed). A clean usually fixed it. Note: I did not have this problem with SBT and Eclipse which is why I was keen on using sbt, but am much happier going back to Maven and keeping the existing deployment pipeline and inhouse knowledge. Since the switch to intellij everything has worked perfectly.

Following on from sticking with maven, I ditched play and went back to Spring MVC. A boring choice perhaps, but it's tried and tested and works perfectly. I didn't want to fight play + maven.

Finally, am using Scalatra for REST.

On 21 November 2012 09:29, Sonnenschein <peter...@arcor.de> wrote:

Sam, which direction did you take finally? Did you find the solution for eclipsify?

--
-Sam

[Andreas Joseph Krogh]

På onsdag 21. november 2012 kl. 11:00:34, skrev Sam (Stephen Samuel) <samsp...@gmail.com>:

Hi guys,

 

First of all thanks for all the replies. Every single one was helpful and courteous.

 

As a result what I've ended up doing is this:

 

Recommended a switch to intellij. Eclipse + Maven + Scala IDE Plugin is not ready for prime time imo. I was forever getting errors which forced a full clean (such as unable to find files that existed). A clean usually fixed it. Note: I did not have this problem with SBT and Eclipse which is why I was keen on using sbt, but am much happier going back to Maven and keeping the existing deployment pipeline and inhouse knowledge. Since the switch to intellij everything has worked perfectly.

 

Following on from sticking with maven, I ditched play and went back to Spring MVC. A boring choice perhaps, but it's tried and tested and works perfectly. I didn't want to fight play + maven.

 

Finally, am using Scalatra for REST.

 

You should try Lift. A reasonably complete example using Maven (multimodule) +Lift is here: https://github.com/andreak/on-example-rpm

I haven't updated it to use Zinc yet but it should be a nobrainer. Import in IntelliJ and off you go.

[Joe Barnes]

Hey Sam,

I'm likewise in a team that has been all Java for years, and I'm giving Scala strong consideration.  My experience in Scala is very limited, but like you I see a lot of potential in it. 

As for SBT, I have REALLY struggled to learn it.  However, I'd still argue that it's simple.  Difficult to learn doesn't imply complex.  This is akin to insisting that Spanish is complex because you can't read it.  In reality, it's a much simpler language than English.  It just takes time to learn it and "get" it.  I just never gave up on SBT, and I'm glad I didn't.  Ant sucks so bad.  I've worked with it for years.  Gradle has a lot of potential, but it's entirely too slow for rapid TDD.

As for handling the binary incompatibilities, have you ever considered OSGi?  Now, I'm not sure at what level the incompatibilities arise.  However, OSGi could potentially alleviate some of these issues.  With OSGi, you can concurrently deploy multiple versions of the same module (in this case, the Scala lib) and the libraries you are using declare which version they require.  Then they can run in the same JVM against the appropriate version.  In theory, they should be able to talk to each other, but I'm not sure if the binary incompatibility is too great to overcome with this approach.

I've not played with any web frameworks at this point, so I cannot offer much advice.  FWIW, I plan to investigate Lift.

Joe

On Thursday, 15 November 2012 11:49:07 UTC-6, SamCook wrote:

Hi All.

For the past 2 weeks I have been evaluating scala as a "full stack" solution at work. What I mean by that is that I have used Scala successfully in the past in mixed java/scala projects using maven, where I have written maybe 20% of the code in Scala, purely because I like the language and its conciseness over Java.

Recently I convinced the CTO to let us develop our new (greenfield) flagship product purely in Scala. I've spent 2 weeks now putting the infrastructure in place / bootstrapping the project. And I'm about to give up. As a last ray of hope I need some coxing and back rubbing and the clever minds here to tell me all the following problems are just me being stupid. Otherwise I worry that I cannot justify moving all 10 developers over next week.

1. SBT. Simple? Please rename it to ComplicatedBuildTool in 0.14 so at least you know what to expect because its anything but simple :) I've spent probably 2 days just learning this and trying to configure it to work in a multi module way, and just when I was satisfied I had it all good, sbteclipse doesn't play nice with play's eclipsify. Arghhh.

1. Binary compatibility. I'm sure some people don't care but right now I have some dependencies that require 2.10 and others that won't work in 2.10. So I have had to dump off casbah (mongo driver), Jackson (the scala module won't work). I'm now using the Java mongo driver and writing my own wrappers. I'm using Jackson without the Scala modules and sticking with Arrays only in my domain objects. Doesn't anyone see binary compatibility as a major issue? I think Java takes it too far but I don't think Scala yet has the size of community to be changing these things between versions because lots of projects are too small right now to be maintaining multiple versions.

1. The drift away from "standard" java deployment. Maybe I'm looking in the wrong places, but the frameworks that have grabbed my attention all do configuration and deployment in their own way. Specifically, neither play nor spray deploy in a standard WAR format (or maybe they can and I've missed it? - I know spray can run on top of a servlet container actually). Maybe you'll argue WAR's are crap, or this way allows faster, lower level frameworks, but it's throwing away all the learned knowledge and standard deployment practices.

On the plus side, the scala-ide nightlies are getting better and better and for "day to day" development I am now very contented.

[Juha Heljoranta]

Ok, I am basically answering to my self :)

Akka deployment is done by using it as a library or as a microkernel. Library
approach is very similar to embedded Jetty deployment.

Microkernel approach pulls automatically dependencies and creates a comfy
bundle including startup scripts. I'd say microkernel is even more about
packaging than deployment: sensible defaults and automated process to wrap an
application into deliverable. Not bad.

Possible (minor) downside (I didn't check) is that akka is now a dependency
even if application it self doesn't use Akka. Also, it seems that sbt is
pretty much mandatory for building the microkernel package.

In summary: Akka has very minimal deployment: it is used as part of some other
application as a dependency, DIY (embedded) or as a JVM process launched
according to Akka microkernel configuration files.

Now that I understand Akka deployment better I could try to reason about your
earlier comment:

> > > Deployment:
> > > Don't bother JEE. Akka will do it seemlessly for you.

Akka microkernel is the application deployment, the "seemless" part, and
nothing more, from deployment perspective, right? It seems suitable for
embeddable applications and for stuff which doesn't depend on enterprise java
tech which is usually better handled by traditional containers (XA, JAAS,
etc.)

So, I think I am seeing some exaggeration in your statement... Anyway, I'd say
both are viable deployment methods. It just depends on application
requirements.

Cheers,
Juha

[Naftoli Gugenheim]

On Thu, Nov 15, 2012 at 3:54 PM, Razvan Cojocaru <p...@razie.com> wrote:

2.       Have multiple projects each be artifacts, built independently and published on an artifactory and used that way

This is a lot better with sbt 0.12.1+.

[Naftoli Gugenheim]

On Fri, Nov 16, 2012 at 9:33 AM, Michael Swierczek <mike.sw...@gmail.com> wrote:

The last time I looked, Lift was all Scala.

It has a Java API. I don't know how comprehensive it is, but if it's lacking it's probably due to lack of demand.

[p...@razie.com]

Good to know - il take a look... Thanks

Sent from my iPad