Scala 3 slowed us down?

> 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.

I feel that I need to preface my answer with the defusing disclaimer: I understand that you love the language very much. And statements like the ones I make may hurt, because they say bad stuff about the thing you love. But getting defensive might detract from otherwise interesting discussion.

In fact, I also love Scala. I've dedicated lots of my time to working with it (almost 15 years at this point!), I've been with it since 2.8.x days. And I really lament that it fell out of favor and huge swaths of the community left.

> Stating this, which is not, and never was true creates the impression you're talking about things you have no clue about.

Of course it is possible that I have misremembered, so I went and checked. It was a mistake on my part to make such a statement and not to provide an actual link.

Not only it was that way, it actually still is. See the official Scala 3 reference: https://docs.scala-lang.org/scala3/reference/

All the code examples there use the new syntax. And I would guess that "Scala 3 reference" is the document that Scala 2 veterans (like myself) would have been using when learning about new features and contemplating migration to the new version.

> You need a degree to understand something such obvious? Never mind…

It might be obvious, but I felt that it wasn't obvious to some people (including the ones that were in charge of the documentation for Scala 3), so I wanted to expand a bit on that.

> The point is: New syntax is only new in the first few hours of contact with it.

Of course, but these "first few hours" are exactly the hours that were spent reading the documentation for the Scala 3, and I feel that making those hours harder wasn't the smart choice.

I think that Scala development team made a decision to chase growth, focusing on attracting new users and disregarding the old ones. Looks like they lost that bet - new users didn't come, and many old users were disappointed and left.

New syntax isn't the only problem of Scala 3, and probably it isn't even the biggest one. But it was the most glaring and visible issue - for me, almost every code example in the reference really felt like a spit in the face. Exactly this kind of off-hand dismissal of old-time users was one of the reasons some of the users started moving away from Scala (myself included).

> Braces in code are 100% redundant, useless noise.

The debate about "braces vs significant whitespace" is raging literally for decades. Like many similar debates, it seems that there's no "true solution" and no "true winner" - both sides have heaps of valid arguments.

I assume that both sides have their merits, and it's always a tradeoff between pros and cons of each approach. I use languages that have braces, and I use languages that use indentation - I see pros and cons of each approach. Outright dismissing the other side of the debate by saying that it's "100% useless" seems to be missing lots of nuance.

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.

First of all nothing in the article is about optimization. Scala does not even have an optimizer…

It was about translation strategies and macro expansion.

But this makes no difference. You have all issues you just named exactly the same in so called "high level languages" as you have in C. C is in fact a high level language, and the code you write in C has not much in common with what the machine actually executes. The last time this wasn't like that is about 40 years ago.

1. Whether the C optimizer kicks in or not is pure dark magic. Nobody can tell from just looking at the code. The optimization techniques are way too complex to be understood ad hoc, not even experts can do that.

2. The difference between the optimizer doing its work, or instead the computer just verbatim executing whatever someone written down is hilariously large! Adding -O2 can make your code many orders of magnitude faster. Or it does almost nothing… (But like said, you can't know what will happen just from looking at the code, that's point again 1.)

3. You neither can express what the machine does in C. The machine does not execute anything like C. The last time it did is over 50 years ago… Since at least 30 years we have kind of JIT compiler in the CPUs which translate the result of compilation to ASM into the actual machine language. A modern CPU needs actually to emulate a computer that still works like a PDP-11 to match the C machine model even the real hardware does not look anything like a PDP-11 any more! You have only very indirect influence on the actual machine code when writing C. It's mostly about forcing the CPU internal JIT to do something, but you have no control over it, exactly as you don't have control over what for example the JVM JIT does. It's the exact same situation, just a level lower.