[rors]

I was big fan of Scala a decade ago. The idea of a “scalable language” where DSLs could be built within the type system seemed super powerful. I lost my enthusiasm when the community decided they wanted to use it as Haskell on the JVM.

I’m hoping more recent developments, like WASM or Graal, provide a route for more flexibility when selecting languages. It’s nice to see Rust slowly become a serious choice for web development. Most of the time JS is fine, but it’s good to have the option to pull out a stricter low-level language when needed.

[Cthulhu_]

That's the main issue I found with Scala, and as I grow older also with certain libraries (especially in unit testing land) that try to add a language / DSL on top. Not only do you need to learn Scala, you need to learn various DSLs on top of that depending on what you use or want to achieve. Some egregious examples here and there.

I'm sure there's good use cases for it - one impressive example at the time was using functional programming to create Hadoop map / reduce jobs, a oneliner in Scala was five different files / classes in Java. But for most programming tasks it's overkill.

You can write boring code in Scala, but in my (limited) experience, Scala developers don't want to write boring code. They picked Scala not because it was the best tool for the job, but because they were bored and wanted to flex their skills. Disregarding the other 95% of programmers that would have to work with it.

(And since these were consultants, they left within a year to become CTOs and the like and ten years on the companies they sold Scala to are still dealing with the fallout)

[f1shy]

> Not only do you need to learn Scala, you need to learn various DSLs on top of that depending on what you use or want to achieve

That is AFAIK the "curse of lisp" because is so easy (and needed and encouraged) to write SDLs, any ecosystem grows many languages in a hurry, so suddenly that elegant minimalistic beautiful pure language, becomes 1000 beautiful clean languages. Now you have to learn them all...

[athenot]

> You can write boring code in Scala, but in my (limited) experience, Scala developers don't want to write boring code. They picked Scala not because it was the best tool for the job, but because they were bored and wanted to flex their skills. Disregarding the other 95% of programmers that would have to work with it.

Intersting observation.

So basically Scala is to the JVM what Perl is to scripting?

[vaylian]

You can write readable Scala code, just like you can write readable Perl code. But both languages allow you to to write very concise and cryptic code as well. Scala doesn't seem to optimize for the "one obvious solution" approach like Python does. Scala seems to be more TIMTOWDY like Perl.

Scala was designed from the beginning to support classical Java-style OOP code and also Haskell-like functional code. These are 2 very different styles in one language. And then Scala supports defining DSLs which give you even more flexibility.

[tasuki]

You can write boring code in Scala, but in my (limited) experience, Scala developers don't want to write boring code. Guilty as charged!

> They picked Scala not because it was the best tool for the job, but because they were bored and wanted to flex their skills.

Guilty as charged!

> Disregarding the other 95% of programmers that would have to work with it.

No. Your coworkers end up being the other 5% of programmers that have the same taste as you. Interviewers ask about monads and lenses. It's fine, as long as everyone is on the same page. Which... they kind of have to be.

[dionian]

i use scala because i can write more expressive and simpler/safer code than java language.

[dkarl]

> I lost my enthusiasm when the community decided they wanted to use it as Haskell on the JVM

It's not the whole community, not by a long shot. Don't judge Scala by the Scala subreddit.

Most new things you'll see written about Scala are about solving difficult problems with types, because those problems are inexhaustible and some people enjoy them, for one reason or another. Honestly I think this shows how easy and ergonomic everything else is with Scala, that the difficulties people write about are all about deep type magic and how to handle errors in monadic code. You can always avoid that stuff when it isn't worth it to you.

The type poindexters will tell you that you're giving up all the benefit of Scala the moment you accept any impurity or step back from the challenge of solving everything with types, and you might as well write Java instead, but they're just being jerks and gatekeepers. Scala is a wonderful language, and Scala-as-a-better-Java is a huge step up from Java for writing simple and readable code. It lets you enjoy the lowest hanging fruit of functional programming, the cases where simple functional code outshines OO-heavy imperative code, in a way that Java doesn't and probably never will.

[vjerancrnjak]

Haskell is usually used as a DSL. I believe Haxl is used at Meta and TidalCycles is a good example of another DSL built in Haskell.

