15 ms·

Scala at scale at Databricks

251 points by lihaoyi 5y ago

waynesonfire 5y ago
Scala was a terrible technology that was adopted by my organization five years ago and were still paying the price. How to deprecate this at scale? The extent to which i like scala is as a dsl for describing etl jobs with spark and i prefer the RDD api. Engineers are consistently crippled by it, we dont even use shapeless or scalaz. Spec2 is a terrible dsl that offers a shitty vocabular to write unit tests and makes the common path incredible difficult compared to junit.
- eweise 5y ago
  Well, you know, you can just use Junit with Scala. That's what I do.
- mhzsh 5y ago
  Spark is really its own world that’s fairly separate from the Scala community at large. What makes it a ”terrible technology”?
  - waynesonfire 5y ago
    Scala moved the needle five years ago and made java better among other languages. Using scala helped me grow as an engineer. in my view, it has no place in an enterprise. I require a mature environment that favors consistency. It boils down to reducing complexity. I can barely handle the complexity growth due to the demands of the business, whether it be software engineering or people and these reasons do not justify scalas pluses. Ymmv.
    - kaba0 5y ago
      I think scala can absolutely account for that complexity, like it is not a one-way street. It can scale both up and down on expressivity. But I agree that often times it is not used that way.
  - tharne 5y ago
    I wouldn't say spark is terrible, but it is a sort of a "reverse bicycle". If you put a spark codebase down for a week or two and pick it back up, it feels like you're learning everything all over again.
- fnord77 5y ago
  newer java has many similar features that scala had, so it seems moot to use it now. unless you like ridiculously long compilation times and having libs tied to what version of the compiler you're using (serious WTF)
  - ebruchez 5y ago
    > it seems moot to use it now It's true that some features of Scala have made it to Java, but I am not sure the gap between the two languages has shrunk much. For example while Java has added first-class functions and closures, it is still clumsy to attempt any serious functional programming approach with Java; Scala's type system is still way ahead; Scala compile to the JVM, JavaScript, and now native via LLVM. > having libs tied to what version of the compiler you're using It's never been that. However libraries used to be tied to the major version of Scala (for example 2.11, 2.12, 2.13) as major versions were not binary-compatible with each other. Scala 3 addresses this thanks to the TASTY format which creates a strong foundation for binary compatibility. [1] You can use Scala 3 libraries with Scala 2.13 and, more importantly, Scala 2.13 libraries with Scala 3. In short, Scala is not standing still. [1] https://docs.scala-lang.org/scala3/guides/tasty-overview.html https://docs.scala-lang.org/scala3/guides/tasty-overview.htm...
- lmm 5y ago
  > Spec2 is a terrible dsl that offers a shitty vocabular to write unit tests and makes the common path incredible difficult compared to junit. Yes it is. Deprecate using it and migrate away from it. I hate that these shitty overengineered Cucumber wannabees are what "Scala" means to most people. It's a great language IMO, but you need to make sure fancy frameworks pay their weight. IMO Shapeless and Scalaz-or-equivalent do - replacing reflection or AOP with plain old compiled code, even complex code, is a huge win. But SBT and the mess of Scala testing libraries are just huge complexity for marginal benefit.
- amir734jj 5y ago
  In my previous company we used Scala + Spark and I hated it initially. I had no idea how syntax worked, no clue about functional programming or the ecosystem. I got interested in the Scala as a language and decided to pursue PhD in computer science focusing on compilers. Long story short, I am finishing my PhD on Monday :) Don't be negative about technology. Be positive.
  - dikei 5y ago
    > In my previous company we used Scala + Spark and I hated it initially. I had no idea how syntax worked, no clue about functional programming or the ecosystem. It's funny that if you tell Cat-purist that Spark is functional-style, they would laugh at your face :)
    - caoilte 5y ago
      That's an unhelpful thing to say. Most people agree that the Spark scala DSL is functional style. It's not as advanced in the style as other scala ecosystems but it has been a very good on ramp for people discovering functional style and is widely celebrated for that
  - burntoutfire 5y ago
    Scala + Spark is absolutely the sane face of Scala. Try using stuff like cats (basically Haskel ported to Scala) to experience the deep end of the pool.
    - esarbe 5y ago
      To discard Cats as 'basically Haskell ported to Scala' is doing it a bit of a disservice. Yes, it explores pure functional programming, but that design space is huge.
- zalequin 5y ago
  It saddens me to see that the HN crowd had been diluted to such an extent in terms of engineering quality that straight up luddism has become the norm, often accompanied with silly ad hominems.
  - _vertigo 5y ago
    I don't agree with him, but that's a biiit smug..
- random314 5y ago
  As a counterpoint, I used scala at my previous job and it was the best coding experience and environment I ever experienced. Got rid of 1000s of lines of Java and SQL for 100s of lines of scala, scalding and Spark. The codebase size on the first migration was 10% of the original Java+SQL. overall, a team of 6 worked for 4 years to produce 10K lines of high quality Scala code for a very complex app and platform after the first transition from 10K lines of java+sql to 1K lines of scala. Never experienced something like this before or after. At the next place I wrote 400 lines of C++ mapreduce over 3 days, which could have been 40 lines of sql or 10 lines of scalding/spark. Jarring transition.
  - chrisjc 5y ago
    Regarding the reduction in lines of SQL. Doesn't this imply a tradeoff with where compute is utilized? By reducing SQL, wouldn't you be "pushing up" the compute from the database to the JVM while also increasing the amount of data that has to be moved around? Edit: Wait, did you imply that the SQL you replaced with Scala ultimately gets transpiled into SQL (spark or other dataframe engine) and "pushed down" to the database? Now you're just maintaining Scala and not a rats nest of SQL strings concatenated together? If so, that's pretty awesome.
    - random314 5y ago
      Most of this was Hadoop. Which executes mapreduce jobs written in sql on the jvm. The scalding jobs executed faster, except for one job for which we had to stick with Apache pig. Spark jobs were native RDDs before the SQL Spark era.
    - random314 5y ago
      No. There was no transpiling to SQL. This was several years ago, before Spark SQL. The SQL was HiveQL. Spark didn't really support SQL at the time and was native JVM Scala RDDs. HiveQL with UDFs compiled to JVM bytecode typically ended up performing worse than scalding that corresponds to straight raw jvm map reduce jobs that are the real native interface of Hadoop. The real performance drag from HQL came from developers writing inefficient map reduce jobs with extra joins to avoid writing Java UDFs because they were a huge PITA. In scalding, developers wrote map reduce jobs with as few group bys as possible. Our hadoop infra team actually complimented us on how great the execution profile of our teams jobs were.
