Scala 3 slowed us down? • Hacker News Board

Re: Scala 3 slowed us down?

#191

Post by still_grokking » Mon, Dec 15, 2025, 12:00 AM UTC

lmm wrote: post #181

still_grokking wrote: post #167

Earlier quoted context omitted.

There's still a working Eclipse plugin? Does Eclipse now support LSP servers? The most reliable Scala IDE is currently Metals (in VSCode, but other editors work, too). Metals uses directly the compiler for all code intelligence so it's as reliable as the compiler itself. https://scalameta.org/metals/ https://scalameta.org/metals/docs/#editor-support

> There's still a working Eclipse plugin? For Scala 2, yes, or there was the last I looked. Still the best Scala development experience by some margin, sadly. > Metals uses directly the compiler for all code intelligence so it's as reliable as the compiler itself. Not my experience; maybe it theoretically should be but the integration/bridging piece is still flaky.

> or Scala 2, yes, or there was the last I looked. Still the best Scala development experience by some margin, sadly.

I can't find it.

Could you link to that "best Scala development experience by some margin"?

All I know is that the Eclipse plugin is dead since about one decade. But maybe I just missed something.

> the integration/bridging piece is still flaky

What concrete issues do you have?

I'm using Metals on a daily basis and don't know about any such problems.

Could it be that the last time you've seen Scala (if you actually ever seen it at all) was about 10 years ago?

The discussions here on HN regarding Scala seem always massively dishonest, with a lot of people always spreading outright FUD for some reason I don't understand…

Re: Scala 3 slowed us down?

#192

Post by still_grokking » Mon, Dec 15, 2025, 12:24 AM UTC

bvrmn wrote: post #184

still_grokking wrote: post #158

Earlier quoted context omitted.

Python's approach is one of the most confusing ways to possibly do it. Not having proper, discoverable methods is super annoying, and I need to look it up every time anew I use Python because it's so unintuitive. Of course you can write a generic version of `mkString` (as this method is called in Scala), so it's also just one method no matter the container count. The Python weirdness is actually a direct result from…

From typing perspective there is no sense to have Container[T].join() -> str for any T.

That's obviously the wrong signature.

The semantically correct one is "Container[T : Printable].join(): String"; T must implement the Printable concept, but Python lacks concepts (or type-classes as these are alternatively called).

But this all is irrelevant as this is anyway not the signature of `str.join()` in Python. It's `str.join(Iterable[str]) -> str` there. With sane design and syntax it would just become `Iterable[str].join(str)`.

Re: Scala 3 slowed us down?

#193

Post by still_grokking » Mon, Dec 15, 2025, 12:41 AM UTC

bvrmn wrote: post #187

mystifyingpoi wrote: post #185

Earlier quoted context omitted.

I agree, but from convenience perspective there is a lot of sense. Java Streams is actually a good example of a "correct" design, but not very convenient.

That's my point. Python has convenient and good type design with str.join ignored by other languages. For example I'm lost which abstract class to inherit in Scala to obtain mkString for my custom container.

> Python has convenient and good type design with str.join ignored by other languages.

Of course such non-discoverable and unintuitive design gets ignored everywhere!

We just established that even in Python the correct way to do it would be

  Iterable[str].join(str) -> str

but for that Python would need generic iterators on the language level…

> For example I'm lost which abstract class to inherit in Scala to obtain mkString for my custom container.

So you're saying you've been able to implement custom Scala collection types, which is regarded some of the more difficult stuff one could possibly do, but you don't know how to implement an Iterator for your custom collection—as this is all needed for mkString to work? BTW, how did you implement the collection type at all without implementing Iterator for it? Your collection is not Iterable?

TBH, this does not sound very realistic. This sounds more like typical HN Scala FUD. People throwing around some vague, most of the time outright made up issues they've heard about somewhere about 10 - 15 years ago.

Re: Scala 3 slowed us down?

#194

Post by still_grokking » Mon, Dec 15, 2025, 1:27 AM UTC

Rogach wrote: post #182

still_grokking wrote: post #180

Earlier quoted context omitted.

The website is a private undertaking which started literally a few days ago. It's not some official complete tracker. The point was to show that big corps are dependent on Scala, often at their core. Scala is likely not for everybody, but where you need to write safe high level code there is more or less no alternative, not even on the horizon. Scala is simply very likely where Rust will end up after the honeymoon, w…

True, Scala (the language) offers lots of great functionality. And Scala 3 brought some important improvements. But safety is not the only important aspect of a programming language. For me personally the community (libraries, tools, forums, blogs, etc) became much more important over the years, and I feel that Scala 3 really hurt the community angle.

> But safety is not the only important aspect of a programming language.

That's also part of what I've said.

The point still being: Where you need a safe language there is no way around it, and Scala is still one of the very few options you have at all. Scala is in that regard indispensable.

> I feel that Scala 3 really hurt the community angle

I don't see that.

Everything relevant, besides Spark, is now on Scala 3, and this is already like that since a few years.

But I agree that Scala documentation / references / tutorials are to this very day lacking. This was and still is a real issue, and that's actually a very relevant one. I really hope this gets better with time.

The sub-optimal situation regarding docs does though not prevent people from starting new projects in Scala.

In fact Scala 3 is again ahead of the pack. It provides features not seen so far in any real world language and will almost certainly again pioneer the implementation of new language concepts in the large, as it did already in the past with its pragmatic approach to a OOP / FP fusion.

Just see for yourself what is currently happening:

https://softwaremill.com/understanding-capture-checking-in-s...

Re: Scala 3 slowed us down?

#195

Post by vips7L » Wed, Dec 17, 2025, 4:59 AM UTC

esafak wrote: post #18

hylaride wrote: post #14

Earlier quoted context omitted.

Outside of Android work, has Kotlin really taken over? My understanding is that Java added a lot of functional programming and that took a lot of wind out of Scala's sails (though Scala's poor tooling certainly never helped anything).

Java's new features are always going to be on paper. The ecosystem, with all its legacy code, is always going to be a decade behind. And if you are starting a new project, why would you pick Java over Kotlin?

The ecosystem is perfectly fine. You’re more than likely using the ecosystem when you choose Kotlin, that’s the whole point. This comment doesn’t make any sense.