Learning Scala is such a pain. Either you follow a large book completely and master it across several months/years or go through overly complicated online guides and get discouraged. I understand it's a large, advanced language, but the community has to seriously work on making things a bit easier for beginners like me. Just look at how easy it is to learn Go or Rust, their official tutorials are amazing and free on the web.
Here is what worked for me to learn the basics well: I started off with the book 'Scala for the Impatient', the first half of the book is freely available. I then used Scala School as a list of topics and researched on each using Google. StackExchange has some amazing answers that helped me a lot.
I've taught Scala to tens of engineers. The golden path is the Coursera course "Functional Programming Principles in Scala"[1]. It's a pretty comprehensive set of lessons, by the author of the language, of how to tastefully compose the basic elements of Scala to solve interview-sized questions. I really think that Martin Odersky's skill as an educator is a highly underrated part of the success of the language.
I have asked tens of final year students to learn Scala for their final year projects, and pointed them towards Odersky's Coursera course. All my students liked the course, picked up Scala quickly, really enjoyed programming in Scala afterwards. Once they get it, they typically say something along the lines of "I never want to go back to Java".
As an aside, part of why Odersky's course work so well is that it's influenced by SICP (Structure and Interpretation of Computer Programs) by Abelson and Sussman.
I'm curious - is the harder part of learning Scala the language itself, or getting one's mind around functional programming itself? (Does having a Scheme/LISP background help?)
For me, I grasped most of usage of the language fairly quickly, from a standpoint of working functionally. I think there are a couple parts of Scala that are intimidating to beginners.
First of all, there's a lot of choice in how to organize a solution to a given problem. Say you've just started to grasp the idea of algebraic data types and manipulations thereof. You might still find it hard to know how to apply it in a given situation, because there are several ways to do it [1]. As you gain experience, you start to get a feel for which option is more appropriate in a given situation.
Secondly, a lot of the basic concepts of Scala are super general, so you can sometimes see language elements used in ways that are surprising. In my experience, you start to build a mental model for actual usage of language elements, but it's still intimidating at first. See this question and answer about the `object` keyword [2].
But then, even as you master the language, there are all sorts of little gotchas you learn to navigate. This is true of any language of course, but it can be more frustrating when you're operating at a higher level of abstraction. The Dotty project seeks to rewrite the Scala compiler in line with an improved framework of some of the more innovative type system features of Scala. I think it's ultimately going to lead to a better foundation with less gotchas. But it's still a long time coming.
Oh yeah, and the `implicit` system is a beautiful concept, but pretty unique to Scala, and intimidating at first.
I was a long time hobby level Common Lisp and Clojure programmer when I started learning Scala. Understanding functional programming before coming to Scala definitely made it easier. That said I think Scala has a little extra learning curve because you need to understand some syntax especially around type declarations, and understand how flatmap and map work, not just on lists but on many different kinds of data structure.
It doesn't help that Scala takes a lax attitude towards functional principles whenever it's convenient -- for instance, you can map over a set, and certain maps will get you a different type back. Haskell it's not. It's more like a terse Java with optional types and pure functions added on.
This might be true, but I don't think it is hard as the general opinion is. I think it's mostly about the technique and patience. You can't expect miracles at once or a wow factor. I generally started using it for smaller projects or parts where I could experiment a bit, and started using it as a better Java. I also played CodinGame with Scala. As things caught pace I started evolving it a bit and looking into refactoring and so on. Too be honest, I'm not too advanced, but I kinda like the pace. Word of warning: Java is still my main language at work, but the language choice is not my decision. However, whatever happens with Scala or me in the future, one thing stays, I became a better Java developer because of Scala. Also, the colleagues got interested after looking into some Akka Streaming apps :D .
But compare this to someone's experience with Python, Ruby, JavaScript, Go, or (maybe) Rust, where they are much more rapidly productive, and they actually have that immediate wow factor. I think this may also apply to "lighter"-weight Scala alternatives like Kotlin/Ceylon one day, depending on their adoption. So I think Scala pales on this dimension relative to its competition.
You can be just as productive as you would be in Python/Ruby/JavaScript/Go from day 1 in Scala - usually the same code will work, with minor syntax differences and maybe the occasional type annotation. The difference is there's more to learn in Scala that will make you even more productive, but that should never be a downside, and you don't have to learn it if you don't want to.
I have to agree with "lmm" and "the_af" here. You can use Scala as a "Java without semicolons", and indeed that's what I recommend to those who want to learn Scala coming form an OO background. There is absolutely no need to use fancy Scala features like higher-kinds or monadic effects. Indeed, there is no need even to use functional features. Scala is a perfectly fine OO language. The one thing I recommend to learn once a learner gets a grip on Scala syntax is pattern matching matching and case classes. It's really easy to understand. And once you understand it, you never want to go back.
I have had a substantial number of undergraduate students learn Scala this way for their final year project and they all got it pretty quickly.
You are advocating that beginners start using Scala without really understanding what they're doing, and being mostly unable to read other code or read the source, while writing what is considered to be bad Scala from the get go. Contrast this to languages like Python or Ruby, where it is totally possible to immediately start writing code you understand that follows the general gist of good Python/Ruby style.
You are certainly right that someone new to Scala can get started quickly this way. You are wrong that Scala is anywhere close to the same level on this dimension as Python or Ruby or Go.
No, I was talking about strong Java (or C# or C++) programmers learning Scala, starting with the OO part of Scala. Clearly this is not a large jump, as Scala has class-based OO that is really similar to Java, C# and C++. It is perfectly possible to be productive in this fragment.
I don't at all agree that someone can pick Python or Ruby up and start writing idiomatic (or even "good") code on day one. In fact I make a good living consulting in JRuby shops where they thought they would get some sort of benefit by using Rails but then wrote all the code as if they were still using Java.
I am speaking from direct personal experience. Explicit effect sequencing is optional (in contrast to Haskell), traditional OO with inheritance is available. You may not be able to read all the standard library type signatures on day 1 but the documentation is adequate without them. Anything you could do in Python/Ruby/Javascript translates directly; in the very short term I guess not having a single baked-into-the-language concurrency model like Go is a disadvantage, but the use case where you'd need that on day 1 is pretty rare.
I have found that the issue isn't the language, it's the ecosystem. If you're coming from Java environment set up is not such a big deal, but if your brand new it is not as easy as other languages.
There are certainly poor libraries and bad advice going around (why people tell beginners to use SBT or ScalaTest is beyond me), but that happens in every language. IME the average quality on maven central is if anything better than on PyPi/rubygems/npm/etc., and the IDEs/profilers/debuggers are better than anything you can get for the other languages.
I can think of some very good reasons to suggest SBT to beginners. Probably the most useful features, in this regard, is that a folder with some Scala files in it is a valid SBT project. You don't even need a build configuration file. This is substantially less work than setting up a Scala project through Gradle, Maven, Ant or an IDE.
Also, if you use SBT through Activator[1] you get project templates and an automatically configured IDE.
> I can think of some very good reasons to suggest SBT to beginners. Probably the most useful features, in this regard, is that a folder with some Scala files in it is a valid SBT project. You don't even need a build configuration file.
Sounds horribly magic/incomprehensible.
> This is substantially less work than setting up a Scala project through Gradle, Maven, Ant or an IDE.
I don't think the work of doing it in Maven with an IDE could be called substantial. Push the button, choose the scala template, give it a groupId and artifactId, done.
Maven and Ant are barely maintained anymore despite so many broken things. Just compare artifact resolution/download speed between Maven/Ivy and sbt with coursier.
There is no way in hell I'll ever touch Maven again. SBT works without a single line of configuration, and that IDEs are not able to touch config files is a big fat benefit.
Eclipse developers can't even turn it into a working editor. I certainly don't want Eclipse to deal with my project configuration.
I'll get over my hate when every setting is documented, every operator is documented in a searchable way (which probably means replacing most of them or writing their own search engine), and build definitions are no longer turing-complete. Until then, Maven's a much better option.
How is compiling everything in a given directory any more magic/incomprehensible than any other build tool?
> I don't think the work of doing it in Maven with an IDE could be called substantial. Push the button, choose the scala template, give it a groupId and artifactId, done
What IDE comes with a 'scala template' out of the box? What if you are not already in the JVM ecosystem? With SBT, the set up is:
- Install SBT/Activator
With your suggested equivalent, the steps are:
- Install Maven
- Install IDE
- Install Scala IDE plugin
I think the SBT option sounds like they would be much less imposing for a beginner.
IntelliJ doesn't have the Scala plugin installed by default. However, that is true that you could combine the 'Install IDE' and the 'Install Scala IDE plugin' steps by installing the Scala IDE.
Even if you do combine those steps, there are still further steps a user would have take after they install everything. You described the set up as just being as simple as "Push the button, choose the scala template, give it a groupId and artifactId, done". However, I don't think it is that simple. As far as I'm aware, no IDE will give you a Scala project with a Maven POM. You can choose to create a 'Scala project' or you can create 'Maven project'. You can't create a 'Maven Scala project'. So you will have to figure out how to add Scala support to Maven manually. Also, you may have to figure out how to let your IDE know that your project is both a Maven project and Scala project.
I find it makes tests much less comprehensible (and gives them worse IDE integration) than JUnit; it uses gratuitous operator overloading style with e.g. "should". And for a beginner it doesn't really offer any advantage - if you're using generators or the like I can see it might be helpful, but for basic unit testing I find straightforward code with JUnit is much easier.
Using the natural language style assertions is optional though, and only work if you incorporate the 'Matchers' trait in your tests. If that's too magical, you can still use plain old assertions or one of the other styles here http://www.scalatest.org/user_guide/using_assertions
You can do what we did in my team: decide on a style of testing and stick to it (in our case, I liked WordSpec). With JUnit you can't do this, because there is only one style.
I particularly liked the "should", "must", "where", etc. DSL. If I remember correctly, this style of testing comes from the Rails community. I guess it's a matter of taste, but I would definitely recommend it to newbies.
I wouldn't recommend it to newbies at all, because it's using relatively advanced Scala features - implicit conversions to make the operators available, "word word word" style desugaring into method calls. Of course these are things that you have to learn eventually and that have value, but making a newbie learn how they work before they can test anything is throwing them in at the deep end, and having to use a test framework that you can't understand isn't good.
A lot of Java programmers don't understand how JUnit works, nor need to, and they still manage to use it, so I don't think this is a strong argument.
The point of DSLs is that they feel natural for their job, regardless of how they are implemented. You can use a DSL without understanding how it works "behind the scenes". To me, ScalaTest with WordSpec seems more natural than JUnit, and at least my own experience shows I'm right: I've successfully introduced it in a team of newbies.
> A lot of Java programmers don't understand how JUnit works, nor need to, and they still manage to use it, so I don't think this is a strong argument.
What's to understand? You write a method in plain old java, and the framework runs it.
> The point of DSLs is that they feel natural for their job, regardless of how they are implemented. You can use a DSL without understanding how it works "behind the scenes".
The point of "embedded DSLs" is that they follow the ordinary rules of the host language. Otherwise they're no better than an external config file, Cucumber-style (which some people apparently like, but I find utterly unusable).
> at least my own experience shows I'm right: I've successfully introduced it in a team of newbies.
When they make a change to code that breaks a test, and you're not there, how long does it take them to understand what's gone wrong? That's the real test of a test framework, and IME ScalaTest does very badly on it.
Let me ask your own question back at you: what's there to understand with WordSpec or Cucumber-style tests? It's just a tool, you just use it as documented... just like you don't need to even look at JUnit's implementation in order to use it.
Yes, when a WordSpec test starts failing, junior devs know how to fix it without my assistance. I haven't noticed any difference in dev effectiveness between ScalaTest and JUnit.
> Let me ask your own question back at you: what's there to understand with WordSpec or Cucumber-style tests?
To use Cucumber you have to understand a whole new grammar. To use ScalaTest you have to understand relatively obscure parts of Scala (implicit conversions, "word word word" style method calls, by-name parameters, ...) - or else treat it like a config file and learn a whole new grammar. To use JUnit you just write plain old Java/Scala.
I've found that Scala beginners google around, and come across lot's of blog posts extolling the virtues of Scalaz, implicits, using higher kinded types, embedding DSLs and so forth. All that is worthwhile, but not really accessible to beginners. It's understandable that Scala bloggers want to write about cutting-edge material, but this misleads beginners, who think you need to use Scalaz, monads and the like to be productive. Nothing could be further from the truth.
With a few exceptions, you can program in Scala as if it were Java++. You won't take full advantage of Scala, but it can be done, and beginners sometimes do precisely that.
It's a lot like learning SVN vs Git, SVN requires fewer steps to do a commit so you can be "productive" faster. Once you learn Git though you won't care that it took you a bit longer to learn. Prioritizing being productive immediately and instant gratification isn't always the best in the long term.
That's a pretty bad example. Git is widely considered [1] to be overly complex and difficult to learn compared to something like Mercurial. The advantage Git has is its dominance in terms of adoption/community. Scala does not have juggernaut dominance in programming languahes.
[1] I acknowledge this is debatable, but it's an opinion I agree with.
Not familiar with Go or Rust, but the issue with newcomers to Scala, as compared to Python, Ruby, Javascript is one of the ecosystem rather than the language. While that's very off-putting to newcomers, it hopefully is a one-time cost amortized of the life of your language use.
I actually had the opposite experience. Yes, Scala takes some time to digest but I didn't find it particularly hard. I come from a C# background and Scala just makes things so much easier to code once you get the hang of it. On the other hand, I tried learning Go before picking up Scala. Something about it's handling of concurrency just didn't sit well with me. Perhaps it was because it was so different for C#. I never really got a good hold of it.
For me Scala has a little bit more upfront cost to learning (but if you come form Java and C#, it should almost be second nature) but the things you can do with it once you get a hold of it is amazing. Go (for me) on the other hand is very easy to write simple Hello World programs, but if you want to do complex applications, it has much more down payment.
Agreed on the C# front. Outside of implicits, I feel like there was just the occasional google search to find what the equivalent LINQ method was in Scala. It took a couple of days to get it sorted out in my head, but I was able to jump in with Play Framework very quickly since everything was so similar to MVC/C#.
I shared the same sentiment the first time I picked up Go. Coincidentally, we also share the same background (I've been a C# developer for years). However, I hold no longer the same sentiment toward Go. Yes, it forced me to think dramatically different than it was the case before, but nowadays Go is just a breeze to work with. Hence, I even do coding challenges in Go just because it's fun.
I agree about painful learning curve for Scala. Problem I think in very divergent community and in different approaches for a every single problem (unlike for example Python or Go): OOP vs FP, Typesafe vs Typelevel, scalaz vs cats, Cake Pattern vs sanity.
There's a also a problem that most powerful Scala techniques are there "by accident" [1] and unlikely will (or should) appear in official guides.
Also I disagree that "Scala for impatient" is good book for start. It make me feel Scala is dump of random unrelated features, it's very easy to disappoint.
However, despite all above I think Scala is definitely worth to invest some time. It made all other learning curves (for languages, techniques, concepts) more flatten.
The community is the worst part IMO, and it all boils down to the Typesafe vs Typelevel communities. The typelevel crowd want to turn Scala into Haskell whereas the typesafe crowd have always recognized it as an ML dialect first and foremost.
The rift pollutes and bloats your dependencies, and causes problems with unexpected behavior and unreadable documentation. Trying to shoehorn libraries into my projects that pollute their code with these new standard libraries with lazy functionality and its accompanying monadic bullshit[1] is a huge thorn in my side. I wish the typelevel crowd would just accept the fact that Scala is an ML language, and adopt Frege instead if they can't handle that.
You are talking from the point of view of an advanced I-know-about-this-stuff annoyance level.
Newbies to Scala, especially those coming from Java, couldn't care less whether it looks more like ML or like Haskell. Both languages would be alien to them. Robert Harper's "Existential Type" blog is hardly aimed at the average programmer.
I'm pretty sure this is not the worst part about Scala :)
I find that the Typesafe (Lightbend) and Typelevel communities are more or less moving in the same direction. Using Shapeless, for example, doesn't seem to really conflict with more mundane Scala usage. I'd say that there's more of a contrast with the Scalaz world, where obscure category-theoretic terms and operators are unavaoidable.
That said, I've had plenty of success applying Scala at work without bringing in overt category theoretical concepts into my codebases. Scalaz remains very much an opt-in community.
> It made all other learning curves (for languages, techniques, concepts) more flatten.
I find learning Haskell definitely does this and although I can't do the same things in C# a lot of the ideals (immutable state, keeping things separate and simple as possible) not having a complex unpredictable state to manage with lots of 'actors' trying to mangle with it.
Haskell has design patterns which are only what in the OO GoF context you couldn't even dream of. The free monad interpreter pattern alone can probably achieve what all of the other patterns do and then a few more light years. It is amazing stuff and to bring a single drop of this greatness back to the mortgage-paying languages is nice to do. Rx anyone?
I'm aware it's probably not intentional, but you describe Scala as being eclectic, and then immediately criticize Scala For The Impatient for presenting it as eclectic!
However, I do feel like you're right. For instance, the section on XML literals probably should have been avoided, since that feature doesn't fit nicely with the rest of the language and most of the time isn't necessary to know.
I think that's totally consistent. It's bad that Scala is so eclectic. It's also bad that introductory books present Scala as eclectic instead of selecting the "best" subset of Scala to teach.
If you have the time and the interest, start with Standard ML. It is one of (or just?) the simplest languages in the ML family (which also include OCaml, Haskell, Scala, etc.).
You'll see yourself wanting a number of features you'd expect in a modern language, and end up discovering the motivation and approach behind how Scala or Haskell work. Operator overloading (ad-hoc polymorphism) and modular implicits are two of the ones I come across the most.
I have always felt that Haskell and Scala (and OCaml sorta) are way too complicated. However, spending time learning Standard ML and the foundations of this family have been really illuminating - you'll discover how powerful Haskell and Scala really are. For an analogy, you can think of switching to FreeBSD from Linux to get closer to Unix roots so you can understand Linux (the historic decisions and reasons) better.
Take a look at the /r/sml wiki [0] if you need help getting started.
I think the Scala learning experience is very different depending on whether you're coming from the Java -> Want to use Functional Programming route or the Functional Programmer -> Have to use Java for a project route.
As someone with a lot FP experience having to work with some Java libraries, getting started with the "This is more pleasant than Java" style of Scala takes very little time. To the point where the typing it saves you in a week roughly equals the cost of skimming through Scala for the Impatient to get started.
Granted the "This is more pleasant than Java" style of Scala is the equivalent of the "C with Classes" style of C++. But as far as getting started learning Scala I've found that it is quicker than most FP languages to just dive in and get things done, refactoring as you learn more idiomatic approaches to problems.
For me the big risk for Scala that I've seen is the same as C++: The language is so big and so flexible that you can have two developers write the same programs and get results that are difficult to see as being the same language. And because you can get stuff done without writing idiomatic code it's very easy to stop learning and be quite far from what experienced Scala developers would consider a Scala programmer.
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.
I totally agree with you, as someone who had to learn it quickly for a new job. A bit of hearsay indicates that a former VP of Engineering at Twitter is not sure he would have gone with Scala again because of the on-ramp for new devs (https://www.quora.com/Is-Twitter-getting-rid-of-Scala).
Even if someone (a fan of Scala) doesn't believe it's that hard, the fact that this comes up again and again should really be an indication that it's truly an issue for people new to the language [1]. It is difficult, and it is intimidating. I would not have learned Scala if it weren't for the extrinsic push of learning it for a job.
[1] This applies to other things that people new to a language constantly complain about: Python's problem with v2 and v3, etc.
My advice is that don't expect that you can "learn" Scala in a couple of weeks or months. Instead expect that you can learn enough Scala to get the next task done. If you like it, you might be pretty happy spending a couple years learning it.
My biggest problem with Scala is that it's too powerful. Reading code I've written weeks or even days later is painful. Conciseness is not always good.
In what ways does Scala you've written end up being unreadable just days later? I honestly find that Scala code is some of the simplest and easiest to reason about of any language. Writing Scala has honestly been such a joy, it's easy to refactor, easy to read and write, and I almost never miss something -- if it compiles, Scala code is usually correct I find.
I think that, if you're not super aware of most of the features of Scala, that it can be confusing to understand what certain syntax means (implicits are a big one!)
Just the infix operator syntax plus implicits can lead to stack trace confusion all around
And try understanding some of the type signature funkiness! It can be difficult
I definitely think that Scala is a harder language than most to grasp, if only for the feature support not seen since C++
Scala's infix operator syntax is very mechanical. Much easier than e.g. Python where you have to remember whether a * b desugars to a.__times__(b) or a.__star__(b) or something else. The IDE support for those and for implicits is very good these days.
The type signatures can be complex but only when you're doing complex things with them - if you stick to doing the kind of things you'd do in another language you'll get similarly simple types.
You're absolutely right that the native stack traces are poor, but you can use tools that understand them better, e.g. Takipi.
Well written Scala code is fantastic to work with, but it does take some practice and judgement to write well structured readable code. If you're having trouble reading your own code days later perhaps consider the way you're using the language. I'd strongly recommend reading http://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLe... if you're have trouble reading your own code.
I second that. Well written Scala code is simply wonderful to read. You learn so much just by seeing how people solve the problem much better than you. Its probably because Scala is so terse, you get to see the logic behind the code much easier than a language with lots of boiler plate.
I find that I consciously need to go over any code and rewrite it with a reader in mind. The first version is usually crap, but at the same time, it's very easy to fall into the trap of making it Just Right which makes the second version "super elegant" but completely opaque at the same time.
I often end up making a "super elegant" version and, almost invariably, end up scrapping it for a (hopefully...) more bread-and-butter version, which may or may not incorporate some lessons learned from the concise version. Even if not, it's not all loss, because coming up with the elegant version is intellectually rewarding and super fun.
Add lots of in-line (not just scaladoc) comments helping the reader along. Extract vals for intermediary steps. Variable naming is always important, but even more so when you don't explicitly declare the type.
Conciseness is optional. Sometimes a new Scala programmer will learn functional combinators and try to cram a lot of logic into one line. Breaking things up into semantically related steps and assigning each step to a val with a descriptive name will make the code more readable to others (and the author's future self)
I was learning Scala at one point. I was reading Atomic Scala [1] (I'm a big fan of Bruce Eckel as I learned Java from one of his earlier books, and some C++ before that). And I also took the Coursera Course from Martin O on functional reactive programming with Scala. I don't remember what is was actually called...
I'm still into alternative languages that run on the JVM...however I went and learned Go Lang in a weekend and it meets a lot of my needs for building out newer services.
Also, for my team the overhead of learning another JVM language (we already use Groovy quite a bit) didn't seem worth it in the end, even though I was a bit of a fan of the Scala idea for a few months.
I might still learn Scala some day, but we're not even on Java 8 at my current job, and that would alleviate a lot of my current Java grievances....
Don't let your experience with Apache Groovy put you off upgrading to a new JVM language. I learnt Clojure after using Groovy for a few years -- Groovy 1.8 was the last version I used. I then looked at Haskell, and now I'm using Go.
Maybe I'm in the minority on this but I felt this guide by twitter was poorly written. It has good coverage but concepts were just not explained very well.
The way I learned was reading from front to back "The Scala Programming Language" by Martin himself and starting a new project completely in Scala (which I'm launching soon). I'm sure that's not the best approach for everyone but using Scala in a practical environment in an idiomatic way really helps ground the concepts which can at first seem intimidating and difficult to comprehend.
Twitter's Futures were developed when Scala's Futures weren't tail-recursive (and so not really production-quality). There's probably an item on the roadmap to port Finagle to using scala.concurrent.Future but I doubt it's high priority. The two support the same set of operations in any case - I doubt it'd be a huge problem for a beginner to translate one to the other.
Do you want basics or advanced? At the moderately fancy level, Spray is great - any time you're using a directive, you can just click through in the IDE and see the implementation of what it actually does. And Doobie is a tour-de-force for advanced type constructs. At a more basic level a lot of Twitter's own libraries are straightforward readable code (e.g. Scrooge is one I've patched a bit myself), though coupled to the Twitter stack of Finagle/Scalding/etc. that you probably don't want to use.
After that you could look into the spray.io source: it is quite complex, but the API it exposes and how extensible it is is amazing... They also coined the _magnet pattern_ which is pretty cool, and probably less abused than the cake pattern.
http://www.squants.com/ seems like a great library for studying, since it's inherently intuitive, self contained, well documented, and exposes a terrific api.
> For each chapter (and occasionally for individual sections), I indicate the experience level. The chapters progress through levels A1, L1, A2, L2, A3, L3.
The number is the expertise level, from junior to expert; A stands for Application developer, L for Library developer.
I often find myself unsure about wheter a book or text is intended for the kind of user I am for whatever the topic is. Skimming through a book trying to identify what parts you should focus is not always easy.
Do you know of other books that do this kind of thing?
I find this schema, promoted if I'm not mistaken by Martin Odersky himself, as one of the biggest marketing blunders possible as far as programming languages are concerned.
You keep telling developers that they are not good enough but they should rest assured that some smarter people are working on the problem and they'll come back with the answers.
When in reality, I think that all developers, when using a library, would like to think that they could have written it themselves, it they would have had the time or the interest.
Twitter, Etsy rely on Scala as their main tech stack.
You can probably list a large chunk of the big banks. I know quite of few of City of London's big investment banks all continually look for scala developers. In the same breath I would probably list the gambling companies which seems to be on scala bandwagon as well...
In the UK the public sector (GDS) are investing in scala based projects. E.g The HMRC have about 200 scala developers (me included).
If Indeed.com job search results are anything to go by there's also EBay, Verizon, Morgan Stanley, Northrup Grumman, Slack, Nike, JPMorgan.
Searching around the web I see other users including Netflix, Tumblr, Xerox, Sony, Siemens, UBS, Ask.com, AT&T, Bloomberg, IBM, Bank of America, Amazon, TomTom, NASA, Credit Suisse, Autodesk, Nokia, Apple, AOL, eHarmony, Gawker, HSBC, Klout, Novell, SAP, UBS, Allan Gray, Telefonica, Weather Channel, The Guardian.
Most of those companies use a bunch of technologies, Scala being only a small part of their stack. Only a few of those companies use Scala as their main language.
Yes, totally. I'm talking about their core language. LinkedIn's core language is Java. Google's main languages are C++ and Java. Pinterest is mostly Python. Quora's core is Python. Stripe's core is Ruby.
It's a fantastic language. It combines the conciseness and readability (if you stick to sensible method names) of Python with the safety of OCaml and the performance of Java. It combines the type-level power of Haskell (i.e. the ability to explicitly sequence effects) with traditional OO inheritance/subtyping and performance behaviour you can reason about (helped by the JVM's well-established profiling/instrumentation support). If you want to use a single language for everything, it can scale up to critical core codebases and down to throwaway scripts / interactive notebook-type use. What else would you use?
AFAIK, quite some components (Hadoop, Kafka, Spark, etc) of a typical big data stack are JVM based. Scala is JVM. And quite some people hate Java. That could be an answer.
There are a few "copy-cats", but it shows that the creators lacked the experience and time to really think about how to achieve coherence of language constructs and how different parts play together.
In addition to that, Scala has a huge head-start and is quite stable and mature. The language is expressive enough that I can't envision many features which couldn't be expressed with the existing language.
For example, Scala.js didn't require any language extensions at all.
The Weather Channel's core weather services such as their weather API, their alerting services (for your phones), and most of their other services are all written in Scala.
I'm about to release an app (will probably publish a beta today - https://invotes.com), and it actually works quite well.
The compile times are probably a bit slower than a standard java project, but not bad - something like 5-30 seconds depending on if it's a full rebuild.
I use android-sdk-plugin with SBT along with Scaloid. Wrestling with proguard to hide appropriate warnings can be a little bit of a pain, but even with no prior Android knowledge I was able to figure everything out.
Everything works as expected. There are a few minor issues where Java expects null and that's not normal Scala style, but other than that, nothing important to speak of. My binary builds to 4-5mb.
I've written some basic android apps for my own use in Scala. There's a bit of a mismatch with the android API (which is very much oriented towards traditional-Java mutable objects and one-thread-per-thing style) but I still find it nicer to work in Scala.
I spoken to many that have made Android apps with Scala but none that have pushed them to the appstore as the final binary is always quite big even for simple apps.
I wouldn't say that's true. I have an app written in Scala [1], and the apk is just 4 MB. Sure, that's more than a comparable Java app, but many apps reach 20+ MB due to graphics anyway.
As someone who's seeing plenty of Scala uptake around me that's a rather surprising claim with no supporting evidence. These days I'm writing 90+% of my code at work in Scala.
This graph shows that Scala grew from 0.02% market share to 0.08% in the last four years. The fact that it's at 0.08% after more than ten years in existence should be a concern for anyone interested in learning it.
For comparison Ruby is just over 0.3% and has been flat for four years. It's the overall job market, not just programming jobs so all percentages will be low.
I have never received so many scala job offers like in the last 6 months. The other day a recruiter contacted me because he needs to fill 60 Scala roles! As someone else stated, it's mostly financial firms that are investing heavily in Scala (at least, in my experience).
It was considered at one point, but the main proponent for one JVM language has left the company and even before that there was strong support for keeping Scala on the list of production languages.
I was not a first party to the discussion, but what I heard is that Alex Roetter had asked the most senior engineers to consider strongly whether or not it would be better to have one JVM language. Twitter pays a polyglot tax and Scala's tool chain is clearly not as mature as Java's. In the resulting discussion, though, even engineers that primarily wrote systems in Java wanted to keep Scala as an option.
I had one conversation 5 years ago with Raffi about which language something should be built in. He advocated strongly for me doing it in whatever I felt made the most sense. I think this is typical of his management style -- which is to establish goals and let the people responsible for achieving those goals work out how to do it. Raffi had left the company by the time the JVM standardization discussion happened.
My biggest challenge with (learning) Scala and the Scala community is that it feels like nobody is actually shipping software, or advocating for making shipping software easier.
And that's a shame, because Scala is language I love for writing a few dozen lines of code, and expressing a domain concept. It's a fantastic language for solving a homework problem set (and it's origins may be part of the reason why). But every library feels like it was concocted as a search for purity with zero attention given to the user experience.
The community is badly missing a DHH or Kenneth Reitz -- someone saying: "Ok, it's cool that we have this academic purity stuff and all that, now let's get serious about shipping software, and making tools that help people ship software." It's not that this view needs to dominate a community, but right now it's thoroughly unrepresented in Scala land.
I feel like my experience is quite a bit different. I chose play framework for my web frontend and REST API, and it's quite easy to get started and ship something quickly.
Play framework itself is pretty straightforward with not much in the way of advanced Scala concepts (implicits are probably the most you have to understand). Testing is baked right in and they even handle setting up the application for you in your fixtures.
Coming from the .NET world, it was a huge relief to see that I could just use activator/sbt to compile and publish my artifacts on a build server, just as it works on my local machine. Setting up continuous integration was super easy in comparison to what Microsoft has historically offered (but looks like they're improving with .NET Core).
As for other frameworks and libraries, you may be right on a number of them, but I wouldn't say that all or even most Scala libs are designed to be pure. I have a number of dependencies that are very easy to reason about even if you aren't aware of advanced features.
None of whom are producing well-supported public code / documentation / conference talks.
Edit: And to clarify. I think part of this is because there's a serious case of imposter syndrome among Scala developers. I feel like much Scala code I've written would make legitimately useful open source projects, but I'm not really happy with the interface, and I feel the innards could be a bit cleaner, so I don't release it, because it feels just hackish enough that I trust it myself, but don't want the outside world depending on it. I'm probably not the only one here.
What about Spark, Kafka and Akka? I actually think the Scala community is working very hard to improve user experience, it's just that they don't do in the expense of soundness.
Spark is interesting, and is probably the most pragmatic focus in Scala land.
On the Akka side: Try picking up Akka-HTTP and use it to write an API client (which seems like something one would do with an HTTP library). There are lifecycle issues that are undocumented, and it really feels like this wasn't a considered use case throughout the entire development process.
I don't necessarily think DHH is right on everything, or even most things. But I do think it's valuable having a voice saying: "Does this help us ship" or "We're adding this feature because it's solving a real problem we encountered multiple times during the development of real software, and it would be nice to have a standardized solution".
Here is what worked for me to learn the basics well: I started off with the book 'Scala for the Impatient', the first half of the book is freely available. I then used Scala School as a list of topics and researched on each using Google. StackExchange has some amazing answers that helped me a lot.
Free part of Scala for the Impatient: http://fileadmin.cs.lth.se/scala/scala-impatient.pdf