philipkglass 5y ago
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 accessing Python-ecosystem libraries.) [1] https://www.lihaoyi.com/ https://www.lihaoyi.com/ [2] https://www.handsonscala.com/ https://www.handsonscala.com/
- tlarkworthy 5y ago
  I considered it a near miss when a Scala shop rejected me because I used Maven to compile their coding challenge. Clearly the company was full of over-complicaters and actively recruiting for it.
  - _vertigo 5y ago
    How did that conversation go? “We like your solution but did you seriously just use Maven?” What did they say exactly?
    - the_only_law 5y ago
wiradikusuma 5y ago
I completely agree with their pragmatic approach to Scala. Scala is a very powerful language, and you can do super crazy stuff. My approach to writing Scala code is similar: 1. Write the code like a better-Java/typesafe-Python (that is, imperative style). 2. Glance through the code. For collections, usually there's a more concise approach. 3. Read the code again. If you think what you did in #2 is making the code _too_ concise, you might need to think twice (or add comments).
- dehrmann 5y ago
  Regarding 1, wouldn't Kotlin be a better choice?
  - dxxvi 5y ago
    I think no, because, IMO, Kotlin doesn't have a good pattern matching like Scala.
  - lmm 5y ago
    I don't think so. Kotlin is an unmaintainable soup of features: it can match all the selling-point examples of Scala but only by adding ad-hoc special cases for each one. (For example, Kotlin has null safety and it lets you write code using errors-as-values style "either" types - but it has two completely separate syntaxes for these things, and so it's impossible to interoperate or reuse code between those two approaches). In practice Kotlin codebases still use magical incomprehensible reflection (Spring Boot) and magical compile-time manipulation (Kapt), so you have the worst of both Java and Scala worlds.
    - wiseowise 5y ago
      > Kotlin is an unmaintainable soup of features Are you sure you're not confusing Kotlin with Scala? > For example, Kotlin has null safety and it lets you write code using errors-as-values style "either" types - but it has two completely separate syntaxes for these things, and so it's impossible to interoperate or reuse code between those two approaches And that is a problem how? Stick to one style. > In practice Kotlin codebases still use magical incomprehensible reflection (Spring Boot) https://github.com/spring-projects-experimental/spring-fu/tree/main/kofu https://github.com/spring-projects-experimental/spring-fu/tr... > and magical compile-time manipulation (Kapt) There's nothing magical about it.
coffeecloud 5y ago
Scala is an organizational red flag for me, especially if their recruiters are looking for "scala engineers."
- m01 5y ago
  What did you think of the organisation described in this HN post?
  - phgn 5y ago
    BTW, the described organisation does not hire "Scala Engineers", but Software Engineers. Scala is just a useful tool.
- snidane 5y ago
  Same. It's a fairly accurate predictor of a company downturn after getting sunk in total complexity and ensuing certain employee churn. The only reason for Scala adoption was Spark 10 years ago. Scala/Spark engineers were pulling the top buck. With pyspark and other cloud big data options on the scene, no one sane is using scala for this anymore.
  - AzzieElbab 5y ago
    Spark wasnt even released 10 years ago :) I think Twitter, Linkedin, and some others gave Scala adaptation big push. Twitter in particular, when they killed their fail whale by moving to Scala/JVM
  - mohanmcgeek 5y ago
    > after getting sunk in total complexity Plus, the cost of teaching Scala to your new hires means they won't be productive for literally _months_ I agree that other big data tooling providers are eating into spark but I'm surprised people are choosing python over Scala for Spark.
- mohanmcgeek 5y ago
  It really should be. When you're trying to solve a business problem, Scala gets on the way. And when I say Scala, I mean libraries like akka http, spray-json and slick. I like FP parts of Scala overall. You would think that Scala 3 released in 2021 would have first class net/http and json that we can get rid of spray json. But no.
msilb 5y ago
> If I had to describe the style of Scala written at Databricks, I’d put it at 50% Java-ish, 30% Python-ish, 20% functional This is interesting as in taking a different approach to most other Scala shops I’ve experienced so far where die-hard monoid/functors fanatics take over and make the code base completely incomprehensible to outsiders / new hires. This seems to be a much more sensible approach.
- leetrout 5y ago
  This was exactly my experience at a scala shop. They didnt want to explain / help other devs.
- foolfoolz 5y ago
  die hard functional scala is the exception not the rule. this isn’t really constrained to scala, language zealots can exist in any language. the real problem is a lack of understanding what maintainable code is
  - grumpyprole 5y ago
    Yes, over-engineering is common in many languages, especially Java, where Spring and OOP patterns would be deployed everywhere. It is not a unique problem to Scala.
deleted 5y ago
[deleted]
eklavya 5y ago
There is development, then there is academic curiosity and code golfing. I have trouble understanding how people who say Scala is bad in the same breath praise the reflection like there is no tomorrow Java alternatives or Go’s ocean of text. There are pros and cons in every tech. Maintaining a large Scala code base is going to be much easier, less to write, less to maintain, easy to refactor. Don’t use a library if you have no need for it but don’t dismiss it as fanatical unless you have actually compared what the same functionality in your fav tech looks like. Choose the right tool for the job, don’t aim it at your foot. Get the job done and have a side project for “fun” coding. Scala is a damn good option for targeting JVM. Don’t blame the tool.
derN3rd 5y ago
It amazes me that such big projects use monorepos. My company also though about doing so, because we have a few typescript projects that share a common module with business logic and everything lags behind when the common module was upgraded, but I don't know if I should sell them to switch over to a mono repo as well. My biggest pro argument would be the speed up in development and review time, because everything is in the same PR/MR and not split into each project Are there any huge downsides?
- MrPowers 5y ago
  Navigating well designed, huge monorepo Scala codebases is surprisingly easy. Spark is a great example of a huge monolith that's relatively easy to work with considering the complexity of the app. If you follow the design principles outlined in this doc (https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofL...), Scala projects are really refactorable, which is nice. But I've also worked on lots of large Scala codebases that are completely incomprehensible and painful to change. Scala allows for devs to make beautiful monoliths, but that's not usually what happens.
  - derN3rd 5y ago
    We use TypeScript not Scala, but I've already found some other TS projects that use monorepos for the exact same reason I would do. Still searching for pros/cons with current toolings etc, as most articles about monorepos are 3-4y old and therefore outdated in some points