Although I agree the usual lens, optics, machines, pipes or other higher kinded libs are completely unnecessary, solving problems you do not want to have and have dire performance implications, but are at least correct and allow you to throw code at problems quickly, even though that code sucks in all ways except correctness.

[antonvs]

I don’t agree that pipes should be in your list, at least for some use cases. Streaming data through pipes gives capabilities that systems written in more traditional ways often simply don’t match. Look at the use of the Stream API in Java for an example of the utility of this outside of the Haskell context.

Pipes also don’t necessarily have “dire performance implications”, but it depends a lot on the implementation. Haskell libraries don’t always emphasize real world performance as a top criterion. E.g. see https://github.com/composewell/streaming-benchmarks for some truly wild variations in performance across libraries (disclaimer: I haven’t investigated or verified those numbers.)

[cbeach]

Scala is a fantastic language and in fact I'd say it's the language that proves the article wrong.

Java was the language where "write libraries instead" happened, and it became an absolute burden. So many ugly libraries, frameworks and patterns built to overcome the limitations of a simple language.

Scala unified the tried-and-tested design patterns and library features used in the Java ecosystem into the core of its language, and we're better off for it.

In Java we needed Spring (urghh) for dependency injection. In Scala we have the "given" keyword.

In Java we needed Guava to do anything interesting with functional programming. FP features were slowly added to the Java core, but the power and expressivity of Java FP is woeful compared what's available at the core of Scala and its collections libraries.

In Java we needed Lombok and builder patterns. In Scala we have case classes, named and default parameters and immutability by default.

In the Java ecosystem, optionality comes through a mixture of nulls (yuck) and the crude and inconsistently-used "Optional". In Scala, Option is in the core, and composes naturally.

In Java, checked exceptions infect method signatures. In Scala we have Try, Either and Validated. Errors are values. It's so much more composable.

There's so much more - but hopefully I've made the point that there's a legitimate benefit in taking the best from a mature ecosystem and simple language like Java and creating a new, more elegant and complete language like Scala.

[kelnos]

I think you misunderstood the article (or only read the first couple paragraphs). The author sets the stage with the statement in the article title (a quote heard from other people), but shows that those fancy language features in some languages are exactly why rich, easy-to-use libraries can be built. And that some of these rich, easy-to-use libraries simply cannot be built in some languages that lack those features.

So you don't actually disagree with the article.

[jibal]

> the language that proves the article wrong

It helps to actually read it. The title is in quotes because the point of the article is to refute it.

[antfarm]

Have you tried Clojure(Script)? It could be just what you need, bottom-up programming in a Lisp-like language essentally means extending the langauge in order to solve the problem at hand.

Or, as Paul Grahmam put it in his 1993 book On Lisp: "a bottom-up style in which a program is written as a series of layers, each one acting as a sort of programming language for the one above"

https://paulgraham.com/progbot.html

https://www.paulgraham.com/onlisptext.html

Here is a talk that explains the concept in Clojure, titled Bottom Up vs Top Down Design in Clojure:

https://www.contalks.com/talks/1692/bottom-up-vs-top-down-de...

[sambuccid]

I recently started to learn Scala and I love it, also for it's functional aspect. Regarding your comment, it feels like scala is generic enough to be used also in other ways, and definitively for DSLs. What do you think it's missing?

[hibikir]

I think the GP is thinking about how libraries and ecosystems are often more important than the language. Most emphasis in scales is in a collection of competing frameworks that, today, are very FP oriented. Some hide the category theory while others put it up front, but it's ultimately what you do. The libraries that wanted to do imperative OO lost most support.

Also see, for instance, Java. There's Java, the language that keeps improving, and then the Spring ecosystem, which is what 95% of programmers end up having to use professionally, with its heavy "magic" component. Writing services avoiding Spring is going against the grain. It might as well be part of the language as far professional Java use is concerned.

Communities matter more than the language features, and Java is all Spring, and now Scala is really a choice of Zio and Cats

[willtemperley]

Hopefully project Panama will see better interoperability with libraries using the C memory model however migration does not appear to be easy. Arrow Java still uses sun.misc.Unsafe for native memory access.

[kayo_20211030]

Reminds me of a joke.

I have a problem.

Right, I'll design a DSL.

Hmm. Now I have two problems.

