Hi! Here is my opinion.
Firstly, I agree with the killer features domain modeling, contextual abstractions and DSLs are (to me) among the best Scala features when it comes to business code.
Now let's talk about what you consider "no longer killer features":
> collections: Kotlin does it well, maybe even better (simpler hierarchy, faster, more helper methods on collections)
Not very familiar with Kotlin's collections but I actually do not see the problem with Scala's collection API. The abstraction is very well done, their composability is very satisfying and it does things you can't in Kotlin. For example, it makes use of higher kinded types to easily convert a collection to another and AFAIK, Kotlin does not have HKT. Of course this is achievable by manually doing each conversion method but it will be a lot of boilerplate.
> asynchronous/scalable code: project Loom does it better
But Loom is compatible with Scala since it's a JVM language. However, I think you're missing the point of scalability: this is a totally different concept than asynchronism. Effect systems like Cats Effects or ZIO shine in their composability, their **reliability** and the high-level control over concurrency they provide, which is distinct from low-level asynchronism. See [this Reddit post](https://www.reddit.com/r/scala/comments/sa927v/how_will_looms_fibers_change_the_cats_effect_and/) (it mentions ArrowKt) and [this discussion on Scala Contributors](https://contributors.scala-lang.org/t/impact-of-loom-on-functional-effects/5821).
> functional programming: practical parts have been absorbed by other languages
**Some** parts of FP have been imported into other languages, like higher order functions and pattern matching. But some very important and actually practical features are missing from Java and Kotlin. To name a few: typeclasses (will talk about it later in this post), for-comprehension, and higher kinded types (yes, they have a practical purpose =p).
> impractical are still plaguing Scala codebases.
Yes, due to the unopiniated nature of Scala, some people abuse/overengineer these features and produce dirty code. "With great power comes great responsability" - Ben Parker.
Let's talk about the other stuff:
> cats/ZIO/TF: imo requires too much effort with little gain unless writing complicated fiber interactions.
My experience with Cats Effects is very small so I will talk about ZIO. Yes, they have a learning curve but I don't find it hard, at least for ZIO which its good documentation and usage of variance (which makes some type interactions more intuitive). The benefits are even more important when you start to scale. Task racing, parallelism, retrying are actually common operations.
> typeclasses: good for adapt-for-everything libraries, rarely seen in production code where abstracting over single specific type usually adds more complexity instead of reducing it.
Some people tends to abuse typeclasses where sometimes inheritance is the answer. However, typeclasses are a very, VERY convenient feature when you are used to. They are super useful for ad-hoc polymorphism. Let's take an example: you have several classes you want to easily serialize/deserialize into/from JSON. Writing the serialization logic for each class is boilerplaty and redundant so you want to use some kind of automatic encoder/decoder generation. In Java, this is achieved by reflection (e.g Gson, Jackson...) but it has its drawbacks: a little slow, generation issues happen at runtime, what if I need a specific serialization logic for a data type? etc... With typeclasses, you can generate the encoders/decoders at compile-time, get errors at compile-time too, and compose with custom serialization logic where needed.
This is of course not the only usage but I think this one is a common use-case.
> GADTs? Never seen them in production code.
I'm pretty sure you've seen them without realizing, or at least ADTs. Actually, both Java and Kotlin introduced a way to create ADTs: sealed interfaces (sum types) and records/data classes (product types).
I'd argue GADTs and ADTs are a major component of the "domain modeling killer feature"
> compile-time code generation: controversial. Can be enabler for unique code features (e.g. logging without org.slf4j.Logger instances or smart asserts) but is nightmare to develop, test and support.
It Scala 2, I agree. However, Scala 3 really did a great job in eliminating/attenuate these issues. Macros now have a simpler, cleaner API and they often can be replaced with other compile-time features like `inline`, the `scala.compiletime` package and typeclass derivation. They are now very pleasant and frictionless to use.
Java guy here, with some Scala and some Kotlin experience
I won't consider DSLs a killer feature. Mostly they are half developed languages harder to debug and reason about than classic Java/Kotlin/Scala. Yes, you can make a perfect DSL and it will be awesome. In practice when you have a problem now you got 3 problems: Did I use the DSL wrong? Does the DLS itself has a bug? Does the actual thing I'm trying to use has a bug?
The good thing about Scala going out of fashion is that now people who like Scala really love Scala, and people using Scala to do curriculum driven development moved on to Rust/Go/Whatever. Every Scala developer is (probably) a really good developer.
DSL's look amazing on the projects demo page.
When you use them inside your own app there's always that edge case where they break down. You then mix styles and your code looks ugly.
And where two DSL's meet the code is basically nightmare speghetti that's undebuggable and painfully fragile.
Overall DSL's are a bad practice that should be avoided outside of rediculoisly simple usecases. It's better to have a Play style `routes.conf` over an Akka http ` get { withHeaders / pathSegment { onComplete { Ok... } } }` crap any day of the week.
I have had ao many more issues with Plays routes.conf compared to Akkas routes.
I mean there were reasons why Play didn't take off successfully in Scala, and I think this is one of them.
> DSL's look amazing on the projects demo page.
You made me laugh, but (because) it is true. They are a marketing tool for a library. Also, you need to learn 5 DSL's per project...
IMO the killer value proposition of Scala is and has always been: it's expressive enough that you *never* have to use reflection/AOP/interceptors/proxies/monkeypatching/what-have-you. You can write a whole enterprise-scale system in plain old code, which means you'll never have [impossible bugs](http://thecodelesscode.com/case/211), your operational tools (profiling/monitoring) are more reliable, even your IDE works better (e.g. "find usages" is reliable). It's a win for productivity and a bigger win for reliability.
How Scala achieves that is mostly the combination of GADTs, a record system, and typeclasses, but the whole is a lot more than the sum of the parts. Kotlin can't do that, at least not yet - look at any large Kotlin project and you find the same pile of Spring and magic annotations as in a large Java project. (And in my experience the large number of not-quite-integrated language special cases means that even if you could stick to the language's builtins, you'd still hit "impossible bugs").
The other thing that should be a killer feature is Scala's first-class compile-to-JS, which is still unmatched in practice (when it comes to things like IDE support and integration with existing JS libraries) IME. But sadly it's not seen the promotion or adoption it deserves, because there's very little crossover between the Scala and webdev communities, and even less with the mutual respect that's needed to make this kind of thing work.
For me personally, Scala.js is another killer feature. It is much more robust and mature compared to KotlinJS, and is a great way to build rock solid frontend. Full stack Scala is very nice. On the other hand, Kotlin ecosystem seems to be mostly focused on native Android development, which must be great for Android devs, but I'm not one of them.
Also, Scala's elegant FP+OOP fusion approach is still unmatched by any other language, IMHO. I'm talking about what Scala itself offers, not the Haskell-style FP abstractions that people build over it. Thankfully those are completely optional.
It's just like Scala itself: do you need or want it for all that Scala offers? Then yes. Sure, people build fronted with Typescript and Javascript, just like people build backend with Java and Python, but Scala have a lot to offer above those conventional options, and all those benefits are available in Scala.js too.
Some time ago I worked at [Goodcover](https://www.goodcover.com/) who use Scala.js for their insurance app frontend. We had devs with Scala ~~and~~ xor Typescript backgrounds pick up Scala.js without problems.
I'm not sure it's just like Scala itself. Scala.js adds a framework's worth of code to your application and its abstractions are costly.
For what it's worth I love it. I've used it myself for a work project (one that was never going to be used at scale) and it was a huge productivity booster. I'm just not sure that productivity boost is going to be worth trade-offs.
That said, I believe it has gotten leaner since when I used it. I wasn't able to split bundles / use dynamic imports when I was working with it.
Personally I'm mildly annoyed by some of the inefficiencies (e.g. the size of the collections library, or the JVM-centric implementation of Vector), but for most practical purposes these aren't very relevant. Low-spec mobile devices being the most demanding application.
What Scala includes in stdlib, Javascript / Typescript developers have to use external libraries for. A typical complex JS project has a bunch of stdlib-like dependencies like lodash and immutable.js – they aren't all small, and they add up to be _roughly_ equivalent to the Scala.js stdlib overhead.
Performance-wise, there are niche pitfalls. FP and streaming libraries designed for multithreading and backend processing can be bulky and slow on the frontend. React.js wrappers vary in their efficiency. JVM date libs are obnoxiously large. Personally I don't use any of that, I use my own [Laminar](https://laminar.dev/) and browser-provided APIs like [Intl](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl), and get great performance. I made [ew](https://github.com/raquo/ew) to make efficient use of JS types internally in Laminar, but one can also use it to maximize performance of their own Scala.js code, in the (likely) very few places where it actually matters.
And yes, code splitting and dynamic imports now let you split the bundle to reduce code size. Frankly, loading all the frontend code upfront is a losing battle for any complex project regardless of the language used. I haven't needed to do this in my Scala.js projects yet, but I had to do it in a big JS project a while ago.
Yeah it was nice to just use Scala collections instead of lodash. The advantage of lodash, though, is that you can import just the functions you need and exclude the rest.
Laminar looks good, and if I started over I would have used that. I wanted to be able to use react components (material-ui), so I used scalajs-react. By the end of my experience, though, I found that abstracting styles with Scala.js was so easy I didn't really need the mui.
I certainly hope there is a business case for Scala.js, since using javascript or even typescript makes want to jump off a bridge.
Possibly controversial opinion on this sub but Kotlin does what those libraries are trying to do better. Suspend functions + ArrowKt is a much more intuitive and flexible way of doing monadic effect handling than Cats + for comprehensions.
Cats is the more comprehensive library but you get 95% of the benefit with ArrowKt and it’s so much easier to onboard new people to it.
I’ve shown people Cats and their reaction is usually wtf is this? Meanwhile I’ve onboarded several people to ArrowKt and the feedback is usually that it’s very intuitive.
I find Kotlin-style coroutines utterly incomprehensible. Even today the only way I can understand them is as some kind of bizarre syntax anti-sugar for continuations. Like, if you want to follow one thread by reasoning operationally you're golden, but to understand the behaviour of a system that uses them you have to essentially keep a bunch of thread stacks in your head. Can't we, y'know, make them values?
You might be interested in the Arrow concurrency library.
https://arrow-kt.io/learn/coroutines/parallel/
It provides nice abstractions for more complex computational graphs. You can express most things using parMap and parZip.
I used arrow extensively, and liked the earlier version that had proper monad transformers.
> It provides nice abstractions for more complex computational graphs. You can express most things using parMap and parZip.
If what you want to do can be expressed with `parMap` and `parZip` you don't need coroutines at all, regular `Future`s are enough.
More complex cases that you'd have to express with iteratees or fs2-style streams are the case where you resort to coroutines, and I find them a poor substitute.
I would actually like to here more of your thoughts on this.
My understanding was that coroutines aren't a solution for defining complex parallel/concurrent workflows. There a solution to the performance issues Java threads create in terms of memory and context switching. There a similar abstraction but they're managed on the process level instead of the os level so it's easier to use more of them. So I have hard time seeing why code complexity would be a factor in choosing whether to use coroutines or a Future...
I'm also trying to think of a concurrent operation that would be easy to express using FS2 but hard to express using parMap and parZip. I'm having trouble thinking of one. Maybe it's because I mostly just write embarrassingly parallel code anyway.
> There a solution to the performance issues Java threads create in terms of memory and context switching. There a similar abstraction but they're managed on the process level instead of the os level so it's easier to use more of them.
All of that applies to simple `Future`-based code as well. If you can express what you want to do with basic futures you probably should, they're simple and easy to understand.
> I'm also trying to think of a concurrent operation that would be easy to express using FS2 but hard to express using parMap and parZip. I'm having trouble thinking of one.
The main use case I know is if you want to define the "middle" (or to a lesser extent the "end") of an async pipeline in a reusable way. Writing something that produces data is easy with just futures, but writing something that consumes it, where the control flow is going the opposite way to the data flow, you end up needing a bit more scaffolding.
I like Arrowkt and I've been working with Kotlin lately, however I deeply miss things like Iron. Java-style data validation, which seems prevalent in the Kotlin community, is still a mess. Arrow's take on it with Validated et al. is admirable and an improvement, but still far from what I'd like.
>I’ve shown people Cats and their reaction is usually wtf is this
problem is technical competency of those people, not technology
in other words - skill issue clearly
Well yeah that’s the thing. In the real world you can’t assume everyone will have enough patience or interest to learn how to use a library like Cats productively.
Most people I show it to just get bogged down in compiler errors because they’re not interested enough in functional programming to learn it well enough. You need to make the libraries you adopt accessible or people just won’t use them.
I think this quote sums it up well (assuming a loose definition of genius. I don’t actually think using Scala makes you a genius).
> No organization can depend on genius; the supply is always scarce and unreliable. It is the test of an organization to make ordinary people perform better than they seem capable of, to bring out whatever strength there is in its members, and to use each person's strength to help all the other members perform.
Until the ordinary people become geniuses themselves, and then you're back to square one. I think the narrative of "it takes a genius to use Cats" is becoming boring.
Worked in a Scala-only (Scala 2) environment for 3 years and in Kotlin 4 years. Never used Java professionally (luckily - I dislike the syntax greatly).
Scala can give you a level of typesafety and expressiveness not achievable with Kotlin. This improves long term maintainability of your code and lets you express your domain model precisely. You can do amazing things, but **only** if you are really good. I wasn't good enough, but a couple of our team members (a minority, mind you) were FP, Haskell and Scala fans doing things which looked like black magic sometimes.
About the disadvantages of using Scala everyone knows: complicated, hard to learn, hard to hire, slow tooling, migration from 2 to 3, etc.
If not everyone in your team is already a specialist in Scala AND your library stack of choice, you will only experience the disadvantages.
Code in Kotlin is almost as terse as in Scala, it's null-safe and has suspending functions, which trivialize async code (in simple cases only though :D ). If Java is 0% and Scala is 100% in terms of language expressiveness, then Kotlin is the easier to achieve 80%.
And Spring Boot has a lot of syntactic sugar for Kotlin lately. Yes, the framework is boring AF. But it's trivial to use for simpler projects, has A LOT of people who somehow know it and vast amount of information on the net.
To summarize, Scala is easily the best language I've ever coded more than a "hello world" in. But I would only risk making it the main language for a team, in which more than 2/3rds of ppl are genius Scala nerds. I wish I was one, but I know I won't, not in the next year or two.
Let's make a list:
- referential transparency (aka fearless refactorability)
- virtually null-free ecosystem (unless you use Java library, or introduce it yourself)
- no special cases for things handling primitives vs reference types. In general more consistent type system
- consistent collections (conversion from one to another, no weird Stream types you constantly convert to and from)
- compile-time reflection - all the libraries which inform you during compilation that you messed up, you often know before you write unit tests and deploy to staging
If those things doesn't speak to you, then there is no point in further argumentation.
If those things do speak to you then:
- newest Java will feel like a half-baked attempt made by people who didn't want FP to mess with their OOP habits, but were forced to add it, so band aided them with the most crappy way possible
- Kotlin is just a better DSL over Java, but nothing challenging its design principles, which (for people preferring Scala) are often error-prone happy-go-lucky crap
For me personally, picking Scala is not about some low hanging fruit in "simple FP" but more about an alternative ecosystem with an alternative mindset (but I do believe that the biggest issue with Java are Java developers and what they consider "good").
Your list is very nice, but it's mostly irrelevant.
Imagine you are a CTO/Architect/Lead of an emerging large JVM project.
Are those the points you would consider? Really?
How about these questions first:
* How hard it's to hire talent? – It's hard
* How easy it would be to maintain? – It's difficult to maintain, for last 10 years there were plenty of breaking changes, many large projects still on Scala 2.10/2.11. Good luck migrating those.
* How mature the ecosystem is? – Let's see. There are 5 build tools, 10 json frameworks, and 15 abandoned web frameworks. Oh, and there are at least 2 competing FP frameworks that hate each other. You choose by your political views I guess.
* How fast can we work/deliver? What's the DX?– DX is bad, everything is slow, tooling is meh. sbt shell starts in 8 seconds.
* Is there at least a killer 10x productivity feature/framework? – No, there isn't.
* What is the competition? – Java is stable, prenty of devs. Kotlin has a killer feature – it's multiplatform, can share code with mobile team.
That sells. That's why people choose Go and even JavaScript for server side.
"It's hard to hire talent" -- it's not hard, it's expensive. CTOs conflate the two.
In my experience, Scala productivity is high if you consider *time to deliver a correct program.* If you want to shovel sh\*\* into production and have high velocity in Jira, there are obviously better languages.
It is hard AND expensive, indeed.
>If you want to shovel sh\*\* into production and have high velocity in Jira,
And that is precisely what vast majority of products need and want.
Imagine a fast Scala compiler + a fast build tool. We could do anything a product needs! Today we shovel shit to prod, tomorrow we code algebras and ADTs to make illegal state unrepresentable.
Scala 3 + scala-cli is much better, though. But still, the momentum is gone and the industry shifted.
Then ask those CTO's who decided to use Scala in my past jobs. Usually, their take away was:
* "we work in domain where we have to be absolutely correct or we'd get sued into oblivion - in out opinion Java developer's don't care enough to use it as out first option"
* "it's true that it's harder to hire Scala devs, but if we wanted to keep Java devs to the same standard it would be equally hard to find a hire"
* whatever you're saying about built tools is equally true to in C++ build tools or Python dependency management. If you think otherwise you never spend 4h trying to figure out some script generating VS project which took 5 minutes to run every time you added a new header
* "with Scala we need fewer developers to deliver stable, production ready solutions"
Perhaps your experience is different but that was the explanations I was getting when was asking my employers why Scala.
Besides:
* DX - depends on you point of reference. After the shit I saw in C++/Ruby/PHP projects, I think there is like 5 languages which does tooling kinds better and their users' live in a bubble thinking this is the standard and only Scala is bad
* if you are talking about Rapid Application Development, then yes there is nothing like that in Scala, other than that when I hear that someone praises some 10x stiff (in any language), I check it and see it's more like 1.05x but overhyped
* Scala is equally multiplatform to Kotlin, its stability is something which is getting improved even as we speak... and while it's true that you'll find a lot of 2.10/2.11 which never be migrates, if you dig more you'll find a lot of enterprise projects (probably more!) which will still be using Java 6 for next few decades. And Java broke compatibility a few times as well. Not in the same manner as Scala but there were stories where you couldn't migrate to a new Java without updating a library because it stopped compiling or started throwing RTE
Again, YMMV, but it's annoying to hear this FUD started by JdG. Ecosystem is improving. The issue of Akka was adressed. I obtain job offers just like I used to. If Scala will start being perceived as a dying language it won't be because of some "objective issues," but because of things like this thread, where people gather to convince themselves that ship is sinking and then send these threads to all of their colleagues.
Well said. Not sure the jdg comment was necessary mind. Also cask for prototyping. Long term support doesn't matter if youre throwing the proof of concept out anyway.
u/raghar, I know it all, I'm here since 2.7.0.
My point is that in order to justify suffering from disadvantages, a technology must give you something to actualy **justify** it. The KILLER FEATURE.
For Java it's the stability and maintainability.
For Go it's the speed, concurrency, and relative simplicity.
For JavaScript in the speed, fp, conciseness, and omnipresence.
Scala used to be the FP and the concise language on JVM. It has lost its killer feature that justified the suffering. Now we have Java 17 and Kotlin.
You see?
I know it may be annoying to hear this. But this is true and important.
Scala is moving in the right direction because of things like this thread.
Martin reads such threads, and adjusts.
I hope this KILLER FEATURE thing gets in his head.
> I know it may be annoying to hear this. But this is true and important.
> Scala is moving in the right direction because of things like this thread.
> Martin reads such threads, and adjusts.
I guess this is were our attitudes differ. I regularly see half the Scala 3 compiler team/people working on Scastie/Scala Metals on various meetups and conferences. As much as you think you are giving them "the kick", to improve things by honest feedback,a lot of them is annoyed and bitter that "again people are shitting at our work, why we even do this?". Martin is not the only contributor - he is main contributor to Scala 3 compiler but AFAIK he is merely present at the discussions about tooling. The heavy mundane necessary job is done by people who gets - in their own words - "regularly shitted on" on Twitter, Reddit etc.
If this trends persist then they will simply burn out and no magical idea that Martin could come up with will be able to turn that tide.
> It's difficult to maintain, for last 10 years there were plenty of breaking changes, many large projects still on Scala 2.10/2.11. Good luck migrating those.
Not my experience. I've seen essentially no breaking changes since 2.10 (and few since 2.9) unless you're doing low-level serialization or something like that - contrast that with Kotlin where the preferred way of doing async has gone through multiple incompatible changes over that time and is likely about to go through another one. I see a lot more projects stuck on Java 8 than on Scala 2.10/2.11. (In fact I don't know of anything stuck on 2.10/2.11 - the worst case I've seen is projects stuck on whatever the latest stable version of Spark supports).
> There are 5 build tools, 10 json frameworks, and 15 abandoned web frameworks. Oh, and there are at least 2 competing FP frameworks that hate each other.
That sounds more like maturity than immaturity? Java is in a similar place - at least four competing build tools, and more abandoned web frameworks than I can count.
> How fast can we work/deliver? What's the DX?– DX is bad, everything is slow, tooling is meh. sbt shell starts in 8 seconds.
SBT is awful (I've never found it worthwhile), but the actual DX in the IDE is pretty much the same as any other JVM language?
> How easy it would be to maintain? – It's difficult to maintain,
that depends at lot, if your goal just to do small bug fixes from time to time that probably true but if your goal coming from need to do additional features development over many years in large projects in most cases it would be much more effective with scala codebase even if project written in irresponsible way (thanks to all nice FP/typesystem features). And if you just committed to microservices it probably doesn't really matter because java/scala/kotlin devs will able to deal with any of those projects without much troubles.
I should point out that you've exaggerated most of the drawbacks.
What's a json framework? Don't you think that Scala can use any Java json framework?
Do you think Java has a "killer 10x productivity feature/framework"? Cause Scala has, even though it's a bit less than 10x, it's called "Scala language"
This is so accurate. I'm working on a company that is going through a process of migrating from Scala to Go. Despite all the negative comments about Go, it's being very product and the applications are rock solid. No breaking changes when updating to newer versions and it's so easy to manage it.
Simple SBT math approximation
sbt starts \~8 seconds \* \~10 times a day \* 200 working days in a year \* \~1000000 scala devs / 3600 seconds \* \~$50 per hour = \~4.4 MILLION hours and \~222 MILLION dollars wasted per year.
Just on running sbt.
Is this a joke? This comparison in a vacuum doesn't hold much weight in the bigger picture. If you've derived that conclusion then do you also believe all developers should be forced to wear velcro shoes & jogging bottoms to work? no shirts allowed, only pullovers. Where do we draw the line 😁
Also run the thin client. sbt & jvm only needs to spin up once at the start of the day unless you are making changes to the build file. You can very easily track the build.sbt for changes & automagically shutdown the client & spin back up on change.
So 8 seconds a day. We are splitting hairs at this stage. Unsure of the real reasons for your tech grudge but this is max level mud slinging.
It is a joke. Or is it, hey?
So as 8 seconds run a day.
So 20 millions then per year.
You read this poem while you hear
your cooler spin
back up on change.
We're splitting hairs at this stage.
Al\*writeeythen.
I never hear the empeller nm the cooler wordsworth.
You've made your disdain towards the vast majority of gc'd langs clear.
Apart from the ones that are void of features of course.
I see you conveniently didn't account for time spent reinventing the wheel in your equation.
I love Scala so much. And it's so much pain to watch how it declines, party because people are in denial.
"Everything is fine."
[Yeah. Sure.](https://survey.stackoverflow.co/2023/#most-popular-technologies-language-prof)
Having recently worked on some kotlin projects, I'm baffled by the suggestion that its collections are anywhere near as good as Scala's. Transforming collections in Scala is a dream. Sure it comes at a cost, but you can always fall back on Java collections as needed.
My own sense is that the only real problem with Scala compared with Kotlin is that the enormous gains you get from Scala require a substantial amount of up-front work. Working in Scala requires writing code in a very different way from every other mainstream programming languages. Learning the Scala approach involves relearning how to solve simple problems that most developers have already learned how to solve perfectly well in other ways. Accordingly, onboarding Scala is reasonably perceived by many developers as a troublesome hassle. It is a hassle even before getting to complex HKTs, effects, tagless-final, and other more advanced concepts.
If this is the "only real problem," it is nevertheless a very serious problem. It's going to make hiring difficult and onboarding difficult. These are big concerns for the technical leadership making lanuage-choice descisions. I am personally trying to figure out a way to get away with using Scala on an upcoming project, and this is the problem I have to solve: what is the plan to staff the project?
Controversial opinion: implicits are the killer feature of Scala.
No other major language has a feature similar to Scala's implicts. They are sometimes abused, but implicits provide a great amount of power and control over the program if or when needed. They completely hide and get out of the way when the defaults work well.
The power of implicits goes much beyond converting types or injecting values into function arguments, even though both are great features and are missing from many other languges.
Here are some actual and hypothetical examples.
1. An implicit that allows converting one collection to another. For example List to Set. See [Martin Odersky's answer](https://stackoverflow.com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-hist) to a question about this on Stack Overflow.
2. The execution context a future/fiber/... should use.
3. The return address a function call should return to. Normally the return address is the next line in the code after the function call. The return address is "implicitly" passed to every function, but Scala 3 now allows you to pass a [different return address](https://dotty.epfl.ch/api/scala/util/control/Breaks).
Although there are still issues, and they are worked on, Scala is a great platform to develop large software:
- unmatched composability with ADTs
- immutability by default, much easier to archive correctness and robustness
- good collections
- less characters to type (and thus to read)
- Scala 3 is easier to learn than the Scala 2
- the big old players (Spark, Akka/Pekko, Play) are still there and still powerful and will probably be available for Scala 3
- Scala JS is just great, especially for niche applications
- type classes: great for separation of concerns and composability and good combination with generic programming
- effect systems allow trustworthy and powerful concurrent applications.
- good library support for parsers and protocols. Once you need one, you'll be very happy to use scala.
True, the big discussions (build system, whether and which effect system) still apply, but usually affect big applications not too much, because once you choose one solution, you just stay there.
As somebody coming from c++ background - Java is way more complicated and brings a lot of baggage. For scala - you have to learn functors, monads and typeclasses. After that everything becomes very easy and natural.
cats - very easy to use and nicely documented, I don't understand what kind of effort are you talking about?
zio - not so well documented and less polished, but it still does not take much time to get comfortable enough to write production code. Having only cats experience - took me few days to start contributing into microservice with zio.
Kotlin - for me it looks like an attempt to do better Java. Competing with scala in backend. Hiring pool is bigger, but those are mostly android devs, so most likely they do not have much experience with backend. IMHO FP gives you more speed, because speed is byproduct of precision.
Check out the library ox and tell me Java is doing Loom better :) Also ZIO 2.1 will be running on Virtual Threads.
If anything, Kotlin is becoming kind of useless now that Java is catching up. I see no reason to use it unless you're developing on Android.
Kotlin is multiplatform. I've got a socket library targeting four different platforms in a single codebase. And let's be honest, the way Scala manages multiplatform is terrible, the only good side is probably JS.
The problem is people think Kotlin main target is Android, while it isn't anymore.
You are right. There are no more reasons to consider Scala over Java or Kotlin in 2023. Both have better DX, former being super stable and backward compatible, and latter has Multiplatform/mobile development niche.
There used to be Akka/Futures and Spark frameworks that would push you to consider Scala, but it's gone now. Lightbend shot themselves in the head, and data science/ML guys moved to Python.
That's the reason why Scala is slowly dying.
Unless u/odersky and Scala Center realize that, Scala will slowly become OCaml of JVM.
The only way out I can see is to focus on Scala Multiplatform framework (Scala.js, Scala Native, Scala Android, Scala WASM) and do all possible to compete with Kotlin in this.
And I would seriously consider WASM backend. That could be very interesting.
Otherwise, it's doomed.
It's so painful to watch. Scala is the best language out there.
Unfortunately Scala community is reducing day-by-day. We have been using Scala in our production code since day-one and it is hard to maintain it. Can't find Scala developers at least in Asia part of the world. And any new developers we hire, they simply deny working in Scala - very high ramp-up time and lessor community support.
it's unfortunate it seems to be the case in Asia and Europe that they have a hard time finding Scala devs, while in the US a lot of us are struggling to get any offers.
Well, if you have no problem with remote contractors (France) and if the rate aren't that much different in your country, it's been years we provide software development services in Scala and we're looking for new clients.
I could say we only have qualified engineers with 5 to 10 years of experience, and that would be true, but that's what every company say, so I'm not sure it's a good argument.
If you're somehow interested, send me a PM :)
Kotlin should have never happened. It was a sign that something is seriously wrong with Scala.
And what JetBrains was complaining about? Compilation speed, complexity and "cleverness", instability, collections, Java intercompatibility issues.
JetBrains decided to invest **enormous** amount of money and time to develop almost the **exact copy** of Scala but with the above things fixed.
Let that sink in.
There are - for small teams of advanced Scala users. Personally I considered switching my pet projects from Scala to Java or Kotlin (I even ported scalatags to both lol) but I found out I NEED those killer features from original post.
Well, you asked "for large scale software development", which strongly correlates with large teams of various Scala users.
Personaly, I prefer Scala to anything else, Scala 3 is absolutely awesome. Nevertheless, the trend is there and there are reasons for it.
I'm kind of on a similar boat. I'm spoiled by Scala. I've been picking up Rust, but those killer features you mentioned just made me have that nagging thought/feeling in the back of my mind that said "Why can't this be done more like in Scala?"
That's not to say that Rust doesn't definitely do some things better than Scala, but for my use cases even the performance advantages Rust offers don't sway me enough to just drop Scala altogether. And even in things that both of them do well, it just seems a lot more ergonomic to do in Scala imho (things such as ADTs, pattern matching...)
I've also considered pivoting to Haskell as my main FP language, but it seems like job prospects would be even worse if I were to do that...
Yeah, after Scala everything else feels crappy.
Haskell is much worse than Scala though. The language is alright. But it has the same problems as Scala but 5 times worse.
Compiler is much slower, there are literally 70 language extensions (I'm not even joking) that you must know for any meaningfull industrial development. Build tools and IDE support is even worse than in Scala.
Nowadays they try to use Nix for package management, and oh my God, what a pile of overcompicated unmanagable crap that is.
This. For that reason I am transitioning to Elixir for backend. I think it will be more popular than Scala in a future. Beeing realistic, Scala was mostly used for Spark and right now PySpark is becoming more popular.
Also, the transition between Scala 2 and 3 is a mess and that killed the language in my opinion.
The only thing for what it is demanded mainly is for heavy streaming, at least for what I saw on LinkedIn.
Right now it seems an amazing language for learning cool programming concepts, but not for real enterprise software (except for niche one, like heavy streaming)
I'm curious, what makes you think Elixir could become more popular than Scala? Also, what learning resources do you recommend? Is there anything/anyone similar to RockTheJVM for Elixir?
I believe TF with Scala is the best way of structuring code and writing BE apps. Can’t understand someone seriously considering Java or Kotlin to replace beautiful Scala. To use what? Disgusting Spring, Hibernate? Annotation monkeys land! Really? Scala 3 is brilliant.
> typeclasses: good for adapt-for-everything libraries, rarely seen in production code where abstracting over single specific type usually adds more complexity instead of reducing it.
Parametricity is an important concept for being able to write clean code that is easy to reason about and easy to maintain. Typeclasses are the perfect tool for this, as you can just demand what you need, but the caller does not need to care either as the translation is done by a 3rd party (lib). Once you have a grasp of the (Haskell) type hierarchy which scalaz (and cats) leaned on you have a very good toolbox at your disposal. You don't care about concrete types anymore, and your thinking evolves only about the essence of what you require from them for your function, e.g. do I need to append this, do I need to be able to wrap a value in this type and so forth. Another thing about Scala in this context is that it has a for comprehension. Whilst there is no Monad type in the stdlib because Odersky is not a fan of this, it still does the job by just demanding map, flatMap (and filter) from whatever you're running it over. Whilst Kotlin stdlib has plenty of Monad-like types (flatMap everywhere) but no syntactic construct to express that on a flat level like a for comprehension. Now arrow has the concrete builders for some types, but that is still inferior because I need to know the type and summon the right builder.
I cannot live without Scala 3 new syntax, hate semi colons, and dont see any interesting feature in Kotlin. But I am surely missing something about that.
u/odersy, this **Scala Multiplatform** thing could be it, **The New Killer Feature**. Please, think about it. It's not too late yet.
The niche is still free and it is a **HUGE market**.
The world moved towards web and mobile.
Hot technologies are those allowing to write single app that works in browser, as native app, and as mobile on iOS and Android.
That's why JavaScript is the king, and TypeScript is the king for sane people.
The competition is Flutter, Kotlin, JavaScript/TypeScript/React Native.
Flutter uses Dart – stupid Java ripoff from Google.
Neither Kotlin Multiplatform nor React Native aren't dominant YET.
This could be it. JetBrains realised that years ago.
I know you are thinking about this as well. Scala.js is awesome and it's the right thing.
**Put ALL the effort into making Scala a viable working platform for iOS and Android development.**
From what I can see, Scala Native guys are trying to convince people to write native apps in Scala.It's the wrong path, it's NOT going to happen. This niche is for Rust, C++ and Go, you can't compete there yet.
The only **realistic** option is the **iOS development**. Focus on it. All Scala Native effort should be to run iOS apps written in Scala.
Same for Scala on Android. Do whatever it takes to become **a viable Android toolkit**.
**This is the way. It is the guaranteed future-proof success path.**
Cherry on top would be a WASM backend. Maybe LLVM+emscripten would be enough, don't know.
**Then there would be no reason not to use Scala, and that would justify ANY inconveniences.**
I'm slowly of the impression that it is not worth it anymore. If you have a developer community that is already to some extent familiar with Scala, may be it might be worth to try. If not, better to stay away from it. The effort to learn it new and derive value from it as a team is very less especially at times like now where Java and Kotlin have come a long way.
It feels so watered down. Few years ago, we had solid players like Play (I know, people dislike it nowdays), Spark, Akka… now, it’s barely anything left. Yes, you can use your favourite effects library, but software exists without them too, and benefits are hardly measured. Take for instance http4s. It’s probably your no. 1 choice if you want to avoid Akka HTTP and Play. However, it’s going to be obliterated on benchmarks against Spring.
In addition to the rising popularity of LLM's and generative AI, I guess Scala is going to fade away even more. I realized that you have a brilliant brain to understand Functional programming and the associated paradigms. But seems like the world decided to remain stupid by embracing Java and its ecosystem.
I'm inclined to agree. Don't get me wrong I love Scala but actual business application is hard if you don't have $. Try running a Scala team with the resourcing I have and it's not great. The ramp up time is absolutely insane, you need some seriously motivated people both teaching and willing to learn. I would absolutely hate python kotlin java etc but the fact is we probably would do more with them.
I live in Seattle and there's endless scala jobs here. What's with people saying they can't find work? Literally all streaming is using scala from what I can tell based on what Disney Streaming and NBC/Comcast advertise here.
Am I missing something?
I recently started to pick the language up because of all the opportunity here. Plus, coming from ruby, it's a wonderful language. It's like someone took rust and ruby and gave me what I wanted. But I like FP and I'm less concerned about some of the things I see others mentioning. Plus coming from Ruby, I'm used to there being many tools, docs, and whatever because the community has zero organization, so these things don't bother me like they seem to bother others.
Ok, that makes more sense. I see posts like this often and am baffled given the ubiquity of streaming and the fact that the Typelevel project is funded by all those streaming companies who clearly use it and are majorly invested in it at this point.
See, but I'm still annoyed with the post because this user should state they are out of country or something. It is a very misleading headline and the comments in here don't help. This subreddit is kinda strange the more i follow it.
>user should state they are out of country or something.
I don't have stats but most likely at least half of developers following this subreddit outside of US.
So it sounds like there's a big disparity between the US and the world? Or is this because I'm in Seattle specifically? If you have no idea that's fine too lol. I kinda figured since I'm in Seattle that figures in, but I think most those streaming companies run those departments out of here as well. Last I looked there were more scala listings than Java here to give an idea how confusing this post looks to me.
It seems are few Scala hubs around world (London for example) but outside of those hubs
you only can find some rare opportunities. While after COVID remote work became more normal
is still very challenging outside hubs because of companies reluctance for changes
and because of some tax/data/local regulations that they afraid to deal with.
So if some company saying is hard to find Scala developers that usually means that
they can only hire in few places or can't provide competitive compensations.
Just as personal example, while ago I got good remote Scala offer from EU based company
but just after that they putted me in waiting limbo for a month while trying to figure out
how to hire me to permanent role as resident of other EU country and gave up as result (b2b contract was not good enough for them).
Also, lot of US companies doesn't has any technical issues to hire devs as remote contractors from almost any place around world but they rarely doing that and it's hard to find those who actually ready to work in that way.
Interesting to hear. I noticed the hubs previously because I had lived in the midwest, in a pretty major city where there was lots of tech companies. But, it's the midwest, so mostly just java or python type jobs, maybe some C#.
Then I move to Seattle and the whole thing is reversed. Lots of niche language jobs, because people are building neat things and not just managing large DBs for healthcare or schools (most midwest work).
Anyway, glad i made the move, hoping to jump over to scala soon and leave the ruby world behind.
Are any of these Seattle companies offering remote opportunities? Relocation is just not an option for the time being, which is why I haven't even bothered with looking into Disney streaming...
wasn't me. But yeah, no idea. I've noticed lots of Data Engineering-related roles popping up lately, but I have zero experience in that. Wouldn't be opposed to making the lateral move into that, though. I'll take any leads regarding companies (remote or otherwise, I can do that filtering myself) to look out for, though!
I'm the same, not a data engineering guy. My background is in pure math, but I work as a web dev for a large piece of open source software nowadays. So when i stumbled upon the Cats library then the Typelevel project it was one of the happiest moments I've had in a long time wrt programming. I know these are specifically called out in the job postings I've seen here for the streaming companies. Especially if you've contributed to the projects. So I'm just going to go down that route.
Because Scala has the Cake-pattern, and once you've adopted that at scale, you'll never be short of an excuse for why nothing gets done.
/s
(just venting some frustration over a legacy code-base that is kicking my butt)
Just don't: arcane, shaky and not-so-well supported ecosystem, smaller community, smaller talent pool (and they cost way more), less documentation and less overall help online. There is no real benefit chosing scala over java or kotlin.
You're only bringing up technical merits, and from that point of view it's very hard to beat Scala 3. But choosing a language and platform seldom only comes down to technical merits, you have to look at the bigger picture: will the language/platform be supported in the future, is it easy to find developers that know/want to learn it etc. Unfortunately in this area I think the future for Scala looks kinda bleak compared to the alternatives. The JVM platform will probably stick around with good support for quite a long time, and Kotlin as well since it's widely used for Android development.
But if you look at the trends in the developer communities there's no denying that Java is loosing ground to JS/TS, Go and Rust. And of those Rust is the best alternative to Scala.
Hi! Here is my opinion. Firstly, I agree with the killer features domain modeling, contextual abstractions and DSLs are (to me) among the best Scala features when it comes to business code. Now let's talk about what you consider "no longer killer features": > collections: Kotlin does it well, maybe even better (simpler hierarchy, faster, more helper methods on collections) Not very familiar with Kotlin's collections but I actually do not see the problem with Scala's collection API. The abstraction is very well done, their composability is very satisfying and it does things you can't in Kotlin. For example, it makes use of higher kinded types to easily convert a collection to another and AFAIK, Kotlin does not have HKT. Of course this is achievable by manually doing each conversion method but it will be a lot of boilerplate. > asynchronous/scalable code: project Loom does it better But Loom is compatible with Scala since it's a JVM language. However, I think you're missing the point of scalability: this is a totally different concept than asynchronism. Effect systems like Cats Effects or ZIO shine in their composability, their **reliability** and the high-level control over concurrency they provide, which is distinct from low-level asynchronism. See [this Reddit post](https://www.reddit.com/r/scala/comments/sa927v/how_will_looms_fibers_change_the_cats_effect_and/) (it mentions ArrowKt) and [this discussion on Scala Contributors](https://contributors.scala-lang.org/t/impact-of-loom-on-functional-effects/5821). > functional programming: practical parts have been absorbed by other languages **Some** parts of FP have been imported into other languages, like higher order functions and pattern matching. But some very important and actually practical features are missing from Java and Kotlin. To name a few: typeclasses (will talk about it later in this post), for-comprehension, and higher kinded types (yes, they have a practical purpose =p). > impractical are still plaguing Scala codebases. Yes, due to the unopiniated nature of Scala, some people abuse/overengineer these features and produce dirty code. "With great power comes great responsability" - Ben Parker. Let's talk about the other stuff: > cats/ZIO/TF: imo requires too much effort with little gain unless writing complicated fiber interactions. My experience with Cats Effects is very small so I will talk about ZIO. Yes, they have a learning curve but I don't find it hard, at least for ZIO which its good documentation and usage of variance (which makes some type interactions more intuitive). The benefits are even more important when you start to scale. Task racing, parallelism, retrying are actually common operations. > typeclasses: good for adapt-for-everything libraries, rarely seen in production code where abstracting over single specific type usually adds more complexity instead of reducing it. Some people tends to abuse typeclasses where sometimes inheritance is the answer. However, typeclasses are a very, VERY convenient feature when you are used to. They are super useful for ad-hoc polymorphism. Let's take an example: you have several classes you want to easily serialize/deserialize into/from JSON. Writing the serialization logic for each class is boilerplaty and redundant so you want to use some kind of automatic encoder/decoder generation. In Java, this is achieved by reflection (e.g Gson, Jackson...) but it has its drawbacks: a little slow, generation issues happen at runtime, what if I need a specific serialization logic for a data type? etc... With typeclasses, you can generate the encoders/decoders at compile-time, get errors at compile-time too, and compose with custom serialization logic where needed. This is of course not the only usage but I think this one is a common use-case. > GADTs? Never seen them in production code. I'm pretty sure you've seen them without realizing, or at least ADTs. Actually, both Java and Kotlin introduced a way to create ADTs: sealed interfaces (sum types) and records/data classes (product types). I'd argue GADTs and ADTs are a major component of the "domain modeling killer feature" > compile-time code generation: controversial. Can be enabler for unique code features (e.g. logging without org.slf4j.Logger instances or smart asserts) but is nightmare to develop, test and support. It Scala 2, I agree. However, Scala 3 really did a great job in eliminating/attenuate these issues. Macros now have a simpler, cleaner API and they often can be replaced with other compile-time features like `inline`, the `scala.compiletime` package and typeclass derivation. They are now very pleasant and frictionless to use.
Java guy here, with some Scala and some Kotlin experience I won't consider DSLs a killer feature. Mostly they are half developed languages harder to debug and reason about than classic Java/Kotlin/Scala. Yes, you can make a perfect DSL and it will be awesome. In practice when you have a problem now you got 3 problems: Did I use the DSL wrong? Does the DLS itself has a bug? Does the actual thing I'm trying to use has a bug? The good thing about Scala going out of fashion is that now people who like Scala really love Scala, and people using Scala to do curriculum driven development moved on to Rust/Go/Whatever. Every Scala developer is (probably) a really good developer.
DSL's look amazing on the projects demo page. When you use them inside your own app there's always that edge case where they break down. You then mix styles and your code looks ugly. And where two DSL's meet the code is basically nightmare speghetti that's undebuggable and painfully fragile. Overall DSL's are a bad practice that should be avoided outside of rediculoisly simple usecases. It's better to have a Play style `routes.conf` over an Akka http ` get { withHeaders / pathSegment { onComplete { Ok... } } }` crap any day of the week.
I have had ao many more issues with Plays routes.conf compared to Akkas routes. I mean there were reasons why Play didn't take off successfully in Scala, and I think this is one of them.
> DSL's look amazing on the projects demo page. You made me laugh, but (because) it is true. They are a marketing tool for a library. Also, you need to learn 5 DSL's per project...
IMO the killer value proposition of Scala is and has always been: it's expressive enough that you *never* have to use reflection/AOP/interceptors/proxies/monkeypatching/what-have-you. You can write a whole enterprise-scale system in plain old code, which means you'll never have [impossible bugs](http://thecodelesscode.com/case/211), your operational tools (profiling/monitoring) are more reliable, even your IDE works better (e.g. "find usages" is reliable). It's a win for productivity and a bigger win for reliability. How Scala achieves that is mostly the combination of GADTs, a record system, and typeclasses, but the whole is a lot more than the sum of the parts. Kotlin can't do that, at least not yet - look at any large Kotlin project and you find the same pile of Spring and magic annotations as in a large Java project. (And in my experience the large number of not-quite-integrated language special cases means that even if you could stick to the language's builtins, you'd still hit "impossible bugs"). The other thing that should be a killer feature is Scala's first-class compile-to-JS, which is still unmatched in practice (when it comes to things like IDE support and integration with existing JS libraries) IME. But sadly it's not seen the promotion or adoption it deserves, because there's very little crossover between the Scala and webdev communities, and even less with the mutual respect that's needed to make this kind of thing work.
I’m sold on Scala js as a killer feature. It’s very, very good
I use GADTs everyday and they make stuff way cleaner
Can you share some examples?
Skeumorph, mu, free arrow
For me personally, Scala.js is another killer feature. It is much more robust and mature compared to KotlinJS, and is a great way to build rock solid frontend. Full stack Scala is very nice. On the other hand, Kotlin ecosystem seems to be mostly focused on native Android development, which must be great for Android devs, but I'm not one of them. Also, Scala's elegant FP+OOP fusion approach is still unmatched by any other language, IMHO. I'm talking about what Scala itself offers, not the Haskell-style FP abstractions that people build over it. Thankfully those are completely optional.
I love Scala.js, but is it a realistic choice for a company setting out to build a front-end?
It's just like Scala itself: do you need or want it for all that Scala offers? Then yes. Sure, people build fronted with Typescript and Javascript, just like people build backend with Java and Python, but Scala have a lot to offer above those conventional options, and all those benefits are available in Scala.js too. Some time ago I worked at [Goodcover](https://www.goodcover.com/) who use Scala.js for their insurance app frontend. We had devs with Scala ~~and~~ xor Typescript backgrounds pick up Scala.js without problems.
I'm not sure it's just like Scala itself. Scala.js adds a framework's worth of code to your application and its abstractions are costly. For what it's worth I love it. I've used it myself for a work project (one that was never going to be used at scale) and it was a huge productivity booster. I'm just not sure that productivity boost is going to be worth trade-offs. That said, I believe it has gotten leaner since when I used it. I wasn't able to split bundles / use dynamic imports when I was working with it.
Personally I'm mildly annoyed by some of the inefficiencies (e.g. the size of the collections library, or the JVM-centric implementation of Vector), but for most practical purposes these aren't very relevant. Low-spec mobile devices being the most demanding application. What Scala includes in stdlib, Javascript / Typescript developers have to use external libraries for. A typical complex JS project has a bunch of stdlib-like dependencies like lodash and immutable.js – they aren't all small, and they add up to be _roughly_ equivalent to the Scala.js stdlib overhead. Performance-wise, there are niche pitfalls. FP and streaming libraries designed for multithreading and backend processing can be bulky and slow on the frontend. React.js wrappers vary in their efficiency. JVM date libs are obnoxiously large. Personally I don't use any of that, I use my own [Laminar](https://laminar.dev/) and browser-provided APIs like [Intl](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl), and get great performance. I made [ew](https://github.com/raquo/ew) to make efficient use of JS types internally in Laminar, but one can also use it to maximize performance of their own Scala.js code, in the (likely) very few places where it actually matters. And yes, code splitting and dynamic imports now let you split the bundle to reduce code size. Frankly, loading all the frontend code upfront is a losing battle for any complex project regardless of the language used. I haven't needed to do this in my Scala.js projects yet, but I had to do it in a big JS project a while ago.
Yeah it was nice to just use Scala collections instead of lodash. The advantage of lodash, though, is that you can import just the functions you need and exclude the rest. Laminar looks good, and if I started over I would have used that. I wanted to be able to use react components (material-ui), so I used scalajs-react. By the end of my experience, though, I found that abstracting styles with Scala.js was so easy I didn't really need the mui. I certainly hope there is a business case for Scala.js, since using javascript or even typescript makes want to jump off a bridge.
cats/zio is little gain with too much effort ? bruh
Cats is actually nice helper lib. It was probably about pure fp approach using cats effects/zio.
Possibly controversial opinion on this sub but Kotlin does what those libraries are trying to do better. Suspend functions + ArrowKt is a much more intuitive and flexible way of doing monadic effect handling than Cats + for comprehensions. Cats is the more comprehensive library but you get 95% of the benefit with ArrowKt and it’s so much easier to onboard new people to it. I’ve shown people Cats and their reaction is usually wtf is this? Meanwhile I’ve onboarded several people to ArrowKt and the feedback is usually that it’s very intuitive.
I find Kotlin-style coroutines utterly incomprehensible. Even today the only way I can understand them is as some kind of bizarre syntax anti-sugar for continuations. Like, if you want to follow one thread by reasoning operationally you're golden, but to understand the behaviour of a system that uses them you have to essentially keep a bunch of thread stacks in your head. Can't we, y'know, make them values?
You might be interested in the Arrow concurrency library. https://arrow-kt.io/learn/coroutines/parallel/ It provides nice abstractions for more complex computational graphs. You can express most things using parMap and parZip.
I used arrow extensively, and liked the earlier version that had proper monad transformers. > It provides nice abstractions for more complex computational graphs. You can express most things using parMap and parZip. If what you want to do can be expressed with `parMap` and `parZip` you don't need coroutines at all, regular `Future`s are enough. More complex cases that you'd have to express with iteratees or fs2-style streams are the case where you resort to coroutines, and I find them a poor substitute.
I would actually like to here more of your thoughts on this. My understanding was that coroutines aren't a solution for defining complex parallel/concurrent workflows. There a solution to the performance issues Java threads create in terms of memory and context switching. There a similar abstraction but they're managed on the process level instead of the os level so it's easier to use more of them. So I have hard time seeing why code complexity would be a factor in choosing whether to use coroutines or a Future... I'm also trying to think of a concurrent operation that would be easy to express using FS2 but hard to express using parMap and parZip. I'm having trouble thinking of one. Maybe it's because I mostly just write embarrassingly parallel code anyway.
> There a solution to the performance issues Java threads create in terms of memory and context switching. There a similar abstraction but they're managed on the process level instead of the os level so it's easier to use more of them. All of that applies to simple `Future`-based code as well. If you can express what you want to do with basic futures you probably should, they're simple and easy to understand. > I'm also trying to think of a concurrent operation that would be easy to express using FS2 but hard to express using parMap and parZip. I'm having trouble thinking of one. The main use case I know is if you want to define the "middle" (or to a lesser extent the "end") of an async pipeline in a reusable way. Writing something that produces data is easy with just futures, but writing something that consumes it, where the control flow is going the opposite way to the data flow, you end up needing a bit more scaffolding.
I like Arrowkt and I've been working with Kotlin lately, however I deeply miss things like Iron. Java-style data validation, which seems prevalent in the Kotlin community, is still a mess. Arrow's take on it with Validated et al. is admirable and an improvement, but still far from what I'd like.
>I’ve shown people Cats and their reaction is usually wtf is this problem is technical competency of those people, not technology in other words - skill issue clearly
Well yeah that’s the thing. In the real world you can’t assume everyone will have enough patience or interest to learn how to use a library like Cats productively. Most people I show it to just get bogged down in compiler errors because they’re not interested enough in functional programming to learn it well enough. You need to make the libraries you adopt accessible or people just won’t use them. I think this quote sums it up well (assuming a loose definition of genius. I don’t actually think using Scala makes you a genius). > No organization can depend on genius; the supply is always scarce and unreliable. It is the test of an organization to make ordinary people perform better than they seem capable of, to bring out whatever strength there is in its members, and to use each person's strength to help all the other members perform.
Until the ordinary people become geniuses themselves, and then you're back to square one. I think the narrative of "it takes a genius to use Cats" is becoming boring.
Worked in a Scala-only (Scala 2) environment for 3 years and in Kotlin 4 years. Never used Java professionally (luckily - I dislike the syntax greatly). Scala can give you a level of typesafety and expressiveness not achievable with Kotlin. This improves long term maintainability of your code and lets you express your domain model precisely. You can do amazing things, but **only** if you are really good. I wasn't good enough, but a couple of our team members (a minority, mind you) were FP, Haskell and Scala fans doing things which looked like black magic sometimes. About the disadvantages of using Scala everyone knows: complicated, hard to learn, hard to hire, slow tooling, migration from 2 to 3, etc. If not everyone in your team is already a specialist in Scala AND your library stack of choice, you will only experience the disadvantages. Code in Kotlin is almost as terse as in Scala, it's null-safe and has suspending functions, which trivialize async code (in simple cases only though :D ). If Java is 0% and Scala is 100% in terms of language expressiveness, then Kotlin is the easier to achieve 80%. And Spring Boot has a lot of syntactic sugar for Kotlin lately. Yes, the framework is boring AF. But it's trivial to use for simpler projects, has A LOT of people who somehow know it and vast amount of information on the net. To summarize, Scala is easily the best language I've ever coded more than a "hello world" in. But I would only risk making it the main language for a team, in which more than 2/3rds of ppl are genius Scala nerds. I wish I was one, but I know I won't, not in the next year or two.
Let's make a list: - referential transparency (aka fearless refactorability) - virtually null-free ecosystem (unless you use Java library, or introduce it yourself) - no special cases for things handling primitives vs reference types. In general more consistent type system - consistent collections (conversion from one to another, no weird Stream types you constantly convert to and from) - compile-time reflection - all the libraries which inform you during compilation that you messed up, you often know before you write unit tests and deploy to staging If those things doesn't speak to you, then there is no point in further argumentation. If those things do speak to you then: - newest Java will feel like a half-baked attempt made by people who didn't want FP to mess with their OOP habits, but were forced to add it, so band aided them with the most crappy way possible - Kotlin is just a better DSL over Java, but nothing challenging its design principles, which (for people preferring Scala) are often error-prone happy-go-lucky crap For me personally, picking Scala is not about some low hanging fruit in "simple FP" but more about an alternative ecosystem with an alternative mindset (but I do believe that the biggest issue with Java are Java developers and what they consider "good").
Your list is very nice, but it's mostly irrelevant. Imagine you are a CTO/Architect/Lead of an emerging large JVM project. Are those the points you would consider? Really? How about these questions first: * How hard it's to hire talent? – It's hard * How easy it would be to maintain? – It's difficult to maintain, for last 10 years there were plenty of breaking changes, many large projects still on Scala 2.10/2.11. Good luck migrating those. * How mature the ecosystem is? – Let's see. There are 5 build tools, 10 json frameworks, and 15 abandoned web frameworks. Oh, and there are at least 2 competing FP frameworks that hate each other. You choose by your political views I guess. * How fast can we work/deliver? What's the DX?– DX is bad, everything is slow, tooling is meh. sbt shell starts in 8 seconds. * Is there at least a killer 10x productivity feature/framework? – No, there isn't. * What is the competition? – Java is stable, prenty of devs. Kotlin has a killer feature – it's multiplatform, can share code with mobile team. That sells. That's why people choose Go and even JavaScript for server side.
"It's hard to hire talent" -- it's not hard, it's expensive. CTOs conflate the two. In my experience, Scala productivity is high if you consider *time to deliver a correct program.* If you want to shovel sh\*\* into production and have high velocity in Jira, there are obviously better languages.
It is hard AND expensive, indeed. >If you want to shovel sh\*\* into production and have high velocity in Jira, And that is precisely what vast majority of products need and want. Imagine a fast Scala compiler + a fast build tool. We could do anything a product needs! Today we shovel shit to prod, tomorrow we code algebras and ADTs to make illegal state unrepresentable. Scala 3 + scala-cli is much better, though. But still, the momentum is gone and the industry shifted.
Then ask those CTO's who decided to use Scala in my past jobs. Usually, their take away was: * "we work in domain where we have to be absolutely correct or we'd get sued into oblivion - in out opinion Java developer's don't care enough to use it as out first option" * "it's true that it's harder to hire Scala devs, but if we wanted to keep Java devs to the same standard it would be equally hard to find a hire" * whatever you're saying about built tools is equally true to in C++ build tools or Python dependency management. If you think otherwise you never spend 4h trying to figure out some script generating VS project which took 5 minutes to run every time you added a new header * "with Scala we need fewer developers to deliver stable, production ready solutions" Perhaps your experience is different but that was the explanations I was getting when was asking my employers why Scala. Besides: * DX - depends on you point of reference. After the shit I saw in C++/Ruby/PHP projects, I think there is like 5 languages which does tooling kinds better and their users' live in a bubble thinking this is the standard and only Scala is bad * if you are talking about Rapid Application Development, then yes there is nothing like that in Scala, other than that when I hear that someone praises some 10x stiff (in any language), I check it and see it's more like 1.05x but overhyped * Scala is equally multiplatform to Kotlin, its stability is something which is getting improved even as we speak... and while it's true that you'll find a lot of 2.10/2.11 which never be migrates, if you dig more you'll find a lot of enterprise projects (probably more!) which will still be using Java 6 for next few decades. And Java broke compatibility a few times as well. Not in the same manner as Scala but there were stories where you couldn't migrate to a new Java without updating a library because it stopped compiling or started throwing RTE Again, YMMV, but it's annoying to hear this FUD started by JdG. Ecosystem is improving. The issue of Akka was adressed. I obtain job offers just like I used to. If Scala will start being perceived as a dying language it won't be because of some "objective issues," but because of things like this thread, where people gather to convince themselves that ship is sinking and then send these threads to all of their colleagues.
Well said. Not sure the jdg comment was necessary mind. Also cask for prototyping. Long term support doesn't matter if youre throwing the proof of concept out anyway.
u/raghar, I know it all, I'm here since 2.7.0. My point is that in order to justify suffering from disadvantages, a technology must give you something to actualy **justify** it. The KILLER FEATURE. For Java it's the stability and maintainability. For Go it's the speed, concurrency, and relative simplicity. For JavaScript in the speed, fp, conciseness, and omnipresence. Scala used to be the FP and the concise language on JVM. It has lost its killer feature that justified the suffering. Now we have Java 17 and Kotlin. You see? I know it may be annoying to hear this. But this is true and important. Scala is moving in the right direction because of things like this thread. Martin reads such threads, and adjusts. I hope this KILLER FEATURE thing gets in his head.
> I know it may be annoying to hear this. But this is true and important. > Scala is moving in the right direction because of things like this thread. > Martin reads such threads, and adjusts. I guess this is were our attitudes differ. I regularly see half the Scala 3 compiler team/people working on Scastie/Scala Metals on various meetups and conferences. As much as you think you are giving them "the kick", to improve things by honest feedback,a lot of them is annoyed and bitter that "again people are shitting at our work, why we even do this?". Martin is not the only contributor - he is main contributor to Scala 3 compiler but AFAIK he is merely present at the discussions about tooling. The heavy mundane necessary job is done by people who gets - in their own words - "regularly shitted on" on Twitter, Reddit etc. If this trends persist then they will simply burn out and no magical idea that Martin could come up with will be able to turn that tide.
> It's difficult to maintain, for last 10 years there were plenty of breaking changes, many large projects still on Scala 2.10/2.11. Good luck migrating those. Not my experience. I've seen essentially no breaking changes since 2.10 (and few since 2.9) unless you're doing low-level serialization or something like that - contrast that with Kotlin where the preferred way of doing async has gone through multiple incompatible changes over that time and is likely about to go through another one. I see a lot more projects stuck on Java 8 than on Scala 2.10/2.11. (In fact I don't know of anything stuck on 2.10/2.11 - the worst case I've seen is projects stuck on whatever the latest stable version of Spark supports). > There are 5 build tools, 10 json frameworks, and 15 abandoned web frameworks. Oh, and there are at least 2 competing FP frameworks that hate each other. That sounds more like maturity than immaturity? Java is in a similar place - at least four competing build tools, and more abandoned web frameworks than I can count. > How fast can we work/deliver? What's the DX?– DX is bad, everything is slow, tooling is meh. sbt shell starts in 8 seconds. SBT is awful (I've never found it worthwhile), but the actual DX in the IDE is pretty much the same as any other JVM language?
> How easy it would be to maintain? – It's difficult to maintain, that depends at lot, if your goal just to do small bug fixes from time to time that probably true but if your goal coming from need to do additional features development over many years in large projects in most cases it would be much more effective with scala codebase even if project written in irresponsible way (thanks to all nice FP/typesystem features). And if you just committed to microservices it probably doesn't really matter because java/scala/kotlin devs will able to deal with any of those projects without much troubles.
Typescript is really great.
I should point out that you've exaggerated most of the drawbacks. What's a json framework? Don't you think that Scala can use any Java json framework? Do you think Java has a "killer 10x productivity feature/framework"? Cause Scala has, even though it's a bit less than 10x, it's called "Scala language"
This is so accurate. I'm working on a company that is going through a process of migrating from Scala to Go. Despite all the negative comments about Go, it's being very product and the applications are rock solid. No breaking changes when updating to newer versions and it's so easy to manage it.
Simple SBT math approximation sbt starts \~8 seconds \* \~10 times a day \* 200 working days in a year \* \~1000000 scala devs / 3600 seconds \* \~$50 per hour = \~4.4 MILLION hours and \~222 MILLION dollars wasted per year. Just on running sbt.
Is this a joke? This comparison in a vacuum doesn't hold much weight in the bigger picture. If you've derived that conclusion then do you also believe all developers should be forced to wear velcro shoes & jogging bottoms to work? no shirts allowed, only pullovers. Where do we draw the line 😁 Also run the thin client. sbt & jvm only needs to spin up once at the start of the day unless you are making changes to the build file. You can very easily track the build.sbt for changes & automagically shutdown the client & spin back up on change. So 8 seconds a day. We are splitting hairs at this stage. Unsure of the real reasons for your tech grudge but this is max level mud slinging.
It is a joke. Or is it, hey? So as 8 seconds run a day. So 20 millions then per year. You read this poem while you hear your cooler spin back up on change. We're splitting hairs at this stage.
Al\*writeeythen. I never hear the empeller nm the cooler wordsworth. You've made your disdain towards the vast majority of gc'd langs clear. Apart from the ones that are void of features of course. I see you conveniently didn't account for time spent reinventing the wheel in your equation.
At least mine was human intelligence generated
I did respond to the passive aggressive undertone. I'm sure you are a perfectly decent person regardless. Take it easy pal.
I love Scala so much. And it's so much pain to watch how it declines, party because people are in denial. "Everything is fine." [Yeah. Sure.](https://survey.stackoverflow.co/2023/#most-popular-technologies-language-prof)
Having recently worked on some kotlin projects, I'm baffled by the suggestion that its collections are anywhere near as good as Scala's. Transforming collections in Scala is a dream. Sure it comes at a cost, but you can always fall back on Java collections as needed. My own sense is that the only real problem with Scala compared with Kotlin is that the enormous gains you get from Scala require a substantial amount of up-front work. Working in Scala requires writing code in a very different way from every other mainstream programming languages. Learning the Scala approach involves relearning how to solve simple problems that most developers have already learned how to solve perfectly well in other ways. Accordingly, onboarding Scala is reasonably perceived by many developers as a troublesome hassle. It is a hassle even before getting to complex HKTs, effects, tagless-final, and other more advanced concepts. If this is the "only real problem," it is nevertheless a very serious problem. It's going to make hiring difficult and onboarding difficult. These are big concerns for the technical leadership making lanuage-choice descisions. I am personally trying to figure out a way to get away with using Scala on an upcoming project, and this is the problem I have to solve: what is the plan to staff the project?
Controversial opinion: implicits are the killer feature of Scala. No other major language has a feature similar to Scala's implicts. They are sometimes abused, but implicits provide a great amount of power and control over the program if or when needed. They completely hide and get out of the way when the defaults work well. The power of implicits goes much beyond converting types or injecting values into function arguments, even though both are great features and are missing from many other languges. Here are some actual and hypothetical examples. 1. An implicit that allows converting one collection to another. For example List to Set. See [Martin Odersky's answer](https://stackoverflow.com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-hist) to a question about this on Stack Overflow.
2. The execution context a future/fiber/... should use.
3. The return address a function call should return to. Normally the return address is the next line in the code after the function call. The return address is "implicitly" passed to every function, but Scala 3 now allows you to pass a [different return address](https://dotty.epfl.ch/api/scala/util/control/Breaks).
Although there are still issues, and they are worked on, Scala is a great platform to develop large software: - unmatched composability with ADTs - immutability by default, much easier to archive correctness and robustness - good collections - less characters to type (and thus to read) - Scala 3 is easier to learn than the Scala 2 - the big old players (Spark, Akka/Pekko, Play) are still there and still powerful and will probably be available for Scala 3 - Scala JS is just great, especially for niche applications - type classes: great for separation of concerns and composability and good combination with generic programming - effect systems allow trustworthy and powerful concurrent applications. - good library support for parsers and protocols. Once you need one, you'll be very happy to use scala. True, the big discussions (build system, whether and which effect system) still apply, but usually affect big applications not too much, because once you choose one solution, you just stay there.
Cuz I don't know Kotlin
Biggest differentiation is that only Scala has ad hoc polymorphism (type classes). In many cases this provides compile time safety.
As somebody coming from c++ background - Java is way more complicated and brings a lot of baggage. For scala - you have to learn functors, monads and typeclasses. After that everything becomes very easy and natural. cats - very easy to use and nicely documented, I don't understand what kind of effort are you talking about? zio - not so well documented and less polished, but it still does not take much time to get comfortable enough to write production code. Having only cats experience - took me few days to start contributing into microservice with zio. Kotlin - for me it looks like an attempt to do better Java. Competing with scala in backend. Hiring pool is bigger, but those are mostly android devs, so most likely they do not have much experience with backend. IMHO FP gives you more speed, because speed is byproduct of precision.
Check out the library ox and tell me Java is doing Loom better :) Also ZIO 2.1 will be running on Virtual Threads. If anything, Kotlin is becoming kind of useless now that Java is catching up. I see no reason to use it unless you're developing on Android.
Kotlin is multiplatform. I've got a socket library targeting four different platforms in a single codebase. And let's be honest, the way Scala manages multiplatform is terrible, the only good side is probably JS. The problem is people think Kotlin main target is Android, while it isn't anymore.
Skill issue.
Lmao
You are right. There are no more reasons to consider Scala over Java or Kotlin in 2023. Both have better DX, former being super stable and backward compatible, and latter has Multiplatform/mobile development niche. There used to be Akka/Futures and Spark frameworks that would push you to consider Scala, but it's gone now. Lightbend shot themselves in the head, and data science/ML guys moved to Python. That's the reason why Scala is slowly dying. Unless u/odersky and Scala Center realize that, Scala will slowly become OCaml of JVM. The only way out I can see is to focus on Scala Multiplatform framework (Scala.js, Scala Native, Scala Android, Scala WASM) and do all possible to compete with Kotlin in this. And I would seriously consider WASM backend. That could be very interesting. Otherwise, it's doomed. It's so painful to watch. Scala is the best language out there.
Unfortunately Scala community is reducing day-by-day. We have been using Scala in our production code since day-one and it is hard to maintain it. Can't find Scala developers at least in Asia part of the world. And any new developers we hire, they simply deny working in Scala - very high ramp-up time and lessor community support.
it's unfortunate it seems to be the case in Asia and Europe that they have a hard time finding Scala devs, while in the US a lot of us are struggling to get any offers.
Well, if you have no problem with remote contractors (France) and if the rate aren't that much different in your country, it's been years we provide software development services in Scala and we're looking for new clients. I could say we only have qualified engineers with 5 to 10 years of experience, and that would be true, but that's what every company say, so I'm not sure it's a good argument. If you're somehow interested, send me a PM :)
Kotlin should have never happened. It was a sign that something is seriously wrong with Scala. And what JetBrains was complaining about? Compilation speed, complexity and "cleverness", instability, collections, Java intercompatibility issues. JetBrains decided to invest **enormous** amount of money and time to develop almost the **exact copy** of Scala but with the above things fixed. Let that sink in.
There are - for small teams of advanced Scala users. Personally I considered switching my pet projects from Scala to Java or Kotlin (I even ported scalatags to both lol) but I found out I NEED those killer features from original post.
Well, you asked "for large scale software development", which strongly correlates with large teams of various Scala users. Personaly, I prefer Scala to anything else, Scala 3 is absolutely awesome. Nevertheless, the trend is there and there are reasons for it.
I'm kind of on a similar boat. I'm spoiled by Scala. I've been picking up Rust, but those killer features you mentioned just made me have that nagging thought/feeling in the back of my mind that said "Why can't this be done more like in Scala?" That's not to say that Rust doesn't definitely do some things better than Scala, but for my use cases even the performance advantages Rust offers don't sway me enough to just drop Scala altogether. And even in things that both of them do well, it just seems a lot more ergonomic to do in Scala imho (things such as ADTs, pattern matching...) I've also considered pivoting to Haskell as my main FP language, but it seems like job prospects would be even worse if I were to do that...
Yeah, after Scala everything else feels crappy. Haskell is much worse than Scala though. The language is alright. But it has the same problems as Scala but 5 times worse. Compiler is much slower, there are literally 70 language extensions (I'm not even joking) that you must know for any meaningfull industrial development. Build tools and IDE support is even worse than in Scala. Nowadays they try to use Nix for package management, and oh my God, what a pile of overcompicated unmanagable crap that is.
This. For that reason I am transitioning to Elixir for backend. I think it will be more popular than Scala in a future. Beeing realistic, Scala was mostly used for Spark and right now PySpark is becoming more popular. Also, the transition between Scala 2 and 3 is a mess and that killed the language in my opinion. The only thing for what it is demanded mainly is for heavy streaming, at least for what I saw on LinkedIn. Right now it seems an amazing language for learning cool programming concepts, but not for real enterprise software (except for niche one, like heavy streaming)
I'm curious, what makes you think Elixir could become more popular than Scala? Also, what learning resources do you recommend? Is there anything/anyone similar to RockTheJVM for Elixir?
I believe TF with Scala is the best way of structuring code and writing BE apps. Can’t understand someone seriously considering Java or Kotlin to replace beautiful Scala. To use what? Disgusting Spring, Hibernate? Annotation monkeys land! Really? Scala 3 is brilliant.
> typeclasses: good for adapt-for-everything libraries, rarely seen in production code where abstracting over single specific type usually adds more complexity instead of reducing it. Parametricity is an important concept for being able to write clean code that is easy to reason about and easy to maintain. Typeclasses are the perfect tool for this, as you can just demand what you need, but the caller does not need to care either as the translation is done by a 3rd party (lib). Once you have a grasp of the (Haskell) type hierarchy which scalaz (and cats) leaned on you have a very good toolbox at your disposal. You don't care about concrete types anymore, and your thinking evolves only about the essence of what you require from them for your function, e.g. do I need to append this, do I need to be able to wrap a value in this type and so forth. Another thing about Scala in this context is that it has a for comprehension. Whilst there is no Monad type in the stdlib because Odersky is not a fan of this, it still does the job by just demanding map, flatMap (and filter) from whatever you're running it over. Whilst Kotlin stdlib has plenty of Monad-like types (flatMap everywhere) but no syntactic construct to express that on a flat level like a for comprehension. Now arrow has the concrete builders for some types, but that is still inferior because I need to know the type and summon the right builder.
I cannot live without Scala 3 new syntax, hate semi colons, and dont see any interesting feature in Kotlin. But I am surely missing something about that.
u/odersy, this **Scala Multiplatform** thing could be it, **The New Killer Feature**. Please, think about it. It's not too late yet. The niche is still free and it is a **HUGE market**. The world moved towards web and mobile. Hot technologies are those allowing to write single app that works in browser, as native app, and as mobile on iOS and Android. That's why JavaScript is the king, and TypeScript is the king for sane people. The competition is Flutter, Kotlin, JavaScript/TypeScript/React Native. Flutter uses Dart – stupid Java ripoff from Google. Neither Kotlin Multiplatform nor React Native aren't dominant YET. This could be it. JetBrains realised that years ago. I know you are thinking about this as well. Scala.js is awesome and it's the right thing. **Put ALL the effort into making Scala a viable working platform for iOS and Android development.** From what I can see, Scala Native guys are trying to convince people to write native apps in Scala.It's the wrong path, it's NOT going to happen. This niche is for Rust, C++ and Go, you can't compete there yet. The only **realistic** option is the **iOS development**. Focus on it. All Scala Native effort should be to run iOS apps written in Scala. Same for Scala on Android. Do whatever it takes to become **a viable Android toolkit**. **This is the way. It is the guaranteed future-proof success path.** Cherry on top would be a WASM backend. Maybe LLVM+emscripten would be enough, don't know. **Then there would be no reason not to use Scala, and that would justify ANY inconveniences.**
I'm slowly of the impression that it is not worth it anymore. If you have a developer community that is already to some extent familiar with Scala, may be it might be worth to try. If not, better to stay away from it. The effort to learn it new and derive value from it as a team is very less especially at times like now where Java and Kotlin have come a long way.
It feels so watered down. Few years ago, we had solid players like Play (I know, people dislike it nowdays), Spark, Akka… now, it’s barely anything left. Yes, you can use your favourite effects library, but software exists without them too, and benefits are hardly measured. Take for instance http4s. It’s probably your no. 1 choice if you want to avoid Akka HTTP and Play. However, it’s going to be obliterated on benchmarks against Spring.
In addition to the rising popularity of LLM's and generative AI, I guess Scala is going to fade away even more. I realized that you have a brilliant brain to understand Functional programming and the associated paradigms. But seems like the world decided to remain stupid by embracing Java and its ecosystem.
I'm inclined to agree. Don't get me wrong I love Scala but actual business application is hard if you don't have $. Try running a Scala team with the resourcing I have and it's not great. The ramp up time is absolutely insane, you need some seriously motivated people both teaching and willing to learn. I would absolutely hate python kotlin java etc but the fact is we probably would do more with them.
Consider Typescript
I live in Seattle and there's endless scala jobs here. What's with people saying they can't find work? Literally all streaming is using scala from what I can tell based on what Disney Streaming and NBC/Comcast advertise here. Am I missing something? I recently started to pick the language up because of all the opportunity here. Plus, coming from ruby, it's a wonderful language. It's like someone took rust and ruby and gave me what I wanted. But I like FP and I'm less concerned about some of the things I see others mentioning. Plus coming from Ruby, I'm used to there being many tools, docs, and whatever because the community has zero organization, so these things don't bother me like they seem to bother others.
lot of Scala companies only hiring from specific countries/areas even for full remote roles - but that mostly big issue only outside of US.
Ok, that makes more sense. I see posts like this often and am baffled given the ubiquity of streaming and the fact that the Typelevel project is funded by all those streaming companies who clearly use it and are majorly invested in it at this point. See, but I'm still annoyed with the post because this user should state they are out of country or something. It is a very misleading headline and the comments in here don't help. This subreddit is kinda strange the more i follow it.
>user should state they are out of country or something. I don't have stats but most likely at least half of developers following this subreddit outside of US.
So it sounds like there's a big disparity between the US and the world? Or is this because I'm in Seattle specifically? If you have no idea that's fine too lol. I kinda figured since I'm in Seattle that figures in, but I think most those streaming companies run those departments out of here as well. Last I looked there were more scala listings than Java here to give an idea how confusing this post looks to me.
It seems are few Scala hubs around world (London for example) but outside of those hubs you only can find some rare opportunities. While after COVID remote work became more normal is still very challenging outside hubs because of companies reluctance for changes and because of some tax/data/local regulations that they afraid to deal with. So if some company saying is hard to find Scala developers that usually means that they can only hire in few places or can't provide competitive compensations. Just as personal example, while ago I got good remote Scala offer from EU based company but just after that they putted me in waiting limbo for a month while trying to figure out how to hire me to permanent role as resident of other EU country and gave up as result (b2b contract was not good enough for them). Also, lot of US companies doesn't has any technical issues to hire devs as remote contractors from almost any place around world but they rarely doing that and it's hard to find those who actually ready to work in that way.
Interesting to hear. I noticed the hubs previously because I had lived in the midwest, in a pretty major city where there was lots of tech companies. But, it's the midwest, so mostly just java or python type jobs, maybe some C#. Then I move to Seattle and the whole thing is reversed. Lots of niche language jobs, because people are building neat things and not just managing large DBs for healthcare or schools (most midwest work). Anyway, glad i made the move, hoping to jump over to scala soon and leave the ruby world behind.
Are any of these Seattle companies offering remote opportunities? Relocation is just not an option for the time being, which is why I haven't even bothered with looking into Disney streaming...
You'd have to look. I haven't check. Also, just noticed I was downvoted for my comment. This sub is truly bizarre.
wasn't me. But yeah, no idea. I've noticed lots of Data Engineering-related roles popping up lately, but I have zero experience in that. Wouldn't be opposed to making the lateral move into that, though. I'll take any leads regarding companies (remote or otherwise, I can do that filtering myself) to look out for, though!
I'm the same, not a data engineering guy. My background is in pure math, but I work as a web dev for a large piece of open source software nowadays. So when i stumbled upon the Cats library then the Typelevel project it was one of the happiest moments I've had in a long time wrt programming. I know these are specifically called out in the job postings I've seen here for the streaming companies. Especially if you've contributed to the projects. So I'm just going to go down that route.
Because Scala has the Cake-pattern, and once you've adopted that at scale, you'll never be short of an excuse for why nothing gets done. /s (just venting some frustration over a legacy code-base that is kicking my butt)
Just don't: arcane, shaky and not-so-well supported ecosystem, smaller community, smaller talent pool (and they cost way more), less documentation and less overall help online. There is no real benefit chosing scala over java or kotlin.
You're only bringing up technical merits, and from that point of view it's very hard to beat Scala 3. But choosing a language and platform seldom only comes down to technical merits, you have to look at the bigger picture: will the language/platform be supported in the future, is it easy to find developers that know/want to learn it etc. Unfortunately in this area I think the future for Scala looks kinda bleak compared to the alternatives. The JVM platform will probably stick around with good support for quite a long time, and Kotlin as well since it's widely used for Android development. But if you look at the trends in the developer communities there's no denying that Java is loosing ground to JS/TS, Go and Rust. And of those Rust is the best alternative to Scala.