- halfmatthalfcat 5y ago
  SBT is actually amazing at maintaining a monorepo (or multi-project as they call it)
MrPowers 5y ago
Scala is a great language when Li Haoyi ecosystem of libraries is used. His libs do crazy Scala stuff under the hood, but expose a clean end user interface. The problem with Scala is that most ppl don't use his libs. Here's a blog post I wrote on reading / writing JSON using one of Li's libs: https://mungingdata.com/scala/read-write-json/ https://mungingdata.com/scala/read-write-json/ There's now a completely sensible option for JSON in Scala. But there are also 16 other Scala JSON lib options: https://stackoverflow.com/questions/8054018/what-json-library-to-use-in-scala https://stackoverflow.com/questions/8054018/what-json-librar... It's so annoying working on a Scala project with dependencies that all use different JSON libs. Even new, awesome projects like Delta Lake still use Scala dependencies like Scalatest and SBT that should be replaced with Li's libs in my opinion (utest & Mill). Scala could be an amazing ecosystem if the community unified around Li's libs. It just doesn't seem like that's going to happen. Li wrote the "whats wrong with SBT" article back in 2017 and it seems like everyone is still using SBT. I wrote an article on the maintenance challenges with Scala projects that trended on HN a while back: https://mungingdata.com/scala/maintenance-nightmare-upgrade/ https://mungingdata.com/scala/maintenance-nightmare-upgrade/. Li's libs would solve a lot of these issues cause most of them are intentionally dependency free. It was frustrating for me to see how Li basically singlehandedly fixed the Scala library ecosystem, but how none of the projects I actually used depended on his libs. I ended up leaving Scala after several years even though I like the language when it's used a certain way. Scala is such a powerful programming language that has so much potential to be mainstream, but it's just so abused by "genius programmers".
- sireat 5y ago
  I seriously love Li Haoyi Scala libraries especially the JSON one. The hilarious thing is/was that Scala tutorials/books would show writing JSON parser as one examples. Yeah Scala makes it easy to write a JSON parser but you still do not want to roll your own. Case in point Odersky's Programming in Scala.
  - MrPowers 5y ago
    Yea, there was a JSON parser in the Scala standard lib at one point and it was then deprecated & removed. Guess it's easy to make a "hello world" JSON lib, but maybe not the best addition to the standard lib, haha.
