Scala in Malvern, PA offers their digital signage software which provides Designer for content design, Content Manager for content organization and control, and Player for content viewing. Notably the software supports a wide array of digital signage including touchscreen kiosks and service for direct customer engagement and interaction.
Well suited: To most of the local run of datasets and non-prod systems - scalability is not a problem at all. Including data from multiple types of data sources is an added advantage. MLlib is a decently nice built-in library that can be used for most of the ML tasks. Less appropriate: We had to work on a RecSys where the music dataset that we used was around 300+Gb in size. We faced memory-based issues. Few times we also got memory errors. Also the MLlib library does not have support for advanced analytics and deep-learning frameworks support. Understanding the internals of the working of Apache Spark for beginners is highly not possible.
If you are in the data science world, Scala is the best language to work with Spark, the defacto data science data store. I think that is really the main likely reason I would ever recommend Scala. Another reason is if you already have a team of programmers familiar with functional programming, e.g. they all have years of Haskell experience. In that case, I definitely think Scala is a superior and faster-growing language than Haskell and that picking up Scala after Haskell should be quick.
The built-in compiler, scalac, is sssssssssslllllooooowwwwww. I mean like, if you thought the Java compiler was slow, try Scala! The default compiler on my 12k line codebase takes 4 minutes to compile from scratch on my i7 quad-core machine. This can be mitigated through the paid solution of Hydra which compiles your code in parallel. Unfortunately, it's quite expensive and your legal department or finance department may not approve of it. But if they do, for me, it reduced my compile time down to 80 seconds, much more manageable.
Scala is not going anywhere and support for it is slowly dying. This is the main reason I would not choose Scala for my next company or project. Important Scala libraries such as secure social (which is used for OAuth, a major requirement of every web app) are hardly maintained. Another library that suffers from lack of updates is Slick, the database mapper. There aren't enough engineers working on it to even provide support for the new features that came out in Postgres 9.0 (e.g. JSONb). There is simply not enough of a community to drive Scala forward and keep 3rd party libraries up to date as Java world does it.
As a corollary of a stagnant community, hiring Scala developers is hard as well. Of the 30 backend engineers we've hired, only 3 came in already knowing Scala. And as I will mention below, this is a BIG problem because learning Scala is really tough.
The learning curve for Scala is very, very steep. Anecdotally, I came into my current company with strong Java experience. Java is the closest language to Scala but it took me 6 months before I stopped needing to pair program on easy tickets. It doesn't help that Scala has some weird syntax like Map[A, +B] and that it forces you to do functional programming.
The only thing I dislike about spark's usability is the learning curve, there are many actions and transformations, however, its wide-range of uses for ETL processing, facility to integrate and it's multi-language support make this library a powerhouse for your data science solutions. It has especially aided us with its lightning-fast processing times.
1. It integrates very well with scala or python. 2. It's very easy to understand SQL interoperability. 3. Apache is way faster than the other competitive technologies. 4. The support from the Apache community is very huge for Spark. 5. Execution times are faster as compared to others. 6. There are a large number of forums available for Apache Spark. 7. The code availability for Apache Spark is simpler and easy to gain access to. 8. Many organizations use Apache Spark, so many solutions are available for existing applications.
The customer service team is very responsive and usually returns calls or emails within a couple of hours of placing a request or inquiry. Just about every rep I've spoken to has been very thorough and helpful, walking me through each problem and explaining the solutions in a way that's easy to understand.
All the above systems work quite well on big data transformations whereas Spark really shines with its bigger API support and its ability to read from and write to multiple data sources. Using Spark one can easily switch between declarative versus imperative versus functional type programming easily based on the situation. Also it doesn't need special data ingestion or indexing pre-processing like Presto. Combining it with Jupyter Notebooks (https://github.com/jupyter-incubator/sparkmagic), one can develop the Spark code in an interactive manner in Scala or Python
Faster turn around on feature development, we have seen a noticeable improvement in our agile development since using Spark.
Easy adoption, having multiple departments use the same underlying technology even if the use cases are very different allows for more commonality amongst applications which definitely makes the operations team happy.
Performance, we have been able to make some applications run over 20x faster since switching to Spark. This has saved us time, headaches, and operating costs.
Negative: slow engineer onboarding. As I mentioned before, it took me 6 months to get up-to-speed on Scala and didn't need to bother more senior Scala engineers anymore for help with every ticket. That's hundreds of hours I wasted of myself and other engineer's time.
Positive: thread safety, no concurrency bug. The ROI on this one is really hard to calculate, but I do believe Scala has saved me hundreds of hours over the past few years by allowing me to never have to worry about deadlocks or race conditions. Scala is simply so safe we've never had race conditions within the JVM before.
Negative: third-party libraries aren't maintained so we have to fork and update them ourselves. As I mentioned before, we use Securesocial but it stopped receiving updates and there is simply no alternative to it. So, we forked it and put an engineer on it for a month to get it back up-to-date. What a waste of his time!
