Related
I'm using ScalaJS with Play. Many of the models I'd like to use on both JS and JVM platforms involve dates and times. Given the lack of a cross-platform date/time library, how are people approaching this?
Things I know about:
scalajs-java-time project (https://github.com/scala-js/scala-js-java-time) to port JDK8's java.time api to Scala.js. Unfortunately, it's far from complete and judging by the commit logs, seems to have stalled.
https://github.com/mdedetrich/soda-time is a port of JodaTime to Scala/Scala.js. But it's not ready for production use.
An old post at https://groups.google.com/forum/#!topic/scala-js/6JoJ7x-VxLA suggests storing milliseconds in shared code and then doing implicit conversions on each platform to either js.Date or JodaTime. But we really need a common interface, which this doesn't give.
Li Haoyi's excellent "Hands-on Scala.js" has a simple cross-platform library (http://www.lihaoyi.com/hands-on-scala-js/#ASimpleCross-BuiltLibrary) that could, in theory, be extended to come up with an API in /shared that delegates to JodaTime on the jvm and Momento on js -- but that sounds like a lot of work.
(added later) https://github.com/soc/scala-java-time is based on an implementation of java-time that was contributed to OpenJDK. The README claims that most stuff is working. Right now, this looks like the most promising approach for my needs.
Any advice from those who have gone before me? Right now the fourth options seems like my best bet (with the API limited to stuff I actually use). I'm hoping for something better.
I was in the same boat as you, and the best solution I came up with was cquiroz's scala-java-time library. From reading the comments to your question above, it appears you landed at the same place eventually!
I came here from a google search, and given how much better this solution is than the alternatives you mentions above, let's consider marking this question as resolved for future visitors.
Note: Unfortunately this question was closed, but I'm trying to maintain it for if someone else comes along with the same question.
I've been looking for a good solution to developing a service in Scala that will sit between mobile devices and existing web services.
The current list of viable options are:
Finagle
Spray
BlueEyes
Akka
Play2 Mini
Unfiltered
Lift
Smoke
Scalatra
There are probably more options out there. How does one decide which one to use? What are the traits (excuse the pun ;-) of a good Scala middleware choice. On the one side, I would like to go for Akka, because it is part of the TypeSafe Scala stack, but on the other, something like Finagle has a rich set of libraries and makes plumbing so easy. Spray looks nice and simple to use.
Any advice, insights or experience would be greatly appreciated. I'm sure someone out there must have some experience with some of these that they won't mind sharing.
UPDATE:
I would love for this question to be reopened. A good answer to this question will help new Scalateers to avoid related pitfalls.
UPDATE 2:
These are my own experiences since asking this question:
Finagle - I used Finagle for a project and it's rock solid.
Spray - In my latest project I'm using Spray and I'm extremely happy. The latest releases are built on Akka 2 and you can run it directly with the Spray-can library which removes the need for a web server. Spray is a set of libraries, rather than a framework and is very modular. The Learn about Spray: REST on Akka video gives a great overview, and this blog at Cakesolutions shows a really nice development approach and architecture.
UPDATE 3:
Life moves pretty fast. If you don't stop and look around once in a while, you could miss it. - Ferris Bueller
These days the choice has become simpler. In my humble opinion Spray has won the battle. It is being integrated into Akka to become the next Akka HTTP. I have been using Spray now on multiple projects and can honestly say that it's fantastic and best supported software I have ever encountered.
This does not answer the initial question, but at least gives some indication on why Spray seems like the best choice in most cases. It is extremely flexible, non-blocking and very stable. It has both client-side and server-side libraries and a great testkit. Also, have a look at these stats to get an idea on performance: Web Framework Benchmarks
I personally started with spray a long time ago and tried everything else there was out there for Scala. While Scala, spray, akka, shapeless, and scalaz certainly have a bit of a learning curve, once you start digging in and really learning how you are supposed to use the technologies, they make sense and I immediately saw the benefits especially for the kind of work I'm doing right now.
Personally I think nothing really stands up to spray for building both servers, rest apis, http clients, and whatever else you want. What I love about spray is that they built with akka in mind. It may have been a really early project when I first started using it, but the architecture made sense. Those guys knew what they were doing in terms of exploiting the benefits of using an actor model and not having any blocking operations.
While actors might take a bit getting used to, I do like them. They have made my systems very scalable and cheap to run because I don't need as beefy hardware as in the past. Plus, spray has that spray-routing DSL so making a rest api is relatively simple as long as you follow the rules ... don't block. That of course means don't go and pull in apache commons http client to make client requests from the api or actors because you will be going back to blocking models.
So far I am very happy with spray, typesafe, and akka. Their models just naturally lend themselves to building very resilient systems that come back up on their own if anything should happen and you take a fail-fast approach. The one beef that I have with spray (and it's not spray's fault) is the damn IDE support for the routing DSL. I absolutely despise Eclipse and have always been an IDEA user. When I started using the Scala plugin, everything seemed ok. Then my routing dsl naturally evolved into way bigger beasts. Something about the way IDEA parses that code makes it shit its pants anytime it encounters anything with spray-routing or shapeless. It's to the point where it's unusable (I type 2-3 letters and have to wait 5 minutes to regain control).
So, for any spray-routing or heavy shapeless code, I fire up emacs with ensime, ensime-sbt, and scala-mode2. Now if I could only get a Cassandra library with the quality of astyanax and built using a more non-blocking architecture.
Here you can find a great list of scala resources with a brief description of all the alternatives you listed.
From my own experience, I use Scalatra and it is tiny, simple and effective for things like uri mapping and calling web services.
I'm curious what's the "best" way to program RIAs with Scala.
I'm new to Scala and would simply like to know where to start learning. It seems obvious that for web-apps Lift is the perfect choice to be combined with Scala. However from what I've seen so far Lift is not really providing the key to great visuals. Certainly there are hundreds of possible frameworks due to the compability with Java but that's not very helpful.
What would you recommend ?
What is a common set-up ?
Among others I found cappuccino, a very impressive framework.
http://www.scala-lang.org/node/7281
It just seems like Cappuccino is designed for a language named Objective-J. That doesn't sound like great compability to me. Yet somehow they can work together.
http://frothy.liftweb.net/
Well, if you are new to Scala you should probably try Play, because learning a web framework and a new programming language is hard.
Play has a big community and seems to be quite user-friendly (pressing F5 in your browser reloads your code and displays any errors which have occured).
Normally any Java web framework can also be used in Scala, but Play seems to be pretty Scala-friendly.
There are quite a few Scala-specific web frameworks too, but I don't know enough to tell you more about them.
Lift is an powerful and impressive framework, but certainly nothing for beginners.
(I assume "new to Scala" doesn't mean "I programmed in Haskell, ML and Scheme for decades").
Of course it all depends. Personally, I have had no problem starting with Lift even though I’d only used Scala in the REPL before and just for some toying around to get to know the syntax.
It certainly helps a lot if you already know how to use collections in a functional way without explicit loops, so you can read and understand other people’s code more easily. But basically, I’d say it is doable learning both Lift and Scala at the same time even without a background in functional languages. It’s just the collections thing you’ll have to get used to and if you happen to know Ruby (or a language with list comprehensions) you’ll easily understand it.
The Frothy integration has not yet been updated to the newest version of Lift and I don’t know of any site which actually uses it but maybe this is a thing to ask on the Lift mailing list. In any case, I think Frothy only helps you connecting a Lift setup with some Cappuccino frontend but does not provide many wrappers to the Objective-J code, so you’ll still have to write code in Objective-J.
At that point you can ask yourself: Why not write the whole thing with Cappuccino and decide afterwards if Lift integration is actually needed.
Considering Lift alone: You certainly can use Lift with some UI Kit like JQuery UI for the visuals. Lift has many advanced possibilities which make it possible to build complicated web applications but you’ll have to care about the wiring for the visuals yourself.
(And arguably, a stateful, non-MVC (‘view first’) framework like Lift might be better suited for a rich internet application than a pure MVC framework…)
we are considering Scala for a new Project within our company. We have some Junior Programmers with only PHP knowledge, and we are in doubt that they can handle Scala. What are your opinions? Some say: "Scala is a complicated beast!", some say: "It's easy once you got it." Maybe someone has real-world experience?
"My coworkers will not understand Scala" is simultaneously overstating its difficulty and insulting your coworkers.
Scala is not that difficult. It's just another programming language. Any trouble that junior programmers have with Scala is going to be more or less the same trouble they would have with any other language.
Your coworkers are smart. Of course, I don't know them, but it's a pretty safe bet unless your company is the kind of organisation that hires stupid people, in which case, you have bigger problems.
That said, at my company we have some core products developed in Scala, and we don't find that people have any more trouble with it than Java. The code is generally more clear and concise, easier to generalise and reuse, etc.
I guess Scala could be used as a "beginners" language. Even though there are tricky ideas behind it, you dont have to use/explain them in the beginning. If you explain pure OO with Scala, I would say it is straight forward and easily understandable. As Scala reduces a lot of code overhead from other languages it might even be easier to learn concepts with Scala than with Java/C++.
A major drawback I see with Scala as a beginner language is the lack of documentation. Don't get this wrong, the official Scala doc is very good and also the few books that are available are quite useful to get the details of the language, but those have not been written for beginners. For example in Java you find hundreds of books titled something like "Learning OO with Java" you wont find that for Scala which may be a show stopper.
As Hannes mentioned, only do new language introductions within research projects and not productive or even flagship projects. If you have some juniors, that makes the situation even better, take some internal tool, you always wanted and needed and let them create it during a research project. This is also a nice opportunity to experiment with different development-processes. And your juniors most probably like to be challenged and will deliver a good prototype and a very well proofed opinion if Scala can be used as a beginner language.
I believe that most people moving to Scala are experienced and enthusiastic coders. I'd suggest that you get in-house experience with a Scala project with your senior programmers first before forming a strategy for mentoring your junior coders. I'd also suggest that you only involve people who are eager to join in.
I would advocate it. But with the proviso that you have clear guidelines on what language features are acceptable for your team. For example, coding primarily in an imperative style (which is familiar for Java-trained people), or perhaps limiting the employment of recursion or closures.
Also plan for seniors to mentor the juniors. This may take the form of any combination of: pair programming, code reviews, info sessions, regular discussion forums, etc.
The opportunity that scala presents for vastly improved coding on the JVM is too great to pass up. When your seniors get into it I would not be surprised if they find renewed passion for development. When your juniors get into it they will be learning best practice JVM development from the start.
If you choose to go this route, perhaps they'll find easier to use the Scalate framework than a more traditional one like Lift, since it allows mixing HTML with Scala, much in the same way as PHP works.
Scala is a very 'normal' programming language. Any programmer should be able to learn this language. The people that have difficulties learning Scala mostly are experienced with imperative languages and are surprised by the functional concepts. So unexperienced programmers may learn it even faster. In my opinion should be no problem, to assign it to juniors. From a management point of view, I would assign a junior and a senior developer as a team (or more of both, depending on the size of the project).
I think it depends whats more importent for you. If you want to learn as possible about OO Programming and the standard stuff its a bad idea.
But what you really give them is a opportunity to learn something really cool and unique. Witch can be good motivation. Scala has many cool stuff in it. If you can handle Scala you can handle a lot of otherstuff as well.
Talk to the Programmers (all of them) and tell them why you wanne to use scala. Ask if the have to motivation to make and learn something not everybody can do and go the extra mile?
If the are go with it!
My initial thought would be that Scala will be too heavy for them but then I guess because Scala is an OO/Imperitave/Functional hybrid, one could introduce them to the OO/Imperative part of scala until their comfortable, but then again they will probably have bad PHP habits in Scala since scala authors mostly prefer the functional style over the imperative one.
So, it could work, but I would do it for a research project, and definately not for a flagship one.
Edit: Perhaps this should be said also: It seems that functional/OO hybrids like Scala is becoming more popular especially because of how functional languages handles parallel processing as opposed to how we know it in languages like in Java. The amount of cores found in a chip is increasing rapidly, so this is important. However, mentioning PHP, it seems that you are developing web server scripts where threading is less important. PHP doesn't even have threads.
This raises another point. Do you want to develop Scala Web applications i.e. Lift. If so then you have a doubled up learning curve which should also be considered.
Imagine that you would have picked Java and asked whether they could handle Java. If your answer is they could, then they can probably handle Scala.
Scala is only marginally more difficult due to:
No great IDE support. The support ranges from poor to good. Not necessarily an issue for a PHP programmer.
Documentation not as rich as Java
Both Java and Scala have new challenges for a PHP programmer (JVM, new libraries, compiled language, statically typed).
I don't think Scala is a complicated beast, but you do need to understand some of the syntactic sugar and design principles, which would be true of learning Java as well.
Yes, if...
Strategic decision has been made to go with Scala
Company can handle the hit (financial and time) that will come from the steep learning curve.
No, if...
No senior Java, C# or C++ programmers can be put on the project too
Can't find a Scala programmer to act as a lead
Programmers don't have the patience to learn Scala or deal with a language where Jars (libraries) are scattered all over the place, rather than in one or two neat packages like PHP.
*Note: if the junior programmers were C++, C#, or Java Software Engineers rather than PHP, then my answer would be different like, Go for it!
I would not recommend it. My experience of Scala is only from homebrew projects, but I would imagine the currently lousy IDE support, quite frequent API changes and a very flexible syntax (that allows one to hang himself and everybody else participating in the project) would cause a lot of problems in a bigger, more official project.
Give them IntelliJ and throw 'em in the deep end.
Here is a blog post I recently stumbled upon:
http://james-iry.blogspot.com/2008/07/java-is-too-academic.html
It shows that even Java can be too academic to be understood by programmers which have no experience in functional programming. On the other hand, Scala allows to write code the "imperative way", so you can avoid all the FP stuff if you do not understand it. In my opinion, Scala is much more concise than Java, so I guess a "junior programmer" should be able to handle it.
I've been asked to run a workshop and coding dojo soon for people to try out Scala and try to build something with it. The attendees are all going to be new to Scala, and could come from any of a number of languages (I'm presuming they can code in at least one mainstream language - I'm including syntax comparisons with Java, C#, Python and Ruby).
Part of the appeal of Scala is that it's practical - you can use it as a drop-in "power Java" (Java with less syntactical clutter, closures, immutability, FP, traits, singleton objects, nifty XML handling, type inference etc.) that still runs on the JVM (and on the .NET CLR supposedly) and doesn't require you to change build tools, server infrastructure, libraries, IDEs and so on. Most of the katas I've seen have been fun but not 'real world' - mathematical challenges like Project Euler and so on. These don't seem appropriate as we're trying to explore the use of it as a practical, real world language that people could consider using for both hacking and work, and because people aren't necessarily going to be too familiar with either the deeper parts of the Scala syntax or necessarily of the concepts behind functional programming.
So, has anyone come across any more practical, everyday katas rather than arithmetical 'problem solving' ones? Katas, that is, that can test whether the language, libraries and tools can satisfy the use cases of the actual day-to-day programming most people have to do rather than testing out. (Not that the impractical ones aren't fun, but just not appropriate for the kind of thing I've been asked to run.)
If I can't find good examples, I'm thinking that it might be useful to try and build something like a library catalogue - the event is for programmers who primarily work on building infrastructure for universities (and in education and culture - museums, galleries, schools, libraries and so on). It's a bit boring though, but it's the sort of thing that the attendees work on in their day-to-day existence. Any suggestions?
There is a creative commons licensed introductory training course with hands-on exercises here:
http://github.com/javaBin/scala-training-slides
http://github.com/javaBin/scala-training-code
The slides are in Open Office format. If you don't have this installed, you can upload them to SlideShare, which will convert them for online viewing.
Most of the programming examples in my blog are, effectively, coding dojo exercises. Particularly the matrices series, but also the puzzles and 99 beers. Now, don't disregard the matrices series as being "mathematical", because the problems I concern myself in it are related to the construction of classes in Scala, not to doing fancy algorithms. In fact, I pretty much skip over the mathematical algorithms themselves.
Now, 99 Scala Problems and pretty much everything from Project Euler are nice exercises for the functional part of Scala, but I understand that not to be your emphasis. I do recommend retronym's answer. Rosetta Code, not being functionally oriented, might have more general examples. There are many with Scala examples, of course, though you may wish to consider other tasks as well, for ideas.
There's lot of cool things to learn about Scala, but one has to be careful at beginner level. For instance, I would not speak of dependency injection (self types and the cake pattern) or of type classes (the pattern that simulates such with implicits).
Do look as well at the material on the Scala Lang site, particularly the Scala by Example document.
EDIT
I have now overseen several Scala dojos, so here's a bit of stuff I've learned from then:
Problems: they have to be fun, not-quite-easy, not-that-hard, and that has to be everyone's opinion.
We use the Dojo Puzzles site, which is in Portuguese so it won't be of use for most people here. If there's a similar site in English, I'd love to hear about it.
The way it works is you ask for a random problem, look it over and discuss to see if you'll pick it up or not, and then indicate by saying you'll use it, you'll not use it, or maybe you'll use it but you'd like to see another one. This vote gets registered and you can see how many people picked up a problem, which helps deciding whether to pick it up or not in first place.
Scala knowledge: it turns out it's not that important to introduce key concepts of Scala language beforehand, particularly if some of the participants have basic knowledge.
In my experience, setting up the testing environment with a trivial "pass" test and explaining how people should write the tests is often enough to get people started. If you feel someone is struggling to write something, give a quick explanation and get on with it.
Teaching Scala: if you do set out to teach Scala, keep lessons short and follow up with a dojo. In this case, keep a set of dojo problems that are adequate to the lesson, and, depending on how many lessons you want in one day, short.
It helps imposing artificial constraints on how one must solve a problem. Some examples of constraints I have put in practice are no classes and single-expression methods (that is, no multiple statements or val/var declarations). The point of these constraints is making it impossible for people to solve the problem in the way they are used to, which gets them to explore the language in search of alternatives.
I have the final results of three dojos done at my current job in this repository.
At the moment we are using the Randori Kata format, but without fixed time or break, and with retrospective at the end of the dojo, not at the beginning of the next. This, however, is just were we are currently at -- we have experimented many variations, and we are still evolving.
Perhaps you could have a look at the Ruby Quiz material for inspiration.
Take a look at Scala by example from Martin Odersky (creator of scala)