nikitaga 5y ago
I've seen a variety of Scala codebases from awesome to terrible (and a lot in between). Guess what, they all use the same Scala. Scala offers you many design choices that work well in skilled hands, but because it is so non-prescriptive, is is also very sensitive to individual talent and engineering culture. If you can't or don't want to maintain a team of strong developers, save yourself and use some other technology. But if you can, and you're working in a complex business domain, Scala can be hugely productive and result in very reliable software. Just my counterpoint to all the negativity that people invariably feel compelled to pour out in any thread about Scala. Tons of devs use Scala productively without deep dives into monadic code golf, you know.
- MrPowers 5y ago
  > Scala offers you many design choices that work well in skilled hands I agree that Scala works well in some skilled hands (see Li's libs), but the people that write the most terrible Scala programs actually know a lot about Scala. Scala has a unique way of encouraging genius programmers to write crazy code. People that know little Scala can just use it as a "better Python" language and actually write amazing Scala code. I agree that Scala codebases that follow the Principle of Least Power can be amazing: https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofL... Scala programmers generally frown on programmers that want to use it as a better Python and I think it should be the opposite.
  - nikitaga 5y ago
    > Scala has a unique way of encouraging genius programmers to write crazy code. Scala is a popular platform to explore FP concepts without fully understanding their caveats or having enough respect for the rest of the team's ability and willingness to follow, I'll give you that. But that's only because it's a great platform to explore FP concepts in general! You have to reign in the "geniuses", that's what engineering culture is for. I really don't like that label for people writing crazy code, btw. They shouldn't be on a pedestal just because they lack the empathy to write maintainable code. The pythonic-Scala approach is certainly gaining steam in the ecosystem. The problem is, it's hard to see because it's boring and doesn't require many special tools – Scala has much of that built-in. So the popularity of this approach is not apparent if you just look at open source activity. But internally companies who work with Scala use it in very benign ways for the most part, in my experience at least.
asimpletune 5y ago
One thing I didn’t see in the article was that Scala is really god for refactoring code. It gives you a lot of great tools, that allow you to do things which would be impossible in other languages. Dependency injection is really natural in Scala, which can help a lot with refactoring code, both when it was being originally written and when it’s in the process of refactored later. Also, advanced features like implicits, can actually save your butt in certain situations, even though people hate them because they don’t understand them. Also I agree with everyone that so many people write the worsttt Scala.
asimpletune 5y ago
I love Scala by the way and have written hugs code based on it. However the reason why Scala can encourage bad code from smart people is that it allows people to max out their budget for writing smart code. It’s like, let’s say it requires 2x more intelligence budget to read/debug than it is to write code. So if we all have more or less an intelligence budget of like 10, maybe some it’s 12 or others even 15-20, and you write crazy intelligent Scala, like at a 6, then you’ve already maxed out most peoples ability to read and debug the code, as we all more or less have a 10. Scala let’s you write code that maxes out these budgets if you’re not careful. Sometimes, very rarely, it’s necessary, but most of the time there is a simpler, dumber way to do the same thing that is actually much better. For most of my career in Scala, when I had conflict with other engineers, it was over this kind of stuff. They insisted on using cats or scalaZ or writing these crazy complicated, overly generic abstractions, and it’s like… I get what you’re doing and even I think it’s stupid and could just be done more directly and more attainably for other people.
- esarbe 5y ago
  > For most of my career in Scala, when I had conflict with other engineers, it was over this kind of stuff. They insisted on using cats or scalaZ or writing these crazy complicated, overly generic abstractions, and it’s like… While I kinda agree that you have to be careful with your abstractions, I see no harm getting familiar with some of the concepts that these libraries use. Being able to just implement a Monoid and then use it to do nested aggregation in maps is pretty neat, for example.
KptMarchewa 5y ago
>Zero usage of “archetypical” Scala frameworks: Play, Akka, Scalaz, Cats, ZIO, etc. This is the key to their success.
- Prunkton 5y ago
  could you elaborate please? I'm especially interested in the Play/Akka part. So what would the alternatives look like, using common Java Frameworks instead or none at all?
  - dudul 5y ago
    Depends on what you're trying to do. For example I think that Lightbend is no longer planning to maintain Play. I would probably go with Spring as a replacement. For Akka, do you really need it? You have to be building a pretty specific kind of system to need it over simpler constructs built into the language.
Phlogi 5y ago
What is their sync tool?
loopsdirectory 5y ago
ha, nice one!
sixminuteabs 5y ago
We develop the majority of our code in scala at my company (in fintech). There seems to be an experience in this thread that training in Scala is difficult. For anyone who is considering and wants another perspective - I have found that junior engineers tend to get up to speed more quickly in Scala than in other languages and that I can give them more freedom (because I know their programs won't compile if they don't line their types up and our use of the type system very immediately forces them to deal with the possibility that an operation can fail, e.g.). I can simply look at types and give them a nudge in the right direction (heyoo -fp either joke-). Yes they suffer a little in the beginning, but are usually shipping code within a few weeks then their trajectory really begins to rocket. It's very cool to watch them grow to building complex systems in a complex domain so quickly. As they grow the ease of refactoring means that it is easy to change their prior work as they gain more understanding, so for our management the penalty of allowing them to learn in the wild about something that's suboptimal is pretty low - they will come back and fix it. Of course what I'm saying above is really about FP and type systems and an implicit (heyoo -scala joke-) presence of thought about how our systems work top to bottom and how we train people. I think that is also required no matter what tools you use or what you're doing in any organization?
- CraigJPerry 5y ago
  >> I can give them more freedom (because I know their programs won't compile if they don't line their types up In what meaningful way can you give them more freedom? When i think about how i spend my time with junior folks, it tends to be on things like: 1. Do they understand enough of our problem domain that i can begin to describe a problem that needs to be solved? 2. Have they understood the problem i described? How confident am i that they're not going to implement a solution to the wrong problem? We don't spend time on "hey, you passed the parameters in the wrong order here". To put it another way based on my experience, what's more useful to a junior developer? Option A: Hey, here's a test case, here's how to run it. I need you to change the behaviour of this component to do X instead. Or Option B: Hey, here's a component with well designed types. I need you to change the behaviour of this component to do X instead. My experience has been that Option A - play with the component hands on, try things, run it, tweak the data supplied to it and observe the results - these encourage engagement. The developer will be excited even. And for Option B, they'll be quite dejected, not that invested in the project. I can't even compile the stupid thing because of some cryptic compile error.
perceptronas 5y ago
In my personal experience, Scala in 2021 is de facto best language for business logic. Effects are easy, parallel code is beautiful and easy to reason about. Ecosystem is big and no other languages comes close to productivity I have with Scala. For example, its very fast and easy to prototype code with ADTs and scale that code to big codebase. I rarely have to run my code and if I do - it most of the time works as intended because of the type system. Its like magic. In other languages if you want to write code without bugs you are stuck with TDD or a lot of tests. With Scala usually few tests are enough, everything else encoded in its expressive type system. I would say the only big negative I see is using Scala as Haskell. With tagless final, Kleisli and so on. If you do - it becomes very hard to onboard new people and I am not sure the positives outweigh the negatives.
- hocuspocus 5y ago
  > With tagless final, Kleisli and so on. Tagless final is a good way to enforce the principle of least power, which has many advantages when onboarding inexperienced developers. It can become unwieldy if abused, but that's true for any style. And if it really bothers you, then you can use your concrete "super monad" everywhere. It's the only way with ZIO, but you can also do that with other effects. Regarding Kleisli, it's such a broad abstraction that you'll find examples everywhere, whether explicit or not. In practice, even with heavy usage of libraries like fs2 or http4s, it's mostly an internal implementation detail, in most cases you'll only see type aliases.
iskander 5y ago
My experience with "Scala at scale" was extremely unsatisfactory and I found Databricks to give very unhelpful responses to basic performance problems arising from the intersection of Scala and Spark, bordering on gaslighting. Memory bloat is one of the most pernicious issues, you have to handle large data very carefully to not end up with massive memory footprints that outstrip any available hardware (and causes hard to debug cascading failures).
throwaway47292 5y ago
haha all this scala hate as if huge javascript or c or whatever at scale are the best the reality is, we are in this spaghetti together, so pick your noodle and move on its just computers, dont take it so seriously :)
esarbe 5y ago
Scala is an amazing language I love writing software in. The tools it offers to model business domains, the power of expressive types make it next-to-none when it comes to shape, remodel and refactor code. Then there's the ecosystem. Sure, you have the whole of the Java ecosystem, but then there are also tons and tons of Scala libraries that are so well designed (Quick shout-out to Lihaoyi here; your libraries are amazing!) and work together so well is astounding. I was very worried with the migration path to Scala 3 but that turned to be out pretty much painless. Scala-2.13-backward-compatiblity is amazing and together with scalafix the transition is as smooth as anyone could reasonably expect. Anyone getting into Scala or worried about complexity with Scala should have a good look at https://www.handsonscala.com/ https://www.handsonscala.com/
- justsaying9 5y ago
  Thanks for the advice. Given that you exposed your warped, racist ideological beliefs in other threads, this helps me to understand that Scala probably isn't something I want to involve myself with under any circumstances. Your judgment about good or bad at best cannot be trusted, and at worst is a contrary indication warning me to stay the hell away.

251 points by lihaoyi 5y ago

Scala was a terrible technology that was adopted by my organization five years ago and were still paying the price. How to deprecate this at scale? The extent to which i like scala is as a dsl for describing etl jobs with spark and i prefer the RDD api. Engineers are consistently crippled by it, we dont even use shapeless or scalaz. Spec2 is a terrible dsl that offers a shitty vocabular to write unit tests and makes the common path incredible difficult compared to junit.

eweise 5y ago
Well, you know, you can just use Junit with Scala. That's what I do.
mhzsh 5y ago
Spark is really its own world that’s fairly separate from the Scala community at large. What makes it a ”terrible technology”?
- waynesonfire 5y ago
  Scala moved the needle five years ago and made java better among other languages. Using scala helped me grow as an engineer. in my view, it has no place in an enterprise. I require a mature environment that favors consistency. It boils down to reducing complexity. I can barely handle the complexity growth due to the demands of the business, whether it be software engineering or people and these reasons do not justify scalas pluses. Ymmv.
  - kaba0 5y ago
    I think scala can absolutely account for that complexity, like it is not a one-way street. It can scale both up and down on expressivity. But I agree that often times it is not used that way.
- tharne 5y ago
  I wouldn't say spark is terrible, but it is a sort of a "reverse bicycle". If you put a spark codebase down for a week or two and pick it back up, it feels like you're learning everything all over again.
fnord77 5y ago
newer java has many similar features that scala had, so it seems moot to use it now. unless you like ridiculously long compilation times and having libs tied to what version of the compiler you're using (serious WTF)
- ebruchez 5y ago
  > it seems moot to use it now It's true that some features of Scala have made it to Java, but I am not sure the gap between the two languages has shrunk much. For example while Java has added first-class functions and closures, it is still clumsy to attempt any serious functional programming approach with Java; Scala's type system is still way ahead; Scala compile to the JVM, JavaScript, and now native via LLVM. > having libs tied to what version of the compiler you're using It's never been that. However libraries used to be tied to the major version of Scala (for example 2.11, 2.12, 2.13) as major versions were not binary-compatible with each other. Scala 3 addresses this thanks to the TASTY format which creates a strong foundation for binary compatibility. [1] You can use Scala 3 libraries with Scala 2.13 and, more importantly, Scala 2.13 libraries with Scala 3. In short, Scala is not standing still. [1] https://docs.scala-lang.org/scala3/guides/tasty-overview.html https://docs.scala-lang.org/scala3/guides/tasty-overview.htm...
lmm 5y ago
> Spec2 is a terrible dsl that offers a shitty vocabular to write unit tests and makes the common path incredible difficult compared to junit. Yes it is. Deprecate using it and migrate away from it. I hate that these shitty overengineered Cucumber wannabees are what "Scala" means to most people. It's a great language IMO, but you need to make sure fancy frameworks pay their weight. IMO Shapeless and Scalaz-or-equivalent do - replacing reflection or AOP with plain old compiled code, even complex code, is a huge win. But SBT and the mess of Scala testing libraries are just huge complexity for marginal benefit.
amir734jj 5y ago
In my previous company we used Scala + Spark and I hated it initially. I had no idea how syntax worked, no clue about functional programming or the ecosystem. I got interested in the Scala as a language and decided to pursue PhD in computer science focusing on compilers. Long story short, I am finishing my PhD on Monday :) Don't be negative about technology. Be positive.
- dikei 5y ago
  > In my previous company we used Scala + Spark and I hated it initially. I had no idea how syntax worked, no clue about functional programming or the ecosystem. It's funny that if you tell Cat-purist that Spark is functional-style, they would laugh at your face :)
  - caoilte 5y ago
    That's an unhelpful thing to say. Most people agree that the Spark scala DSL is functional style. It's not as advanced in the style as other scala ecosystems but it has been a very good on ramp for people discovering functional style and is widely celebrated for that
