As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Many Java x Scala comparisons seem to focus on the language alone (syntax, collections api, actors, etc) but what about enterprise application development?
If you want to build a distributed enterprise system using Scala, would you code a traditional Java EE application using Scala syntax (e.g. EJB compatible class using Scala syntax) and run it in a Java EE container, or is there a Java EE replacement in the Scala ecosystem?
If the second, so far the closest thing I found is the typesafe stack; is it Scala's replacement for a Java EE container?
Is Akka a JMS (and possibly Session Beans) replacement or would your Scala system still leverage Java EE services?
Well,
Scala / Akka offer different concepts for many of the common pitfalls
in system development. To compare just a few to Java EE:
=> JavaBeans:
Mutable Data-structures are just plain evil and not thread-safe.
Putting them into a container doesn't change anything.
Use immutable data structures instead, as scala enforces with CaseClasses.
=> EJB:
Composition of EJBs just sucks. The actual problem is that EJBs need to have a high level of cohesion to be useful in terms of re-usability which is hardly the case in practice. Stuffing them into a container wan't make it any better. In Scala, using traits,
for composition enables you to use ad-hoc composition through constructor injection protected by f-bounded polymorphism. Life can be so easy.
=> Transactions:
Yes transaction managers already make things better but it's still
requires the big Java EE stack to make it work. In Scala, just use Software Transactional Memory (STM) as provided by akka and you're done.
=> Persistence:
Do we really need ORM? Projects like squeryl.org add strongly typed LINQ to Scala.
Instead of heavy-weight query language mapping, as Hibernate does, it just integrates
queries into scala, fully checked by the compiler. This is of course only true for relational DB's. For no-sql, there are other solutions available.
=> Scaling?
Clustering Java EE? Do I need to say more?
In akka you just add a few more server and the system just scales. Why? Because
remote actors are treated and accessed the same way as local actors and everything
else is just a matter of configuring your distributed actor system. Akka is based on
the Erlang model, so they do not look for five-nine up-time but nine-nine up-time
under full system load.
At the same time, akka is so easy and light-weight that you
can use it on Android. Would you try to run Java EE on Android?
https://github.com/gseitz/DiningAkkaDroids
To be clear, maybe ten years ago, Java EE was the answer to the question how to build
large enterprise grade software and, once Spring has made it usable, it was maybe the best available solution at those days.
Today, the world has changed a lot and most of the old answers do not fit today's reality anymore. Scala, is not perfect but if it really comes down to one single line it would b be this:
In scala, I get my actual programming done in a fraction of time the Java EE
and container setup would take.
Even Spring, as the framework of choice for Java EE is moving towards scala:
http://blog.springsource.org/2012/12/10/introducing-spring-scala/
To start with both, concepts and best practices for Akka, there is a handy
book called "Akka Essential"
http://www.akkaessentials.in/2012/12/adding-turbchargers-to-jee-apps.html
If you want Java EE, you can go right ahead and use Java EE with Scala. However, I don't know anyone in the Scala community who doesn't want to get away from Java EE (or continue to avoid it).
Akka is indeed a sort of "replacement" for JMS. Behind this idea (and your question) it is indeed a change of paradigm, and we must be aware of that, but starting from this fact i think akka had chance to be used very widely in the next future for several uses, from message passing to integration between distributed etherogeneus concurrent platform.
Typesafe stack is a stack, so i found unuseful to think that regarding Java EE contanier.
And last, the first answer: if you want to use the EJB syntax, please consider using annotations and you should have the chance to write EJB more or less in the same way as java, plus some "syntactic sugar" of scala
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I used play2 before with java. It felt a little bit like boilerplate especially if you used akka with java. But that is not the fault of the framework.
Yesterday I read "Scala for the impatient" and I really enjoy the language.
Now I looked at both frameworks Lift 2.5 and Play 2.0.3. I think lift has a higher learning curve and I could not just do something with lift. This is not a con for me. From what I saw, Lift has a very nice and clean design.
But for me it is hard to tell what the main differences are. I think both frameworks are great.
The Views First approach doesn't allow you to code in your templates, instead you have to code in snippets. I like this a lot because it looks more organized to me. It also lets you use a normal html editor.
(I have not much experience, this is just my first impression)
For the security I don't think that is the job of the framework.
Stateless/Stateful : It is hard to tell where the main differences are. I only know that play has also a state if you use web sockets.
Both frameworks are able to compile after you press F5. I like this feature a lot.
Both frameworks are using sbt
Lift comes with authorization but I think there is a play2 scala plugin that does the same thing
Lift has a ORM mapper for mongoDB. Because I want to use noSQL, this looks cleaner to me.(Again not much experience) Edit There is a ORM mapper for scala mongodb in play2 https://github.com/leon/play-salat
Async - Play 2 uses Akka. Don't know what lift uses but they also have something similar.
Lift ships with CSRF support. Play2 has a modul for CSRF but this adds a boilerplate to your code.
Stateless authentication seems to have some security vulnerabilities. Both frameworks have the stateful authentication. (play2 stateful/stateless , lift stateful)
What are the strengths of each framework?
Posting this after spending a week or two with Lift doesn't really
serve anybody's interests. However, I want to spend some time correcting
some mistakes and mis-perceptions.
For the security I don't think that is the job of the framework.
You're dead wrong. Security is the job of the framework. It's critical that security
is done by default rather than relying on each developer to understand every
security vulnerability and make sure every line of code takes that into account.
All we have to do is look at what happened to GitHub
to understand that even the best coders using well known technology
can make a critical mistake.
Lift gives a solid security layer on top, so by default, there's no XSS, CSRF, etc.
but the developer can dig down as deep as he wants to the HTTP request and deal
with the bytes on the wire.
Stateless/Stateful : It is hard to tell where the main differences are. I only know that play has also a state if you use web sockets.
Lift is very clear about where you need state and where you don't. Lift can support
stateless, partially stateful, and completely stateful apps. On a page-by-page and
request-by-request basis, a Lift app can be stateful or stateless (for example,
in Foursquare, the venue pages are stateless for
search engine crawls, but stateful for browsers that are logged in.) For
more on the design decisions around state, please see Lift, State, and Scaling.
Both frameworks are using sbt
Lift uses Maven, sbt, Buildr, and even Ant. Lift is agnostic about the build environment
and about the deploy environment (Java EE container, Netty, whatever). This is important
because it make Lift easier to integrate with the rest of your environment.
Lift comes with authorization but I think there is a play2 scala plugin that does the same thing
Lift has been around for 5+ years and has a lot of modules and stuff for it. The Lift web framework (as distinguished from the modules) is agnostic about persistence, authentication, etc., so you can use anything with Lift.
Async - Play 2 uses Akka. Don't know what lift uses but they also have something similar.
Lift has had Async support for more than 5 years. It's baked into the framework. Lift's Comet support is the best of any web framework because,
among other things, it multiplexes all the "push" requests on a page through a single request
to the server which avoids connection starvation. How Lift does async is a whole lot
less important because one of the core philosophies with Lift is that we remove the
plumbing from the developer so the developer can focus on business logic.
But for those who care, Lift has the best and lightest weight actors of any framework in
Scala-land. We were the first to break away from the Scala Actor's library and worked
to blaze the trail for different Actor libraries that allowed Akka and ScalaZ Actors
to flourish.
Lift ships with CSRF support. Play2 has a modul for CSRF but this adds a boilerplate to your code.
This is part of Lift's commitment to security. It's important.
Stateless authentication seems to have some security vulnerabilities. Both frameworks have the stateful authentication. (play2 stateful/stateless , lift stateful)
Lift apps can be as stateful or as stateless as you want. It's your choice and Lift
makes very clear how to make the decision.
Also, as I pointed out in the Lift, State, and Scaling post, making the developer figure out
how to serialize state in a secure, scalable, performant way
(because virtually every request on a web
app that recognizes specific users is stateful) should be done in a predictable,
secure way by the framework with reasonable overrides for the developers.
Parting note
Play is a lot like Rails: it's quick to get a site knocked together and it's
based on MVC, so a lot of developers understand it. But Play lacks the
depth and breadth of Rails (community, plugins, expertise, talent, etc.) If you
want quick, easy MVC, then go with Rails and JRuby and write your
back end in Scala (they work together extraordinarily well.)
Lift is a different beast. There's a significant unlearning curve (stop thinking
MVC and start thinking about user experience first that flows to business logic.)
But once you're up the unlearning curve, Lift sites are more secure, highly
scalable, super-interactive, and much easier to maintain over time.
To see what can be done with Play (it can be cool), have a look at the TypeSafe Console
To get going quick with Lift, use a template project.
For a sample of using Mongo with Play, look at Factile.
In summary, I don't think you will go wrong with either Lift or Play. Both are active projects, with good communities and good backing from the authors. It really depends on your business problem. If tool support are important to you, then you may want to look at using Play (it's well supported on IntelliJ Idea).
Take note that Play, being part of the TypeSafe technology stack, will have builds up to the latest versions of Scala, so if using Scala 2.10 features are important to you, then you may want to keep that in mind. Lift is currently using Scala 2.9.2, which is fine also.
For my current project I use lift-mapper for ORM (It's great and rock solid), with Spray for REST (which is simply amazing). This approach avoids frameworks altogether, but it depends on what you want to do. Frameworks are quite often the way to go.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
since concurrent programming becomes constantly more important, I was wondering
what you think about Erlang vs. Scala in that respect. It seems to me that Scala
has a larger user base and potentially a brighter future than Erlang. Furthermore,
Scala is kind of java.
I know these questions are alway a bit subjective, but what would be the better
future investment: Erlang or Scala. Or even another language?
Erlang has been designed for concurrent, fault-tolerant communication systems. You can easily write servers that handle large number of network connections and (thanks to one garbage collector per Erlang process) the servers can retain soft real-time characteristics (i.e., the whole server is not paused until GC finishes). You can also hot-swap Erlang code, distribute it across several nodes, etc. That's why (arguably) the most-scalable XMPP server (ejabberd) is written in Erlang. Yaws (a web server) is another example where Erlang excels, see: http://www.sics.se/~joe/apachevsyaws.html. Riak/Couch are examples of NoSQL DB build with Erlang. These are the problems where Erlang is a great choice.
But Erlang VM is not as fast as JVM in terms of raw computations, so as soon as you need to do something computationally intensive (e.g. financial modeling) JVM will be your preferred platform. Moreover, Erlang's concurrency model (actors) is baked in the language. If that doesn't fit the problem you're trying to solve, then you won't be happy with Erlang.
Scala is more 'general' language in a sense that concurrency, horizontal scalability, or fault-tolerance is not part of the language. It is solved at the level of libraries (that's why there are at least 3 implementations of actors in Scala). The good thing is that you can pick concurrency model that fits your domain. For example if you need software transactional memory (STM), just pick Akka and you're good to go (http://akka.io/).
Plus there is the whole argument that with Scala you can leverage your "JVM investments" and multitude of JVM libs.
You didn't give any info on what kind of software you want to write with either of those languages so it's hard to give you a definitive answer. Having said that, given all the above, Scala may be "safer" investment than Erlang (not bashing Erlang/OTP at all, it's a fine language/platform).
BTW. If a single-machine concurrency is important to you Clojure (http://clojure.org/) should not be overlooked (also JVM language).
UPDATE1: If you like what Erlang offers but not its syntax, take a look at elixir-lang.org
UPDATE2: STM has been removed from Akka - now you have a choice (mix/match) between actors (untyped or typed) and streams.
It doesn't matter Just pick one and stick with it for a while. Learn some stuff, make some cool things and either keep going with that language or move on to another one.
With respect to learning concurrent programming, either will be fine. The key here is that you will be learning something new and unless there's a job opening that you are trying to get hired for that uses Erlang specifically, it really doesn't matter. Plus, even if that opening did require Erlang, you would still likely have a good chance if you knew Scala really well.
Just think, all of the time you have spent trying to pick a new language could have been better spent if you just picked one and already started learning it by now.
Both languages, at the core, are not that hard to learn, and also to learn the concurrency features they provide. In fact, Scala actors are influenced by Erlang actors. I would go to both of them, take your time looking at their construct, do some tests in concurrency problems, etc.
If you know Java, Scala will be more natural, as Erlang is more like prolog. If, on the contrary, you're more oriented towards mathematical or logical type of languages, start with Erlang.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm starting to understand Scala and I like it a lot.
How can you position yourself to get a paying job as a Scala developer (assuming those become more common)?
What parts of the Scala ecosystem have the best job potential (Lift, Actors?).
How can you gain credibility with a prospective employer without being able to point to Scala work experience (maybe experience on open-source projects?).
(The above questions are hopefully of somewhat general interest to Scala folk. If you want to factor my particular situation into your response, here are a few details about me: longtime developer (mostly Java) with a Computer Sci PhD; not currently working; I'm tied to a non-cutting edge location (Rochester NY), so I may be limited to remote work.)
Update 2010/07/30:
Thanks for the responses. I'd like to crank up the emphasis on the location issue. I'm tied by family to a location that probably won't have Scala work locally for a long time. Are there realistic prospects for getting remote Scala work, and if so how do you position yourself to get remote work? (A modest amount of travel would be doable, but not a full-on road warrior.)
Also, I was wondering about leveraging my teaching background. Would teaching a Scala class at a local university make a big difference in one's marketability as a developer, or just divert more effort than it is worth?
Pure Scala position:
Finding a pure Scala position is not very easy, but it is getting easier and easier. I am going on my first pure Scala job interview in a few days.
I hope we will see a lot of new systems being written entirely in Scala, and I think these systems will be mostly back-end, heavy duty systems. These systems will be using Scalas less error prone functional style to reduce bugs. I think Akka, SBT and Specs will be important frameworks for the Scala developer (this is not much of a prediction since they are already important).
If you do not find a pure Scala position:
Your credibility comes from your time with Java. Most big companies have heaps of Java code that must be maintained and developed. If it is your job to babysit the old Java code, and as an old Java guru, you should have some say in how this should be done. The first step is to change the Maven setup to allow mixed Java/Scala environment. Moving to SBT is probably your best choice. This is a one time investment you have to do or else you can not proceed!
If you work independently you could probably replace Java with Scala whenever you feel like, most likely when you have to re-factor some old code. Talk about Scala as a "framework" for Java (this is technically a lie) that boosts productivity when speaking to the non technical project manager, this might calm their worrying minds. In the end it will be your responsibility to see to it that Scala indeed integrates with Java. But since Scala does this very well it is not much of a problem. Actually, maintaining old legacy code is not a dream for anyone, so PMs are usually happy if they find anyone who would do it for more than 3 month. Management will probably put up with you rebellion.
If you work in a team it is a bit more tricky. In this case you have to teach the team Scala, or else they will not be able to understand your code. You have to persuade your PM to set aside resources for Scala training (might be hard). When you introduce Scala to a team, start small. My experience is that it takes a while for a Java dude to learn Scala, so this is not done overnight. Therefore, ignore everything that is "hard" when you teach Scala. When the team grasps the basics, start with writing tests in Scala (thank Davetron5000 for this tip), continue to use Java for programming in the application (the production code). Hopefully the team will learn and enjoy Scala and after that, well, it is all downhill from that point.
Good luck!
If I was hiring at the moment, I can tell you right now what questions I would be asking and they would be about the language. It is a hard language to understand at a deep level, even if it seems easy to use and, as a consequence, you might be expected to understand code written in a large number of different styles.
Knowledge of libraries (Akka and Lift being the obvious ones) the sbt build tool is great but it is an extra. I would want to know that you understand:
a bit (well, a lot) about the type system (and higher-kinded types)
something about the typeclasses approach
implicits and the pimp-my-library approach
good scala style (i.e. idiomatic scala)
recursion
the actors approach to concurrency
the standard libraries
functional programming
If you understand the language, you'll pick up the libraries with no problems, I'm sure.
Other libraries:
scalaz for functional programming
scalala for numerical programming (linear algebra etc)
scalaj for interacting with Java
I think your best bet is to get good at Scala and to get visible in the Scala community. These are not necessarily the same thing but luckily they are very closely related in the Scala community. Once you do this there are definitely opportunities to use Scala for fun and profit, whether as a consultant/contractor or as a (remote) full-time employee. As part of getting better and more visible I would recommend becoming active in one of the existing communities (Lift, Akka, ScalaNLP, you name it) or even going out in the wilderness and hacking away to solve a common problem, even if it's just making a native Scala alternative to a popular Java library (e.g. squeryl and Dispatch maybe weren't necessary but they're awesome).
I guess what I'm saying is that contributing to any good, useful Scala code will be good experience and I think the ecosystem is so young that there's no need (or benefit?) to specializing in only one part of it. Of course, if there's a specific subject that Scala is useful for and/or a specific field that benefits from Scala that jumps out to you, direct your attention in that direction.
Having had two full-time Scala jobs at this point, I'd say that the most important thing to do is learn the type system and the standard libraries inside and out. The individual technologies can then be picked up with relative ease.
Also, start using Scala (specifically Specs and ScalaCheck) for testing in your current project, today, if you possibly can.
Finally, as pr1001 said, get visible in the Scala community. Contribute to a project, interact on the mailing list, hang out in #scala on freenode, answer questions where you can.
Take your current job, and implement resume driven development. Just claim that xyz can't get done on schedule without Scala, and then use it. After that, take your project to success and either work elsewhere, open your own business, or continue developing Scala apps at your own company.
It worked for Dick Wall, so it should work for you. :)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Which tools or libraries do you wish existed in the Scala ecosystem?
Are there any existing ones you wish were greatly improved?
In no particular order:
A Scala version of the Clojure Incanter libraries would be very handy indeed, and could probably be even nicer to use than Clojure's.
It would also be exceptionally cool if the parallel version of the 2.8 collection library had been ready for (todays!) 2.8 release, rather than waiting for 2.8.1. Even cooler would be something with the power and feel of the 2.8 collection library which offloaded calculations to something like Hadoop.
Standard library support for software transactional memory would be very nice.
The IntelliJ IDEA plugin for Scala is an amazing piece of work, but (unsurprisingly) still lags behind Java in some annoying ways, particularly in on-the-fly error reporting.
There need to be some standard shims built so that various "enterprise" libraries (Spring/Hibernate/Ibatis/Freemarker, etc.) can use Scala objects without scattering #BeanProperty annotations around and without using Java collections objects.
A single lib for time, money and physical units would be cool
Scala Swing should be more complete (and more consistent)
Would be nice if the DBC lib for wrapping JDBC access would be finished
A Scala 3D engine would be awesome. Simplex3D and Sgine are on the way, but it's a long way...
I think it is important not to pack too much functionality into Scala. It is really easy to expand Scala on your own, so let's do that for a while. Then, when some framework emerge as a winner, this might shipped with Scala.
For those of you who have suffered the result of the JCP committee, please remember the disasters of premature standardizations.
That said, I have my own wish list :-) I would like a simple DSL for Date. The one from DPPs book would do.
Off the top of my head:
A good scala <-> JDBC bridge.
A good mocking framework.
Scala wrapper for Spring DI.
I have been working on a project and as I have just started on the webservice I found Lift has been released, so I am curious if there will be much more complication by using Lift over Jax-WS using JDK6.
I am doing this with the Eclipse IDE, but I don't know if I will get much benefit from the IDE on this project.
Lift is written in Scala, so the simple question is do you know Scala? If you don't know Scala but you do know JAX-WS, then Lift will clearly be way more work to get to a working implementation.
Scala and Lift are cool, but unless you are already comfortable with functional programming approaches, they will make your head hurt for at least 6 months. Since they are relatively new they also suffer from a lack of tooling.
You mention that you are using JAX-WS - can you do that with Lift? If you can't do it natively with Lift, can you easily integrate the standard Java libraries for this?
Depending on whether this is a personal project or work-related, your tolerance for taking technical risk can vary widely.