9 ms·

Scala is a language I find interesting. Between Spark, Akka, and all of the FP, it seems like it has most of the boxes I’d want. I have read mixed things about

by p33p 6y ago

Scala is a language I find interesting. Between Spark, Akka, and all of the FP, it seems like it has most of the boxes I’d want. I have read mixed things about the language though, specifically with respect to its future viability and development. Is Scala worth learning in 2020? Are there other languages with a well developed actor model that is also performant with numerical computing? That seems like a deal breaker with respect to a language like Elixir.

nicoburns 6y ago
Rust and Actix? I'm not familiar with what other Actor frameworks provide though, so Actix may well not count as "well developed".
- Cyph0n 6y ago
  I don’t have much experience with either, but Akka is probably way more mature than Actix.
- marcinzm 6y ago
  Didn't the Actix creator say "fuck open source, fuck all of you" due to the amount of hate he got from the Rust community for overusing unsafe? That doesn't seem a stable foundation on top of which to build something no matter which side of the argument you fall on.
  - deleted 6y ago
    [deleted]
lmm 6y ago
> Scala is a language I find interesting. Between Spark, Akka, and all of the FP, it seems like it has most of the boxes I’d want. I have read mixed things about the language though, specifically with respect to its future viability and development. Is Scala worth learning in 2020? Scala has always attracted an outsized amount of hate and FUD. That said, Scala 3 has taken a long time to arrive, costing the language a lot of momentum, and makes some fairly radical changes. I'm a huge fan of Scala and I really want it to succeed. Haskell's laziness is a dealbreaker IMO (it makes it impossible to reason about performance), and no other language offers the combination of: 1. A type system powerful enough to replace all your uses of reflection/AOP/metaclassing/etc.. No more magic frameworks to learn; write real-world business applications using nothing but plain old functions and values that follow the normal rules of the language (e.g. your web routes can be literally a function from request to response; they don't look quite as nice as a dedicated routing config file would, but they're normal code that automated refactoring etc. will work normally on). Concretely, what makes this possible is the combination of higher-kinded types (letting you represent any custom effect, e.g. a database transaction, as an F[_] type, and then use the language's for/yield syntax to compose those effects in a way that makes them visible but not overly verbose/intrusive), and records (letting you "walk the object graph" in a type-safe way). Scala can do all this without having to resort to general-purpose macros (there is one macro in shapeless that the whole rest of the ecosystem just reuses), so you can be confident that your IDE/debuggers/etc. will all understand your code. 2. A proper first-class IDE, and a good declarative build tool integrated fully with that IDE (maven - for some reason the Scala community pushes the incomprehensible SBT, but ignore that). 3. Completely seamless compile-to-javascript experience. You write normal code, push the button, and there it is running in your browser. When you want to use a library you import typescript type definitions with https://scalablytyped.org/ https://scalablytyped.org/ and it all just works. Combined with the previous point that means Scala is actually the best language to use for frontend development right now. Unfortunately the set of people who know about Scala and the set of people who do frontend development don't really overlap. I'm not wedded to Scala for the sake of Scala. But no other language comes close. All that said, it definitely feels like the next year or two could be a turning point (in either direction) for the popularity of the language. Scala 3 may revitalise scala or destroy it. So it's undeniably a risk. But I'd say that even if the language becomes less popular, learning it will make you a better programmer and give you an appreciation for what's possible.
- theCodeStig 6y ago
  Can you elaborate on why Haskell's laziness is a dealbreaker?
  - mangamadaiyan 6y ago
    Especially how/why it makes it hard to reason about performance (referring to the GP's point). Asking because I'm genuinely interested in understanding why.
    - jose_zap 6y ago
      I believe this is a Haskell meme in hacker news. There is some truth to it, though. The meme is only relevant for memory allocations. In a lazy language you don’t always know what memory the runtime is holding on to as you haven’t consumed the full result of a function. In practice, you only encounter this problem in very rare situations. I have personally never had to care of bad performance in Haskell in any of my projects. In some projects I had to deal with high memory consumption problems. I could reason about why with ease: I was deciding very large JSON structures in hundreds of threads. Any other language would have had the same high memory profile.
  - lmm 6y ago
    I find it basically impossible to reason about performance in the presence of laziness because it means performance is no longer compositional. In a regular language if I write: def h(a) = { val b = f(a) g(b) } and this is taking too long, I can examine f and g separately; I know that h(a) will take as long to run as f(a) plus g(b) (plus a little bit). In a lazy language I have no clue.
    - theCodeStig 6y ago
      Pardon me if this is dense, but I don't see how laziness prevents you from examining f and g separately.
      - 6y ago
bozoUser 6y ago
Scala is amazing if you want to use it for light weight server programming and want to use functional constructs along the way. If somehow you are convinced to use Akka because of high throughput streaming architecture, please just take a step back and make sure you understand what you are getting into!
- p33p 6y ago
  I don't particularly care about high throughput streaming architecture. The actor model as a concept, its concurrency, and how that models the business domain is more along the lines of what I'm interested in. Same as what intrigues me about Elixir as well, but I need hundreds of thousands of actors that can react to events that require numerical computing.
  - njacobs5074 6y ago
    Actors, in of themselves, are pretty lightweight. The bigger challenge is figuring out how many threads you want to configure to back them. Also, consider that while message passing as an architecture can lend itself to well-structured applications, it's not a panacea against issues like deadlock & livelock. It also sounds like you may need some kind of distributed fabric for that kind of system and again, while Akka provides an elegant toolset, you still have to contend with network resiliency issues. TBH, I have found biggest challenge in constructing these architectures is coordinating their completion or shutdown. You can up with thread leaks that will only show up through extensive testing or experience.
    - bozoUser 6y ago
      If there`s state associated with Akka actors, to shut them down in a proper manner and not lose state you have to use Akka persistence which just means doubling down on Akka ecosystem.
  - lihaoyi 6y ago
    If you're interested in Actors, the book has a chapter `Chapter 16: Message-based Parallelism with Actors` that does an introduction to them, and they are used "in anger" in `Chapter 18: Building a Real-time File Synchronizer`. I've worked hard to make this the best introduction to real-world use cases of Actors I've seen anywhere on the internet. For simplicity, it uses a tiny Actor library instead of a big framework like Akka, but all the concepts and techniques should be transferrable to any Actor-based application
rb808 6y ago
I'm in this boat too. If you look at lot of the Scala talks from 5-8 years ago it talks a lot about why Scala is better than Java, but since then Java has copied a bunch. Now Kotlin is taking over and Scala seems like yesterday's language. I've heard its really slow to compile too which makes it frustrating.
- lihaoyi 6y ago
  The book's web page makes this pitch: Python-like convenience with Go-like performance, easy safety and correctness via compiler checks, and a huge ecosystem of tools and libraries. Compilation time is definitely a tradeoff, but if any of those bullet points seem interesting to you then you should definitely give Scala a serious look
  - ghj 6y ago
    I think a better way to sell a language is to name a few concrete niches that they are amazing at. For example: C for low level systems, javascript for browser apps, bash for shell scripts, java/swift for mobile, erlang for actor models, haskell for compilers, python for ml, go for distributed systems, etc etc. To me, scala used to own the niche of "if you must use a jvm language but don't want to use java". But now kotlin is the first language that springs to mind. What would you say scala is best in class for now?
    - dropofwill 6y ago
      I’d argue Scala still owns that niche. Kotlin is nice if you’re stuck on Android, but with the speed Java is progressing I don’t see a huge difference. Especially in 2-3 years. Also with Scala you get a best in class JS compile target, a great scripting platform in Ammonite, and Graal native image for binaries with fast startup.
      - RhodesianHunter 6y ago
        > I don’t see a huge difference. Especially in 2-3 years. There is a huge difference now. Maybe 50% of that difference could be made up by what Java has in the planning stage. Even if it was 100%, I'm writing code right now.
tombert 6y ago
Yes and no. I'll be honest, I'm personally not a fan of Scala (I prefer Clojure for my JVM goodness), but Scala does give a lot of niceties IF AND ONLY IF you're willing to learn how to program the more pure functional side of things. A lot of Scala converts fall into the trap of "writing Java in Scala", and if you're doing that I'd argue it's not really worth it...at that point, you can really just write Java; however, if you're willing to learn functional principles (including some basic category theory), it has an incredibly powerful Hindley Milner system under the hood. Spark is a really useful tool, and the Java bindings work well enough, but it clearly is a "Scala-first" framework. For that alone, I'd argue getting proficient with Scala is probably worth it. My biggest complaint with Scala is that, because it's very much not opinionated, you end up getting paradigm-clashes with larger teams of people. This will happen to some extent with most languages, but I find it especially egregious with Scala. If you decide to use Scala on a team of multiple people, I cannot overstate the need to codified standards of what is allowed and not allowed.
- sjrd 6y ago
  > but Scala does give a lot of niceties IF AND ONLY IF you're willing to learn how to program the more pure functional side of things. I disagree. Context: Scala has been my language of choice for the past 9 years, and I'm the author of Scala.js. I don't know anything about category theory, I don't really care about referential transparency, and I've used a monad as a monad exactly 0 times in my career. If you're really writing Java in Scala, then yes, perhaps Kotlin is a better choice for you. But there is a whole world of mix of OO, imperative and FP that you can do with Scala, and as soon as you start writing a bit more functionally (immutable collections, not category theory), you get a huge value from Scala. IMO no other language gives you that. I have crystallised the essence of what I consider Scala to be in my talk Functional Object-Oriented Imperative Scala [1], for those who are interested. [1] https://vimeo.com/362001027 https://vimeo.com/362001027
  - sideeffffect 6y ago
    https://vimeo.com/362001027 https://vimeo.com/362001027 is dead :(
dustingetz 6y ago
I left scala in 2014 because pure functional scala was clearly a dead-end (in industry) and why else would I use it, but in 2020, ZIO + Scalajs is making me want to try pure FP again (for industry). (I'm a ClojureScript programmer)
- lihaoyi 6y ago
  I wouldn't call pure functional Scala a dead-end, but it's definitely a niche that not everyone will be comfortable with. For those that enjoy it it works great, but this book is intended to promote a style of programming that is perhaps more approachable to programmers coming from outside the Scala ecosystem. Scala.js amazing. It just works. I've picked it up after multiple years of non-use and it everything worked perfectly with no surprises. I don't cover it in this book, but might write about it in another book in future!
nikitaga 6y ago
Scala is a formidable language. It is very flexible, elegantly supporting a variety of programming styles from Haskell-on-the-JVM to Java++ to everything in between. Those two extremes hate on each other a lot, and this also spills out into annoyance at Scala not being ever more perfect for one of those extremes at the expense of the other. Then there are career enterprise Java programmers who are fine with Java and make it Scala's fault. Scala community is not a monoculture, it's a refuge for different people with different ideas, and the vast majority of its users are quite happy with it and with each other. But that also means that different Scala teams work differently, everyone's experience with Scala is greatly affected by the preferences of the developers they're working with. Everyone mostly agrees what a React.js application should look like. Not the same for Scala. You're going to have a tough time working with a Hascalator codebase if that's not how you think. With preferences-compatibility warning in mind, Scala is still amazing for complex projects thanks to its rich type system and language features as long as everyone's on the same page for how they want to use Scala. And yes, it's overkill for your microservice that has seven classes and a plain JSON HTTP API. Use node or go or whatever for that kind of thing. Scala is doubly amazing for complex full-stack projects thanks to Scala.js. These days I basically choose my stack from either full stack JS or full stack Scala depending on project complexity. It's true but not unexpected that Scala 3 is taking a while. Good things take time. And once again, the amount of whining on the scala internet even about things like Dotty not being officially called Scala 3 (until that inevitably happened) was insane. If you want to learn a safe-bet language strictly for career purposes, I'm not sure about Scala. The ecosystem is mature, the jobs pay well, and the users are very qualified on average in my experience, but it's a more niche job market than react/redux/node.js and all the other hip stuff. If you want to learn Scala for any other reason though, go ahead, it can be fun and productive. Odersky's coursera course is a great introduction.
- lihaoyi 6y ago
  Trying to make Scala better for "simple" projects is definitely a focus of this book. You are right that traditionally the fixed overhead of learning Scala made it only worth it for huge and complex projects, but this book introduces it in a way that's easy to learn and easy to get started with, making it feasible to use for tiny projects 1 line of code and above. In particular, none of the projects in this book take more than ~2 pages of text (~90 lines). You implement a programming language in <90 lines, a real-time network file synchronizer in <90 lines, a websocket chat website in <90 lines, a massively-parallel web crawler in <90 lines. These are 90 line complete applications, not "90 lines changed in a sea of boilerplate" or some other nonsense like that! The goal of all this is to make a case that yes, you can use Scala for small projects! But you'll have to read the book to see for yourself if you find it convincing :)
namelosw 6y ago
The actor model is not performant with numerical computing since there are usually messaging overhead. And it might be more straightforward and use it in the typical ways instead of putting them in actors. If it is worth learning, the really depending on what you want from this language. It was and it would be the most novel language in the mainstream industry - it has almost all the features developers can dream of, and most of the features are not arbitrarily piled together like C++, instead, there are synergies between features. With that being said, it's still a hard language to learn. And programmers from different backgrounds wouldn't interpret it in the same way. In real-world codebases, if the teams are not very good at training and aligning, it would be too diverse. All in all, it's not only a get-things-done technology like Go, but it's pretty educating and mind-blowing.
scns 6y ago
You could use Rustler to use nifs written in Rust with erlang/elixir. The tradeoff would be two languages but maybe it could deliver higher performance.

by p33p 6y ago

nicoburns 6y ago

Rust and Actix? I'm not familiar with what other Actor frameworks provide though, so Actix may well not count as "well developed".

Cyph0n 6y ago
I don’t have much experience with either, but Akka is probably way more mature than Actix.
marcinzm 6y ago
Didn't the Actix creator say "fuck open source, fuck all of you" due to the amount of hate he got from the Rust community for overusing unsafe? That doesn't seem a stable foundation on top of which to build something no matter which side of the argument you fall on.
- deleted 6y ago
  [deleted]

lmm 6y ago

> Scala is a language I find interesting. Between Spark, Akka, and all of the FP, it seems like it has most of the boxes I’d want. I have read mixed things about the language though, specifically with respect to its future viability and development. Is Scala worth learning in 2020? Scala has always attracted an outsized amount of hate and FUD. That said, Scala 3 has taken a long time to arrive, costing the language a lot of momentum, and makes some fairly radical changes. I'm a huge fan of Scala and I really want it to succeed. Haskell's laziness is a dealbreaker IMO (it makes it impossible to reason about performance), and no other language offers the combination of: 1. A type system powerful enough to replace all your uses of reflection/AOP/metaclassing/etc.. No more magic frameworks to learn; write real-world business applications using nothing but plain old functions and values that follow the normal rules of the language (e.g. your web routes can be literally a function from request to response; they don't look quite as nice as a dedicated routing config file would, but they're normal code that automated refactoring etc. will work normally on). Concretely, what makes this possible is the combination of higher-kinded types (letting you represent any custom effect, e.g. a database transaction, as an F[_] type, and then use the language's for/yield syntax to compose those effects in a way that makes them visible but not overly verbose/intrusive), and records (letting you "walk the object graph" in a type-safe way). Scala can do all this without having to resort to general-purpose macros (there is one macro in shapeless that the whole rest of the ecosystem just reuses), so you can be confident that your IDE/debuggers/etc. will all understand your code. 2. A proper first-class IDE, and a good declarative build tool integrated fully with that IDE (maven - for some reason the Scala community pushes the incomprehensible SBT, but ignore that). 3. Completely seamless compile-to-javascript experience. You write normal code, push the button, and there it is running in your browser. When you want to use a library you import typescript type definitions with https://scalablytyped.org/ https://scalablytyped.org/ and it all just works. Combined with the previous point that means Scala is actually the best language to use for frontend development right now. Unfortunately the set of people who know about Scala and the set of people who do frontend development don't really overlap. I'm not wedded to Scala for the sake of Scala. But no other language comes close. All that said, it definitely feels like the next year or two could be a turning point (in either direction) for the popularity of the language. Scala 3 may revitalise scala or destroy it. So it's undeniably a risk. But I'd say that even if the language becomes less popular, learning it will make you a better programmer and give you an appreciation for what's possible.

theCodeStig 6y ago
Can you elaborate on why Haskell's laziness is a dealbreaker?
- mangamadaiyan 6y ago
  Especially how/why it makes it hard to reason about performance (referring to the GP's point). Asking because I'm genuinely interested in understanding why.
  - jose_zap 6y ago
    I believe this is a Haskell meme in hacker news. There is some truth to it, though. The meme is only relevant for memory allocations. In a lazy language you don’t always know what memory the runtime is holding on to as you haven’t consumed the full result of a function. In practice, you only encounter this problem in very rare situations. I have personally never had to care of bad performance in Haskell in any of my projects. In some projects I had to deal with high memory consumption problems. I could reason about why with ease: I was deciding very large JSON structures in hundreds of threads. Any other language would have had the same high memory profile.
- lmm 6y ago
  I find it basically impossible to reason about performance in the presence of laziness because it means performance is no longer compositional. In a regular language if I write: def h(a) = { val b = f(a) g(b) } and this is taking too long, I can examine f and g separately; I know that h(a) will take as long to run as f(a) plus g(b) (plus a little bit). In a lazy language I have no clue.
  - theCodeStig 6y ago
    Pardon me if this is dense, but I don't see how laziness prevents you from examining f and g separately.
    - 6y ago

bozoUser 6y ago

Scala is amazing if you want to use it for light weight server programming and want to use functional constructs along the way. If somehow you are convinced to use Akka because of high throughput streaming architecture, please just take a step back and make sure you understand what you are getting into!

p33p 6y ago
I don't particularly care about high throughput streaming architecture. The actor model as a concept, its concurrency, and how that models the business domain is more along the lines of what I'm interested in. Same as what intrigues me about Elixir as well, but I need hundreds of thousands of actors that can react to events that require numerical computing.
- njacobs5074 6y ago
  Actors, in of themselves, are pretty lightweight. The bigger challenge is figuring out how many threads you want to configure to back them. Also, consider that while message passing as an architecture can lend itself to well-structured applications, it's not a panacea against issues like deadlock & livelock. It also sounds like you may need some kind of distributed fabric for that kind of system and again, while Akka provides an elegant toolset, you still have to contend with network resiliency issues. TBH, I have found biggest challenge in constructing these architectures is coordinating their completion or shutdown. You can up with thread leaks that will only show up through extensive testing or experience.
  - bozoUser 6y ago
    If there`s state associated with Akka actors, to shut them down in a proper manner and not lose state you have to use Akka persistence which just means doubling down on Akka ecosystem.
- lihaoyi 6y ago
  If you're interested in Actors, the book has a chapter `Chapter 16: Message-based Parallelism with Actors` that does an introduction to them, and they are used "in anger" in `Chapter 18: Building a Real-time File Synchronizer`. I've worked hard to make this the best introduction to real-world use cases of Actors I've seen anywhere on the internet. For simplicity, it uses a tiny Actor library instead of a big framework like Akka, but all the concepts and techniques should be transferrable to any Actor-based application

rb808 6y ago

I'm in this boat too. If you look at lot of the Scala talks from 5-8 years ago it talks a lot about why Scala is better than Java, but since then Java has copied a bunch. Now Kotlin is taking over and Scala seems like yesterday's language. I've heard its really slow to compile too which makes it frustrating.

lihaoyi 6y ago
The book's web page makes this pitch: Python-like convenience with Go-like performance, easy safety and correctness via compiler checks, and a huge ecosystem of tools and libraries. Compilation time is definitely a tradeoff, but if any of those bullet points seem interesting to you then you should definitely give Scala a serious look
- ghj 6y ago
  I think a better way to sell a language is to name a few concrete niches that they are amazing at. For example: C for low level systems, javascript for browser apps, bash for shell scripts, java/swift for mobile, erlang for actor models, haskell for compilers, python for ml, go for distributed systems, etc etc. To me, scala used to own the niche of "if you must use a jvm language but don't want to use java". But now kotlin is the first language that springs to mind. What would you say scala is best in class for now?
  - dropofwill 6y ago
    I’d argue Scala still owns that niche. Kotlin is nice if you’re stuck on Android, but with the speed Java is progressing I don’t see a huge difference. Especially in 2-3 years. Also with Scala you get a best in class JS compile target, a great scripting platform in Ammonite, and Graal native image for binaries with fast startup.
    - RhodesianHunter 6y ago
      > I don’t see a huge difference. Especially in 2-3 years. There is a huge difference now. Maybe 50% of that difference could be made up by what Java has in the planning stage. Even if it was 100%, I'm writing code right now.

tombert 6y ago

Yes and no. I'll be honest, I'm personally not a fan of Scala (I prefer Clojure for my JVM goodness), but Scala does give a lot of niceties IF AND ONLY IF you're willing to learn how to program the more pure functional side of things. A lot of Scala converts fall into the trap of "writing Java in Scala", and if you're doing that I'd argue it's not really worth it...at that point, you can really just write Java; however, if you're willing to learn functional principles (including some basic category theory), it has an incredibly powerful Hindley Milner system under the hood. Spark is a really useful tool, and the Java bindings work well enough, but it clearly is a "Scala-first" framework. For that alone, I'd argue getting proficient with Scala is probably worth it. My biggest complaint with Scala is that, because it's very much not opinionated, you end up getting paradigm-clashes with larger teams of people. This will happen to some extent with most languages, but I find it especially egregious with Scala. If you decide to use Scala on a team of multiple people, I cannot overstate the need to codified standards of what is allowed and not allowed.

sjrd 6y ago
> but Scala does give a lot of niceties IF AND ONLY IF you're willing to learn how to program the more pure functional side of things. I disagree. Context: Scala has been my language of choice for the past 9 years, and I'm the author of Scala.js. I don't know anything about category theory, I don't really care about referential transparency, and I've used a monad as a monad exactly 0 times in my career. If you're really writing Java in Scala, then yes, perhaps Kotlin is a better choice for you. But there is a whole world of mix of OO, imperative and FP that you can do with Scala, and as soon as you start writing a bit more functionally (immutable collections, not category theory), you get a huge value from Scala. IMO no other language gives you that. I have crystallised the essence of what I consider Scala to be in my talk Functional Object-Oriented Imperative Scala [1], for those who are interested. [1] https://vimeo.com/362001027 https://vimeo.com/362001027
- sideeffffect 6y ago
  https://vimeo.com/362001027 https://vimeo.com/362001027 is dead :(

dustingetz 6y ago

I left scala in 2014 because pure functional scala was clearly a dead-end (in industry) and why else would I use it, but in 2020, ZIO + Scalajs is making me want to try pure FP again (for industry). (I'm a ClojureScript programmer)

lihaoyi 6y ago
I wouldn't call pure functional Scala a dead-end, but it's definitely a niche that not everyone will be comfortable with. For those that enjoy it it works great, but this book is intended to promote a style of programming that is perhaps more approachable to programmers coming from outside the Scala ecosystem. Scala.js amazing. It just works. I've picked it up after multiple years of non-use and it everything worked perfectly with no surprises. I don't cover it in this book, but might write about it in another book in future!

nikitaga 6y ago

Scala is a formidable language. It is very flexible, elegantly supporting a variety of programming styles from Haskell-on-the-JVM to Java++ to everything in between. Those two extremes hate on each other a lot, and this also spills out into annoyance at Scala not being ever more perfect for one of those extremes at the expense of the other. Then there are career enterprise Java programmers who are fine with Java and make it Scala's fault. Scala community is not a monoculture, it's a refuge for different people with different ideas, and the vast majority of its users are quite happy with it and with each other. But that also means that different Scala teams work differently, everyone's experience with Scala is greatly affected by the preferences of the developers they're working with. Everyone mostly agrees what a React.js application should look like. Not the same for Scala. You're going to have a tough time working with a Hascalator codebase if that's not how you think. With preferences-compatibility warning in mind, Scala is still amazing for complex projects thanks to its rich type system and language features as long as everyone's on the same page for how they want to use Scala. And yes, it's overkill for your microservice that has seven classes and a plain JSON HTTP API. Use node or go or whatever for that kind of thing. Scala is doubly amazing for complex full-stack projects thanks to Scala.js. These days I basically choose my stack from either full stack JS or full stack Scala depending on project complexity. It's true but not unexpected that Scala 3 is taking a while. Good things take time. And once again, the amount of whining on the scala internet even about things like Dotty not being officially called Scala 3 (until that inevitably happened) was insane. If you want to learn a safe-bet language strictly for career purposes, I'm not sure about Scala. The ecosystem is mature, the jobs pay well, and the users are very qualified on average in my experience, but it's a more niche job market than react/redux/node.js and all the other hip stuff. If you want to learn Scala for any other reason though, go ahead, it can be fun and productive. Odersky's coursera course is a great introduction.

lihaoyi 6y ago
Trying to make Scala better for "simple" projects is definitely a focus of this book. You are right that traditionally the fixed overhead of learning Scala made it only worth it for huge and complex projects, but this book introduces it in a way that's easy to learn and easy to get started with, making it feasible to use for tiny projects 1 line of code and above. In particular, none of the projects in this book take more than ~2 pages of text (~90 lines). You implement a programming language in <90 lines, a real-time network file synchronizer in <90 lines, a websocket chat website in <90 lines, a massively-parallel web crawler in <90 lines. These are 90 line complete applications, not "90 lines changed in a sea of boilerplate" or some other nonsense like that! The goal of all this is to make a case that yes, you can use Scala for small projects! But you'll have to read the book to see for yourself if you find it convincing :)

namelosw 6y ago

The actor model is not performant with numerical computing since there are usually messaging overhead. And it might be more straightforward and use it in the typical ways instead of putting them in actors. If it is worth learning, the really depending on what you want from this language. It was and it would be the most novel language in the mainstream industry - it has almost all the features developers can dream of, and most of the features are not arbitrarily piled together like C++, instead, there are synergies between features. With that being said, it's still a hard language to learn. And programmers from different backgrounds wouldn't interpret it in the same way. In real-world codebases, if the teams are not very good at training and aligning, it would be too diverse. All in all, it's not only a get-things-done technology like Go, but it's pretty educating and mind-blowing.

scns 6y ago

You could use Rustler to use nifs written in Rust with erlang/elixir. The tradeoff would be two languages but maybe it could deliver higher performance.