- burntoutfire 5y ago
  Scala + Spark is absolutely the sane face of Scala. Try using stuff like cats (basically Haskel ported to Scala) to experience the deep end of the pool.
  - esarbe 5y ago
    To discard Cats as 'basically Haskell ported to Scala' is doing it a bit of a disservice. Yes, it explores pure functional programming, but that design space is huge.
zalequin 5y ago
It saddens me to see that the HN crowd had been diluted to such an extent in terms of engineering quality that straight up luddism has become the norm, often accompanied with silly ad hominems.
- _vertigo 5y ago
  I don't agree with him, but that's a biiit smug..
random314 5y ago
As a counterpoint, I used scala at my previous job and it was the best coding experience and environment I ever experienced. Got rid of 1000s of lines of Java and SQL for 100s of lines of scala, scalding and Spark. The codebase size on the first migration was 10% of the original Java+SQL. overall, a team of 6 worked for 4 years to produce 10K lines of high quality Scala code for a very complex app and platform after the first transition from 10K lines of java+sql to 1K lines of scala. Never experienced something like this before or after. At the next place I wrote 400 lines of C++ mapreduce over 3 days, which could have been 40 lines of sql or 10 lines of scalding/spark. Jarring transition.
- chrisjc 5y ago
  Regarding the reduction in lines of SQL. Doesn't this imply a tradeoff with where compute is utilized? By reducing SQL, wouldn't you be "pushing up" the compute from the database to the JVM while also increasing the amount of data that has to be moved around? Edit: Wait, did you imply that the SQL you replaced with Scala ultimately gets transpiled into SQL (spark or other dataframe engine) and "pushed down" to the database? Now you're just maintaining Scala and not a rats nest of SQL strings concatenated together? If so, that's pretty awesome.
  - random314 5y ago
    Most of this was Hadoop. Which executes mapreduce jobs written in sql on the jvm. The scalding jobs executed faster, except for one job for which we had to stick with Apache pig. Spark jobs were native RDDs before the SQL Spark era.
  - random314 5y ago
    No. There was no transpiling to SQL. This was several years ago, before Spark SQL. The SQL was HiveQL. Spark didn't really support SQL at the time and was native JVM Scala RDDs. HiveQL with UDFs compiled to JVM bytecode typically ended up performing worse than scalding that corresponds to straight raw jvm map reduce jobs that are the real native interface of Hadoop. The real performance drag from HQL came from developers writing inefficient map reduce jobs with extra joins to avoid writing Java UDFs because they were a huge PITA. In scalding, developers wrote map reduce jobs with as few group bys as possible. Our hadoop infra team actually complimented us on how great the execution profile of our teams jobs were.