[morshu9001]

Doing fancy things with types used to interest me, now it's the last thing I want to touch, after being burned too many times by libs trying to be clever.

I used Scala a few times when it was semi popular, just seemed like Java but with lots of redundant features added. Not sure what the aim was.

[kelnos]

Certainly one can get too clever/fancy, but I appreciated that Scala let me express things in the type system that made more of my program confidently correct at compile time than I could do in Java. I hate writing tests, and with Scala, I could write fewer of them, but still be confident that things were working as intended.

But ultimately using Scala at the place I worked at the time was a failure. A couple of my co-workers had introduced it, and I joined the bandwagon at some point, but it just didn't work out.

Many Java developers inside the company didn't want to learn, and it was really hard to hire good Scala developers. The ones who did learn (myself included) wrote terrible Scala for a least the first 6 months, and that technical debt lingered for a long time. When other people outside the team (who didn't know Scala) needed to make changes to our code, they had a lot of trouble figuring things out, and even when they could, the code they wrote was -- quite understandably -- bad, creating extra work for us to review it and get it into shape.

I also feel like Scala suffers from similar complexity/ways-to-do-things problems as C++. I often hear people say things like "C++ can be a safe, consistent language if you just use a subset of it!", and then of course everyone has a subtly (or not-so-subtly) different subset that they consider as The One True Subset. With Scala, you can write some very complex, type-heavy code that's incredibly hard to read if you are not well-versed in type/category/etc. theory (especially if you are using a library like cats or scalaz). Sure, you could perhaps try to come up with some rules around what things are acceptable and what aren't, but I think in this case it's a hard thing to specify, and different people will naturally disagree on what should be allowed.

I really wanted Scala to succeed at our company, but I think that's hard to do. I feel like the ideal case is a small company with just a few tens of developers, all whom were hired specifically for their Scala expertise, with a product/business that is going to keep the number-of-developers requirement roughly static. But that's probably very rare.

[morshu9001]

C++ was how I'd describe it, too many different ways to do simple things. I guess Java++

[dionian]

then why is java adding back half baked versions of scala features every major release

[brabel]

Saying that the new Java features are half baked, to me, shows you're just feeling hurt because people prefer Java over your favourite language.

Java may not be the pinnacle of programming languages, but since Java 8, pretty much every feature it's added has been absolutely excellently done.

[dionian]

i mean, it follows the java philosophy (preseving backward compat). theyve done great work improving java. but i see no reason to use it over scala where i get better features, its more like a java 2.0

[surgical_fire]

Then don't. You can use Scala to your heart's content. No one is stopping you.

I had to work on a Scala codebase at some point, and I thought it horrible. I judge a language on how easy it allows you to create an unreadable mess. Scala makes it incredibly easy. And the people that enjoy Scala seem to like "unreadable messiness" as a feature.

I found it fun to learn the basics, and it was interesting to think of problems from a FP approach, but it is never something I would use in the real world.

I vastly prefer Java. The features it imported from Scala were fine, made the language better. It doesn't need to import everything.

[morshu9001]

Usually someone is stopping you, unless this is a hobby project. At least Scala can use Java libs so you aren't stopped by stuff not being available for it. But yeah I would never use it.

[morshu9001]

Cause it actually needed lambdas and things that go with it. Didn't need all the Scala-specific data structs like Array.

And the most important thing Java was always missing until recently, virtual threads, were lacking in Scala too.

[kelnos]

Virtual threads is a JVM & stdlib feature, not a language feature.

(And I'd disagree that virtual threads were all that important compared to language features.)

[morshu9001]

In pretty common applications, virtual threads will make the difference between chaining futures (this.then(that).then(...)) vs not, all throughout your code. Or some frameworks had far uglier ways to deal with cooperative multitasking.

[EricRiese]

Lambdas weren't simple to shoehorn into Java. But most of the recent changes have been implemented as well or better, or as well as you could imagine while maintaining backwards compatibility and Java-ness.

Records/sealed interfaces (ADTs) are quite clean.

Text Blocks are better in Java IMO. The margin junk in Scala is silly.

[tasuki]

> I used Scala a few times when it was semi popular, just seemed like Java but with lots of redundant features added. Not sure what the aim was.

Blub is a great language!