Hands-on Scala Programming
handsonscala.com
handsonscala.com
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.
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!
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.
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).
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.
Given how much work I’ve obsessively put into that effort over many years, the final library damn well better be good to use!
- 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!
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.
should be: This chapter will not be covering any Scala-specific
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.
Here is a by no means exhaustive list of projects
- A buildtool
- A bash replacement that speaks Scala
- A test framework
- A parsing library
- Ports of several python libraries in Scala
- Several libraries in the scala.js ecosystem
For the full list see https://github.com/lihaoyi?tab=repositories
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 :)
Sorry but saying a dude on github has to do a test framework or port libraries, convince me Scala isn't ready.
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".
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.
- 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
I'd guess all is done after work. Please support him to make Scala better: https://www.patreon.com/join/lihaoyi
My day job disagrees Haskell isn't good for profit ;)
https://www.simplehaskell.org/
Then if you use simple Haskell for a year and want more type safety, you can fearlessly refactor to get that.
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).
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.
Features we know Scala 3 will have https://dotty.epfl.ch/docs/
A comparison of features across Scala 2.x and Scala 3 is the migration guide https://github.com/scalacenter/scala-3-migration-guide
It has a lot of what makes Scala good with less of the bits that make it bad.
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.
avoids the complexities
of the scala FP purists.
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.
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!".
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.
Spark (and Kafka too maybe) are outliers here.
throw exception
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.
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.
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!
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.
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.
> Because this is the scala api that the scalajs folks expose - https://www.scala-js.org/api/scalajs-stubs/latest/#scala.pac.... . So that's fewer than 70 types.
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.
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?
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
I gave a talk on this topic, with examples in Scala: https://www.youtube.com/watch?v=bL-CcjKW1lw
This paper is about the idea of paradigm shifts in programming, and is beautiful and profound, though not about functional programming: https://www.dreamsongs.com/Files/Incommensurability.pdf
For me, Scala is much nicer for imperative/OOP than Java, in ways that aren't just skin deep.
https://medium.com/@ryanberckmans/why-i-like-scala-45e65cde3...
https://www.lihaoyi.com/post/WhatsFunctionalProgrammingAllAb...
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
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.
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!
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?
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:
libraryDependencies += "com.lihaoyi" %% "upickle" % "1.0.0"
Normally that is fine.
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.
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.