philipkglass 5y ago

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 accessing Python-ecosystem libraries.) [1] https://www.lihaoyi.com/ https://www.lihaoyi.com/ [2] https://www.handsonscala.com/ https://www.handsonscala.com/

tlarkworthy 5y ago
I considered it a near miss when a Scala shop rejected me because I used Maven to compile their coding challenge. Clearly the company was full of over-complicaters and actively recruiting for it.
- _vertigo 5y ago
  How did that conversation go? “We like your solution but did you seriously just use Maven?” What did they say exactly?
  - the_only_law 5y ago

wiradikusuma 5y ago

I completely agree with their pragmatic approach to Scala. Scala is a very powerful language, and you can do super crazy stuff. My approach to writing Scala code is similar: 1. Write the code like a better-Java/typesafe-Python (that is, imperative style). 2. Glance through the code. For collections, usually there's a more concise approach. 3. Read the code again. If you think what you did in #2 is making the code _too_ concise, you might need to think twice (or add comments).

dehrmann 5y ago
Regarding 1, wouldn't Kotlin be a better choice?
- dxxvi 5y ago
  I think no, because, IMO, Kotlin doesn't have a good pattern matching like Scala.
- lmm 5y ago
  I don't think so. Kotlin is an unmaintainable soup of features: it can match all the selling-point examples of Scala but only by adding ad-hoc special cases for each one. (For example, Kotlin has null safety and it lets you write code using errors-as-values style "either" types - but it has two completely separate syntaxes for these things, and so it's impossible to interoperate or reuse code between those two approaches). In practice Kotlin codebases still use magical incomprehensible reflection (Spring Boot) and magical compile-time manipulation (Kapt), so you have the worst of both Java and Scala worlds.
  - wiseowise 5y ago
    > Kotlin is an unmaintainable soup of features Are you sure you're not confusing Kotlin with Scala? > For example, Kotlin has null safety and it lets you write code using errors-as-values style "either" types - but it has two completely separate syntaxes for these things, and so it's impossible to interoperate or reuse code between those two approaches And that is a problem how? Stick to one style. > In practice Kotlin codebases still use magical incomprehensible reflection (Spring Boot) https://github.com/spring-projects-experimental/spring-fu/tree/main/kofu https://github.com/spring-projects-experimental/spring-fu/tr... > and magical compile-time manipulation (Kapt) There's nothing magical about it.

coffeecloud 5y ago

Scala is an organizational red flag for me, especially if their recruiters are looking for "scala engineers."

m01 5y ago
What did you think of the organisation described in this HN post?
- phgn 5y ago
  BTW, the described organisation does not hire "Scala Engineers", but Software Engineers. Scala is just a useful tool.
snidane 5y ago
Same. It's a fairly accurate predictor of a company downturn after getting sunk in total complexity and ensuing certain employee churn. The only reason for Scala adoption was Spark 10 years ago. Scala/Spark engineers were pulling the top buck. With pyspark and other cloud big data options on the scene, no one sane is using scala for this anymore.
- AzzieElbab 5y ago
  Spark wasnt even released 10 years ago :) I think Twitter, Linkedin, and some others gave Scala adaptation big push. Twitter in particular, when they killed their fail whale by moving to Scala/JVM
- mohanmcgeek 5y ago
  > after getting sunk in total complexity Plus, the cost of teaching Scala to your new hires means they won't be productive for literally _months_ I agree that other big data tooling providers are eating into spark but I'm surprised people are choosing python over Scala for Spark.
mohanmcgeek 5y ago
It really should be. When you're trying to solve a business problem, Scala gets on the way. And when I say Scala, I mean libraries like akka http, spray-json and slick. I like FP parts of Scala overall. You would think that Scala 3 released in 2021 would have first class net/http and json that we can get rid of spray json. But no.

msilb 5y ago

> If I had to describe the style of Scala written at Databricks, I’d put it at 50% Java-ish, 30% Python-ish, 20% functional This is interesting as in taking a different approach to most other Scala shops I’ve experienced so far where die-hard monoid/functors fanatics take over and make the code base completely incomprehensible to outsiders / new hires. This seems to be a much more sensible approach.

leetrout 5y ago
This was exactly my experience at a scala shop. They didnt want to explain / help other devs.
foolfoolz 5y ago
die hard functional scala is the exception not the rule. this isn’t really constrained to scala, language zealots can exist in any language. the real problem is a lack of understanding what maintainable code is
- grumpyprole 5y ago
  Yes, over-engineering is common in many languages, especially Java, where Spring and OOP patterns would be deployed everywhere. It is not a unique problem to Scala.

deleted 5y ago

[deleted]

eklavya 5y ago

There is development, then there is academic curiosity and code golfing. I have trouble understanding how people who say Scala is bad in the same breath praise the reflection like there is no tomorrow Java alternatives or Go’s ocean of text. There are pros and cons in every tech. Maintaining a large Scala code base is going to be much easier, less to write, less to maintain, easy to refactor. Don’t use a library if you have no need for it but don’t dismiss it as fanatical unless you have actually compared what the same functionality in your fav tech looks like. Choose the right tool for the job, don’t aim it at your foot. Get the job done and have a side project for “fun” coding. Scala is a damn good option for targeting JVM. Don’t blame the tool.

derN3rd 5y ago

It amazes me that such big projects use monorepos. My company also though about doing so, because we have a few typescript projects that share a common module with business logic and everything lags behind when the common module was upgraded, but I don't know if I should sell them to switch over to a mono repo as well. My biggest pro argument would be the speed up in development and review time, because everything is in the same PR/MR and not split into each project Are there any huge downsides?

