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

171–180 of 195 posts

Re: Scala 3 slowed us down?

#171

Post by still_grokking »

groundzeros2015 wrote: post #97
blandflakes wrote: post #93

Earlier quoted context omitted.

The bug in TFA is hardly a reason that Scala is not a success, though.

I didn’t say that. I’m highlighting a specific challenge of getting predictable performance over the lifetime of code. Lower-level languages don’t have this same problem to the same extent. They have other problems Scala doesn’t have.

> Lower-level languages don’t have this same problem to the same extent.

Of course they have.

If the computer would directly execute what you write down in what you call "low level language" this would be slow as fuck.

Without highly optimizing compilers even stuff like C runs pretty slow.

If something about the optimizer or some other translation step of a compiler changes this has often significant influence on the performance of the resulting compilation artifacts.

Re: Scala 3 slowed us down?

#172

Post by still_grokking »

scotty79 wrote: post #84

It's quite impressive that you can swap out major version from under running application and have just one subtle issue.

The upgrade Scala 2 -> 3 is usually super smooth. The compiler does all the work, you just need to update your build config / dependencies.

The only exception is macros: If you used the experimental Scala 2 macros you need to migrate them to the new system which is completely different.

Re: Scala 3 slowed us down?

#173

Post by still_grokking »

rr808 wrote: post #101

I'm on Spark Scala 2 project and I hate it. Basically any good Scala dev would never want to work on our ETL projects, so we get second rate Python or Java devs like me who bastardize the language to get anything to work. Most of our new stuff is all pyspark, hopefully we can replace Scala asap.

What's so bad about it?

Why not try to learn it for good?

Re: Scala 3 slowed us down?

#174

Post by still_grokking »

phendrenad2 wrote: post #29

Controversial opinion: Scala should have gone into maintenance mode a decade ago. They got the language right at the beginning, and a decade of tinkering has just fatigued everyone and destroyed any momentum the language once had.

Sure. All successful languages go into decades still stand.

Just see how great this worked out for Java (or Perl… ;-))!

/s

Re: Scala 3 slowed us down?

#175

Post by still_grokking »

hunterpayne wrote: post #76
instig007 wrote: post #33

Earlier quoted context omitted.

> and a decade of tinkering has just fatigued everyone and destroyed any momentum the language once had. it's hard to buy it, considering that many of those "fatigued" moved on Kotlin, led by their managers' bs talking points.

Many of the Scala projects got people fired. Something the Scala devs largely ignore. Plus Scala support is truly awful even by the low standards of an OpenSource project. Then there is the fact that the Scala specific libraries are largely dead. Scala had/has a lot of promise. But how the language is marketed/managed/maintained really let a lot of people down and caused a lot of saltiness about it. And that is befor…

> The original language spec is the best thing the Scala devs ever made.

The overreaching majority thinks that Scala 3 is objectively much better than Scala 2 ever was. That's at least what you hear just everywhere, besides the occasional outlier by some Scala 2 die hards.

Re: Scala 3 slowed us down?

#176

Post by still_grokking »

hocuspocus wrote: post #88
hunterpayne wrote: post #76

Earlier quoted context omitted.

Many of the Scala projects got people fired. Something the Scala devs largely ignore. Plus Scala support is truly awful even by the low standards of an OpenSource project. Then there is the fact that the Scala specific libraries are largely dead. Scala had/has a lot of promise. But how the language is marketed/managed/maintained really let a lot of people down and caused a lot of saltiness about it. And that is befor…

Kotlin has become a pretty big and complex language on its own so I'm not sure this is a good counterexample. The fundamental issue is that fixing Scala 2 warts warranted an entirely new compiler, TASTy, revamped macros... There was no way around most of the migration pains that we've witnessed. And at least the standard library got frozen for 6+ years. However I agree that the syntax is a textbook case of trying to…

> However I agree that the syntax is a textbook case of trying to fix what ain't broke.

The great new syntax is the very reason I don't want to even touch Scala 2 any more.

The syntax change is the absolute highlight in Scala 3. It makes the language so much better!

