Evolving Scala
scala-lang.org
scala-lang.org
Yes, it's a very common one shared by virtually all Scala 3 developers. Stop. At least for a couple of years.
Tooling and the community just can't keep up and the language is very good already that the focus should be on the ecosystem and not language.
But Scala devs are beyond deaf and that's what you get when a programming language is an ongoing research project on which many students and professors depend.
It's not enough to say "if we stop developing new features the language will die" when there's 0 evidence by it and a huge fatigue towards the relentless development coming from most of the community.
If we want to say it really doesn't matter what language we choose, because any solution can be cooked up regardless, it absolutely matters then what the tools around that language bring to the table.
Please avoid generalisation. Not "all".
> Yes, it's a very common one shared by virtually all Scala 3 developers. Stop. At least for a couple of years.
I, for one, think Capture Catching can't arrive soon enough. It will allow us to write much simpler programs, getting an edge over modern Java & co. I'm very much looking forward to it.
Don't use experimental Scala features in production code. They may change or be removed. And they will likely lack support in IDEs. But that is a common sense.
- faster compile times
- faster compile times
- I want sbt+scalatest (the blessed build tool/test framework) to not leak memory constantly (https://olegych.github.io/blog/sbt-fork.html this is an issue I specifically run into)
- I want useful documentation when I ctrlclick into settingKeys in build.sbt
- I want Intellij to not bug out when you pass explicitly the implicit arguments required by a function that uses both context bounds and implicits
- I want intellij to always agree with the scala compiler
https://mill-build.org/mill/comparisons/why-mill.html#_perfo...
And support for Scala in [web frameworks for Java].
Still on Scala 2.13, so don't know what 3.* I'd want, more than what already exist
Edit: It focuses too much on the language instead of the ecosystem.
---------
To me the goals are sensible the flagship goals (for 2025H1 for example [1]) are all about DX and focus on downstream devs and their needs (all hands, Rust in the kernel).
The usual problem of "compile times" [2] (usually link times and LLVM throughput and so on) are things that are being worked on, but fundamentally they all can only be solved by caching, incremental compilation, and better developer tooling that are not language problems.
[1] https://rust-lang.github.io/rust-project-goals/2025h1/goals....
[2] https://old.reddit.com/r/rust/comments/1if5wpm/high_hopes_fo...
It's time to shift priorities.
Now even Java has cheap threads (Loom).
And Go even has generics. Just 20-ish years later than Java. And it's likely that more features that now Java has will trickle into Go. If Go wants to survive.
All this to say that there is no space in the market for another language which is a stupid simple Algol. Go already occupies that space. And even Go will have to add features developers want/need, if it doesn't want to get cornered out of the market.
It's not only Scala that must evolve.
If by "cheap threads" you mean M:N threads a.k.a. fibers/green threads, Java had that on Solaris well before Go.
Java is one of the few languages that does have it, besides Erlang, Haskell and Go. That "even" is absolutely not warranted.
Java needed Apple, Go needed Google, React needed Facebook, TypeScript needed Microsoft, etc
In this way Rust is actually a pretty unique success story in that there's no singular major tech firm pushing it
2. Rust has improved its compiler performance by >3x in the last 5 years.
3. Rust hasn't gotten any major new language feature in the last 6 years. Most language improvement is improving orthogonality of existing features.
4. Rust has an excellent backwards compatibility story also right from the start. Code/libraries written in 2015 can be still compiled and used together with code from 2025.
5. Rust has a serious backing from all major IDE / editor providers.
6. Rust has integrates easily with other languages and ecosystems. It's easier to call Rust from Python than to call Scala from Python. It's easier and more performant to call C from Rust than to call C from Scala. Things like that. It's sad that Scala even struggled with interoperability with Java; which should theoretically be easy as it is the same platform.
Seriously, doesn't look to me like the same mistakes. It's actually quite opposite.
If you want a more useful standard library, perhaps consider Go.
But it makes up for the minimalist stdlib by making it a breeze to use third-party libraries.
There's plenty of old modules in the Python standard library that hardly any one uses. But removing them would break backwards compatibility guarantees. The Rust project has decided that they want to keep the standard library lean. And this works well in practise, because cargo is a really good package manager.
Rust also ships with a functioning epoch/edition system that makes it feasible to rework existing language features for improved generality, elegance etc. without losing backward compatibility. I'm not sure if Scala has anything like that.
Also, the nightly/stable split in Rust means that most new features don't reach the final adoption stage unless there's a very real consensus about their design. A lot of effort is made to get rid of incidental complexity wherever feasible, before the new features are actually stabilized.
Most language implementations that "haven't gotten any major new language feature in the last 6 years" would be described as broadly stagnant or stale, but Rust is quite different.
Cargo is a really good tool, but I wouldn't say it is 10x better than SBT.On the other hand, Scala can be used with different build tools: Maven, Gradle, Mill. With Rust you have no choice(or I'm not aware of). Rust-analyzer is better than metals, can't argue with that...
>Rust has improved its compiler performance by >3x in the last 5 years
Rust compiler is very slow. I can't imagine what compilation time was 5 years ago, but even now, it is incredibly slow, even compared to "slow" Scala compiler(which is no longer true). I'm working on a little project with bevy, and even on such small project compilation time sucks. You can't compare it with Scala, it's just completely different experience.
>Rust hasn't gotten any major new language feature in the last 6 years.
That's not true. Rust team handles these changes correctly. Rust has concept of "Editions", and every 3 years new edition introduces significant changes. I really like how editions work, it's a great way to maintain backwards compat.
>4 Mostly agree
>5 Fully agree
>It's easier and more performant to call C from Rust than to call C from Scala.
Yep, but it's not Scala but the JVM limitation. JNI sucks, but there is an effort to improve that (project Panama).
Overall, both Scala and Rust are great languages. Rust team has addressed many typical issues from the beginning. Scala had its mistakes, but moving in the right direction.
What do you mean by that? What is missing?
Language geeks want language geeking, what Scala users want is a "faster horse". (Faster compiler, nicer project/package manager [sorry sbt], incremental compiler, LSP-compatible compiler, and so on. All good and nice and completely valid and important things!)
Unfortunately usually corporate backers can deliver these things not language researchers.
There's no need for the tooling and community to keep up. If Scala 2.12 is so good for the community stick with it.
The obvious problem is that Scala 3 delivers features (and whatever Odersky et al. cooks up will likely be useful for a lot of Scala users) that incentivizes attention fragmentation.
Yes, it's true that the community cannot keep up. (Yet the community is not a hivemind, it was able to churn out so many effect libs over the years I lost count.)
But it's an unforced error to put this responsibility on the researchers.
Anyway, squeezing water from stone might be easier than persuading certain folks :)
Scala is perhaps not going to replace Java in every old enterprise, but in my personal experience working for startups, it's been an awesome force multiplier for small teams who need to productively pump out safe and ergonomic code. Finance, health systems, etc. And yet it's also ergonomic and pleasant enough for me to eagerly use it in my non-mission-critical personal projects as well.
But once Valhalla lands, with some additional JEPs, Java will be very close to the core of what Scala offers. Where there are gaps, some of these can be filled via libraries (think immutables.org, or others providing persistent data structures).
As a matter of fact, these days at most companies that I see the typical deployment model is "micro"services, which you can quickly develop via Spring Boot or the alternatives. No need for ultra complex code or asbtractions, Java does it just fine. And you have all the tooling you need for the enterprise world.
I think Scala is an excellent language for teaching ML-style programming. I would still recommend it for that purpose. But there is no longer a killer app or need for Scala, that would convince most people to use it for new projects.
Kotlin has an advantage here, because ART nowadays is effectly KVM from Google's point of view, where they grudgingly update Java support to keep up with Maven central.
Scala has nothing like this, and the update on Python alongside native libraries, kind of stole its demand in big data, hence why this kind of scenarios is described on the article.
Whether that's an advantage in day to day business development is a different question.
Scala is even more "powerful" than TS or Rust as it has real HKT (higher-kinded types), and for example Effect.TS needs to emulate/simulate it.
https://github.com/Effect-TS/effect/blob/main/packages/effec...
Yes, Java has been getting a lot of features Scala has had since (more or less) always. But it's a continuing process, and not all such features are yet fully fleshed out and polished in Java.
Also, Java will probably never get many of important features Scala has (or will have). It may not be some esoteric things, like higher-kinded types. But things like meta-programming/macros. Or features which may be advanced from theoretical point of view, but are actually easy from user point of view (because they lead to a simpler code), like Capture Catching.
- Desktop GUI app which used Tauri/Rust but heavy Scala.js on the frontend
- Cloudflare Workers using Scala.js
- Web apps using Slinky React [1] and Scala.js
- Highly concurrent, fiber-based backend apps using Scala and Ox [2]
- OpenAI model inference against ultra large datasets using Scala, Spark and MS Synapse
- CLIs using Scala Native
Working in a single language across frontend and backend is amazing, especially when the language is so nice. Sharing models, codecs, validations, etc. And again – all of that in a very friendly language. Scala's expressive yet safe type system is very good at describing the business domain, encoding constraints, etc.
The only weakness of Scala.js I would say is it takes a bit more effort to integrate with JS libs. The mechanism is the same as with Typescript – just need the type definitions, but in practice it needs a bit of manual work. It's not a big deal though because with Scala.js you don't really do the 200-npm-dependencies thing that so many JS projects are cursed with. Lots of stuff comes with the language or from nice Scala libraries, including immutable data structures, powerful collections, validations, state management, etc.
Scala has somewhat of a reputation for being complex, but the language itself is ecstatic in its simplicity and elegance. The problem historically lied in certain functional programming libraries that require a certain formal / academic mindset to work with. They did become more ergonomic and better documented with time, but those are still very advanced concepts for most devs. I did work with such a codebase, and I have to admit it was not the easiest. But that was before AI – nowadays it's a lot easier for me to figure out these things. But I don't need to, at my current job we don't use them. So I would advise to learn Scala the language before going off the deep end into hardcore FP libraries. That's a completely optional destination that you don't need to force onto yourself if that kind of style doesn't jive with you.
Speaking of AI, I've been asking both ChatGPT and more recently Claude about Scala 3 and about functional programming libraries, and they're pretty good. I don't "vibe code" so don't know about that, just asking for code snippets or for explanations.
Also for me, subjectively, it honestly feels too abstract at times. You can almost feel the academic joy of the beautiful, unintelligible concepts where you can express things so succinctly, but requires a small mountain of concepts to understand how to write that nice code. It’s quite frustrating to do battle with the compiler when you don’t fully understand the type system and that initial hurdle is kind of tough to get over if you’re also trying to switch into a functional paradigm from an objected oriented one.
Which functional paradigm. There are at least two in common usage in the Scala community. Odersky's vision was an ML style FP. And now ML patterns are common in modern PLs.
If you need to know category theory concepts like Monad / Semigroup / etc. in order to understand your code, you're not doing regular Scala, you're doing Haskell-style FP in Scala. Which is a popular choice that many people swear by, but is entirely optional. Personally I don't think the complexity of that approach is worth it, and we don't use any of that stuff at work, and still reap the benefits of Scala.
Scala is a true multi-paradigm language, it does not have a monoculture. Lots of people who use Scala don't use highly abstract FP libraries. I very much don't think that the OOP side of Scala is the language designers' concession for the sake of broad appeal. Seamless fusion of FP and OOP is the essence of Scala, and it works great for that without any third party libraries. The designers' attitude is evidenced by the libraries created by their companies (e.g. Play, Akka) and by the learning materials, both of which lean heavily on plain Scala without going off the deep end with FP libs.
FWIW, "Semigroup" is not a "Haskell concept" either. Equally, it's a facet of specific Haskell functional programming libraries, and not Haskell itself. Granted, Monad is baked into the language (as do notation).
How much of this would be due to actual language features, and how much due to selection bias induced by talented and ambitious software developers looking into functional programming languages as a means to satisfy their intellectual appetite?
https://github.com/Iltotore/iron
Shifts entire classes of errors to compile time.
I'd rather work with Scala devs on a Java codebase than Java devs on a Scala codebase.
It's not about intellectual appetite though. It's about not re-litigating the same crap at every new work place. Avoid mutability and nulls where possible, etc.
And Java devs on a Scala codebase is effectively the norm once your project enters BAU/maintenance phase.
In terms of talent there is definitely some self-selection as with any non-default tech stack. Scala is a sharp tool and there are both people who are attracted to it for the pragmatic utility of its sharpness, and people who are attracted to it for wanting to play with sharp things. Both types are smart but the latter group have given Scala a bad rep in the past for being too smart and thus writing code that was too clever for others to understand. But nowadays the general vibe in the talent pool is a lot more pragmatic.
Wouldn't you want to use Kotlin for the latter these days? It seems to have broadly wider adoption than any "plain" variety of Scala.
Scala was always much more elegant and actually going the extra mile.
Kotlin as a language is also closer to Java on the Haskell <---> Scala <---> Java spectrum. We just don't want to move in either direction on that spectrum, Scala sits perfectly where it makes sense to us.
It's interesting that some people here are saying that Java's recent improvements will eat into Scala's market, when actually, it seems that it will eat into Kotlin first.
But once it clicked, it's been a joy to work in.
Back in the days using Java was mind-numbing boring and boilerplate-galore. Scala offered vastly more productivity and fun. These days Java is... fine. Scala is still amazing but Java doesn't cause active pain anymore. It becomes harder to justify using a niche language.
Scala will still live. It is an amazing language with a great combination of functional and OO programming. I just don't see a big breakthrough in popularity.
But I think it still has many rough edges -- things that are awkward (or outright impossible) to do in Java and Scala is great. It doesn't have to be advanced features, like meta-programmig/macros. Here are some example that I think are not anything esoteric:
* Just the mere fact that Scala has immutable/persistent collections improves how and what programs people write.
* Scala also has good infrastructure to deal with "modifying" data model graphs in a persistent/immutable way. Think deeply nested case classes and sealed traits. You have the copy method, lens libraries, etc. Java does have records and sealed interfaces, but all the rest of the machinery to work with them is still missing.
* To generalize the points above, Scala is immutable-first language, with all the positives that come with it. Java, still not so much (even though they are moving in that direction, e.g. `record`s).
* Another weird thing in Java is how it deals with variance. In Scala, I find it easy to comprehend, in comparison.
* Scala is expression oriented. Ifs, trys, etc -- all of them are expression. You can bound the result of these expressions to a variable. Not the case in Java, which makes it annoying to work with. You have to fist make the variable null or something and then make sure it gets assigned within of the body of the if/try/... Just a bad experience :(
Than there is a matter of culture:
* Java libraries like to return (and expect to be passed) a `null`. Scala culture embraces `Option` from its standard library.
* While Java does have support for checked exceptions, which I think is a very good idea in theory, in practice its implementation is underwhelming (e.g. not possible to abstract over) and so libraries don't use it as much. With Scala you can return an `Either`. Or with new Scala 3, we may soon have powerful capability system to, among others, allow throwing "checked" exceptions. That's the Capture Checking https://docs.scala-lang.org/scala3/reference/experimental/cc... research.
* This may be even more personal opinion that others, but I find Java libraries more difficult to use that Scala ones. With Scala, you just follow the types and you create and work with the objects that the library gives you in an intuitive way. With Java, the types don't help you as much. You have to read the documentation thoroughly, to make sure you're calling the right methods on the right objects, in the right order. Because the types don't help you, you can't be sure you doing it correctly, because every other way compiles too.
Kotlin is also much more popular than Scala.
That's not what (at least some) numbers say. Both Scala and Kotlin are 14th.
https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2...
Kotlin may be more popular, but not much. It's nowhere near the mainstream languages like Java, Python, JavaScript, C# or PHP. Not even close to TypeScript.
That said, probably "number of Github projects" and/or "number of StackOverflow tags" doesn't encapsulate the sheer amount of code written in Kotlin for Android apps, which is where my head was probably at.
5-8 years ago Scala had a large boost in data science/big data work as it was either it or Python for a lot of frameworks like Spark. We used Scala because we wanted static typing and threading (among other things) for our workloads.
Up to Java 21,
https://advancedweb.hu/a-categorized-list-of-all-java-and-jv...
Remaining ones until Java 24, released last week,
https://www.infoworld.com/article/2335077/jdk-22-the-new-fea...
https://www.infoworld.com/article/2336682/jdk-23-the-new-fea...
https://www.infoworld.com/article/3491404/jdk-24-the-new-fea...
Additionally, commercial AOT compilers have taken a big hit, as two great options are now freely available,
https://www.graalvm.org (Basically LLVM, but in Java)
https://eclipse.dev/openj9/docs/aot
With them there is also the rise of AOT friendly frameworks like Quarkus and Micronaut.
"if" not being an expression is my main personal pain point for the time being. It would make simple code so much more readable.
And Kudos to VirtusLabs for maintenance.
Huge Kudos to Daniel for his courses. If you think Scala is difficult, check his course, these will change your mind.
When building Wide Angle Analytics backend I chose Scala. Sometimes I miss the convenience of Spring Boot of having all integrations at the fingertips. But then I implement same thing in Scala and it is much leaner, boils down to couple of functions and it just fits nicely.
My only personal pet peeve with Scala is painful upgrade path between libraries (Cats 2 -> Cats 3). Oh well.
Daniel Ciocirlan I guess ?
I guess I'm not recursively solving my problems in my day to day challenges
But say you're interviewing for a job - what does it say about an organization if they've picked a somewhat obscure, academic tool to build their product? They are probably exceedingly clever, but are you in for long technical debates about arcane minutiae? Are they stubborn and uncompromising? Do they make impractical technical decisions?
It's a hybrid paradigm language and back when I used it (v2), it was perfectly possible -- and common -- to write code without using more FP idioms than is now common in most languages, Javascript, Python and Java included. A lot of people used Scala as "a better Java" back then.
I don't know what's the situation with Scala 3 nowadays, but judging from TFA it remains a hybrid language.
[1] "`Mostly Functional` Programming Doesn't Work" https://queue.acm.org/detail.cfm?id=2611829
If an employer uses Scalaz or Cats, on the other hand, run for the hills.
Could you elaborate? I changed jobs while it was still v2, stopped using it, and haven't kept up with the changes.
But from what I have observed in the last few years Scala is either used in legacy projects or you're talking to a hard-core FP shop. The saddest fact that it's true even in Data Engineering with Spark :(
I found Kotlin to be great for writing very performant concurrent code. It was actually easier to write faster code in Kotlin, and even though the pattern matching isn't quite as powerful, it was good enough. The code was also much easier to grok.
I can see how that can be a real challenge, but I, for one, am excited by this aspect of Scala more than any other.
- Apache Spark picked Scala in 2014 as a language with lambdas and pattern matching on the JVM.
- Akka picked Scala because it was a concise, performant language with support for lightweight concurrency with Futures or Actors.
- Scalaz and Cats picked Scala as a concise language with a rich type system.
val date = raw"(\d{4})-(\d{2})-(\d{2})".r
"2004-01-20" match
case date(year, month, day) => s"$year was a good year for PLs."
I assume this Kotlin snippet would, at minimum, need to do null-checking on "matchEntire" before it finds its way to a production codebase.
If you want a more verbose option, you can import the Regex type and write:
val date = Regex(raw"(\d{4})-(\d{2})-(\d{2})")
Boy do I have news for you
Sadly, I just don't find a spot for Scala in my toolkit these days: it's either Python for the numpy-et-al ecosystem, Clojurescript for frontend, Rust for portability, and something frontend-ish (probably just Javascript) for serverless backends. The long-lived JVM just doesn't have a place.
If Clojure and Rust work well for you, more power to you. But at least in theory, you could very well use just Scala for these purposes
Scala can compile to JS https://www.scala-js.org/ if you target frontend.
And if you want portability, you can compile a Scala program with GraalVM's native-image and statically link everything with musl libc https://www.graalvm.org/latest/reference-manual/native-image...
And if you want both frontend and portability everywhere, Scala will soon have a support for compiling to WASM (with WASI, etc) https://github.com/scala-wasm/scala-wasm/ (to be integrated into Scala.js after developed)
According to https://www.graalvm.org/latest/introduction/#licensing-and-s... the community edition is free software (GPLv2 + classpath exception).
But it isn't really clear what the differences are between the free software version and the proprietary version.
There does not seem to be a page detailing the differences between the two (or at least I couldn't find it)
But the AOT compilation (native-image) is available in the GPL community variant.
Getting the musl stuff to work can be tricky, mostly-static (only libc dynamically linked) is an easier option.
I've built a CLI diagnostics app with Scala & NativeImage and I've embedded the Graal Python interpreter inside it to allow extension scripts to be written. The result is a zero-install executable that provides an n entire Python environment. I think that's a good showcase for one of Scala's strengths, it's interoperability with the Java ecosystem.
The main issue is if you are using reflection, which needs metadata adding to describe it so the necessary metadata is included in the image. Some libraries already have it built in, and there are tools to help.
For building, https://github.com/sbt/sbt-assembly supports native Image.
> We acknowledge that there is still work to do. The IntelliJ team is working hard on bringing the best support for Scala 3, and you can expect more improvements in the following months.
Good to hear. I thought Jetbrains had completely abandoned Scala for Kotlin, so I'm glad they're still willing to support Scala.
Thank goodness that Shapeless is not needed in Scala 3. The good parts have been integrated into the language itself and so it's reliable and faster.
> Jetbrains had completely abandoned Scala
Thankfully not at all. Gets regular releases, Scala 3 support is improving with each. They're also welcoming to PRs, if you have spotted a bug that needs fixing. (The codebase of the Scala plugin is in Scala, so that makes it easy for the community to contribute.)
But you can (and people mostly do) use Spark from Python. And Akka/Pekko from Java (but I'm not sure how that is common).
And the job market is there:
https://functional.works-hub.com/jobs/?remote=true&tags=scal...
https://scalajobs.com/locations/remote/
https://remoteok.com/remote-scala-jobs
https://betterremotejobs.com/search?title=scala
https://readytotouch.com/organizers/scala/vacancies?remote=1
https://www.levels.fyi/jobs?searchText=Scala&workArrangement...
https://www.linkedin.com/mwlite/search/jobs?keyword=Scala&lo...
https://discord.com/channels/629491597070827530/629546253381...
https://discord.com/channels/632277896739946517/840255868096...
But i do not like to see switch between java and scala and these days also kotlin. Syntax model switches in my head drive me nuts. :))
Julia for mathy stuff.
Python with pandas / polars.
Rust with polars / actor frameworks.
Go for simple systems tooling / api dev.
Zig and Rust for systems programming.
Elixir / gleam for functional webdev.
JS / TS for everything.
But one of Scala's strength is versatility. You could use it quite well for all the listed use cases too. With just one language. (Maybe with the exception of system programming -- Scala Native still requires a tracing GC.)
Also, it's worth noting that Scala is more popular/mainstream/supported/has bigger community than Julia, Zig and Elixir / gleam. And if Red Monk is to be trusted, even more than Rust https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2... That comes with many benefits.
> if you don’t need JVM / Java interop
OpenJDK is also very good, even if it's not a strict requirement to use it. Battle-tested, easily debugable, etc... AOT compilation is possible via GaalVM's native-image.
Or you can try Scala.js or Scala Native (which don't have anything to do with JVM).
I think that the jack of all trades space is already occupied by C#.
Oracle started heavily investing into Java. And Google picked Kotlin as the language for Android.
But Scala hasn't stagnated since. And as the blog post suggest, plans on moving further still. For example, https://docs.scala-lang.org/scala3/reference/experimental/cc... may be one of the most impactful developments in the language's history.
Scala meetups were full with newcomers! Hadoop and Spark and Big Data[TM] was the thing! Distributed systems, were all the rage! Everyone and their dog was waiting patiently for the next HighScalability post about something even more crazier and bigger than before. People were writing homage posts to The Log post. Kafka was the thing you had to have in your system for it to be worth the napkin it was sketched on! Netflix and Twitter were talking about microservices and releasing all the amazing libraries to handle the load! (Circuit breakers, service discovery, etc.)
And then.
...
AWS and k8s and Go (and later Rust) and just an ungodly amount of hardware and deep learning progress happened.
People slowly realized that the JVM and Hadoop is a mess. (Ultra-low latency GCs like Shenandoah arrived too late.) That kind of Big Data is actually just irrelevant unfiltered shit (and implicit feedback is all you need for recommendation systems) and slowly but surely people started to move to S3 from Hadoop (and in general into the cloud).
And scientists - bless their little non-programmer hearts - did their best and moved from R ... to Python. (And there was already a ton of bindings to low-level linear algebra and tensor libs in Python, and calling into C/C++ was standard from Python - Cython is great - even if technically it's exactly as easy from Scala/JVM.
...
Fundamentally the lack of corporate sponsorship and the main contributors' lack of DX obsession led to the natural consequence of the industry leaving that Scala behind.
(Even though both Rust and Scala are research-heavy just compare how much attention Rust as a project spent on improving DX, including backward compatibility, trying very very hard to avoid py2-3 and scala2.11-2.12-2.13 upgrade speed bumps, and so on.)
I miss it a lot.
Albeit that is possible in typescript these days too tho.
Typescript's typesystem is even Turing complete.
Regardless, it is not very practical to use a type checker as your runtime.
* Immutable/persistent collections in standard library
* Machinery to "modify" immutable deeply nested case classes/sealed traits. You have the copy method, you have lens libraries. Very easy and comfortable to use.
* Expression oriented. if/try/etc expression can be bound to a variable
* less characters to write the same idea/program, while not losing readability
* better tooling: Scalafmt is ubiquitously used, supported in IntelliJ and is very good. Scalafix (a linter which can also fix some issues automatically) is used a little bit less, but is also good.
* build tools: while I don't like sbt, Mill is a so much better build tool than Maven or, even worse, Gradle. Then there is also scala-cli, which is not a build tool, but can work like it, if you have a simple, single-module project (i.e. no sub-projects/sub-modules).
It is waning as other languages catch up, but to some extent perhaps having the self styled elitists move on to rust will mean that a more pragmatic and less dramatic user base is left behind and the intellectual one upmanship that has made scala toxic can find a home somewhere else.
If I was starting out today I'd lean more towards python, typescript and go depending on use case. (I still think rust is over engineered, over used and over prescribed with very few people getting paid to write it)
Anyway I am hoping it turns into somewhat of a COBOL where I can charge outlandish rates for fixing banks technical debt issues.
None of these issues should kill the language and I think it still has a potentially bright future.
Rust publishes their performance data: https://perf.rust-lang.org/dashboard.html Where do I find similar thing for scala?
This comment from Odersky also says that Dotty was not automatically faster than 2.12: https://news.ycombinator.com/item?id=16884317
This is also heavily influenced by the build too you use. Don't use sbt or Maven or Gradle. Use the good stuff. Use Mill.
https://mill-build.org/mill/comparisons/why-mill.html#_perfo...
Or Bleep, if you're feeling more experimental https://bleep.build/ .
https://mill-build.org/mill/comparisons/sbt.html
SBT does suck for other reasons, however.
Rustc in my experience is an extremely well optimized compiler, only second to Go. It beats pure Java with Maven / Gradle as well. It gets bad reputation because Rust projects are compiled fully from source, so Rustc has usually like 100x more code to compile than in languages which use binary dependencies.
fclones is ~500k LOC gross with all dependencies. Takes 9 seconds to cold compile with linking on my machine.
I haven't used Scala for a while but last time we used it (Scala 2.12 + gradle) the compile times were just abysmal. A project containing just about 20k lines of Scala + some Java took over 5 minutes to build, and incremental compilation didn't work at all (probably due to Gradle not understanding Scala dependencies).
I don't think that checks out.
Java's compilation is ridiculously fast.
https://mill-build.org/blog/1-java-compile.html
According to this, javac itself can compile up to 100k lines per second, while Maven/Gradle is an order of magnitude slower.
The only info I found for Rust mentions something along the 5k lines/second mark (on a different computer), but it is at most roughly the same, if not slower than a java build tool.
> The only info I found for Rust mentions something along the 5k lines/second mark (on a different computer)
On Pentium III?
Let's see how it performs on M3 Pro:
cargo loc --filter-platform=aarch64-apple-darwin
...
Total lines: 961318
(783408 code, 77484 comments, 100426 blank lines)
cargo clean
cargo build
Compiling libc v0.2.155
Compiling autocfg v1.1.0
Compiling cfg-if v1.0.0
Compiling proc-macro2 v1.0.69
Compiling unicode-ident v1.0.12
Compiling memchr v2.6.4
...
Compiling dtparse v2.0.0
Compiling fclones v0.35.0 (/Users/piotr/Projects/fclones/fclones)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 9.75s
If pure javac can also do 100k LOC/s (which is definitely something I believe is possible) but then "Maven/Gradle is an order of magnitude slower" then my point stands. No-one uses pure javac to compile big projects.
I assume this refers to operator overloading. I think `a + b - c` looks way more readable than `a.add(b).sub(c)` and I'm happy when a language lets me define my own operators for vectors/matrices but I also have a side-curiosity: do they ever have a good use case outside of a math context? I never heard anyone praise `<<` `>>` in C++ for ex.
Each of which was specific to that library and would confuse new developers beyond belief.
I actually do like symbols as opposed to words (+ instead of append, : instead of as, < instead of extends, -> instead of function etc). They just need to have stable meaning, which conflicts with operator overloading/math.
But akka aka pekko is still perfectly usable.
Which libraries are you referring to that do the same? Just curious.
I don't know if I personally agree with that, I've had a better experience with Akka (even raw actors) than with FP libraries, but what I mentioned is definitely the general vibe in the publicly active part of the community that's I'm observing. We gotta keep in mind that there are lots of companies and devs that never talk about what they're doing in public, so of course my perception is biased by that.
My own expertise is shifting more and more to the frontend / Scala.js these days, so please forgive/correct any inaccuracies.
One reason to reach for the pure functional libraries is a desire to avoid some of the many footguns Akka / Pekko has. For a long time, using Akka meant not being able to rely on the Scala type system for checking messages sent between actors, and for the people attracted to Scala due to the advanced type system, this was a deal-breaking drawback.
All in all, the FP libraries and the actor system libraries are almost direct opposite approaches to problem solving.
There are inspiring talks on the capabilities of actor-based streams, like this one: https://www.youtube.com/watch?v=ilhImUjF53A
As someone said - these are very cool but niche capabilities that companies do not talk about. It's almost like a secret weapon in the sea of over-engineering and hype.
1) The language is too unstable - something that might seems as a great boon is actually a big problem if you want to use the language for greater periods of time.
2) The tooling around it is not the best - problem with syntax support in IDEs, sbt is still a mess. Compared to modern offerings like Rust or Go it doesn't look that great.
3) Competition is quickly catching up - this isn't 2010-2015, Scala's competitors have been evolving quickly and picking up a lot of FP features (pattern matching HOFs, etc.) that made it stand out but at the same time offering a much bigger developer base, more mature frameworks, etc. A great example of this is modern Java but also Kotlin. Scala is still great but the gap isn't as big as it was a decade ago when Scala's popularity peaked.
And of course it is still hard to find and recruit competent people, especially if you go FP-heavy using Cats/ZIO and not Java+ style. Guess that's why we see less and less new projects written in it (and most of those probably are Spark) and in many companies it's becoming a legacy language waiting for a rewrite to e.g. Java.
"Scala will continue to evolve until morale improves"
Thankfully not anymore. They got their act together and have been maintaining compatibility since Scala 3.0.0 has been released in May 2021, which is almost 4 years and counting.
https://github.com/scala/scala3/releases/tag/3.0.0
Scala 3.x is to remain compatible for the whole 3.x series (think of semantic versioning). There's no Scala 4 (breaking with Scala 3) in sight.
Also, Scala 3 and Scala 2.13 JARs are also compatible with each other, which helped with the transition.
> 2) The tooling around it is not the best
sbt may not be good. But Mill is much better than either Maven or Gradle. Especially Gradle. Bleep is also promising.
Scalafmt is widely used and liked. Scalafix -- the linter/fixer -- is used a bit less, but still of a good quality.
The only way I'm productive on scala is on Intellij, as soon as I have to even glance at the metals LSP implementation my productivity skydives
This is compounded by the fact that most good AI editors are based on VSCode, which means I either have to suffer through it, or alt-tab to intellij any time I want to edit code