MrPowers 5y ago
Navigating well designed, huge monorepo Scala codebases is surprisingly easy. Spark is a great example of a huge monolith that's relatively easy to work with considering the complexity of the app. If you follow the design principles outlined in this doc (https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofL...), Scala projects are really refactorable, which is nice. But I've also worked on lots of large Scala codebases that are completely incomprehensible and painful to change. Scala allows for devs to make beautiful monoliths, but that's not usually what happens.
- derN3rd 5y ago
  We use TypeScript not Scala, but I've already found some other TS projects that use monorepos for the exact same reason I would do. Still searching for pros/cons with current toolings etc, as most articles about monorepos are 3-4y old and therefore outdated in some points
halfmatthalfcat 5y ago
SBT is actually amazing at maintaining a monorepo (or multi-project as they call it)

MrPowers 5y ago

Scala is a great language when Li Haoyi ecosystem of libraries is used. His libs do crazy Scala stuff under the hood, but expose a clean end user interface. The problem with Scala is that most ppl don't use his libs. Here's a blog post I wrote on reading / writing JSON using one of Li's libs: https://mungingdata.com/scala/read-write-json/ https://mungingdata.com/scala/read-write-json/ There's now a completely sensible option for JSON in Scala. But there are also 16 other Scala JSON lib options: https://stackoverflow.com/questions/8054018/what-json-library-to-use-in-scala https://stackoverflow.com/questions/8054018/what-json-librar... It's so annoying working on a Scala project with dependencies that all use different JSON libs. Even new, awesome projects like Delta Lake still use Scala dependencies like Scalatest and SBT that should be replaced with Li's libs in my opinion (utest & Mill). Scala could be an amazing ecosystem if the community unified around Li's libs. It just doesn't seem like that's going to happen. Li wrote the "whats wrong with SBT" article back in 2017 and it seems like everyone is still using SBT. I wrote an article on the maintenance challenges with Scala projects that trended on HN a while back: https://mungingdata.com/scala/maintenance-nightmare-upgrade/ https://mungingdata.com/scala/maintenance-nightmare-upgrade/. Li's libs would solve a lot of these issues cause most of them are intentionally dependency free. It was frustrating for me to see how Li basically singlehandedly fixed the Scala library ecosystem, but how none of the projects I actually used depended on his libs. I ended up leaving Scala after several years even though I like the language when it's used a certain way. Scala is such a powerful programming language that has so much potential to be mainstream, but it's just so abused by "genius programmers".

sireat 5y ago
I seriously love Li Haoyi Scala libraries especially the JSON one. The hilarious thing is/was that Scala tutorials/books would show writing JSON parser as one examples. Yeah Scala makes it easy to write a JSON parser but you still do not want to roll your own. Case in point Odersky's Programming in Scala.
- MrPowers 5y ago
  Yea, there was a JSON parser in the Scala standard lib at one point and it was then deprecated & removed. Guess it's easy to make a "hello world" JSON lib, but maybe not the best addition to the standard lib, haha.

nikitaga 5y ago

I've seen a variety of Scala codebases from awesome to terrible (and a lot in between). Guess what, they all use the same Scala. Scala offers you many design choices that work well in skilled hands, but because it is so non-prescriptive, is is also very sensitive to individual talent and engineering culture. If you can't or don't want to maintain a team of strong developers, save yourself and use some other technology. But if you can, and you're working in a complex business domain, Scala can be hugely productive and result in very reliable software. Just my counterpoint to all the negativity that people invariably feel compelled to pour out in any thread about Scala. Tons of devs use Scala productively without deep dives into monadic code golf, you know.

