Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala 3 slowed us down?

kmaliszewski9.github.io

Post reply on HN
Print view View original

111–120 of 195 posts

Re: Scala 3 slowed us down?

#111

Post by blandflakes »

pjmlp wrote: post #47
noelwelsh wrote: post #37

Earlier quoted context omitted.

Everything is up to date with the new syntax as far as I'm aware. Also, the compiler and scalafmt can rewrite one to the other. A project can pick whatever style it wants and have CI reformat code to that style.

When I checked a year ago, the IDE tooling still wasn't quite there.

I always find downvoting on stuff like this perplexing. It still isn't there. I know that a lot of Scala people are doing metals and some kind of text editor experience, but if you've used something as powerful as Intellij, the Scala 3 experience is a serious downgrade, and it still is today, even though it's better than it was a year ago.

Re: Scala 3 slowed us down?

#112

Post by Pet_Ant »

hunterpayne wrote: post #87
imtringued wrote: post #78

Earlier quoted context omitted.

What you're asking for is essentially commercial support from Oracle.

Nope, what I am asking for is disabling an on by default feature that maybe 1% of the market wants and/or needs and creates significant pain for the other 99%. By the time strong encapsulation meets an attacker, the battle is already lost most of the time.

That feature is necessary to enable future enhancements. It’s an important stepping stone. Just update your code. I’m doing it on 20 year old legacy billion dollar code base. It can be done.

Re: Scala 3 slowed us down?

#114

Post by AdieuToLogic »

_old_dude_ wrote: post #10

In Scala 3, the inline keyword is part of the macro system. When inline is used on a parameter, it instructs the compiler to inline the expression at the call site. If the expression is substantial, this creates considerable work for the JIT compiler. Requesting inlining at the compiler level (as opposed to letting the JIT handle it) is risky unless you can guarantee that a later compiler phase will simplify the inli…

> There's an important behavioral difference between Scala 2 and 3: in 2, @inline was merely a suggestion to the compiler, whereas in 3, the compiler unconditionally applies the inline keyword. Consequently, directly replacing @inline with inline when migrating from 2 to 3 is a mistake.

This reminds me of a similar lesson C/C++ compilers had to learn with the "register" keyword. Early versions treated the keyword as a mandate. As compiler optimizers became more refined, "register" was first a recommendation and then ultimately ignored.

The C++ inline keyword is treated similarly as well, with different metrics used of course.

EDIT:

Corrected reference to early C/C++ keyword from "auto" to "register".

Re: Scala 3 slowed us down?

#115

Post by ergocoder »

pjmlp wrote: post #6

The only issue I have with Scala 3 is Python envy, they should not have come up with a second syntax, and pushing it as the future. If anything is slowly down Scala 3 is that, including the tooling ecosystem that needs to be updated to deal with it.

It's on brand for Scala to have multiple ways of achieving the same thing.

Now we x2 by having the curly brace syntax and the indent syntax.

Re: Scala 3 slowed us down?

#116

Post by cpeterso »

AdieuToLogic wrote: post #114
_old_dude_ wrote: post #10

In Scala 3, the inline keyword is part of the macro system. When inline is used on a parameter, it instructs the compiler to inline the expression at the call site. If the expression is substantial, this creates considerable work for the JIT compiler. Requesting inlining at the compiler level (as opposed to letting the JIT handle it) is risky unless you can guarantee that a later compiler phase will simplify the inli…

> There's an important behavioral difference between Scala 2 and 3: in 2, @inline was merely a suggestion to the compiler, whereas in 3, the compiler unconditionally applies the inline keyword. Consequently, directly replacing @inline with inline when migrating from 2 to 3 is a mistake. This reminds me of a similar lesson C/C++ compilers had to learn with the "register" keyword. Early versions treated the keyword as…

Do you mean the ‘register’ keyword?

Re: Scala 3 slowed us down?

#117

Post by ergocoder »

hunterpayne wrote: post #64

The problem with Scala 3 is that nobody asked for it. The problem with Scala 2 is that the type inference part of the compiler is still broken. Nobody worked on that. Instead they changed the language in ways that don't address complaints. Completely ignore the market and deliver a product nobody wants. That's what happened here. PS Perhaps they should make an actual unit test suite for their compiler. Instead they h…

You capture the root issue quite well.

Now every tool has to adapt to Scala 3. And you guess it? It will take time. Even IntelliJ still doesn't correctly highlight syntax on some parts that also exist in Scala 2. And this has been years after Scala 3 was launched. It's mind-boggling.

They could have improved upon Scala 2 and incrementally add more capabilities. It's obvious they don't care about Scala's industry success. They care mostly about the academic success. Nothing wrong with that, but that should be made very clear.

In Scala, they have a huge debate with zealots arguing against, for example, early return; they would describe how bad it will be blah blah blah e.g. https://tpolecat.github.io/2014/05/09/return.html, meanwhile Kotlin supports early return with absolutely no issue.

Re: Scala 3 slowed us down?

#118

Post by AdieuToLogic »

cpeterso wrote: post #116
AdieuToLogic wrote: post #114

Earlier quoted context omitted.

> There's an important behavioral difference between Scala 2 and 3: in 2, @inline was merely a suggestion to the compiler, whereas in 3, the compiler unconditionally applies the inline keyword. Consequently, directly replacing @inline with inline when migrating from 2 to 3 is a mistake. This reminds me of a similar lesson C/C++ compilers had to learn with the "register" keyword. Early versions treated the keyword as…

Do you mean the ‘register’ keyword?

> Do you mean the ‘register’ keyword?

Yes I did, my bad.

Re: Scala 3 slowed us down?

#119

Post by monksy »

hunterpayne wrote: post #64

The problem with Scala 3 is that nobody asked for it. The problem with Scala 2 is that the type inference part of the compiler is still broken. Nobody worked on that. Instead they changed the language in ways that don't address complaints. Completely ignore the market and deliver a product nobody wants. That's what happened here. PS Perhaps they should make an actual unit test suite for their compiler. Instead they h…

It was absolutely amazing how stubborn and ridiculous the whole bracket-less syntax change was handled. It was basically a dictatorial decision that they pretended to be a community decision. It was just pushed and tons of people voiced their disapproval. In the end it was "so bad so sad you can always reenable brackets".

They did it to try to appeal to Pythonists.. turns out that wasn't why Pythonists didn't use scala in the first place.

Re: Scala 3 slowed us down?

#120

Post by AdieuToLogic »

cpeterso wrote: post #116
AdieuToLogic wrote: post #114

Earlier quoted context omitted.

> There's an important behavioral difference between Scala 2 and 3: in 2, @inline was merely a suggestion to the compiler, whereas in 3, the compiler unconditionally applies the inline keyword. Consequently, directly replacing @inline with inline when migrating from 2 to 3 is a mistake. This reminds me of a similar lesson C/C++ compilers had to learn with the "register" keyword. Early versions treated the keyword as…

Do you mean the ‘register’ keyword?

My root-cause analysis:

I was visualizing Scala method definitions and associated the language's type inference with keyword use, thus bringing C++'s "auto" keyword to mind when the long-since deprecated "register" keyword was the correct subject.

It would appear LLM's are not the only entities which can "hallucinate" a response. :-D

Post reply on HN