The real question: is it worth it? Up to now I could successfully avoid learning Scala. My problem with it is the complexity that the language by itself introduces and the readability of code that comes out at the end. Maybe I am just valuing simplicity too much when it comes to programming languages. Anyways thanks for the impatient guide!
It's the best language going these days, IMO; it's a real sweet spot in terms of power, flexibility, maturity, ecosystem and learning curve. It's not the best at any one thing but it's the best overall language. Haskell is possibly more powerful, but it's (for many people) harder to learn and doesn't have quite the same library/tool support. Ceylon (or Idris) is probably better designed, but you won't find much in the way of libraries for it. OCaml brings shorter startup times, but worse throughput and a smaller community. F# might be a little more elegant and have good tools, but it doesn't have the same power.
I have done a lot of Ruby work and a lot more JavaScript work (not one of the languages you mentioned, but I consider it a similar language to ruby/python). I find Scala to be a lot more enjoyable to use compared to them. It's probably my favorite language so far.
I never thought I would like statically typed languages, but now I don't know how I can live without them.
Scala is also more functional than Ruby or Python. I use it in a hybrid OO/Functional style. I probably lean 80-90% functional though.
As for people complaining it being hard to read, I disagree. Sure, some people try to be clever and play the, "how much can I reduce this code down to as few lines as possible" game. But if you break things out and not chain too many combinators or use too many symbolic operators, it can be readable. I don't find it any more difficult or easy compared to any other languages out there. It's just how you write it.
I think the biggest hurdle is to find a good mentor to give you the ah ha! moment when learning Scala (or any other functional language). I don't think many people can learn it by themselves. But once someone shows you how you can write your app in a more functional way, you begin too see some of the benefits of FP.
Very similar-looking when used with taste (unfortunately some libraries have a culture of using unreadable symbols and poor documentation, but that's changing), so you get the conciseness and readability of Python or Ruby (indeed better - I wish Python would adopt the "_" syntax for lambdas), but with greatly improved safety (and performance), or equivalently with the same level of safety for less testing.
I assume you know this, but it warrants saying explicitly: Scala is statically typed, while Python and Ruby aren't. This has immediate practical implications which for many people (on both sides of the divide) are A Big Deal.
In terms of elegance and succinctness, Scala is somewhere in the middle between Java's bureaucratic verbosity and Python's terseness.
Scala code will generally have a slightly lower LoC than Ruby IMO. Maybe 20% overall typically. And the lines will be longer.
Ruby forces new lines for many expressions that Scala doesn't. (Think class with accessors vs a typical case class.) as things get more advanced, Scala allows you to express things that can be very difficult or awkward in Ruby. Like function composition, currying, pattern matching.
There's not really a case where a Ruby program will typically be shorter than a Scala program (well, excluding imports since there's no shared global namespace in Scala), even if you're avoiding typelevel style programming.
Yes - I have substantial experience with both. The differences from those are wider (and the advantages - or what others may see as disadvantages - clearer) - I felt it was more useful to compare against more similar languages where people would be more likely to be choosing between them.
"Java
Python programs are generally expected to run slower than Java programs, but they also take much less time to develop. Python programs are typically 3-5 times shorter than equivalent Java programs."
I think Python performance wise a less attractive options than Java or Scala. At least according to the authors. Development time is a different question.
Absolutely - if I could reliably write correct code first time then Python might well be a better option. Reduced debugging time is my biggest reason for preferring Scala. In particular the ability to refactor with confidence is exponentially helpful (you can keep your APIs clean and clear, which feeds back in and helps prevent mistakes). Having the safety of a typed language without having to sacrifice any of the clarity of Python was a real revelation.
If you have to use the JVM and don't want to code in Java, your options are Scala or Clojure (maybe Groovy?). Then it comes down to essentially the tradeoff between a static typesystem vs macros (imho, ymmv etc).
I second the reccomendation for Chuisano and Bjarnasaon's "Functional Programming in Scala".
Kotlin and JRuby appear to be your next best options after Scala and Clojure. Both have growing user communities (thanks to Rails in the case of JRuby and Android in the case of Kotlin). Both solve the library problem by offering seamless compatibility — with Java and MRI (with some caveats [1]) respectively. If you start a long-term project in JRuby you'll be able to hire Ruby programmers down the line. Kotlin is a less safe bet in terms of hiring but I except its prospects to become clear soon, probably within a year.
Apache Groovy is really for those quick'n'dirty scripts manipulating and testing Java classes -- that's its original use case. Later it added a MOP so Grails, a knock-off of Rails, would work, though Grails use is fast waning -- not many people upgraded their websites to Grails 3, or start new projects in it. Gradle then started using it as a DSL, so there's now a few thousand sites using the non-Turing Complete features of Groovy in 20-line build files. When Groovy 2 came along with static compilation and eventually targeting Android, not many people upgraded, prefering to stick with Groovy 1.8. The programmer who put the static compilation into Groovy now works at something else, and no-one's replaced him. So really Groovy's not a contender for building systems in the way Scala or Kotlin are, which were both designed for static compilation from the ground up. Nor does Groovy have syntactic macros the way Clojure has -- you need to write screes of Java code to implement a single annotation.
What about Kotlin? Its 1.0.0 has been recently released and comes as "pragmatic" Java, bringing a lot of useful features and having more concise yet readable syntax. Also, the Java interop is really good (better than that of Scala, for instance).
The Java interop is worse than that of Scala - Kotlin can't represent Java's variance (i.e. existential types) so it has hacks to avoid it. It doesn't have the maturity or ecosystem of Scala. The "pragmatic" design feels like they took a grab-bag of features from Scala and implemented all the simpler use cases individually, with no appreciation for the underlying coherence; IMO the language will not be able to evolve because it has too many special cases. And Ceylon does everything it does but better. Kotlin is a triumph of marketing hype, nothing more.
What do you mean by inability to represent existential types? Kotlin has in/out/star projections, which are be used for corresponding Java variance. A note about Scala interop: forget the existential types, in Scala I cannot simply use interfaces with bounded type parameters without some dirty hacks, just because compiler will generate weird errors and/or incorrect bytecode. I am sorry, but this makes it just impossible to work with Java in Scala.
The whole point of Kotlin is that it does not need its own ecosystem - it is intended to be used seamlessly (unlike Scala or Ceylon) and, like, today with all existing Java libraries and frameworks. Sure, more idiomatic solutions would always be nicer to work with (and they would probably appear at some time), but you do not need to wait for them - just go with your existing codebase.
As for the tooling, Kotlin IDE support way better than Scala's. It is not surprising, however, due to the fact that main language kontributors are JetBrains.
> What do you mean by inability to represent existential types? Kotlin has in/out/star projections, which are be used for corresponding Java variance
Hmm ok, that does seem to provide equivalent functionality. Is it implemented?
> in Scala I cannot simply use interfaces with bounded type parameters without some dirty hacks, just because compiler will generate weird errors and/or incorrect bytecode
Example? I've never seen that happen and I've done a fair bit of mixed Java/Scala.
> The whole point of Kotlin is that it does not need its own ecosystem - it is intended to be used seamlessly (unlike Scala or Ceylon) and, like, today with all existing Java libraries and frameworks.
Scala was intended for that at first. It turned out to be a bad approach. Interfaces are important, library APIs have a surprisingly far-reaching impact on the code that calls them.
> As for the tooling, Kotlin IDE support way better than Scala's. It is not surprising, however, due to the fact that main language kontributors are JetBrains.
That one specific tool perhaps. In terms of the much larger ecosystem of third-party JVM tools, Scala support is naturally more mature.
With more than 2,000 people in its Slack channel alone, I think Kotlin is a bit more than marketing hype (to compare, Java has about 500 and Scala 450).
As for your other point, tying Java interop with existential types is pretty absurd.
I'd say both Kotlin and Scala are about equally good when it comes to interoperating with Java.
> With more than 2,000 people in its Slack channel alone, I think Kotlin is a bit more than marketing hype (to compare, Java has about 500 and Scala 450).
So do you really think Kotlin is used 4x as much as Java? Or is it possible that this is a pretty poor measure of actual usage?
> As for your other point, tying Java interop with existential types is pretty absurd.
Only as absurd as Java. Java libraries contain methods that return existential types (e.g. List<?>) everywhere. If you can't represent that type in your type system (note that it's not the same type as List<Object>), you can't have full Java interop.
I don't know what libraries you are looking at but these are extremely rare these days. At least for the popular ones. You seem to be talking about Java like it was written eight years ago.
I gave List<?> as a simple example; usually we're talking about List<? extends Foo> or similar. Anything that involves a ? anywhere is an existential type, and they're the only way to write a whole lot of things safely, e.g. any kind of callback has to involve a "? super" type to avoid disallowing perfectly valid code. Unless the Java community has abandoned generics and decided to go back to using casts everywhere there's really no alternative in the language.
Exactly, I love working with Clojure, never disappoints, CSP is amazing and even though I understand the benefits of type safety too many people get hang up on that and write type safe incorrect code that does not do well in production. Kotlin seems a bit less complex than Scala, I might give a shot to that. Thanks for the book recommendation though!
I'd say yes. It certainly is hard and I spent the first few months wrestling with the syntax, but when you figure out all the puzzle pieces and they come together, then it suddenly turns very beautiful and terse.
The terseness is probably what makes the learning hardest, but there is utility there, because you don't have to focus on the boilerplate, but can see more of the algorithm at once.
Also, anything that moves you more towards fp is a good thing, because again, when you start to get it and manage to apply it in the correct way, it is extremely elegant and composable.
Yes as a programmer. No as startup guy. For me, it's like learning to do multiplications instead of just adding and subtracting. You will still get the same answer at the end.
For a startup, you don't want to your programmers to learn cause its a heavy investment in terms of time. Adding and subtracting works just fine so they often advocate that route. You definitely get to the end goal, but when it comes to learning new things, you are never certain what the outcome will be.
We started with Scala when we were a startup. It's worked out very well for us: our orchestration layer in Scala has been maintainable and scaled well as the organisation grew, and the power of Scala has meant each change is small and focused (i.e. doesn't have the verbosity and boilerplate of Java).
Im currently at a startup and we're trying to introduce more Scala into the pipeline. I agree that languages like NodeJS can speed up time to market slightly but we are taking a huge hit for it right now as we try to scale with 5x/10x load. I really wish we introduced more Scala/Java up front.