MrPowers 5y ago
> Scala offers you many design choices that work well in skilled hands I agree that Scala works well in some skilled hands (see Li's libs), but the people that write the most terrible Scala programs actually know a lot about Scala. Scala has a unique way of encouraging genius programmers to write crazy code. People that know little Scala can just use it as a "better Python" language and actually write amazing Scala code. I agree that Scala codebases that follow the Principle of Least Power can be amazing: https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofL... Scala programmers generally frown on programmers that want to use it as a better Python and I think it should be the opposite.
- nikitaga 5y ago
  > Scala has a unique way of encouraging genius programmers to write crazy code. Scala is a popular platform to explore FP concepts without fully understanding their caveats or having enough respect for the rest of the team's ability and willingness to follow, I'll give you that. But that's only because it's a great platform to explore FP concepts in general! You have to reign in the "geniuses", that's what engineering culture is for. I really don't like that label for people writing crazy code, btw. They shouldn't be on a pedestal just because they lack the empathy to write maintainable code. The pythonic-Scala approach is certainly gaining steam in the ecosystem. The problem is, it's hard to see because it's boring and doesn't require many special tools – Scala has much of that built-in. So the popularity of this approach is not apparent if you just look at open source activity. But internally companies who work with Scala use it in very benign ways for the most part, in my experience at least.

asimpletune 5y ago

One thing I didn’t see in the article was that Scala is really god for refactoring code. It gives you a lot of great tools, that allow you to do things which would be impossible in other languages. Dependency injection is really natural in Scala, which can help a lot with refactoring code, both when it was being originally written and when it’s in the process of refactored later. Also, advanced features like implicits, can actually save your butt in certain situations, even though people hate them because they don’t understand them. Also I agree with everyone that so many people write the worsttt Scala.

asimpletune 5y ago

I love Scala by the way and have written hugs code based on it. However the reason why Scala can encourage bad code from smart people is that it allows people to max out their budget for writing smart code. It’s like, let’s say it requires 2x more intelligence budget to read/debug than it is to write code. So if we all have more or less an intelligence budget of like 10, maybe some it’s 12 or others even 15-20, and you write crazy intelligent Scala, like at a 6, then you’ve already maxed out most peoples ability to read and debug the code, as we all more or less have a 10. Scala let’s you write code that maxes out these budgets if you’re not careful. Sometimes, very rarely, it’s necessary, but most of the time there is a simpler, dumber way to do the same thing that is actually much better. For most of my career in Scala, when I had conflict with other engineers, it was over this kind of stuff. They insisted on using cats or scalaZ or writing these crazy complicated, overly generic abstractions, and it’s like… I get what you’re doing and even I think it’s stupid and could just be done more directly and more attainably for other people.

esarbe 5y ago
> For most of my career in Scala, when I had conflict with other engineers, it was over this kind of stuff. They insisted on using cats or scalaZ or writing these crazy complicated, overly generic abstractions, and it’s like… While I kinda agree that you have to be careful with your abstractions, I see no harm getting familiar with some of the concepts that these libraries use. Being able to just implement a Monoid and then use it to do nested aggregation in maps is pretty neat, for example.

KptMarchewa 5y ago

>Zero usage of “archetypical” Scala frameworks: Play, Akka, Scalaz, Cats, ZIO, etc. This is the key to their success.

Prunkton 5y ago
could you elaborate please? I'm especially interested in the Play/Akka part. So what would the alternatives look like, using common Java Frameworks instead or none at all?
- dudul 5y ago
  Depends on what you're trying to do. For example I think that Lightbend is no longer planning to maintain Play. I would probably go with Spring as a replacement. For Akka, do you really need it? You have to be building a pretty specific kind of system to need it over simpler constructs built into the language.

Phlogi 5y ago

What is their sync tool?

loopsdirectory 5y ago

ha, nice one!

sixminuteabs 5y ago

We develop the majority of our code in scala at my company (in fintech). There seems to be an experience in this thread that training in Scala is difficult. For anyone who is considering and wants another perspective - I have found that junior engineers tend to get up to speed more quickly in Scala than in other languages and that I can give them more freedom (because I know their programs won't compile if they don't line their types up and our use of the type system very immediately forces them to deal with the possibility that an operation can fail, e.g.). I can simply look at types and give them a nudge in the right direction (heyoo -fp either joke-). Yes they suffer a little in the beginning, but are usually shipping code within a few weeks then their trajectory really begins to rocket. It's very cool to watch them grow to building complex systems in a complex domain so quickly. As they grow the ease of refactoring means that it is easy to change their prior work as they gain more understanding, so for our management the penalty of allowing them to learn in the wild about something that's suboptimal is pretty low - they will come back and fix it. Of course what I'm saying above is really about FP and type systems and an implicit (heyoo -scala joke-) presence of thought about how our systems work top to bottom and how we train people. I think that is also required no matter what tools you use or what you're doing in any organization?

CraigJPerry 5y ago
>> I can give them more freedom (because I know their programs won't compile if they don't line their types up In what meaningful way can you give them more freedom? When i think about how i spend my time with junior folks, it tends to be on things like: 1. Do they understand enough of our problem domain that i can begin to describe a problem that needs to be solved? 2. Have they understood the problem i described? How confident am i that they're not going to implement a solution to the wrong problem? We don't spend time on "hey, you passed the parameters in the wrong order here". To put it another way based on my experience, what's more useful to a junior developer? Option A: Hey, here's a test case, here's how to run it. I need you to change the behaviour of this component to do X instead. Or Option B: Hey, here's a component with well designed types. I need you to change the behaviour of this component to do X instead. My experience has been that Option A - play with the component hands on, try things, run it, tweak the data supplied to it and observe the results - these encourage engagement. The developer will be excited even. And for Option B, they'll be quite dejected, not that invested in the project. I can't even compile the stupid thing because of some cryptic compile error.

perceptronas 5y ago

In my personal experience, Scala in 2021 is de facto best language for business logic. Effects are easy, parallel code is beautiful and easy to reason about. Ecosystem is big and no other languages comes close to productivity I have with Scala. For example, its very fast and easy to prototype code with ADTs and scale that code to big codebase. I rarely have to run my code and if I do - it most of the time works as intended because of the type system. Its like magic. In other languages if you want to write code without bugs you are stuck with TDD or a lot of tests. With Scala usually few tests are enough, everything else encoded in its expressive type system. I would say the only big negative I see is using Scala as Haskell. With tagless final, Kleisli and so on. If you do - it becomes very hard to onboard new people and I am not sure the positives outweigh the negatives.

hocuspocus 5y ago
> With tagless final, Kleisli and so on. Tagless final is a good way to enforce the principle of least power, which has many advantages when onboarding inexperienced developers. It can become unwieldy if abused, but that's true for any style. And if it really bothers you, then you can use your concrete "super monad" everywhere. It's the only way with ZIO, but you can also do that with other effects. Regarding Kleisli, it's such a broad abstraction that you'll find examples everywhere, whether explicit or not. In practice, even with heavy usage of libraries like fs2 or http4s, it's mostly an internal implementation detail, in most cases you'll only see type aliases.

iskander 5y ago

My experience with "Scala at scale" was extremely unsatisfactory and I found Databricks to give very unhelpful responses to basic performance problems arising from the intersection of Scala and Spark, bordering on gaslighting. Memory bloat is one of the most pernicious issues, you have to handle large data very carefully to not end up with massive memory footprints that outstrip any available hardware (and causes hard to debug cascading failures).

throwaway47292 5y ago

haha all this scala hate as if huge javascript or c or whatever at scale are the best the reality is, we are in this spaghetti together, so pick your noodle and move on its just computers, dont take it so seriously :)

esarbe 5y ago

Scala is an amazing language I love writing software in. The tools it offers to model business domains, the power of expressive types make it next-to-none when it comes to shape, remodel and refactor code. Then there's the ecosystem. Sure, you have the whole of the Java ecosystem, but then there are also tons and tons of Scala libraries that are so well designed (Quick shout-out to Lihaoyi here; your libraries are amazing!) and work together so well is astounding. I was very worried with the migration path to Scala 3 but that turned to be out pretty much painless. Scala-2.13-backward-compatiblity is amazing and together with scalafix the transition is as smooth as anyone could reasonably expect. Anyone getting into Scala or worried about complexity with Scala should have a good look at https://www.handsonscala.com/ https://www.handsonscala.com/

justsaying9 5y ago
Thanks for the advice. Given that you exposed your warped, racist ideological beliefs in other threads, this helps me to understand that Scala probably isn't something I want to involve myself with under any circumstances. Your judgment about good or bad at best cannot be trusted, and at worst is a contrary indication warning me to stay the hell away.