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.
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