However, if you are happy with your current working language and are, instead, looking for a language that will let you grow as a programmer...well, for that sort of approach I'm not so sure Scala is the best you can do. This is just anecdotal, but I've noticed a trend where someone does something cool in Haskell, and then says "oh yeah, and with a few adjustments and given a couple of caveats, you can do it in Scala like so...". In other words, it seems to me that more of the innovation is happening in other languages and then its being brought back into Scala as almost an afterthought.
I have seen some hints that this is changing, and so I definitely won't write-off Scala. At the same time, there are an awful lot of interesting languages out there if you're looking to grow as a programmer...
My money is on Jetbrains' Kotlin as a significant but manageable step forward from Java. Given its pedigree I expect it to have tooling support that no other JVM language can match.
Of course, Scala creator Martin Odersky completely rewrote Scala after version 1.0, and even in version 2.x, has considered fixing stuff between point releases to be more important than backwards compatibility, so Scala similarly ought to be quite polished by now (version 2.10), in both feature set and implementation.
Looks like a simple yet powerfull language. While still remaining type safety. Going to look into it!
2.9 manage to not change the language much, AFAIR, but now 2.10 gets macros, string interpolation, implicit classes, value classes, and a whole new concurrency framework.
All cool stuff, but the nonchalance in adding more and more things makes me uncomfortable.
 yes, I know, "experimental"
