5 ms·

Scala has been very enjoyable and productive for me and the teams I've worked on. The first couple years of v2 -> v3 transition were a bit rough as the tooling

Scala has been very enjoyable and productive for me and the teams I've worked on. The first couple years of v2 -> v3 transition were a bit rough as the tooling and ecosystem was catching up, but now we happily use Scala 3 with no looking back. The language and ecosystem are evolving in a good direction, and I'm happy to play a small part in that with my open source libraries for Scala.js (which is the entire reason I got into Scala in the first place – so much simpler and safer than Typescript). 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.

sgt 2y ago
How far is Java 24 from catching up to Scala though?
- haspok 2y ago
  Java will never "catch up" to Scala (for example, the type system / generics will not evolve in the foreseeable future). 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.
  - pjmlp 2y ago
    Just like Scala by virtue of being a guest language on the JVM ecosystem, never will replace Java on the minds of JVM architects. 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.
- dtech 2y ago
  They're not in the same playground. Scala has a far more advanced type system - more close in power to Typescript or Rust than Java - and capabilities like compile time metaprogramming which aren't on the Java roadmap. Or more mundane things like immutable collections or a copy method for "record" classes. Whether that's an advantage in day to day business development is a different question.
  - pas 2y ago
    Just as context for anyone curious: 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/effect/src/HKT.ts https://github.com/Effect-TS/effect/blob/main/packages/effec...
- deleted 2y ago
  [deleted]
- sideeffffect 2y ago
  Probably never. It's very slow to move. 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.
  - pas 2y ago
    If capabilities (Capture Catching) proves to be very useful (and really solves the problems it claims to be able to solve) then it's likely that Java will also implement it, no? So... in about 8-15 years?
    - sideeffffect 2y ago
      I doubt it. For Capture Catching of Capabilities to work, you need some of the unique sauce practically only Scala has. E.g. Contextual functions or path-dependent types. Java almost certainly won't adopt these.
amelius 2y ago
What kind of applications have you built in it? GUIs, or web? Mobile perhaps? AI? Does Scala have strong/weak areas here?
- threeseed 2y ago
  So I have built all sorts of applications using Scala: - 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 [1] https://slinky.dev https://slinky.dev [2] http://ox.softwaremill.com http://ox.softwaremill.com
- nikitaga 2y ago
  We built full stack web applications: Scala on the JVM on the backend, and Scala.js on the frontend. For the frontend, used React.js (via Scala.js bindings) at one company, and my own Scala.js UI library Laminar at another. Mobile was implemented as a responsive web app. I've read that you can even use React Native from Scala.js, but we haven't needed that, so I haven't tried. The older React.js bindings were somewhat cumbersome, but the newer ones (slinky.dev) were great. The rest worked very well. 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.
smokel 2y ago
> it's been an awesome force multiplier for small teams who need to productively pump out safe and ergonomic code. 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?
- threeseed 2y ago
  Type system makes a huge difference especially things like refined types: https://github.com/Iltotore/iron https://github.com/Iltotore/iron Shifts entire classes of errors to compile time.
  - beastman82 2y ago
    Most underrated library in the world
- mrkeen 2y ago
  I've had a (relatively) bad time with Scala codebases. The last one I was involved in was like a 6-minute wait between making a code-change and being able to run or test it. But I still wanna work with Scala devs. 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.
  - JackFr 2y ago
    > I'd rather work with Scala devs on a Java codebase than Java devs on a Scala codebase. And Java devs on a Scala codebase is effectively the norm once your project enters BAU/maintenance phase.
    - SOLAR_FIELDS 2y ago
      One of Scala’s major issues is that it’s too easy to write Scava IMO

sgt 2y ago

How far is Java 24 from catching up to Scala though?

haspok 2y ago
Java will never "catch up" to Scala (for example, the type system / generics will not evolve in the foreseeable future). 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.
- pjmlp 2y ago
  Just like Scala by virtue of being a guest language on the JVM ecosystem, never will replace Java on the minds of JVM architects. 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.
dtech 2y ago
They're not in the same playground. Scala has a far more advanced type system - more close in power to Typescript or Rust than Java - and capabilities like compile time metaprogramming which aren't on the Java roadmap. Or more mundane things like immutable collections or a copy method for "record" classes. Whether that's an advantage in day to day business development is a different question.
- pas 2y ago
  Just as context for anyone curious: 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/effect/src/HKT.ts https://github.com/Effect-TS/effect/blob/main/packages/effec...
deleted 2y ago
[deleted]
sideeffffect 2y ago
Probably never. It's very slow to move. 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.
- pas 2y ago
  If capabilities (Capture Catching) proves to be very useful (and really solves the problems it claims to be able to solve) then it's likely that Java will also implement it, no? So... in about 8-15 years?
  - sideeffffect 2y ago
    I doubt it. For Capture Catching of Capabilities to work, you need some of the unique sauce practically only Scala has. E.g. Contextual functions or path-dependent types. Java almost certainly won't adopt these.

amelius 2y ago

What kind of applications have you built in it? GUIs, or web? Mobile perhaps? AI? Does Scala have strong/weak areas here?

threeseed 2y ago
So I have built all sorts of applications using Scala: - 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 [1] https://slinky.dev https://slinky.dev [2] http://ox.softwaremill.com http://ox.softwaremill.com
nikitaga 2y ago
We built full stack web applications: Scala on the JVM on the backend, and Scala.js on the frontend. For the frontend, used React.js (via Scala.js bindings) at one company, and my own Scala.js UI library Laminar at another. Mobile was implemented as a responsive web app. I've read that you can even use React Native from Scala.js, but we haven't needed that, so I haven't tried. The older React.js bindings were somewhat cumbersome, but the newer ones (slinky.dev) were great. The rest worked very well. 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.

smokel 2y ago

> it's been an awesome force multiplier for small teams who need to productively pump out safe and ergonomic code. 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?

threeseed 2y ago
Type system makes a huge difference especially things like refined types: https://github.com/Iltotore/iron https://github.com/Iltotore/iron Shifts entire classes of errors to compile time.
- beastman82 2y ago
  Most underrated library in the world
mrkeen 2y ago
I've had a (relatively) bad time with Scala codebases. The last one I was involved in was like a 6-minute wait between making a code-change and being able to run or test it. But I still wanna work with Scala devs. 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.
- JackFr 2y ago
  > I'd rather work with Scala devs on a Java codebase than Java devs on a Scala codebase. And Java devs on a Scala codebase is effectively the norm once your project enters BAU/maintenance phase.
  - SOLAR_FIELDS 2y ago
    One of Scala’s major issues is that it’s too easy to write Scava IMO