Li Haoyi, a Scala developer, writes about Scala style, build tools, testing, functional programming, and tools like Ammonite.
Commenters praise his Scala posts and book as clear for experienced developers, and cite his post on what's wrong with SBT.
> when properly designed (especially, avoiding the feeping creaturitis of something like Scala)
What I find interesting here is that Scala has the reputation of being a complex language, while its syntax and grammar are among the simplest and most straightforward there is: https://images.app.goo.gl/K1NTGUP4G9T6wfY48
I believe that this is what "scalable" means in the eyes of its creator: it offers very powerful abstractions to be adequate for mundane tasks (e.g. file-level scripting) up to complex systems and problem spaces.
Yes, as a consequence, people have created libraries and codebases with Scala that are inadequately complex and abstract for the problem at hand, but that's not something one should blame on the language but on the project/company culture. Same is true for any language: C++ templates can be abused in ludicrous ways, some of Java's design patterns make you wish inheritance would be forbidden, python's module imports potentially overwriting globals and other footguns.
No language can be dumbed-down so much that the resulting codebase becomes immune to some amount of "abstraction management", not go, not even python. Once this is understood and accepted, it becomes obvious that it's not worthy to castrate a language on the basis of "simplicity", because eventually this complexity will be warranted at a point in the future or for some aspect of the project.
I think the go designers did the right thing here, I don't think this will bring dramatic changes…
> awkward currying
Personally, even though I haven't really thought it through deeply, I feel like Scala would be better if everything were curried.
> Subtyping also has many complex consequences
But also substantial benefits!
> There is limited type inference
I wish Scala would improve in this regard. Maybe paradoxically, inference works better with code tuned for subtyping and variance.
> tail call optimisation
This will be fundamentally solved by Project Loom. At least on the JVM (there's also Scala on JS and on LLVM).
> F# has units of measure
I dearly miss those. Type Providers even more so.
> OCaml has polymorphic variants
Could be nice in Scala. Or maybe not, can't tell now. And there's always the risk of too many features, which makes a language worse, not better.
> It was not designed as a functional programming language first and foremost
This is misleading at best. It was designed to show that the distinction between OOP and FP is arbitrary, not fundamental. In other words, Scala erases the distinction, it's fully OOP and fully FP. Scala has higher order functions, ADTs, pattern matching, a module system, like SML/OCaml. But it uses keywords `class` and calls it's instances "object" like Java. And it's interoperable with Java. But theoretically there's no fundamental distinction.
More languages are becoming more and more like Scala, btw.
https://www.lihaoyi.com/post/FromFirstPrinciplesWhyScala.html
And the concept of a programming language paradigm…
> I like Rust's pragmatism.
Me too.
But Scala is also a very pragmatic language. If you want something academic go for Haskell.
> Allow limited operator overload.
Nitpick: Scala does not have any operators. So it doesn't have operator overloading at all.
Scala simulates operators by infix method syntax.
Instead of writing `1.+(2)` you can just write `1 + 2`. But the later is the same method call as the first one!
> Eschew HKT for a simpler abstractions.
AFAIK HKTs are more or less "just postponed" in Rust, AFAIK.
People would like to add them of course. The discussion goes on forever by now. Some small insight (there is much more when you look for it):
https://github.com/rust-lang/rfcs/issues/324
https://internals.rust-lang.org/t/higher-kinded-types-the-difference-between-giving-up-and-moving-forward/3908/7
> Don't go in the deep end with type power, nor too much in opposite direction and avoid any complicated feature.
While having a full ML style type system with afine types on top, and quite some other type level mechanics up to singleton types?
Sure sure, no power in here. :-)
> The more powerful feature the more abusable it is, and Scala loves the power at all cost.
Everything is "abusable". This is not an argument.
But that Scala loves power at all cost is simply not true. The contrary is.
Just to cite one of the most influential post in Scala land of all times:
https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html
This, and the…
First I would ask, what's your motivation?
- If you are just looking for a better Java, Kotlin is likely the way.
- If you are looking for a better language that leverages the JVM ecosystem, then, Scala might be the way.
It also depends about what kinds of projects do you want to work with, Scala is a no-go for Android if you are just learning, on the other hand, if you plan to work in distributed systems, Scala is great for that.
The biggest advantage I see on Kotlin right now is the Multiplatform side, we are taking advantage from it to write a library once, that can be consumed by Android, iOS, and our backend services built with Scala (we even want it for the JavaScript side but it isn't as mature as Scala.js).
On the Scala side, it has a very nice ecosystem, with powerful tools that usually get ported to other languages, for example, its the first language where I see good tools for:
- Compile time checked SQL queries.
- Documentation tools that actually compile your code examples to make sure it is correct (even arrow-ank on Kotlin was inspired by tut from Scala).
- Generating JavaScript code that actually works.
While Scala may have had not-so-good tooling years ago, right now is pretty good.
People usually complain about over-complex code, which can be true, but, you can find bad code in any language, on Scala you can choose a path, whether to be pure-FP or pure when practical, and there is great tooling for any side, I personally try to be practical and…
Yeah, that's true. Scala 2 allowed a lot of weird things and sometimes even nudged people into the direction of overengineering and writing cryptic code. I'm not surprised a lot of people were burned.
Basically, you needed a good and experienced developer from the start of a project for it to be a nice code base.
> I'm very fluent in Scala 2, but I will avoid Scala if I can, mostly to stay away from purely functional programmers.
There is the whole [Li Haoyi](http://www.lihaoyi.com/) ecosystem in Scala that is much more python-like, but nicely designed, statically typed and using immutable datastructures by default. I think it's the best you can get nowadays if you want to have immutable datastructures on the JVM. Any other option I've ever tried was way worse.
If you are fine with Java's stdlib then I guess Kotlin is the better choice.
> Does it prevent me from using a non-thread-safe object in multiple threads?
I would answer the question with yes, but maybe in a different way than you might expect. Scala prevents problems/bugs from using a non-thread-safe object in multiple threads by simply having immutability by default. Rust cannot do that (due to performance) so it has to have another way (the borrow checker). I would argue that the Scala way is better if you don't need the performance / memory-efficiency of rust and can live with garbage collection. That reduces the domains that you can use Scala for, but in exchange the code will be simpler compared to Rust…
I will toot the author's horn for him. He has a fine series of Scala posts on his blog [1] and his book Hands-On Scala Programming [2] is a great introduction to building real applications with Scala so that any experienced developer can understand and extend them.
I work at a small company that has been using Scala for 7 years. Some of the prior employees enjoyed playing with advanced language features and writing libraries for the most general possible case even when that made it hard to understand how they were used for the 2 actual cases we needed to handle. Akka, Cats, and Shapeless were all over the place.
Those earlier employees have churned off to other places and I have successively simplified the code they wrote that is still useful, while encouraging the use of no more language power than necessary in new development. Hands-On Scala Programming is the book I give new hires as a language introduction that shows the sort of style to be preferred. It's much more like super-powered Python than like Haskell.
I have written C, Fortran, JavaScript, Python, and Scala for money. When I started on Scala I had never written Java nor used any JVM language. I have come to really appreciate the rich ecosystem of JVM libraries, the instrumentation and profiling tools I get, and many aspects of the Scala language and standard library. I love Scala's collections and miss their power and ease when I'm writing Python. (Which I still do for certain scripting tasks and for…