However it is not correct to say that Haskell is more expressive than Scala. It is in some ways but Scala is more expressive in others. There is a paper that discusses type classes in Scala and show they have some advantages over Haskell's implementation. As more people use Scala and discover neat things you do in it, this is feeding back into other languages. For example, here's the mighty Oleg implementing the cake pattern from Scala in Haskell: http://okmij.org/ftp/Haskell/ScalaCake.hs
No. Even if you just mean the FP (functional programming) community this isn't true, and it's definitely not true for the whole of SIGPLAN.
Still, I think Scala is first and foremost a practical language. Straying too far from that as a primary goal would probably be harmful in the long run (i.e. driving a Ferrari might be fun, but you're not going to buy one for the daily commute).
It's definitely at a good intersection of "useful" (all the JVM stuff) and "nice" (you can be functional or imperative, writing DSLs are super easy, etc).
- Its not objective: It's from Typesafe. Logically they are not going to mention the negative sides of Scala
I used Scala myself and I think it is a very good approach to combining functional, imperative, object oriented and type safety in one language.
But the big downside is complexity: Scala is utterly complex, its has all the features of java. But it simplifies the object model (everything is an object), that's a good thing. But the type system? Really complex. Making compile time errors very difficult to understand.
A shift to functional style programming is happening more and more. But I think, and hope, there will be a complete paradigma shift from imperative to completely functional. This should start with universities starting with lambda calculus and functional languages to 1st year CS students.
Functional programming has the simplest execution model, is one of the best to reason about, and works very well with current multicore systems. That's why i'm spending more time on learning Clojure than learning Scala. In the end a language like lisp is much simpler but the paradigma shift is what makes it a bit difficult for those imperative programmers like me.
In the end a language like lisp is much simpler but the paradigma shift is what makes it a bit difficult for those imperative programmers like me.
It's not very fair to compare Scala with Clojure - static typing might not be everyone's cup of tea, but over time, I have come to appreciate it's power when dealing with certain classes of problems.
I'm not disagreeing about the complexity, but you can choose
to use a sane subset of the language and do away with all
the other stuff.
0. Of all the "new" languages Scala has the best selection of libraries and I think is the easiest to become instantly productive in. Languages like Rust and even to some extent Go are also really exciting and let you do great things, but the native library support isn't as robust as it is for Scala, and Rust in particular is still under heavy development and isn't really ready yet. From a stability standpoint you should be OK with Go, but even it will be baking in more stuff and changing more then you will see Scala change.
1. The Productivity Boost Effect. You will find you can solve complex problems with a few lines of code and a little thinking. I have ported 1K+ lines of C++ to 10 or 20 lines of Scala
2. Personal Growth. If you are coming from C++ or Java and have done Imperative programming your whole career then Scala is a _gentle_ introduction to functional programming. As you start to use the language you might start by using it as java and only typing half the character ( no type signatures ,semi-colons , or in some places parentheses ) as you do more things and look for elegant solutions the function patterns will become obvious in their usefulness and you will start seeing their value first hand.
3. Awesome Libraries you get access to. I think immediatly of things like Akka, Twitter Storm , Play2 , and my personal favorite Spark. Not that there aren't great libraries in other languages and most if not all of those expose themselves to Java and other languages, but its great using the native language they were designed for. you can do some great stuff.
4. Finally its better then spending all day reading and commenting on Hacker News. :-)
> I have ported 1K+ lines of C++ to 10 or 20
> lines of Scala
a) Rewrites are usually more succinct simply because you've done the legwork before; a second solution is almost bound to be more to the point.
b) One wasn't using the initial language properly.
Sure, going from C to Haskell may lead to insanely compressed code, but C++ in conjunction with its mature standard library, Boost, and the multitude of libraries available is such an advanced and excessively paradigm-spanning language that a reduction by not one but two orders of magnitude suggests a less than perfect first draft.
Another issue is the fact that it interacts with the JVM. Short answer, it seems nice, but if you're functional, you can't really use the 3rd party libs because you can't be sure they will play well in the functional world. Long answer is here. http://talesfromannoyance.blogspot.com/2012/05/why-im-lookin....
I'll probably double back to Scala at some point, but I think a language off the JVM is a better option. Or at lease one that is so odd to the JVM that most people will only look for libs written in that language. For that I assume Clojure is a better choice.
Or C++. Brilliant programmers will undoubtedly do brilliant things with it, but for a lot of folks, the word "multiparadigm" might as well read "radioactive." It's true (as someone above noted) that you can use a useful subset of the language and discard the rest, but weak programmers seldom choose correctly, and so we're left with steaming piles of spaghetti everywhere.
Ten years ago, I would have been thrilled reading Odersky's book. Nowadays, I die a little inside every time I see the phrases "language feature" and "syntactic sugar" in a language manual.
I hate to speak the Word of Curse, but this was why we used monads. They gave us something of an effect-typing system in which to wrap calls to side-effecting third-party libraries.
It's true that Scala DSL is scary. As far I know soon (version 2.10?) you will have to add a compiler flag to enable some scary stuff. They are useful for library developers, but not too great for everyday apps.
Also you don't have to use the functional part. I saw plenty of code that looked like a nicer Java. You get less boilerplate and better performance - see http://news.ycombinator.com/item?id=2615096
Edit: The article you linked says: "... one call to some open source project that didn't worry enough about threading to even warn the user that the object is not thread safe."
This would fail in any language, including Java.
The fact is Java interop is a fundamental feature providing great pragmatic utility as well as an absolute prerequisite for any kind of adoption of these languages. It's basically the opposite of "hype."
There are 1000s of great and well tested components available. Apache, IBM, Yahoo etc. invested years in these, most of the time it just works.
There might be some libraries with issues, but so far I had only good experience with everything from security (bouncycastle) to PDF processing or geocoding.
I think if you look at just about any common example of idiomatic Clojure code you'll find Java interop sprinkled all over the place. People aren't going to reimplement all those libraries in Clojure, Scala, or whatever other JVM lang you're targeting. Seamless interop is a prerequisite. I think most Clojurians feel it yields far more benefit than any problems it might introduce.
Coursera has a Scala course from Odersky that's worth giving a shot: https://www.coursera.org/course/progfun
Eckel's Thinking in Java was a classic, I suspect he will this one out of the bag too.
The Odersky book is good as a reference, but not a great teaching tool, its too big. I watched the video lectures, they're quite good if a little dry and occasionally quite abstract especially if you're trying to apply Scala to real world problems.
Be warned though interop isn't perfect between Java and Scala, sometimes you have to resort to tricks to make things work, Hadoop APIs being a good example.
For more links, visit http://typesafe.com/resources
the other good starter book: http://horstmann.com/scala/
detailed looks, all angles: http://www.manning.com/suereth/
You can get it for free from Typesafe: http://typesafe.com/resources/book/scala-for-the-impatient
More than 10: http://www.quora.com/Startups/What-startups-or-tech-companie...
Getting hired by any of these companies can be a good enough reason for some.
- If you're average or below average developer: the language does not matter. Focus on algorithms and read other people's code a lot.
- If you are using anything other than Java: consider testing Scala ( * ). You might learn great new ways of writing code, especially if you never used Functional Programming before.
- If you're above average developer programming in Java: you have to learn Scala now! Soon having "Java" on your resume without "Scala" will suggest "this person's skills are outdated" or "this is a junior developer".
( * ) I just put together a small starter project, no dependencies:
It's just for convenience: it will automatically install Java, Scala and dependencies. Run it and you don't have to hunt down anything from the web.
If you have SBT already installed (with homebrew, MSI, apt-get etc), you don't need that file at all.
Main.scala is a "println", Build.scala sets some compiler flags and project name - this is all.
About "Unit": Scala is strongly typed. In exchange you will not have run-time type errors and also you don't need type checking unit tests.
Java and Scala have essentially the same bytecode output as both compilers were written by Martin Odersky.
There are many links below: free books, PDFs, articles, videos, tutorials.
Or just Google "The busy Java developer's guide to Scala" (article), "Scala for the impatient" (PDF), "A Tour of Scala", "An Introduction to Scala for Java Developers" (about REPL) etc.
Speed-up is part of the roadmap: http://blog.typesafe.com/getting-down-to-work
I did scala in IntelliJ. The lack of tooling reduces the value a lot. I almost prefer plain java over the sheer simplicity it has comparatively...
The sbt 'directory of configuration' was always a bummer for me. The single pom.xml is a nice mechanism. Also maven has good CI compatibility.
The way I think of it is that maven has a good way of specifying a build. The mvn command is the slow, but complete, way of building. The normal development lifecycle is to load your maven model into an IDE then go from there, using IntelliJ's incremental build support, etc.
SBT in other words, solves a problem I don't have.
The other major problem is last year, SBT was a fucking train wreck between 0.7, 0.8, 0.9 and 0.10. Now that we are a YEAR out from that yeah sure maybe it's a lot better. I'd give it another year before I'd seriously try it again.
In the mean time, I am more interested in kotlin for sane static typed JVM languages, and clojure for real functional sauce. Scala is too slow for me :-/
I actually like 'directory of configuration'. The SBT build configuration is actually an SBT project itself. So you can use a lot of the same tools to trouble shoot the build configuration that you would use to troubleshoot the build itself. Also, this means that in some cases (such as multi-project builds) you can use much fewer files.
I'm not sure about CI compatibility. I know that Jenkins/Hudson have SBT support but I have never tried to use it.
I actually think that way that most IDEs interact with maven builds is less complete than what you have with SBT. For example, frequently you need specify your build configuration again if you want your IDE to do incremental compilation or to run individual tests. This can be very painful if your build contains anything out of the ordinary. With SBT you just attach a remote debugger to a long running SBT process and then let SBT due all of the building and running. It takes care of the automatic incremental compilation and lets you run individual tests (which, unlike most IDEs, it can be configured to run tests automatically and it can probably run them much faster).
I can certainly understand if the previous 0.7 to 0.10 jump made you nervous about SBT. However, I think that SBT has matured a lot in the year and a half since then. I think it has finally reached a stability point where it is ready for general use. In particular I think the 0.12.x series is where this finally occurred. It has now has a steady release process and has fixed issues that SBT (along with Scala the language) had, in the past, with binary compatibility.
EDIT: lost a bunch of text in the submit, had to retype
There are three types of sbt config files: .properties, .sbt, .scala.
* .properties: pure key-value text file
* .sbt: SBT DSL
* .scala: full valid Scala code
I found this little nugget buried deep in the old SBt Github wiki. Now that SBT has its own website, its partially explained in the first few lines:
* .sbt build definition uses a Scala-based "domain-specific language" (DSL)
* More advanced .scala build definitions and extensions use the full flexibility of unrestricted Scala code
Personally I find the SBT Scala file much simpler than a Maven XML.
intellij is really a much better experience in developing than eclipse. Lots of fit and finish things, also intellij is very keyboard-centric, so whereas eclipse had lots of graphical widgety things, intellij has all your normal day to day stuff fully keyboard accessible. It's the closest to emacs in an IDE I've ever seen.
To me, I had to give up scala due to lack of tool support. Maybe if you are used to an emacs/gcc paradigm, but I've gotten quite productive in intellij, as much or more than any C++-styled development. Why have another window with compiler output when you could have it inline with the code and using the typographic features?
I could go either way, but with Java, intellij I have 'develop and run anywhere' going on. Sure there are some super edge causes at the highest performance profiles, but that is always hardware specific, and unless you are developing on the same server class boxes you wont find it.
I find that it works pretty good (although obviously not as good as the built in maven support).
If you change a public method, SBT will recompile all users of that class even if they don't use that method. If you change a private method, it's smart enough to recompile only the one file.
Annotating your return types both saves the compiler the effort of figuring out what you meant, and also prevents you from accidentally changing the return type and forcing recompilation of a bunch of client code.
The article seems to imply Scala jobs are taking off (19 pages). Are Scala jobs really outpacing Clojure and Haskell?
(To get more accurate results, you should search in-title or by tagged skill.)