IMO Scala is one of the best programming languages out there. I know it might sound like zealotry because Scala is already way past its hype curve, and the “Through of disillusionment” already caught a fair bunch in ways that more recent and hyped languages haven’t yet, but it’s not only still very relevant today, but more and more so (IMO).
So, what’s to like about Scala? Like most of things, those are two-edged swords:
1- multi paradigm
To my knowledge Scala is the only language that unifies object oriented programming and functional programming so seamlessly. You can pick the right tool for the job, opting for imperative-style where it’s fit and choosing elegant composable/curried when appropriate, without having to bend your mind as much as you would with Haskell/clojure/OCaml/F#/… where things are more one-sided. The downside is that different programmers will have different takes and preferences as to what’s the most adequate style might be, and a same codebase might look very different from one place to the other.
2- type system
Scala has one of the most advanced type system. Nothing Rust or Kotlin might match any time soon, or ever. Scala’s implementation of GADTs, combined with its powerful pattern matching enables concise and idiomatic abstractions. Many of which are zero-cost thanks to things like opaque types, inlining, tail recursion, … There is a whole area of the Scala community striving to make invalid states irrepresentable (your code won’t compile if your instance of a pizza is missing a topping), which makes such libraries self-documenting and easy to use. The downside is that nothing prevents you from climbing the abstraction ladder and encoding everything in the type system when all you need is a simple trait/generic, and that’s a human/complexity management problem tooling and the language can hardly mitigate.
3- scalable
The author of Scala (who was a long-time Java compiler architect) wanted Scala to scale from shells one liners to complex multi-cluster distributed systems, and delivered on that. You can start small with a scala-cli proof of concept, transition to a mid-scale “python with types” kind of project, and grow up to very large and complex projects. Beyond the JVM, you can target the browser with scala-js and share models and validation logic between the front and back ends. You can target native binaries for instant startup/low footprint executables that are cheap to spin-up as microservices.
4- has a foothold in academics
A whole team at the EPFL is pushing boundaries of programming languages and using Scala and its compiler as a ground for experimentations. Scala 3 has a proven sound type system thanks to its foundations on the DOT calculus. Effects and Capabilities are being researched as part of the project Caprese to offer a solution to “what color is your function” (mixing sync and async), of memory management/lifecycles (more generic than rustc’s), of pure/side-effectful code, etc. The downside is that this gives an impression that Scala’s development lacks focus, but arguably those happen in distinct development branches and by different people.
Hi there! Looks like you linked to a Lemmy community using a URL instead of its name, which doesn’t work well for people on different instances. Try fixing it like this: !scala@programming.dev
I’d be curious to know what makes you think that. Scala 3 released relatively recently and is basically a full rewrite of the compiler with a new type system/theory and features that you will see creeping into other languages for decades to come. And Scala 3.3.0 came out weeks ago as the first LTS version of Scala 3. Things are going at a fast pace there, on the library side, ecosystems like typelevel, zio and lihaoyi got a lot of polish and focus on practical use-cases, and tooling-wise, Scala now has cohesive and easy to use IDEs, linter, reformatter, build tools, …
Sure, nothing’s perfect, but it’s a much more vibrant place than most programming communities out there :)
Scala lets you define new operators, but only in the sense that any method can be used in operator notation and method names don’t have to be alphanumeric (e.g. ++ is a valid method name).
Scala lets you quote reserved words in order to use them as identifiers. They’re quoted, though; an unquoted reserved word cannot be used as an identifier.
Several Java operators, including instanceof, are just methods in Scala. They are special in that they are final and don’t cause NPE when called on null, but they are not reserved words and can, for example, be used as local variable names.
Scala isn’t insane, just misunderstood. Its build tool, on the other hand… 😬
Scala isn’t insane, just misunderstood. Its build tool, on the other hand… 😬
Good thing is, mill brings a lot of sanity into this space. It’s been years since I’ve had to use sbt on a regular basis, and every time I looked at it since was with incomprehension and disgust. I don’t think sbt is improving in ways that makes it friendlier. Nowadays scala-cli is all the rage, and deserved (IMO).
I stand with you amongst the “displeased with sbt” crowd. If I feel the need to have my build config in a file, mill is everything I’ve ever needed. If I have just a bunch of source files and don’t want to bother with any of that, scala-cli is pretty awesome and might appeal to cargo lovers.
Mill has way too much boilerplate. It makes the same critical mistake as sbt.
Go take a look at Cargo. That is the correct way to design a build system. Configuration is purely declarative, in a language (TOML) that doesn’t even allow imperative code. Custom build behavior, if any, goes in a separate script alongside the configuration file.
Also look at Maven, which tried and failed to do what Cargo has done successfully.
I rather disagree with the statement about mill’s perceived boilerplate, you build is composed/extended from classes and traits and the behavior is provided by overrides, OOP style. It’s nothing like sbt’s layered opaque architecture, yet you can do as many complex things as you need, programmatically, with the same scala language your project is written in.
As I said, you might not need that if your build is simple enough, and the more direct equivalent to cargo would be scala-cli. Going on a tangent here, Cargo is pretty basic and restrictive: scala build tools need to concern themselves with binary/ABI compatibility and cross targets compilation (to the JVM, JS, Native, WASM, …) all at once, whereas cargo only “cares” about source compatibility (no dynamic linking, no publishing in a compiled ABI stable form).
you build is composed/extended from classes and traits and the behavior is provided by overrides, OOP style.
Yes, that’s the boilerplate I’m complaining about.
you can do as many complex things as you need, programmatically, with the same scala language your project is written in.
That belongs in a separate file, and the typical project shouldn’t need one.
the more direct equivalent to cargo would be scala-cli.
That’s a false equivalence. Cargo is a full-fledged build system and handles multi-module projects.
Cargo is pretty basic and restrictive: scala build tools need to concern themselves with binary/ABI compatibility and cross targets compilation (to the JVM, JS, Native, WASM, …) all at once, whereas cargo only “cares” about source compatibility (no dynamic linking, no publishing in a compiled ABI stable form).
That can be a problem, but it doesn’t justify Mill’s boilerplate.
I think the only way to make this constructive is if you could describe what you mean by “boilerplate”. My experience of writing and reading mill build files is that they are extremely succinct and convey their intent clearly.
And judging by your “false equivalence” statement, I’m not sure you actually read the thread I linked. Cargo is factually a very basic tool, comparatively.
I think the only way to make this constructive is if you could describe what you mean by “boilerplate”.
object, extends, def, Seq, etc. These things do not belong in the top-level description of the project.
And judging by your “false equivalence” statement, I’m not sure you actually read the thread I linked.
I just did. I am not at all convinced by lihaoyi’s reasoning. Maven already solved the “templating system” problem with POM inheritance. POMs are not functional programs. There is no need to pass values between different parts of the structure; simple variable substitution is usually adequate, and when it’s not, scripts and plugins fill the remaining gaps.
Cargo is factually a very basic tool, comparatively.
Maven isn’t, and although it has serious problems, none of them arise from the fact that its project description is not executable code. There is no need for that.
And there is a need for not-that: it takes a long time for IDEs to open sbt projects, and they frequently fail to do so at all. Maven and Cargo projects, meanwhile, open instantaneously and reliably.
I’ve only written a “hello, world” in Scala a long time ago, but it seems to be used a lot in the banking or fintech industry mostly. Is there a reason for this?
It got this foothold pre-spark, largely due to the akka and typesafe/lightbend ecosystem. Then spark resulted in a lot of data engineers picking up scala (this was my entrance, from the Hadoop map/reduce world). And now cats/zio and effect systems have rounded it out.
Personally I love scala, my teams use it heavily (mix of styles but mostly zio-http, and a lot of spark). But scala3/dotty has been problematic enough for us that we decreed people stop updating their apps. The learning curve is HIGH (esp for functional/effect system scala). The candidate pool is small. I don’t know that if I were to start a greenfield project (without all the rest of the platform already using it) I would suggest we use scala. But the rest of our platform does, and we have tooling, and L&D tracks, etc. So onwards we go.
The learning curve is an interesting one. We’ve had new devs contribute within a sprint from zero knowledge. When they are contributing to an established platform.
Once they start looking beyond the walled garden things get complex. Scala supports a lot of variety in approaches. Which do they choose? Which is ”better"? Those questions can be hard to answer.
For me the variety of choice is great. For a new dev… Not so much.
Seconding what the below poster says. Spark and akka. Akka streams, specifically, was the only real distributed streaming system for a very long time. Which is very, very nice for low latency. Even now it’s tough to beat.
Can you point to a particular project written in Scala that exemplifies the best parts of the language? I remember having a lukewarm experience with Scala when I tried it several years ago.
That was my point above about being multi-paradigm/having a powerful type system, what’s interesting about the language may depend whether you approach it from a “OOP done right”, “python with types” or “Haskell on steroids” perspective. Akka/pekko and Play projects may be in the first category, projects built with the Scala toolkit may be representative of the second, and typelevel/zio communities like heavy abstractions and pure functional programming a lot.
This approach may induce drastically different looking code, but on the upside, the Scala community seems to be converging towards those 2/3 styles nowadays, vs. the wild west of before where each project was full of its own idiosyncrasies.
IMO Scala is one of the best programming languages out there. I know it might sound like zealotry because Scala is already way past its hype curve, and the “Through of disillusionment” already caught a fair bunch in ways that more recent and hyped languages haven’t yet, but it’s not only still very relevant today, but more and more so (IMO).
So, what’s to like about Scala? Like most of things, those are two-edged swords:
1- multi paradigm
To my knowledge Scala is the only language that unifies object oriented programming and functional programming so seamlessly. You can pick the right tool for the job, opting for imperative-style where it’s fit and choosing elegant composable/curried when appropriate, without having to bend your mind as much as you would with Haskell/clojure/OCaml/F#/… where things are more one-sided. The downside is that different programmers will have different takes and preferences as to what’s the most adequate style might be, and a same codebase might look very different from one place to the other.
2- type system
Scala has one of the most advanced type system. Nothing Rust or Kotlin might match any time soon, or ever. Scala’s implementation of GADTs, combined with its powerful pattern matching enables concise and idiomatic abstractions. Many of which are zero-cost thanks to things like opaque types, inlining, tail recursion, … There is a whole area of the Scala community striving to make invalid states irrepresentable (your code won’t compile if your instance of a pizza is missing a topping), which makes such libraries self-documenting and easy to use. The downside is that nothing prevents you from climbing the abstraction ladder and encoding everything in the type system when all you need is a simple trait/generic, and that’s a human/complexity management problem tooling and the language can hardly mitigate.
3- scalable
The author of Scala (who was a long-time Java compiler architect) wanted Scala to scale from shells one liners to complex multi-cluster distributed systems, and delivered on that. You can start small with a scala-cli proof of concept, transition to a mid-scale “python with types” kind of project, and grow up to very large and complex projects. Beyond the JVM, you can target the browser with scala-js and share models and validation logic between the front and back ends. You can target native binaries for instant startup/low footprint executables that are cheap to spin-up as microservices.
4- has a foothold in academics
A whole team at the EPFL is pushing boundaries of programming languages and using Scala and its compiler as a ground for experimentations. Scala 3 has a proven sound type system thanks to its foundations on the DOT calculus. Effects and Capabilities are being researched as part of the project Caprese to offer a solution to “what color is your function” (mixing sync and async), of memory management/lifecycles (more generic than rustc’s), of pure/side-effectful code, etc. The downside is that this gives an impression that Scala’s development lacks focus, but arguably those happen in distinct development branches and by different people.
Anyway, feel free to continue the discussion on: !scala@programming.dev
Hi there! Looks like you linked to a Lemmy community using a URL instead of its name, which doesn’t work well for people on different instances. Try fixing it like this: !scala@programming.dev
IMO this should be a feature of the comments editor, if this matters at all.
Good bot
Scala is really nice and fun, but I get the feeling that it’s been kinda dead for a pretty long time
I’d be curious to know what makes you think that. Scala 3 released relatively recently and is basically a full rewrite of the compiler with a new type system/theory and features that you will see creeping into other languages for decades to come. And Scala 3.3.0 came out weeks ago as the first LTS version of Scala 3. Things are going at a fast pace there, on the library side, ecosystems like typelevel, zio and lihaoyi got a lot of polish and focus on practical use-cases, and tooling-wise, Scala now has cohesive and easy to use IDEs, linter, reformatter, build tools, …
Sure, nothing’s perfect, but it’s a much more vibrant place than most programming communities out there :)
Yeah … but Scala is insane, you can fundamentally redefine the behavior of reserved words.
Since when?
Scala lets you define new operators, but only in the sense that any method can be used in operator notation and method names don’t have to be alphanumeric (e.g.
++is a valid method name).Scala lets you quote reserved words in order to use them as identifiers. They’re quoted, though; an unquoted reserved word cannot be used as an identifier.
Several Java operators, including
instanceof, are just methods in Scala. They are special in that they arefinaland don’t cause NPE when called onnull, but they are not reserved words and can, for example, be used as local variable names.Scala isn’t insane, just misunderstood. Its build tool, on the other hand… 😬
Good thing is, mill brings a lot of sanity into this space. It’s been years since I’ve had to use sbt on a regular basis, and every time I looked at it since was with incomprehension and disgust. I don’t think sbt is improving in ways that makes it friendlier. Nowadays scala-cli is all the rage, and deserved (IMO).
Scala desperately needs a new build system along the lines of Cargo. Sbt is a mess.
I stand with you amongst the “displeased with sbt” crowd. If I feel the need to have my build config in a file, mill is everything I’ve ever needed. If I have just a bunch of source files and don’t want to bother with any of that, scala-cli is pretty awesome and might appeal to cargo lovers.
Mill has way too much boilerplate. It makes the same critical mistake as sbt.
Go take a look at Cargo. That is the correct way to design a build system. Configuration is purely declarative, in a language (TOML) that doesn’t even allow imperative code. Custom build behavior, if any, goes in a separate script alongside the configuration file.
Also look at Maven, which tried and failed to do what Cargo has done successfully.
I rather disagree with the statement about mill’s perceived boilerplate, you build is composed/extended from classes and traits and the behavior is provided by overrides, OOP style. It’s nothing like sbt’s layered opaque architecture, yet you can do as many complex things as you need, programmatically, with the same scala language your project is written in.
As I said, you might not need that if your build is simple enough, and the more direct equivalent to cargo would be scala-cli. Going on a tangent here, Cargo is pretty basic and restrictive: scala build tools need to concern themselves with binary/ABI compatibility and cross targets compilation (to the JVM, JS, Native, WASM, …) all at once, whereas cargo only “cares” about source compatibility (no dynamic linking, no publishing in a compiled ABI stable form).
Here’s an interesting thread describing very well the problem space, and elaborating on the situation in rust/js (reply from mdedetrich): https://www.reddit.com/r/scala/comments/12jhud7/comment/jg2aecf/
Yes, that’s the boilerplate I’m complaining about.
That belongs in a separate file, and the typical project shouldn’t need one.
That’s a false equivalence. Cargo is a full-fledged build system and handles multi-module projects.
That can be a problem, but it doesn’t justify Mill’s boilerplate.
I think the only way to make this constructive is if you could describe what you mean by “boilerplate”. My experience of writing and reading mill build files is that they are extremely succinct and convey their intent clearly.
And judging by your “false equivalence” statement, I’m not sure you actually read the thread I linked. Cargo is factually a very basic tool, comparatively.
object,extends,def,Seq, etc. These things do not belong in the top-level description of the project.I just did. I am not at all convinced by lihaoyi’s reasoning. Maven already solved the “templating system” problem with POM inheritance. POMs are not functional programs. There is no need to pass values between different parts of the structure; simple variable substitution is usually adequate, and when it’s not, scripts and plugins fill the remaining gaps.
Maven isn’t, and although it has serious problems, none of them arise from the fact that its project description is not executable code. There is no need for that.
And there is a need for not-that: it takes a long time for IDEs to open sbt projects, and they frequently fail to do so at all. Maven and Cargo projects, meanwhile, open instantaneously and reliably.
I’ve only written a “hello, world” in Scala a long time ago, but it seems to be used a lot in the banking or fintech industry mostly. Is there a reason for this?
It got this foothold pre-spark, largely due to the akka and typesafe/lightbend ecosystem. Then spark resulted in a lot of data engineers picking up scala (this was my entrance, from the Hadoop map/reduce world). And now cats/zio and effect systems have rounded it out.
Personally I love scala, my teams use it heavily (mix of styles but mostly zio-http, and a lot of spark). But scala3/dotty has been problematic enough for us that we decreed people stop updating their apps. The learning curve is HIGH (esp for functional/effect system scala). The candidate pool is small. I don’t know that if I were to start a greenfield project (without all the rest of the platform already using it) I would suggest we use scala. But the rest of our platform does, and we have tooling, and L&D tracks, etc. So onwards we go.
The learning curve is an interesting one. We’ve had new devs contribute within a sprint from zero knowledge. When they are contributing to an established platform.
Once they start looking beyond the walled garden things get complex. Scala supports a lot of variety in approaches. Which do they choose? Which is ”better"? Those questions can be hard to answer.
For me the variety of choice is great. For a new dev… Not so much.
C++ has the same issue, and that doesn’t stop everyone from using it.
Seconding what the below poster says. Spark and akka. Akka streams, specifically, was the only real distributed streaming system for a very long time. Which is very, very nice for low latency. Even now it’s tough to beat.
Can you point to a particular project written in Scala that exemplifies the best parts of the language? I remember having a lukewarm experience with Scala when I tried it several years ago.
That was my point above about being multi-paradigm/having a powerful type system, what’s interesting about the language may depend whether you approach it from a “OOP done right”, “python with types” or “Haskell on steroids” perspective. Akka/pekko and Play projects may be in the first category, projects built with the Scala toolkit may be representative of the second, and typelevel/zio communities like heavy abstractions and pure functional programming a lot.
This approach may induce drastically different looking code, but on the upside, the Scala community seems to be converging towards those 2/3 styles nowadays, vs. the wild west of before where each project was full of its own idiosyncrasies.