The full book is ~400 pages and will be released Summer 2020 (i.e. soon!). If you're interested in being notified when it comes out, there's a mailing list link on the page and I'll let you know when it's out. There will be both E-Books as well as paperbacks & hardcovers (assuming the supply-chains are still open in this COVID-19 global environment...)
The first 5 chapters are already online, for free now and forever. These form a self-contained introduction to the Scala language: setup, basic syntax, collections, and a notable language features. If you're looking for a quick introduction to Scala, this is it.
The rest of the book goes heavily into use cases and projects in a way that few other programming books do: interactive websites, network file synchronizers, programming language interpreters, migration tools, parallel web scrapers, and much more. The book intentionally skips a lot of language esoterica in favor of showing how to use Scala to do things someone might pay you a salary for.
You will learn Scala by building a breadth of useful experience, rather than a depth of knowledge in language minutiae.
The chapters in the book are all based on real projects I have worked on. Most projects take <100 lines of code (i.e ~2 printed pages), and it is a testament to the Scala language that we can build working prototypes of all these things in a single 400-page book!
If this interests you, feel free to leave your email on the website, and browse through the free chapters already available.
I can vouch for lihaoyi. He is one of the more prolific people in the scala community writing top notch stuff. The best part about most of the stuff be writes is they are extremely ergonomic, even by scala standards. Look at either scala-tags or even better his parsing library. The parsing library is actialy so good you'll feel like finding more problems to solve. Its a breeeze to get started with (even in repl). Scala-tags also is amazing and has spawned other similar projects , one of which is laminar which is currently one of the top scala-js frameworks.
In fact I can probably say this for a lot of his work, anyone learning from him would probably learn a user centric way of library design.
Glad you like them! The reason Scalatags is so good is that it is my 7th iteration of a HTML templating library: starting from using XHP at work, I had written my own templating libraries in PHP, Python, C#, F#, and 2 others in Scala before settling on the Scalatags style a few years ago that is basically unchanged today.
Given how much work I’ve obsessively put into that effort over many years, the final library damn well better be good to use!
As someone who really like reading your blog articles, I'm super happy to see this :) I'll probably purchase it, as a part of my strategy to make my friends and colleagues start scala :)
I'm looking forward to a "advanced scala programming" follow up ;)
You should! Been coding in Scala in my day job for the past 5 years, and it’s a great language - my personal favourite. Elegant/beautiful AND practical. The mix of OOP, FP, really robust static type system, and great 1st class concurrency support is a direction most languages are moving in, and Scala already nails it. There’s a significant learning/ramp-up period, but it’s good learning that helps your programming in any language, and once you start getting comfortable with the language you become quite productive.
I agree. I've used both heavily, they are both amazing, but Scala nowadays has a much richer ecosystem of libraries (because of the JVM heritage). Nevertheless, they are both in the ML tradition of languages, and once you've mastered on, the other is easily picked up.
I can’t really promise the “before”, but the e-book will be released when the current round of review and edits is complete. The physical books released when I can figure out the logistics of printing and distribution
It doesn't for now, and doesn't really need to. Scala 3 isn't out yet, and when it is there will be a migration period (as always) while things will remain backwards compatible and libraries will remain cross compiled.
This book also explicitly skips over all the deep language esoterica, in order to focus on use cases. As a happy consequence, I expect ~all code samples to continue working unchanged in Scala 3 for the foreseeable future.
We use a lot of functional techniques in this book, but we do not dwell on them. In the end you will be using functional techniques not because they’re interesting, but because they’re the obvious and easy. That is how functional programming should be!
Functional programming is a style or pattern. If a language gives you basic stuff, you can do that pattern.
I learned a bit of haskell a long time ago - mind blown kind of time - then found javascript had closures (erm, kind of a way of turning functions into objects-with-state-that-still-look-like-functions) and functions as first class objects (meaning a function can be passed around exactly like and integer or a string) and so I used it in javascript. Google up "javascript functional" and see what happens. Do some exercises.
Beware there are libraries out there that make simple functional Jscript stuff look entirely unnecessarily complicated.
And when you're ready, pick up this guy's book!
Edit: that may have come across a bit insulting towards the author. All I'm saying is you can learn the functional stuff while you wait for the book to come out. And when you have the functional stuff under your belt, get the book and you'll be one large step better prepared to dive into it - scala has a lot more to offer than just functional programming, and the book will surely cover a lot of ground.
> Functional programming is a style or pattern. If a language gives you basic stuff, you can do that pattern.
Kind of... correctness isn't as guaranteed though. Having a hard time putting it into words at the moment, maybe I just need some holes poked into it to draw out the rest of my view (or change it).
Regardless of how good a book may be, I think Scala itself might prove to be a challenging language to learn FP through. I use it daily at work and definitely appreciate all its strengths, but I don't think I'd ever really understand it if I hadn't studied Haskell first. I'd recommend it as a second language, after you've been bitten by the bug and want a job writing functional code.
Hiya, found a typo - couldn't see where else to mention it so adding here, maybe the author will notice.
Ch 3.
This chapter will not covering any Scala-specific
should be:
This chapter will be not covering any Scala-specific
Otherwise enjoying what I've read so far. I've just been dropped in at the deep end of a project with no scala experience, so I'm trying to get off the ground asap.
Sure! I have the table of contents for "Scala for the Impatient" open in front of me:
- S4tI goes into a lot more detail into language features: custom extractors, abstract overrides, annotations, higher kinded types, custom operators. Hands-on Scala skips all of that. Most developers do not need to know this stuff to get stuff done professionally.
- Hands-on Scala spends its pages working on fun use cases instead! As far as I can tell, S4tI doesn't cover use cases at all. Sure it's great you know about structural/compound/existential types, but it's setting up webserver, mangling a database, or scraping someone's website that gets you paid a salary.
- S4tI is a bit out of date (at least the preview copy I have) and covers things like Delimited Continuations, XML processing, and the scala-parser-combinators and scala-actors libraries which you shouldn't really be using any more
- S4tI doesn't really use third party libraries AFAIK; that means things like working with files uses the `java.io` or `scala.io` APIs, which are strictly worse than the modern alternatives. In fact, it is only due to the modern collection of libraries such as Requests-Scala, OS-Lib, Cask, Quill, etc. that allows Hands-on Scala to cover as much ground as it does in a tiny amount of code. Hands-on Scala leverages this ability to the fullest!
Some context for people who have limited knowledge of Scala.
Lihaoyi is one of the most prolific coder's, not just in Scala, but in any language. He looks like he is much to humble and modest to claim so himself, so I will do it for him.
Discussions on Scala on HN tends to contain a somewhat large volume of comments that explicitly or implicitly tries to communicate that Scala is a language that is much to complicated to really be productive in. Lihaoyi is a rather clear example of why this is not true. If this random internet citizens endorsement doesn't convince you maybe the book will :)
I think your argument here is counterproductive. Lihaoyi is a prolific coder but most coder like me are average Joe. How can Scala be useful and make average Joe like me productive. The fact that Lihaoyi is a prolific coder in any language does not help selling Scala.
Haoyi makes libraries that are very easy to use, modelling them after popular Python libraries. If you're interested he recently wrote a long blog about the future of Scala being exactly this approach; make easy to use libraries for people like yourself interested in being productive in Scala quickly.
https://www.lihaoyi.com/post/TheDeathofHypeWhatsNextforScala...
The remaining piece of the puzzle is that Lihaoyi's libraries and general approach is exactly what a joe average coder would want. There is minimal use of advanced features, it is all quite straightforward and simple.
There are other productive contributors in Scala, but among them I would rate Lihaoyi to be among the least "magical". The fact that he is both practical and productive is what makes him unique. I guess my point was that there is a lot to be learned from that. For some nice examples of what it looks like in practice see his series of blogposts titled "how to work with x in scala".
My personal pitch for Scala comes down to two things: developer experience and suitability for projects of all scales.
I frequently miss basic features when I'm using other languages. Some of these include:
- Its system for basic immutable data structures.
- Pattern matching for very concisely extracting and branching on data.
- A really nice immutable collections library.
- Scalacheck for generative testing, driven by the type system.
- A bunch of other nice-to-have syntactic features.
From the perspective of building projects, I appreciate that it can model anything from quick utilities to simple web services to concurrent systems, all within a single JVM. And with tools like Akka, you can move that to distributed systems without having to add external software you have to operate.
I think the parent is just giving background about the author of the book, who wrote all of those tools mentioned. I don't think they're only trying to convince you that Scala is easy, but maybe I'm reading it incorrectly.
Haoyi is an amazing guy. Last night at 8pm and 2pm this morning I submitted two PR to the Mill, he merged within one hour. In about 7 years, he helped to create an eco-system around Scala:
- REPL (ammonite)
- build tool (mill)
- JSON serializer(uPickle)
- web framework (cask)
- test framework(uTest)
- http client lib (requests-scala)
- HTML tag lib (scalatags)
- parser(fast parse)
Scala development and tool can be divided into four categories
- Java (OO): wrong idea for many developers. Use Kotlin if you like OO.
- Haskell (pure FP, even HKT): good for fun but not for profit. Use Haskell for pure FP.
- Erlang (Actors): fibers are better. Use Clojure if you like Actors.
- Easy: practical FP, the above tools from Haoyi. Use them if you program in Scala
> - Erlang (Actors): fibers are better. Use Clojure if you like Actors.
Usually the suggestion for actors is to use something else, but I think the main exception is the big one. If you have a need for horizontally scalable concurrent state and behavior, there hasn't really been a good alternative to distributed Akka Cluster Sharding. People are working on it, but I don't think we're there yet (although my opinion might be six months out of date, I haven't caught up).
I think you're missing perhaps the biggest camps in the form of the Lightbend ecosystem (very much pragmatic OO/FP hybrid) and the big data ecosystem around Spark. Even though the Lightbend stack also has Java APIs, the Scala APIs are very much their own thing.
I work JavaScript/TypeScript day to day, but I like Python syntax and easiness but also like Go's concurrency. Having learned Haskell and Rust in the past, these days I appreciate simpler language.
In what way does Scala have Python's convenience and Go's concurrency? Based on talking to a few people that used Scala in the past they said they wouldn't use it again and they said I probably wouldn't like it.
Scala has a very wide surface area, and it can be as simple or complex as you want it to be.
Written in a certain way, it's that different from writing Python 3 with PEP-484 type annotations. You can easily write Python-like code and just get things done. :)
Concurrency-wise, you can implement any concurrency model you want on top of it, and, personally, I find immutability + Task-like implementations (Monix, ZIO, IO, etc.) easier to understand than CSP, but that's just me. There's also actors & channels & threads & anything else you could want.
What's cool, though, IMO, is that once you need more power than just Pythonic Scala gives you, it has one of the most powerful type systems in the world; you can verify as much as you need to, and refine things over time. It's not a language that hamstrings you once you do need more power.
Scala gets its bad reputation from that huge surface area and flexibility, though. There was a period (2009ish, maybe) where the Scala community was having a field day with its flexibility via custom operators like '<<++>>' and implicit conversions and untyped actors that made it impossible to figure out what was going on. It was like using the worst of Erlang with the worst of Haskell with the worst of Java. I'd say they've matured past that entirely, though; in 2020, it's one of the nicer and more practical languages, ecosystem, & communities IMO. Scala is made for getting things done.
I think that's the main problem. Everyone writes Scala differently. In Go pretty much everything is quite similar. In JavaScript people also write things differently, like any other language really, but in Scala it is compounded.
Is there a concrete example of the Python-like code vs the more complex ones? I appreciate the help.
I'm thinking what language next should I pick up. It is either OCaml or Scala.
> Is there a concrete example of the Python-like code vs the more complex ones? I appreciate the help.
Haha this book is going to be 400 pages of concrete examples. It's not out yet, so you'll have to take my word for it for the next few weeks while the last round of reviews and editing are incorporated into the manuscript. If you're interested, put your email down and I'll let you know when it's ready!
I've been wanting to learn more Scala and this book seems perfect! I'm definitely going to buy it when it comes out. The website mentions that there's a PDF download of the free chapters, but I can't seem to actually find it. Do you have a direct link?
This isn't helpful for you if you're trying to pick one, but I find OCaml and Scala somewhat complementary for my tastes:
Scala is a pretty great investment for services, big data, etc. It has a robust ecosystem.
However, the compiler is slow, and startup time can be slow (and Graal and Scala Native just aren't options yet), and if I want to make some tool that gets called fast in a loop or deploys as a "small", native binary, OCaml is nice alternative which I prefer to the only other compelling entry in this area, Go.
Experts' code looking like beginners' code is not a good thing! If better learning a language doesn't make your code clearer and more concise, the language isn't pulling its weight.
Scalas echosystem is overloaded with overly complex libraries that take months to learn. Li Haoyi has been trying to change that for years with his to the point open source projects. In my opinion, now is a pretty good time to get into scala with projects from Haoyi, ZIO, quill, akka, and many others that are built on strength of scala itself matured way pass being carbon copies of java or Haskell's equivalents.
This is one of the most persistent myths about Scala, the language itself is far smaller than, for example, Java, and its standard library is very approachable.
Kotlin is probably a better route if you're considering a non-Java JVM language. Its simple, has easy access to the Java ecosystem, and avoids the complexities of the scala FP purists.
Are you sure? Have a look at Arrow [1] and similar! I am glad that languages offer pure FP frameworks, so I can use them if I think they are the right tool for the job, and can avoid them otherwise. It's an important software engineering choice which style of programming to use, especially with multi-paradigm languages. But the language should not enforce them!
Most Scala programmers are probably just maintaining Play apps or using Apache Spark, with no pure FP in sight. The pure FP contingent is just very active and vocal online.
Unfortunately like you say the pure FP crowd are extremely vocal online and that seeps into the culture of any company that uses Scala. Most of the visible members of the community value and advocate for fp purity and 100% type-safety at any cost, and that has a large effect on who gets attracted to learn Scala in the first place, what they consider to be good or bad code, etc. The resulting culture of firms using Scala ends up being one of pure-fp aspirational, if not pure-fp outright. Anyone who denies the superiority of a pure fp approach is constantly brow-beaten for being such a simpleton.
Every time you dare use something as impure as a mutable object, or a non-const reference (so var instead of val), or even want to look up an item in a collection by index (unsafe operation since it will throw exception if index >= length) you'll have to prepare for a heckling from your team mates. Anyone you might ask help from online will first look down their nose at you for even wanting to do something so despicable, and you'll have to humour them with "well yes oh great FP lords, I know that this is really really bad I know, but I have to for .... reason, please help me anyways!".
There is definitely some truth in what you’re saying —- especially at startups without a strongly developed internal Scala culture.
I think it’s less of an issue at large companies like Twitter, Asana, Databricks, etc, which overall probably employ most working Scala programmers but not the most vocal.
Zalando has probably surpassed Twitter as the biggest Scala shop for a few years now. If you look at Twitter's ecosystem you'll see that while it's mature, the style is very good overall and not so different from modern and opinionated FP libraries. Twitter used to employ people like Travis Brown for instance.
I agree with your evaluation that parts of the FP community are extremely vocal and extremely smug, and this can and does have a bad effect on a community. This is a problem.
Dealing with this problem requires leadership. In particular a project leader typically has to decide (in a Scala context) whether to go FP or imperative, because mixing both is often a problem. Similar to e.g. using message passing or shared memory for communication between threads.
throw exception
This is a good example. It is really important to be very clear from Day 1 how to handle errors in a project. One hybrid choice that is popular is: use exceptions for errors that you cannot recover from, use Options for local error handling.
Option does throw away the error. I like Try { expr } a lot, to the point that I retry, give up, and then serialize a Try[T <: Product] into a Row so flaky dependencies don't trash all the output from a big Spark job.
Yes, that's true, if you want to propagate information about the nature of what went wrong locally (e.g. logging) you need to use something richer (e.g. Either).
This is down voted, but for someone wanting to learn a Scala like language, it delivers most of the capability with less complexity and tooling problems.
I still prefer Scala, but found Kotlin to be enjoyable to write as well. Probably a perfect gateway into Scala if that's an eventual goal too.
Agree. It’s a bag of knives. Used scala for many years at Twitter and other places and There’s always a massive combination of tooling and code reviews that eventually hammer the devs into shape.
My anecdote: if I were to go from Java to Go I would have been I impressed with its ease of concurrency, but going from Java to Scala to Go, I was unimpressed. I already had simplicity of concurrency with Scala without feeling primitive like I did with Go.
"In what way does Scala have Python's convenience and Go's concurrency" - I think that is exactly what the book is trying to teach you. There are some pretty good examples in the free chapters
> So you think, hey! I get to use scala.util.Random in javascript instead of javascript's shitty Math.random() ! Woah! That is so beyond awesome.
What? You can certainly use scala.util.Random from scala.js, there are very few Scala features that Scala.js does not actually support, such as blocking (because javascript) and reflection.
That's not everything that's available in Scala.js, those are just some stubs for smooth cross compiling.
---
Scala.js is certainly not for every project. It's not a better typescript than typescript is. But typescript also isn't the right tool for every project.
This book has a section on "Why Scala" but not on "Why Functional Programming". What is interesting about Scala, if you already know Java (and most CS grads already do), is that Scala is a functional language.
Anyone know of a good book or article that gives an overview of functional programming and answers the question of "Why Functional Programming", without going into details any one functional language?
As someone who has been in the functional programming world for a long time I don't think you can really understand it without some time using it. Beginners tend to focus on language features (immutability, first class functions, map instead of loop, etc.) but it's really a completely different approach to programming than imperative programming. A paradigm shift, in the original sense of the word.
It is also difficult to talk about concepts without some notation, and a notation is exactly what a programming provides (as well as other things)!
That said, several people have attempted to write about it. John Hughes' "Why Functional Programming Matters" is one that often comes up. There are a million versions of this floating around the web. Here is one: https://www.youtube.com/watch?v=bL-CcjKW1lw
> Knowing the language alone isn't enough to go to production: Hands-on Scala introduces the reader to the ecosystem of editors, build tools, web frameworks, database libraries, everything necessary to do real work using Scala. You will finish this book having all the necessary building blocks to be productive using Scala in production.
We definitely need more books to include this by default. Kudos!
I only wish a book like this existed for F#! If anyone has any recommendations, I'm all ears
Honestly interested to know: Is there any added value for a Python developer in learning and using Scala? I love Python, especially because of its ecosystem, its widespreadedness, and of course because of Pandas, Numpy, Matplotlib. But I miss functional constructs from Mathematica or Scheme. Scala seems to be much more systematic and profound, but again: For everyday usage, is it overkill?
It depends on your needs. Scala has some advantages over Python when you want high performance, or if you want to build large programs, or if you're interested in building principled or robust programs using functional programming. Netflix machine learning seem to be leaning towards using both Python and Scala together to take advantage of both. See this project: https://netflixtechblog.com/open-sourcing-polynote-an-ide-in...
I cannot answer your question. Since you love Python, I guess you don't have any problem with dynamic type-checking. You also mentioned Scheme, I take that as you don't mind parentheses either. :)
If you would like to try something that's closest to Scheme and has access to the rich libraries in both the Python and Java ecosystems, give Clojure a try. You have access to the Java libraries out of the box and, with libpython-clj [1], you get access to your familiar Python libraries.
I love Python too! The style of Scala used in this book is much closer to Python than Mathematica or Scheme, with many of the libraries involved being carbon copies (os-lib, requests-scala, ujson) so you will feel right at home.
As to what you get going to Scala, it depends what matters to you.
Does 50x faster compute matter to you, for the code that’s CPU bottlenecked but inconvenient to rewrite in C?
How about easy parallelism, to trivially and fully utilize multiple cores without clunky subprocess management?
How about easy packaging? One builtin command to package your program as a single file that can run anywhere with a JVM, no other global installs required?
You do give up some things using Scala: compile times are slower than iterating on Python scripts, the JVM runtime takes a second or two to warm up when launched, and you don’t have quite the same numpy/scipy machine-learning ecosystem. Whether that is worth it is up to you!
Both the content and layout looks really fantastic!
I wanted to ask any experienced Scala folks if its possible become really proficient without a solid background in Java. I understand that its only JVM hosted language so I guess my concern is how much Java you need to know when things go sideways - stack traces, low level debugging etc?
I learned Scala on the job with no previous Java or JVM experience. At the time I had been writing software professionally for 8 years. Before Scala I had professionally written C, Fortran, and Python.
You will inevitably have to learn about the Java ecosystem when things go sideways.
One example that comes to mind is problems with dependency resolution. SBT, the most common Scala build tool, allows you to add libraries to your project easily with notation like this:
But when things go awry, sbt may provide unhelpful messages. You actually end up having to learn about how Java's Maven (or Ivy) and its repositories work.
A couple of instances I recall:
- SBT repositories were configured to look for dependencies on site A. A was redirecting downloads to site B. Site B was configured with an expired TLS certificate. The error message reported from sbt only mentioned site A. I only figured out what was going on by tracing the network activity.
- Maven central disabled insecure (HTTP) access earlier this year and started requiring HTTPS. Some of our build configurations still referenced repositories via HTTP URLs. I don't remember what the SBT error message was, but it was again cryptic and unhelpful. Other developers who mostly work with Go had to enlist my help in diagnosing the problem and fixing it.
A lot of Scala teaching material also assumes familiarity with Java. "Scala's Traits are like Java Interfaces, but with these improvements: ...."
That didn't help when I hadn't used Java Interfaces before.
Fortunately, it looks like Hands-On Scala Programming doesn't assume a Java background.
It also took me longer than it should have to understand the deep stack traces you often run into. The key: look for lines that reference your own application code, and focus there. (But this doesn't work if you are really encountering library bugs or infrastructure flakiness.) The traces can be very deep and a lot of the lines are not really relevant to solving your problem. I was accustomed to reading shallower Python traces.
Learn to use a debugger early on. JVM code debugging with an IDE is powerful and easy to use. Plus you can't just monkey-patch your dependencies on the fly to add more diagnostics, the way I had done in Python.
I agree about Haoyi's libraries, but you're mention of overhead reminds me of the overhead you run into trying to be purely functional in Scala.
If you're sold on benefits of purely functional programming, I think it's good to know (at least as of a few years ago) Scala makes that more painful than Haskell if you have even a little Haskell experience.
When you’re choosing Scala you have all the perks of JVM platform. You can reuse Java libraries if needed. Scala has pretty powerful type system. JVM in turn is a pretty good platform, with decades of effort, which can tolerate high load, make different optimizations in runtime, tolerate large heaps if needed, GC story in Haskell runtime is not even close to JVM.
The full book is ~400 pages and will be released Summer 2020 (i.e. soon!). If you're interested in being notified when it comes out, there's a mailing list link on the page and I'll let you know when it's out. There will be both E-Books as well as paperbacks & hardcovers (assuming the supply-chains are still open in this COVID-19 global environment...)
The first 5 chapters are already online, for free now and forever. These form a self-contained introduction to the Scala language: setup, basic syntax, collections, and a notable language features. If you're looking for a quick introduction to Scala, this is it.
The rest of the book goes heavily into use cases and projects in a way that few other programming books do: interactive websites, network file synchronizers, programming language interpreters, migration tools, parallel web scrapers, and much more. The book intentionally skips a lot of language esoterica in favor of showing how to use Scala to do things someone might pay you a salary for.
You will learn Scala by building a breadth of useful experience, rather than a depth of knowledge in language minutiae.
The chapters in the book are all based on real projects I have worked on. Most projects take <100 lines of code (i.e ~2 printed pages), and it is a testament to the Scala language that we can build working prototypes of all these things in a single 400-page book!
If this interests you, feel free to leave your email on the website, and browse through the free chapters already available.