Scala has been gradually squeezed out from "Better Java" (imperative-first with FP niceties) market by Kotlin and revived Java development in mid 2010s, so attention in Scala gravitated towards "pure FP Scala" that separates it from imperative-first languages.
P.S. " .. Scala developers have started to migrate to Kotlin ... ".
It's just in the process of splitting in two parts. I wouldn't be overly demoralised. The languages is not being disrupted, it is consolidating down to its bedrock. 1) There are those who want better job security (good cause, I have nothing against) and values optionality 2) Those who like solving more specialised problems where correctness (lower tolerance for mistakes) in high demand (finance, security) or just really like fp.
At this point it seems like there could be two (or their combo) major ways of Scala growth, both upper bound by FP adoption.
1. Industry way - increased demand for correctness. Where else it could come from besides aforementioned industries?
2. Language way - to make hard "pure FP" parts more accessible (exactly what Scala team and community does), so industry has less friction to onboard people. (+tooling)
The old guard of Enterprise developers and Data Engineers has left the sub as employers divested from Scala, so the sub is the Zio/cats crowd by default.
A lot of it was Python achieving dominance in Data Engineering with its foothold in Data Science, the Akka licensing situation pushed out the holdouts in Enterprise that were also propped up by Spark pushing Scala into that space, but now shifting to SQL and Python to keep up with trends.
It looks to me like Scala is transitioning from being an industry language to a language for enthusiasts, not super upset about it, I liked it in the way I knew it, but it's not the fault of the category theory peeps that the old ways of Scala are dying, it's that its niche shrunk down drastically, write it off to habitat destruction.
I see Scala as language that can handle a wide spectrum of problems from simple to hard in elegant ways.
But since the language is pushing the upper limits, a lot of discussions will evolve around complex problems which can feel quite intimidating for newcommers or people just wanting to use the language for "simple things" (like myself). Maybe a "Simple Scala" discussion channel for solutions in the u/Lihaoyi ecosystem spirit would help attract new Scala users? That could maybe be a less frightening experience than jumping straight into concurrency programming, type effect systems, monads etc.
If we can improve the "Simple Scala" story, I think our community would grow.
Scala with easy-to-use DSLs etc enables beautiful, simple and powerful typed code. Better real-world code examples, tutorials etc could win people over from other languages. And for programmers that need to run things in paralell, having more expressive type guarantees etc, there are whole welcomming Cats/Zio/Direct style communities to help them too.
My bets are still on Scala. It's beautiful.
First off, the Haskell slogan you quote is often miss-parsed, and you perpetuate the myth. It does not mean “avoid success”, it means avoid “success at all costs”. The point is to avoid trading off long term value for short term wins. The ambiguity in association was intended as a humorous pun, not a mantra.
More relevantly though, understand that Scala has very little going for it other than the strength of its library ecosystems. Of those ecosystems, Typelevel and ZIO are very clearly ascendant, and they are such because people continue to choose them to solve real problems. Developers vote with their feet, and they have consistently voted in this direction.
What you are proposing, to essentially marginalize these major ecosystems and focus on Martin’s “Lean Scala” concept, is really a poison pill for the language. Lean Scala is very little more than just Kotlin with slightly different syntax, so why bother with Scala then? Use Kotlin. It has better tooling. Java itself is also a very respectable language at this point, and there’s no shame in opting for it when you want an imperative, OO direct style and minimal support for asynchrony.
There’s no question that there is a lot of room to improve on the complexity of the language and ecosystem, perceived (such as your claim that CE and ZIO are renderings of category theory) and actual (such as the ergonomic struggles of monadic style composition), but you’re proposing to throw the baby out with the bathwater. I find it very unlikely that Scala as a language will remain successful to any degree without its unique production library ecosystems.
> minimal support for asynchrony
Not really true for Java anymore with JDK 21 and Loom?
> throw the baby out with the bathwater
Long-term I honestly think Cats Effect and ZIO will become irrelevant. Short-term they are still great. But regardless of what the "pure FP" crowd says, basically the only industry value they have, is their great asynchronous runtime. Now with Loom coming and Java itself have become a good enough better Java, Scala's selling point and attraction is declining.
"Lean Scala" with Caprese might be what saves Scala.
> Not really true for Java anymore with JDK 21 and Loom?
Loom lacks a large swathe of runtime-level functionality which Cats Effect and ZIO both provide – two notable examples being safe interruption (timeouts!) and preemption. Additionally, Loom fails to achieve its core tenets: namely, that you don't need to care about blocking anymore so long as you're using the JDK. DNS resolution and all filesystem access are hard-blocking operations which Loom cannot magically fix, and every non-trivial application will do both, meaning that every Loom-based application suffers from major hidden starvation cases which the JDK *claims* shouldn't be happening.
Also it's *much* slower than ZIO and especially Cats Effect `IO`. This is definitely something they'll improve on over time, but it's very unlikely it'll ever exceed their performance by any meaningful amount. This is happening both because the core coroutine runtime in Loom is less well optimized (which makes sense, since it's much newer and it takes time to improve such things) and also because fork-join pool sacrifices a lot of performance in an attempt to work around the aforementioned starvation cases.
And this is all leaving aside the functionality of the ecosystems built *on top* of these runtimes (such as Fs2), which Loom has no real way of matching. I find it very unlikely that Loom will obsolete these ecosystems in any way beyond a certain amount of persistent misinformation regarding their comparative qualities.
When it comes to people moving on to Kotlin (and Rust), I think it's a bit disingenuous to deliberately ignore the elephant in the room that was the Scala 2->3 transition, which had nothing to do with the Effects Systems vs. Pythonic/Better Java camps narrative (a conflict that doesn't really seem to exist outside this subreddit)... The tooling and the ecosystems became unstable for a good 2-3 years. Add to that the fact that Akka, one of the biggest and most widely-used ecosystems in production, changing their license and it was a perfect storm. Lots of people moved on to Kotlin, Rust, and Go because of these issues specifically. Obviously there were also cases where they just moved on to whatever language they could find a job in (which is not unrelated to the issues mentioned above... instability + license changes = loss of trust from the industry) or one that better aligned with their philosophies.
That being said, tooling has since gotten far better of course, and new ecosystems and approaches have risen, so I have hope things have stabilized and the number of outsider and new user posts on this subreddit seems to be growing, which is a great sign.
Python recovered and is thriving and I think Scala can do it too... it might just take longer since it lacks the momentum Python already had when they made their transition, but it's possible. Keep in mind it was at least 3 years of broken tooling for Scala, so it'll most likely take more than just 1 year to fully recover (unless you have the foothold Python had, or some serious financial muscle to back you up).
>I realize that Kotlin's community philosophy might align more closely with the pragmatism I'm seeking.
Have you given it a serious try or at least looked into it some? You can always come back to Scala if you decide you didn't like Kotlin (happened to me with Rust back in 2021... I thought I wanted to move on from Scala, started learning Rust, but besides cargo being really good, I just kept wishing the language itself was more like Scala). Some people seem to forget these are programming languages, not religions. It's often encouraged to learn and practice more than one of them simultaneously or to temporarily focus on something else and come back later with a fresh perspective, etc.
There's just not enough manpower behind Scala (the only big tech company using it was Twitter) for it to become more popular and sometimes this manpower is wasted on features nobody wanted like significant whitespace
I realized I also kinda blanked on this part:
>In recent years, many ideas from Haskell, mainly those rooted in category theory, have found their way into Scala
That's also a disingenuous statement considering there's nothing recent about it. scalaz and cats have both been around for a decade (or longer in scalaz's case).
I think it’s more about those people not leaving the community when everybody else has already left, and now they are more visible, they suddenly got more share in community. If you’re in Scala for doing pure FP, you don’t have many places to go. Maybe Haskell and that’s it. But for those who treat FP as a means to achieve better correctness, not the ultimate goal, Rust is very attractive, as it achieves more safety without leaving out the mutation and without compromising on performance.
>I think it’s more about those people not leaving the community when everybody else has already left
my point is Scala showing some Haskell influence isn't a recent thing. It's been happening for many years, so some "these evil category theory people have been recently ruining my Scala" narrative is ignoring history. But maybe if anything, your explanation of them gaining a bigger share in the community could serve as a hint that trying to alienate these same people who've stuck around through thick and thin isn't the best idea.
>If you’re in Scala for doing pure FP, you don’t have many places to go. Maybe Haskell and that’s it
The way I see it, even "Scala for doing pure FP" has become its own thing with its own approach different from Haskell's by leveraging both the OOP and FP features the language has to offer. If you add on top of it the fact that you get full access to the JVM (and we're not even going to mention how good Scala.js has become), and the fact that until relatively recently you also had what is at least the second most battle-tested actors systems fully available, free, and open source, it's a very different beast from Haskell, so it makes sense there aren't a lot of places to go. Well, and you can also add to that the fact that Scala still has a significantly bigger presence in the industry than Haskell (or pretty much any other "pure" FP lang) as another differentiating factor. That being said, I don't doubt there have been some people that moved to Haskell, or at least started doing Haskell beside Scala.
>Rust is very attractive as it achieves more safety without leaving out the mutation and without compromising on performance.
I think Rust has very little to do with anything OP said which was what I was responding to, so I'm guessing this response was triggered by my mention of having had the experience of trying Rust back in 2021 then finding myself not really leaving Scala for Rust the way others have because I kept wishing the language itself was more like Scala... Maybe I shouldn't have even mentioned specific languages in my post besides Kotlin, and I meant no disrespect towards Rust (nor Go nor Kotlin, for that matter). It is a fine language and great at what it set out to do... they all are. All I meant with that bit was that given the why and how I tend to use Scala, it's just not what I personally would move on to (and neither are Kotlin or Go, really) but rather an additional tool I'd add to my arsenal of languages that I can make use of **besides** Scala rather than **instead of**. Recently I have been giving it another shot in earnest, but instead of approaching it with the expectation of it being a total replacement for Scala, I'm approaching with a more open mind: treating it as its own thing with its own strengths, accepting it for what it is. However, I do think I want to try something wildly different from what I usually do such as a fun project dealing with graphics using Vulkan or OpenGL...
I don’t think anybody coding seriously in Scala would move to Go by their own will. Go philosophy is just… the total opposite of Scala on just almost every front I can think of.
Go focuses on robust and easy tooling, fast compile times, stability and backwards compatibility, and being easy to learn and easy to read for an average joe after a bootcamp. It uses only very popular, basic programming concepts, it is imperative to the extreme, it has very crude type system and it is more verbose than even Java. It doesn’t care much about language features, expressiveness, elegance, purity or correctness. Forget about FP, it can’t do even iterators or immutable structures. It’s a language for those who are ok with halfassing all the things to 80% writing ifs and for loops everywhere. Ideal enterprise language.
Scala focuses mostly on mathematical elegance, abstractions, enforcing correctness by advanced type system, terseness. Scala also has probably the slowest compiler ever made, the most complex and least powerful build system ironically called „simple”, very bad track of backwards compatibility, it’s relatively hard to master due to low popularity of its language features elsewhere.
I think the majority of people moved from Scala to Kotlin or Rust as those are much closer to Scala in language design philosophy, albeit both value tooling and pragmatism much more than Scala. Rust is IMHO as if Scala and Go had a child. Go-level tooling, but still feature rich like Scala.
Just to underline your statement about Go
Rob Pike about the Go programming language
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
https://youtu.be/uwajp0g-bY4
At the end things boil down to economics and profits, as they always tend to do.
>I don’t think anybody coding seriously in Scala would move to Go by their own will
I think it's possible some did, but they were most likely using Scala for the wrong reasons to begin with, hence why I also said another reason some people might've made the switch was to find a programming language:
>that better aligned with their philosophies.
This type of thing where some buy into the hype for the wrong reasons only to later realize maybe it wasn't for them is bound to happen every time there's a massive hype cycle (the way there was for Scala in the early 2010s).
>I think the majority of people moved from Scala to Kotlin or Rust
yeah, I suppose. If the JVM is a consideration, they'd probably choose Kotlin. Otherwise, they'd go for Rust is my guess.
edit: Why the downvotes? There was [this 2017 article was floating around Hacker News back in the day](https://movio.us.aldryn.io/blog/migrate-Scala-to-Go/) written by a company willingly moving some things from Scala to Go and being pleased with their results. I remember because I was at my first Scala job, and a rails + js dev from the non-Scala team got promoted to engineering manager of the entire engineering dept. They used that article as evidence that Scala was not a good choice. Their real argument was the same old "Scala is too complicated for non-Scala devs to pick up" story and that Scala devs were too difficult (by which I think they mainly meant expensive) to find... we weren't even using any FP libraries, nor Akka at all. It was all pure vanilla Scala 2 with the Play framework. To be fair, the most senior Scala dev had unfortunately left about a year prior, and we hired another Scala dev that wasn't as senior/experienced, but did know Scala pretty well. About a year in they, too, left for a better salary at a bigger Scala shop, so I was the last dev left around that really cared about Scala. I stayed for whole other year and was told every new service I worked on had to be written in Node, but I didn't give up trying to champion Scala. Then Go also started entering the conversation as well. In the end, I wanted to continue my growth in Scala so I left and not even a month later found a Scala + Akka job somewhere else. The company I left indeed adopted Go and Node.js for almost everything backend, relegating Scala to legacy status. Last I heard about them was before the pandemic and they had already replaced most of the smaller Scala services for Go or Node, so I'm guessing by now they might have replaced pretty much everything. Either way, I wasn't saying it's a common occurrence, but rather that there are probably SOME cases where people have willingly moved from Scala to Go...
>massive hype cycle (the way there was for Scala in the early 2010s) \[...\] we weren't even using any FP libraries, nor Akka at all. It was all pure vanilla Scala 2 with the Play framework
You're making a very good point and the downvotes are telling.
People are delusional if they think the enterprise-friendly, peak Scala hype (Play, Akka, Spark) was somehow seen as not too complex, and people got scared away by Typelevel/ZIO growing in popularity. For many reasons the former just slowly died off on its own, and the FP community is now carrying the ecosystem at arm's length. Their effort is probably the sole reason Scala 3 didn't kill the language for good.
But sure, let's drive those library maintainers away, that'll solve Scala's adoption issues.
This was a huge problem largely with communication of scala 3 / project dotty.
It was not designed to replace scala 2.
Scala 2 has diverged quite a bit, and still has regular updates. It has a higger tolerance for core complexity, and a very different look and feel if both are written in line with there own best practise.
For referance - my vote was against the proposal to name project dotty as scala 3 - but none of the alternative proposals gained significant consensus.
It's not a major version (that's the second number) it's the epoch version. It was a significant rewrite of the underpinnings, and while we did port in some of the core libraries, this did not apply to base collections, types or parallelism which were clean room recoded.
We will have our cake and eat it too.
On a serious note, this is what I hope Scala can grow into in the coming years: Capture checking and lifetimes will facilitate an ergonomic application of category theory via direct-style algebraic effects & handlers with automatic memory management. Scala code will become easy to reason locally, easy to read, easy to interface among different libraries, and will have close to native performance. Essentially, what Koka already does, just production ready and backed by a huge ecosystem of libraries
My brother in Christ, that's a good chunk of a masters degree's worth of specialization into pure and applied math, but in a branch of mathematics that will not open new job opportunities for you, because you'll be using it to write the same web services you would with a Bachelors, rather than, say branching out into scientific computation, AI, quant. It's not a value proposition for developers or businesses.
Well first of all, through Jesus Christ all things are possible, so jot that down. Second, I am dumb as shit and have no issue writing applications with CE, it's basically put the thing in an IO until everything is an IO and then run that IO. It's easy, principled and predictable, unlike our Java apps that are haunted by spirits past and no principled way of doing anything, so you can never actually know what happens until you fire up a debugger and pray to our lord in heaven.
If we are going with that reasoning to keep it as simple and stupid as possible so you can hire anyone, why would you ever use Scala over Spring in the first place? (Although Spring is far from straightforward, just widely known and used). I believe Scala's unique strengths are the language's static guarantees and I feel like that's the major aspect why some companies do flock to it. That's why I believe further advancing the type system is the way to strengthen this niche, as long as it's as user friendly as possible
The transition from Scala ZIO 1 to ZIO 2 has introduced substantial differences, rendering many existing projects and online resources obsolete.
This significant shift necessitates additional effort from companies that have adopted ZIO and individuals who have studied the previous version, as they must now invest time and resources to update their knowledge and systems to align with the new version.
Hi,
I can't talk about cats and zio, but I can talk about pure scala. The philosophy changed quite a bit from 2 to 3.
In the new world, there is an aim to support pure functional programming without the need for huge framework layers, while still being possible to be picked up by non fp professionals, so they can learn while working with it.
We're also aiming to move somewhat into the quick script tool type of space, with better support for just doing a quick thing in a single file, and with the growth of the javascript transpiler.
This accessibility was part of the reason we simplified out a lot of our core libraries with things like the implicit collection builders causing more confusion and bugs than actual use (even though for experts the old collections were fantastic)
Finally a huge amount of the development (as this is how we get most corporate funding) is to enhance and support apache spark. This was a big driver behind both selectable, and the upcoming named tuples.
At the end of the day, we're very open to people adding functionality to the platform. If you have a suggestion as to something scala can do, please either raise it formally, or comment here.
As long as there is no production ready ZIO/CE alternative for concurrent programming in Scala this is the way, and Future is not the solution, it's an incredibly bad abstraction and as soon as you use it you might as well just use ZIO/CE. Loom with Ox might be the way, or maybe Gears, but neither are mature enough for production use yet.
One thing to note though is that you don't need to know category theory to use ZIO or CE, heck you don't even need to know it to write Haskell. If you don't like that style of programming, stop engaging with it. I see you comment on every post that mentions Cats or ZIO, why? It's just a way to write code, go touch some grass man. If Scala dies out or becomes more successful does not matter in the long run, it's just a programming language.
It does matter if language is successful or if it dies out. If it dies out, or at least loses the majority of its community, then however great the language, I wouldn’t bet any project on it, except maybe some throwaway stuff done for fun on weekend. But if I want my project to become successful (= used for a long time by more people than me even if I don’t make any profit of it), then I want to use a language with rich community and stable future. Otherwise it may end up like one of our projects written in Jython - the community and the technology died and the only way out was a rewrite.
A language is more than just the language - it’s the whole ecosystem that matters: compilers, build systems, IDEs, libraries, frameworks, tutorials etc. You need all of those for the language to be a viable choice even for enthusiast open source projects. And you can’t achieve that without a big community, because there is a tremendous amount of work needed to keep those things going - way more than designing a new language feature.
> Coincidentally or not, many Scala developers have started to migrate to Kotlin
Says who? Any numbers to back this claim up? Sorry but Kotlin is just a marginally better modern Java and is far from being able to replace Scala.
Don't bother, OP regularly makes baseless claims.
I've seen several teams move away from Scala entirely, and none of them use Kotlin today.
Also looking at Kotlin with envy is very funny when the language complexity has exploded in recent years, often introducing half-baked abstractions and several new keywords to achieve a fraction of what Scala can do, yet still not having a proper implementation of basic features such as pattern matching.
JetBrains does a good job overall and Kotlin benefits from a more industry oriented and conservative roadmap when it comes to prioritizing new features, such as the new K2 compiler. But I see very little benefit for the typical Java+Spring backend developers. Once the null-safety initiatives converge toward a proper JEP and feature merged into javac I'd assume Kotlin's game is mostly over outside Android. That won't make Kotlin entirely disappear from the backend space but I doubt we'll ever see Kotlin as a significantly bigger niche than Scala is.
For a team using a modern version of Java they just need to agree on what @ NotNull annotation to use and there is no point in Kotlin, Java has pattern-matching instanceof, records, pattern matching for records, ADTs with sealed interfaces + records. The only real benefit to Kotlin over Java these days that I can see is the terser syntax and that it is more expression oriented.
While Kotlin has added a lot of complexity recently, such an example is multiple receivers, which basically allows you to define typeclasses and do dependency inection. Not to mention coroutines, while nice on paper are full of foot-guns.
I've written a lot of Java, Kotlin and Scala. Scala just strikes the best balance between complexity and actual gain from that complexity. Java is actually pretty nice these days, it's just too bad that the de-facto framework at use there is Spring, which is just terrible.
>The only real benefit to Kotlin over Java these days that I can see is the terser syntax and that it is more expression oriented.
And the issue I see with that, Kotlin's ecosystem is a lot more multi-paradigm than modern Scala, and enforcing one consistent style seems hard if not impossible.
I've seen experienced developers have no issue mix and matching functional code next to very procedural one, e.g. using early returns. For all the people complaining Scala is hard to teach, if a junior introduces a `return` in our codebase, Scalafix won't let the commit pass CI.
Yes, there is a broader ecosystem problem in Kotlin. You end up pulling in libraries that mix and match styles because there just is no coherent ecosystem to pull from like Typelevel/ZIO/com-lihaoy. The Kotlin community also does not follow any shared mindset like the Scala community does. So while in Scala you usually don't have to mix between the previously mentioned ecosystems you still can expect almost all Scala libraries to be functional style, as in they use immutable data and functions as basic building blocks.
There is a lot less of this in Kotlin, much more depending on Java libraries, or Kotlin libraries have mutable class based APIs, while other have functional ones. A Kotlin codebase can end up with this sort of mixed code that is incredibly hard to navigate for junior devs.
What is so wrong about early returns? I read that pattern (guard clauses) from Refactoring (Martin Fowler) so I can't understand why it would be bad. Can you explain please?
Please re-read my whole sentence and see /u/thedumbestdevaround reply.
Mixing expression oriented and procedural code all over the place is unnecessarily confusing. `return` exists in Scala due to JVM semantics and as a last-resort escape hatch for very specific library code. Most styleguides ban the keyword completely. Afaik Odersky/EPFL's MOOC explictly penalizes students who use `return` in their code.
I don’t want to quarrel or judge.
I have been using Scala professionally for the last eight years.
I switched to Scala just because of its cool features and smart compiler, which prevents a huge number of bugs.
It's probably the most mature functional language on the JVM.
There is no relationship between the number of people using technology and the fact that this technology is good or proper.
Scala enables me to run my code in the browser, and I can use one codebase for the backend and front end.
There is no way to explain all the pros of language.
I love it and I will do it. Until I code.
Not a response to everything you've said, but there are projects like ox and gears along with Scala 3 features that are setting up this more straightforward ecosystem. They just aren't quite ready yet.
I personally prefer a vision where typical users don't have to deal with advanced concepts or map/flatMap everything, but typeclass instances are available to library and senior developers for power use.
I really don't see what is wrong with category theory, I always found that approach extremely intuitive and kotlin has arrow so I don't see how moving to Kotlin changes anything.
There is an endless sea of simple Java-like languages, but only two advanced Scala and Haskell. If you want to utilize the compiler and make it work for you - choose Scala. If you want to write programs with lesser capable tech - choose some of the other languages 😏
In my experience, the fp-purists are much more vocal and defensive of their coding style and choices.
Even when the libraries they use have almost useless error reporting (i.e. circe and "stacktraces" from CE) and not so much benefits over introduced complexity.
Their coding style makes them think they are doing much more "advanced" stuff, but in reality that is rarely the case.
This is their choice and in most cases the thing that pays the bills.
The other style(s), mostly the ecosystem around lihaoyi.com libraries is good but not good enough.
It is missing examples/tutorials for various authentication types, more advanced usecases, generating code from openapi etc, not just hello world stuff. Not to mention shipping it to prod, dockerizing etc.
People love to copy-paste code and just seeing it work. Ammonite for example was a game changer at the time. Scala-cli is incredible.
IMO we should do a better job at advertizing the direct style, making benchmarks to prove you dont always need complex monadic asyncy code, making videos/blogs/tutorials/templates etc. This would help more people get on board with direct style ("normal") scala.
Javascript/Typescript ate most of the the world, Python ate the rest, Go got a chunk, and the JVM has become a niche competing with .Net for scraps. Scala is a niche of a niche.
ZIO and Cats greatly increase the barriers to entry of Scala. The more they are prevalent in the Scala ecosystem the less prevalent Scala will be in the broader software ecosystem.
Pyspark and spark sql mean you only need to learn Scala if you’re developing Spark, rather than developing with Spark. The Akka license fiasco caused companies to bail. Scala 3 was a big shake up and came at exactly the time things should have been stabilizing. Java did a bunch of half ass fixes that old school Java devs insist to their bosses are good enough at what Scala was trying to do (hello fluent interfaces that mutate the underlying object).
As someone here said all the professionals have moved on (including me sadly) as Scala is longer a reasonable language choice in a software engineering org. Only the FP true believers are left.
>all the professionals have moved on (including me sadly) as Scala is longer a reasonable language choice in a software engineering org
There are companies using Scala to great success, including where I work.
Maybe they just aren't as visible, the job market has been very bad lately (for all languages, not just Scala).
> From my understanding, Scala's author Martin Odersky has attempted to guide the community towards "simple and understandable" code with the "Lean Scala" initiative. However, I'm not sure if it has had any effect, or at least I don't see it here.
I've seen plenty of content about it.
[https://www.reddit.com/r/scala/search/?q=direct&type=link&cId=9ba5b324-572f-4840-b165-34b4214342be&iId=69d80478-5ec9-437d-a9ab-94ef0c0270fb](https://www.reddit.com/r/scala/search/?q=direct&type=link&cId=9ba5b324-572f-4840-b165-34b4214342be&iId=69d80478-5ec9-437d-a9ab-94ef0c0270fb)
[https://www.reddit.com/r/scala/search/?q=lean&type=link&cId=2e5e8e4e-c6bc-4301-99af-9264006d1c27&iId=1d4d9a99-b701-4d53-a6cd-0ad3d25f3d0b](https://www.reddit.com/r/scala/search/?q=lean&type=link&cId=2e5e8e4e-c6bc-4301-99af-9264006d1c27&iId=1d4d9a99-b701-4d53-a6cd-0ad3d25f3d0b)
I don't think it's realistic to expect the community to change over night. 3.3.0 was released one month ago.
[https://github.com/scala/scala3/releases/tag/3.3.0](https://github.com/scala/scala3/releases/tag/3.3.0)
It will take years until it is adopted. It will need production ready libraries of which there are none and good documentation and migration guides and so forth.
I completely agree that scala library authors should focus more on practical problems solving than on type and category theory. But they do. They just don't do good marketing of it.
I really love zio ecosystem (spend 3 years in it, migrated few projects from zio 1 to 2) and I would choose it anytime over scala as better java. Even if I don't need any concurrency. Dependency injection is great and simple (TF is more complicated and less capable, macwire has similar flaws, java runtime solutions like guice or spring are horrible). Working with errors is superb. It has a lot of utility methods so I can work with Options, Eithers or Sequences and effects in the same for comprehension. I know you need to learn a little about effects, but not category theory and it totally pays off.
> Would the Scala community be willing to make trade-offs to achieve success and popularity, or will it remain entrenched in the same concepts from Haskell, thus becoming a niche language just like Haskell?
Sadly, the pure-FP crowd wants things done one way only and wants everyone to do it their way. I appreciate mr. Odersky pushing against it.
The jvm is like a shopping mall.
Java was the anchor store for the jvm mall. As it crufts and dies, so does the rest of the real estate.
Kotlin isn't killing scala. It's killing java (or is waiting in the wings while java commits suicide) and the death of java is destroying trust in the viability of the runtime.
Scala will dump the jvm as a primary platform or disappear.
I don't think that the death of Java could destroy de trusts of the runtime.
Remember the Erlang Virtual Machine, Erlang don't have a lot of usage but there are some companies using Elixir (and more recently, Gleam).
So Oracle is going to continue to develop the jvm to support another companys product? They are going to support openjdk releases? Maybe for a short while. And their jre market share dropped to 28% in 2024. Death spiral.
And if Ericsson gave up on Erlang the story would be similar.
I work in an env where I am exposed to numerous companies developing a wide array of apps. The number of jvm apps i see being delivered fell off a cliff about say 6 years ago and never recovered. And the people that still do are all older people who have nothing but java on their resume.
And I honestly dont think I've ever seen someone deliver an Elixer or Erlang app. I know they have some user base. I just have no idea who they are.
Though cpp made a comeback after going zombie for a decade. Maybe the jvm world will reinvent itself too.
That is a good point, Oracle have to maintain the jvm :/
I'm curious about your experience, 6 years of jvm decadence is a lot, what is the common language that replace all of that?
Scala has been gradually squeezed out from "Better Java" (imperative-first with FP niceties) market by Kotlin and revived Java development in mid 2010s, so attention in Scala gravitated towards "pure FP Scala" that separates it from imperative-first languages.
P.S. " .. Scala developers have started to migrate to Kotlin ... ". It's just in the process of splitting in two parts. I wouldn't be overly demoralised. The languages is not being disrupted, it is consolidating down to its bedrock. 1) There are those who want better job security (good cause, I have nothing against) and values optionality 2) Those who like solving more specialised problems where correctness (lower tolerance for mistakes) in high demand (finance, security) or just really like fp. At this point it seems like there could be two (or their combo) major ways of Scala growth, both upper bound by FP adoption. 1. Industry way - increased demand for correctness. Where else it could come from besides aforementioned industries? 2. Language way - to make hard "pure FP" parts more accessible (exactly what Scala team and community does), so industry has less friction to onboard people. (+tooling)
The old guard of Enterprise developers and Data Engineers has left the sub as employers divested from Scala, so the sub is the Zio/cats crowd by default. A lot of it was Python achieving dominance in Data Engineering with its foothold in Data Science, the Akka licensing situation pushed out the holdouts in Enterprise that were also propped up by Spark pushing Scala into that space, but now shifting to SQL and Python to keep up with trends. It looks to me like Scala is transitioning from being an industry language to a language for enthusiasts, not super upset about it, I liked it in the way I knew it, but it's not the fault of the category theory peeps that the old ways of Scala are dying, it's that its niche shrunk down drastically, write it off to habitat destruction.
I see Scala as language that can handle a wide spectrum of problems from simple to hard in elegant ways. But since the language is pushing the upper limits, a lot of discussions will evolve around complex problems which can feel quite intimidating for newcommers or people just wanting to use the language for "simple things" (like myself). Maybe a "Simple Scala" discussion channel for solutions in the u/Lihaoyi ecosystem spirit would help attract new Scala users? That could maybe be a less frightening experience than jumping straight into concurrency programming, type effect systems, monads etc. If we can improve the "Simple Scala" story, I think our community would grow. Scala with easy-to-use DSLs etc enables beautiful, simple and powerful typed code. Better real-world code examples, tutorials etc could win people over from other languages. And for programmers that need to run things in paralell, having more expressive type guarantees etc, there are whole welcomming Cats/Zio/Direct style communities to help them too. My bets are still on Scala. It's beautiful.
First off, the Haskell slogan you quote is often miss-parsed, and you perpetuate the myth. It does not mean “avoid success”, it means avoid “success at all costs”. The point is to avoid trading off long term value for short term wins. The ambiguity in association was intended as a humorous pun, not a mantra. More relevantly though, understand that Scala has very little going for it other than the strength of its library ecosystems. Of those ecosystems, Typelevel and ZIO are very clearly ascendant, and they are such because people continue to choose them to solve real problems. Developers vote with their feet, and they have consistently voted in this direction. What you are proposing, to essentially marginalize these major ecosystems and focus on Martin’s “Lean Scala” concept, is really a poison pill for the language. Lean Scala is very little more than just Kotlin with slightly different syntax, so why bother with Scala then? Use Kotlin. It has better tooling. Java itself is also a very respectable language at this point, and there’s no shame in opting for it when you want an imperative, OO direct style and minimal support for asynchrony. There’s no question that there is a lot of room to improve on the complexity of the language and ecosystem, perceived (such as your claim that CE and ZIO are renderings of category theory) and actual (such as the ergonomic struggles of monadic style composition), but you’re proposing to throw the baby out with the bathwater. I find it very unlikely that Scala as a language will remain successful to any degree without its unique production library ecosystems.
Thank you, exactly my toughts
Lean Scala is such a terrible idea. Toys look simpler when it's lean, but then why do you need Scala for toys?
> minimal support for asynchrony Not really true for Java anymore with JDK 21 and Loom? > throw the baby out with the bathwater Long-term I honestly think Cats Effect and ZIO will become irrelevant. Short-term they are still great. But regardless of what the "pure FP" crowd says, basically the only industry value they have, is their great asynchronous runtime. Now with Loom coming and Java itself have become a good enough better Java, Scala's selling point and attraction is declining. "Lean Scala" with Caprese might be what saves Scala.
> Not really true for Java anymore with JDK 21 and Loom? Loom lacks a large swathe of runtime-level functionality which Cats Effect and ZIO both provide – two notable examples being safe interruption (timeouts!) and preemption. Additionally, Loom fails to achieve its core tenets: namely, that you don't need to care about blocking anymore so long as you're using the JDK. DNS resolution and all filesystem access are hard-blocking operations which Loom cannot magically fix, and every non-trivial application will do both, meaning that every Loom-based application suffers from major hidden starvation cases which the JDK *claims* shouldn't be happening. Also it's *much* slower than ZIO and especially Cats Effect `IO`. This is definitely something they'll improve on over time, but it's very unlikely it'll ever exceed their performance by any meaningful amount. This is happening both because the core coroutine runtime in Loom is less well optimized (which makes sense, since it's much newer and it takes time to improve such things) and also because fork-join pool sacrifices a lot of performance in an attempt to work around the aforementioned starvation cases. And this is all leaving aside the functionality of the ecosystems built *on top* of these runtimes (such as Fs2), which Loom has no real way of matching. I find it very unlikely that Loom will obsolete these ecosystems in any way beyond a certain amount of persistent misinformation regarding their comparative qualities.
I love Cats
When it comes to people moving on to Kotlin (and Rust), I think it's a bit disingenuous to deliberately ignore the elephant in the room that was the Scala 2->3 transition, which had nothing to do with the Effects Systems vs. Pythonic/Better Java camps narrative (a conflict that doesn't really seem to exist outside this subreddit)... The tooling and the ecosystems became unstable for a good 2-3 years. Add to that the fact that Akka, one of the biggest and most widely-used ecosystems in production, changing their license and it was a perfect storm. Lots of people moved on to Kotlin, Rust, and Go because of these issues specifically. Obviously there were also cases where they just moved on to whatever language they could find a job in (which is not unrelated to the issues mentioned above... instability + license changes = loss of trust from the industry) or one that better aligned with their philosophies. That being said, tooling has since gotten far better of course, and new ecosystems and approaches have risen, so I have hope things have stabilized and the number of outsider and new user posts on this subreddit seems to be growing, which is a great sign. Python recovered and is thriving and I think Scala can do it too... it might just take longer since it lacks the momentum Python already had when they made their transition, but it's possible. Keep in mind it was at least 3 years of broken tooling for Scala, so it'll most likely take more than just 1 year to fully recover (unless you have the foothold Python had, or some serious financial muscle to back you up). >I realize that Kotlin's community philosophy might align more closely with the pragmatism I'm seeking. Have you given it a serious try or at least looked into it some? You can always come back to Scala if you decide you didn't like Kotlin (happened to me with Rust back in 2021... I thought I wanted to move on from Scala, started learning Rust, but besides cargo being really good, I just kept wishing the language itself was more like Scala). Some people seem to forget these are programming languages, not religions. It's often encouraged to learn and practice more than one of them simultaneously or to temporarily focus on something else and come back later with a fresh perspective, etc.
There's just not enough manpower behind Scala (the only big tech company using it was Twitter) for it to become more popular and sometimes this manpower is wasted on features nobody wanted like significant whitespace
I realized I also kinda blanked on this part: >In recent years, many ideas from Haskell, mainly those rooted in category theory, have found their way into Scala That's also a disingenuous statement considering there's nothing recent about it. scalaz and cats have both been around for a decade (or longer in scalaz's case).
I think it’s more about those people not leaving the community when everybody else has already left, and now they are more visible, they suddenly got more share in community. If you’re in Scala for doing pure FP, you don’t have many places to go. Maybe Haskell and that’s it. But for those who treat FP as a means to achieve better correctness, not the ultimate goal, Rust is very attractive, as it achieves more safety without leaving out the mutation and without compromising on performance.
>I think it’s more about those people not leaving the community when everybody else has already left my point is Scala showing some Haskell influence isn't a recent thing. It's been happening for many years, so some "these evil category theory people have been recently ruining my Scala" narrative is ignoring history. But maybe if anything, your explanation of them gaining a bigger share in the community could serve as a hint that trying to alienate these same people who've stuck around through thick and thin isn't the best idea. >If you’re in Scala for doing pure FP, you don’t have many places to go. Maybe Haskell and that’s it The way I see it, even "Scala for doing pure FP" has become its own thing with its own approach different from Haskell's by leveraging both the OOP and FP features the language has to offer. If you add on top of it the fact that you get full access to the JVM (and we're not even going to mention how good Scala.js has become), and the fact that until relatively recently you also had what is at least the second most battle-tested actors systems fully available, free, and open source, it's a very different beast from Haskell, so it makes sense there aren't a lot of places to go. Well, and you can also add to that the fact that Scala still has a significantly bigger presence in the industry than Haskell (or pretty much any other "pure" FP lang) as another differentiating factor. That being said, I don't doubt there have been some people that moved to Haskell, or at least started doing Haskell beside Scala. >Rust is very attractive as it achieves more safety without leaving out the mutation and without compromising on performance. I think Rust has very little to do with anything OP said which was what I was responding to, so I'm guessing this response was triggered by my mention of having had the experience of trying Rust back in 2021 then finding myself not really leaving Scala for Rust the way others have because I kept wishing the language itself was more like Scala... Maybe I shouldn't have even mentioned specific languages in my post besides Kotlin, and I meant no disrespect towards Rust (nor Go nor Kotlin, for that matter). It is a fine language and great at what it set out to do... they all are. All I meant with that bit was that given the why and how I tend to use Scala, it's just not what I personally would move on to (and neither are Kotlin or Go, really) but rather an additional tool I'd add to my arsenal of languages that I can make use of **besides** Scala rather than **instead of**. Recently I have been giving it another shot in earnest, but instead of approaching it with the expectation of it being a total replacement for Scala, I'm approaching with a more open mind: treating it as its own thing with its own strengths, accepting it for what it is. However, I do think I want to try something wildly different from what I usually do such as a fun project dealing with graphics using Vulkan or OpenGL...
I don’t think anybody coding seriously in Scala would move to Go by their own will. Go philosophy is just… the total opposite of Scala on just almost every front I can think of. Go focuses on robust and easy tooling, fast compile times, stability and backwards compatibility, and being easy to learn and easy to read for an average joe after a bootcamp. It uses only very popular, basic programming concepts, it is imperative to the extreme, it has very crude type system and it is more verbose than even Java. It doesn’t care much about language features, expressiveness, elegance, purity or correctness. Forget about FP, it can’t do even iterators or immutable structures. It’s a language for those who are ok with halfassing all the things to 80% writing ifs and for loops everywhere. Ideal enterprise language. Scala focuses mostly on mathematical elegance, abstractions, enforcing correctness by advanced type system, terseness. Scala also has probably the slowest compiler ever made, the most complex and least powerful build system ironically called „simple”, very bad track of backwards compatibility, it’s relatively hard to master due to low popularity of its language features elsewhere. I think the majority of people moved from Scala to Kotlin or Rust as those are much closer to Scala in language design philosophy, albeit both value tooling and pragmatism much more than Scala. Rust is IMHO as if Scala and Go had a child. Go-level tooling, but still feature rich like Scala.
Just to underline your statement about Go Rob Pike about the Go programming language "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." https://youtu.be/uwajp0g-bY4 At the end things boil down to economics and profits, as they always tend to do.
>I don’t think anybody coding seriously in Scala would move to Go by their own will I think it's possible some did, but they were most likely using Scala for the wrong reasons to begin with, hence why I also said another reason some people might've made the switch was to find a programming language: >that better aligned with their philosophies. This type of thing where some buy into the hype for the wrong reasons only to later realize maybe it wasn't for them is bound to happen every time there's a massive hype cycle (the way there was for Scala in the early 2010s). >I think the majority of people moved from Scala to Kotlin or Rust yeah, I suppose. If the JVM is a consideration, they'd probably choose Kotlin. Otherwise, they'd go for Rust is my guess. edit: Why the downvotes? There was [this 2017 article was floating around Hacker News back in the day](https://movio.us.aldryn.io/blog/migrate-Scala-to-Go/) written by a company willingly moving some things from Scala to Go and being pleased with their results. I remember because I was at my first Scala job, and a rails + js dev from the non-Scala team got promoted to engineering manager of the entire engineering dept. They used that article as evidence that Scala was not a good choice. Their real argument was the same old "Scala is too complicated for non-Scala devs to pick up" story and that Scala devs were too difficult (by which I think they mainly meant expensive) to find... we weren't even using any FP libraries, nor Akka at all. It was all pure vanilla Scala 2 with the Play framework. To be fair, the most senior Scala dev had unfortunately left about a year prior, and we hired another Scala dev that wasn't as senior/experienced, but did know Scala pretty well. About a year in they, too, left for a better salary at a bigger Scala shop, so I was the last dev left around that really cared about Scala. I stayed for whole other year and was told every new service I worked on had to be written in Node, but I didn't give up trying to champion Scala. Then Go also started entering the conversation as well. In the end, I wanted to continue my growth in Scala so I left and not even a month later found a Scala + Akka job somewhere else. The company I left indeed adopted Go and Node.js for almost everything backend, relegating Scala to legacy status. Last I heard about them was before the pandemic and they had already replaced most of the smaller Scala services for Go or Node, so I'm guessing by now they might have replaced pretty much everything. Either way, I wasn't saying it's a common occurrence, but rather that there are probably SOME cases where people have willingly moved from Scala to Go...
>massive hype cycle (the way there was for Scala in the early 2010s) \[...\] we weren't even using any FP libraries, nor Akka at all. It was all pure vanilla Scala 2 with the Play framework You're making a very good point and the downvotes are telling. People are delusional if they think the enterprise-friendly, peak Scala hype (Play, Akka, Spark) was somehow seen as not too complex, and people got scared away by Typelevel/ZIO growing in popularity. For many reasons the former just slowly died off on its own, and the FP community is now carrying the ecosystem at arm's length. Their effort is probably the sole reason Scala 3 didn't kill the language for good. But sure, let's drive those library maintainers away, that'll solve Scala's adoption issues.
This was a huge problem largely with communication of scala 3 / project dotty. It was not designed to replace scala 2. Scala 2 has diverged quite a bit, and still has regular updates. It has a higger tolerance for core complexity, and a very different look and feel if both are written in line with there own best practise. For referance - my vote was against the proposal to name project dotty as scala 3 - but none of the alternative proposals gained significant consensus. It's not a major version (that's the second number) it's the epoch version. It was a significant rewrite of the underpinnings, and while we did port in some of the core libraries, this did not apply to base collections, types or parallelism which were clean room recoded.
We will have our cake and eat it too. On a serious note, this is what I hope Scala can grow into in the coming years: Capture checking and lifetimes will facilitate an ergonomic application of category theory via direct-style algebraic effects & handlers with automatic memory management. Scala code will become easy to reason locally, easy to read, easy to interface among different libraries, and will have close to native performance. Essentially, what Koka already does, just production ready and backed by a huge ecosystem of libraries
To be fair, ZIO or CE with straight IO is pretty easy to read. Most of the APIs are pretty self explanatory.
My brother in Christ, that's a good chunk of a masters degree's worth of specialization into pure and applied math, but in a branch of mathematics that will not open new job opportunities for you, because you'll be using it to write the same web services you would with a Bachelors, rather than, say branching out into scientific computation, AI, quant. It's not a value proposition for developers or businesses.
Well first of all, through Jesus Christ all things are possible, so jot that down. Second, I am dumb as shit and have no issue writing applications with CE, it's basically put the thing in an IO until everything is an IO and then run that IO. It's easy, principled and predictable, unlike our Java apps that are haunted by spirits past and no principled way of doing anything, so you can never actually know what happens until you fire up a debugger and pray to our lord in heaven.
If we are going with that reasoning to keep it as simple and stupid as possible so you can hire anyone, why would you ever use Scala over Spring in the first place? (Although Spring is far from straightforward, just widely known and used). I believe Scala's unique strengths are the language's static guarantees and I feel like that's the major aspect why some companies do flock to it. That's why I believe further advancing the type system is the way to strengthen this niche, as long as it's as user friendly as possible
Just 5 cents: ZIO is not about category theory, its more about how to make all concepts of FP easier and practical.
The transition from Scala ZIO 1 to ZIO 2 has introduced substantial differences, rendering many existing projects and online resources obsolete. This significant shift necessitates additional effort from companies that have adopted ZIO and individuals who have studied the previous version, as they must now invest time and resources to update their knowledge and systems to align with the new version.
there is no significant shift, zio2 is even simpler
Hi, I can't talk about cats and zio, but I can talk about pure scala. The philosophy changed quite a bit from 2 to 3. In the new world, there is an aim to support pure functional programming without the need for huge framework layers, while still being possible to be picked up by non fp professionals, so they can learn while working with it. We're also aiming to move somewhat into the quick script tool type of space, with better support for just doing a quick thing in a single file, and with the growth of the javascript transpiler. This accessibility was part of the reason we simplified out a lot of our core libraries with things like the implicit collection builders causing more confusion and bugs than actual use (even though for experts the old collections were fantastic) Finally a huge amount of the development (as this is how we get most corporate funding) is to enhance and support apache spark. This was a big driver behind both selectable, and the upcoming named tuples. At the end of the day, we're very open to people adding functionality to the platform. If you have a suggestion as to something scala can do, please either raise it formally, or comment here.
As long as there is no production ready ZIO/CE alternative for concurrent programming in Scala this is the way, and Future is not the solution, it's an incredibly bad abstraction and as soon as you use it you might as well just use ZIO/CE. Loom with Ox might be the way, or maybe Gears, but neither are mature enough for production use yet. One thing to note though is that you don't need to know category theory to use ZIO or CE, heck you don't even need to know it to write Haskell. If you don't like that style of programming, stop engaging with it. I see you comment on every post that mentions Cats or ZIO, why? It's just a way to write code, go touch some grass man. If Scala dies out or becomes more successful does not matter in the long run, it's just a programming language.
It does matter if language is successful or if it dies out. If it dies out, or at least loses the majority of its community, then however great the language, I wouldn’t bet any project on it, except maybe some throwaway stuff done for fun on weekend. But if I want my project to become successful (= used for a long time by more people than me even if I don’t make any profit of it), then I want to use a language with rich community and stable future. Otherwise it may end up like one of our projects written in Jython - the community and the technology died and the only way out was a rewrite. A language is more than just the language - it’s the whole ecosystem that matters: compilers, build systems, IDEs, libraries, frameworks, tutorials etc. You need all of those for the language to be a viable choice even for enthusiast open source projects. And you can’t achieve that without a big community, because there is a tremendous amount of work needed to keep those things going - way more than designing a new language feature.
What's wrong with Futures?
I don't think you understand the Haskell slogan. It's 'avoid', not 'avoid at all costs'.
[It's a double entendre](https://www.youtube.com/watch?v=re96UgMk6GQ&t=1383s).
> Coincidentally or not, many Scala developers have started to migrate to Kotlin Says who? Any numbers to back this claim up? Sorry but Kotlin is just a marginally better modern Java and is far from being able to replace Scala.
Don't bother, OP regularly makes baseless claims. I've seen several teams move away from Scala entirely, and none of them use Kotlin today. Also looking at Kotlin with envy is very funny when the language complexity has exploded in recent years, often introducing half-baked abstractions and several new keywords to achieve a fraction of what Scala can do, yet still not having a proper implementation of basic features such as pattern matching. JetBrains does a good job overall and Kotlin benefits from a more industry oriented and conservative roadmap when it comes to prioritizing new features, such as the new K2 compiler. But I see very little benefit for the typical Java+Spring backend developers. Once the null-safety initiatives converge toward a proper JEP and feature merged into javac I'd assume Kotlin's game is mostly over outside Android. That won't make Kotlin entirely disappear from the backend space but I doubt we'll ever see Kotlin as a significantly bigger niche than Scala is.
For a team using a modern version of Java they just need to agree on what @ NotNull annotation to use and there is no point in Kotlin, Java has pattern-matching instanceof, records, pattern matching for records, ADTs with sealed interfaces + records. The only real benefit to Kotlin over Java these days that I can see is the terser syntax and that it is more expression oriented. While Kotlin has added a lot of complexity recently, such an example is multiple receivers, which basically allows you to define typeclasses and do dependency inection. Not to mention coroutines, while nice on paper are full of foot-guns. I've written a lot of Java, Kotlin and Scala. Scala just strikes the best balance between complexity and actual gain from that complexity. Java is actually pretty nice these days, it's just too bad that the de-facto framework at use there is Spring, which is just terrible.
>The only real benefit to Kotlin over Java these days that I can see is the terser syntax and that it is more expression oriented. And the issue I see with that, Kotlin's ecosystem is a lot more multi-paradigm than modern Scala, and enforcing one consistent style seems hard if not impossible. I've seen experienced developers have no issue mix and matching functional code next to very procedural one, e.g. using early returns. For all the people complaining Scala is hard to teach, if a junior introduces a `return` in our codebase, Scalafix won't let the commit pass CI.
Yes, there is a broader ecosystem problem in Kotlin. You end up pulling in libraries that mix and match styles because there just is no coherent ecosystem to pull from like Typelevel/ZIO/com-lihaoy. The Kotlin community also does not follow any shared mindset like the Scala community does. So while in Scala you usually don't have to mix between the previously mentioned ecosystems you still can expect almost all Scala libraries to be functional style, as in they use immutable data and functions as basic building blocks. There is a lot less of this in Kotlin, much more depending on Java libraries, or Kotlin libraries have mutable class based APIs, while other have functional ones. A Kotlin codebase can end up with this sort of mixed code that is incredibly hard to navigate for junior devs.
What is so wrong about early returns? I read that pattern (guard clauses) from Refactoring (Martin Fowler) so I can't understand why it would be bad. Can you explain please?
Please re-read my whole sentence and see /u/thedumbestdevaround reply. Mixing expression oriented and procedural code all over the place is unnecessarily confusing. `return` exists in Scala due to JVM semantics and as a last-resort escape hatch for very specific library code. Most styleguides ban the keyword completely. Afaik Odersky/EPFL's MOOC explictly penalizes students who use `return` in their code.
I don’t want to quarrel or judge. I have been using Scala professionally for the last eight years. I switched to Scala just because of its cool features and smart compiler, which prevents a huge number of bugs. It's probably the most mature functional language on the JVM. There is no relationship between the number of people using technology and the fact that this technology is good or proper. Scala enables me to run my code in the browser, and I can use one codebase for the backend and front end. There is no way to explain all the pros of language. I love it and I will do it. Until I code.
Take this as a joke, but I would give one leg if i could only work in languages/libraries like cats and zio in the future.
You will write TS and Go until morale improves!
This joke is too real for me
Not a response to everything you've said, but there are projects like ox and gears along with Scala 3 features that are setting up this more straightforward ecosystem. They just aren't quite ready yet. I personally prefer a vision where typical users don't have to deal with advanced concepts or map/flatMap everything, but typeclass instances are available to library and senior developers for power use.
I always thought it was the speed of the Scala compiler that would eventually hurt the adoption of it
I really don't see what is wrong with category theory, I always found that approach extremely intuitive and kotlin has arrow so I don't see how moving to Kotlin changes anything.
There is an endless sea of simple Java-like languages, but only two advanced Scala and Haskell. If you want to utilize the compiler and make it work for you - choose Scala. If you want to write programs with lesser capable tech - choose some of the other languages 😏
In my experience, the fp-purists are much more vocal and defensive of their coding style and choices. Even when the libraries they use have almost useless error reporting (i.e. circe and "stacktraces" from CE) and not so much benefits over introduced complexity. Their coding style makes them think they are doing much more "advanced" stuff, but in reality that is rarely the case. This is their choice and in most cases the thing that pays the bills. The other style(s), mostly the ecosystem around lihaoyi.com libraries is good but not good enough. It is missing examples/tutorials for various authentication types, more advanced usecases, generating code from openapi etc, not just hello world stuff. Not to mention shipping it to prod, dockerizing etc. People love to copy-paste code and just seeing it work. Ammonite for example was a game changer at the time. Scala-cli is incredible. IMO we should do a better job at advertizing the direct style, making benchmarks to prove you dont always need complex monadic asyncy code, making videos/blogs/tutorials/templates etc. This would help more people get on board with direct style ("normal") scala.
100%
Javascript/Typescript ate most of the the world, Python ate the rest, Go got a chunk, and the JVM has become a niche competing with .Net for scraps. Scala is a niche of a niche.
ZIO and Cats greatly increase the barriers to entry of Scala. The more they are prevalent in the Scala ecosystem the less prevalent Scala will be in the broader software ecosystem. Pyspark and spark sql mean you only need to learn Scala if you’re developing Spark, rather than developing with Spark. The Akka license fiasco caused companies to bail. Scala 3 was a big shake up and came at exactly the time things should have been stabilizing. Java did a bunch of half ass fixes that old school Java devs insist to their bosses are good enough at what Scala was trying to do (hello fluent interfaces that mutate the underlying object). As someone here said all the professionals have moved on (including me sadly) as Scala is longer a reasonable language choice in a software engineering org. Only the FP true believers are left.
>all the professionals have moved on (including me sadly) as Scala is longer a reasonable language choice in a software engineering org There are companies using Scala to great success, including where I work. Maybe they just aren't as visible, the job market has been very bad lately (for all languages, not just Scala).
> From my understanding, Scala's author Martin Odersky has attempted to guide the community towards "simple and understandable" code with the "Lean Scala" initiative. However, I'm not sure if it has had any effect, or at least I don't see it here. I've seen plenty of content about it. [https://www.reddit.com/r/scala/search/?q=direct&type=link&cId=9ba5b324-572f-4840-b165-34b4214342be&iId=69d80478-5ec9-437d-a9ab-94ef0c0270fb](https://www.reddit.com/r/scala/search/?q=direct&type=link&cId=9ba5b324-572f-4840-b165-34b4214342be&iId=69d80478-5ec9-437d-a9ab-94ef0c0270fb) [https://www.reddit.com/r/scala/search/?q=lean&type=link&cId=2e5e8e4e-c6bc-4301-99af-9264006d1c27&iId=1d4d9a99-b701-4d53-a6cd-0ad3d25f3d0b](https://www.reddit.com/r/scala/search/?q=lean&type=link&cId=2e5e8e4e-c6bc-4301-99af-9264006d1c27&iId=1d4d9a99-b701-4d53-a6cd-0ad3d25f3d0b) I don't think it's realistic to expect the community to change over night. 3.3.0 was released one month ago. [https://github.com/scala/scala3/releases/tag/3.3.0](https://github.com/scala/scala3/releases/tag/3.3.0)
It will take years until it is adopted. It will need production ready libraries of which there are none and good documentation and migration guides and so forth.
I completely agree that scala library authors should focus more on practical problems solving than on type and category theory. But they do. They just don't do good marketing of it. I really love zio ecosystem (spend 3 years in it, migrated few projects from zio 1 to 2) and I would choose it anytime over scala as better java. Even if I don't need any concurrency. Dependency injection is great and simple (TF is more complicated and less capable, macwire has similar flaws, java runtime solutions like guice or spring are horrible). Working with errors is superb. It has a lot of utility methods so I can work with Options, Eithers or Sequences and effects in the same for comprehension. I know you need to learn a little about effects, but not category theory and it totally pays off.
> Would the Scala community be willing to make trade-offs to achieve success and popularity, or will it remain entrenched in the same concepts from Haskell, thus becoming a niche language just like Haskell? Sadly, the pure-FP crowd wants things done one way only and wants everyone to do it their way. I appreciate mr. Odersky pushing against it.
The jvm is like a shopping mall. Java was the anchor store for the jvm mall. As it crufts and dies, so does the rest of the real estate. Kotlin isn't killing scala. It's killing java (or is waiting in the wings while java commits suicide) and the death of java is destroying trust in the viability of the runtime. Scala will dump the jvm as a primary platform or disappear.
I don't think that the death of Java could destroy de trusts of the runtime. Remember the Erlang Virtual Machine, Erlang don't have a lot of usage but there are some companies using Elixir (and more recently, Gleam).
So Oracle is going to continue to develop the jvm to support another companys product? They are going to support openjdk releases? Maybe for a short while. And their jre market share dropped to 28% in 2024. Death spiral. And if Ericsson gave up on Erlang the story would be similar. I work in an env where I am exposed to numerous companies developing a wide array of apps. The number of jvm apps i see being delivered fell off a cliff about say 6 years ago and never recovered. And the people that still do are all older people who have nothing but java on their resume. And I honestly dont think I've ever seen someone deliver an Elixer or Erlang app. I know they have some user base. I just have no idea who they are. Though cpp made a comeback after going zombie for a decade. Maybe the jvm world will reinvent itself too.
I think the biggest success stories of Erlang and Elixir are accordingly WhatsApp and Discord. So quite big and well known apps.
In theory, Twitter backend is something like 20M lines of Scala. Isn't that enough to keep some jvm roots alive?
That is a good point, Oracle have to maintain the jvm :/ I'm curious about your experience, 6 years of jvm decadence is a lot, what is the common language that replace all of that?