The only real problem was that it happened so late; at least a decade too late.

Re: Scala 3 slowed us down?

#177

Post by still_grokking »

munchler wrote: post #102
hunterpayne wrote: post #72

Earlier quoted context omitted.

Because the jit will let the unoptimized code run a few (hundred) times to take measurements to know what needs to be optimized and how it needs to be optimized. This is a good solution and makes hotspot very effective. The problem is that it happens randomly a few minutes/seconds into the operation of the service. So you randomly have a big pause with the performance hit everytime you run the service. The upside is…

Ah, that’s interesting. I wasn’t aware that JIT-ing will do that sort of performance analysis first. Thank you for the explanation.

It won't in general.

Doing so is a feature of high-end VM runtimes like the state of the art JVMs or JS runtimes.

Re: Scala 3 slowed us down?

#178

Post by still_grokking »

gavinray wrote: post #61
dtech wrote: post #34

Earlier quoted context omitted.

Macro's are compile time, there is no runtime codegen. The problem was overly-frequent inlining generating enormous expressions, causing a lot JIT phase and slow execution.

That's not true, Spark's entire query engine relies on use of runtime codegen via macros/quasi quotes Look up the architecture of Catalyst + Tungsten https://www.databricks.com/glossary/catalyst-optimizer

Scala 2's macros are compile time constructs. There is no runtime code generation / staging.

Scala 3's macros support staged compilation, so you can have macros which create code in later stages at runtime.

https://docs.scala-lang.org/scala3/reference/metaprogramming...

Re: Scala 3 slowed us down?

#179

Post by still_grokking »

Rogach wrote: post #164
still_grokking wrote: post #155

Earlier quoted context omitted.

> In the end it was "so bad so sad you can always reenable brackets". This is not true. Nobody ever proposed to replace the old syntax! The new syntax was, and is, optional, and that's exactly like designed from the very beginning.

They didn't explicitly propose replacing the syntax, true. But to an outsider, it sure looked like the new syntax was a priority - all the examples and code snippets in the official docs defaulted to the new syntax, making them infuriating to read for someone accustomed to braces. If I recall correctly, later they added a switch allowing one to choose between syntax versions in the online docs. But it wasn't done rig…

Examples and code snippets in the official docs of course default to the new syntax, making them well readable for all people accustomed to Scala's new syntax.

> If I recall correctly, later they added a switch allowing one to choose between syntax versions in the online docs.

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

The point is: Removing braces really makes code much easier to read for people who get distracted by useless line noise!

> So reading unfamiliar syntax is literally harder. > […] > Source: have a degree in neurophysiology.

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

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

Anybody who uses more than one language knows that switching languages is in fact a bit distracting, but at latest on the second day you completely stop thinking about syntax, and than switching back to whatever was before is as hard as the previous switch to the current thing. Usually this happens already after a few hours for languages you already know.

As we're talking about neurophysiology: As a matter of fact filtering "noise" — irrelevant information — from sensory input is a hard task for the brain. So having less distracting useless noise in the input helps to concentrate on the stuff that actually matters!

Braces in code are 100% redundant, useless noise. The only reason they were added in the first place was to make code simpler to parse for computers, something that does not matter any more since many decades. So there is no rational reason any more to pollute code with useless, distracting noise.

Re: Scala 3 slowed us down?

#180

Post by still_grokking »

Rogach wrote: post #163
still_grokking wrote: post #153

Earlier quoted context omitted.

> It was a little weird it blew up in industry for a while. It never went away. It only got more: https://business4s.org/scala-adoption-tracker/

Wow, 34 companies with "possibly" 233 more! I don't see the chart with changes of number of companies using Scala over time. But even without the chart - if after 15 years there are less than 300 companies in total, that's a bit depressing. Of course legacy never goes away, and even 20 years down the line there will still be some demand for Scala programmers. Similar to how Cobol still lives on. But in my experience…

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, when people realize that feature rich, safety first languages aren't for the mass market, where mostly only the cost of initial development counts.

Post reply on HN