still_grokking (u/still_grokking)

still_grokking commented on Scala 3 slowed us down? kmaliszewski9.github.io/s... · Posted by u/kmaliszewski

Rogach · 2 months ago

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.

still_grokking · 2 months ago

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

still_grokking commented on Scala 3 slowed us down? kmaliszewski9.github.io/s... · Posted by u/kmaliszewski

bvrmn · 2 months ago

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.

still_grokking · 2 months ago

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

still_grokking commented on Scala 3 slowed us down? kmaliszewski9.github.io/s... · Posted by u/kmaliszewski

bvrmn · 2 months ago

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

still_grokking · 2 months ago

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

still_grokking commented on Scala 3 slowed us down? kmaliszewski9.github.io/s... · Posted by u/kmaliszewski

lmm · 2 months ago

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

still_grokking · 2 months ago

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

still_grokking commented on Scala 3 slowed us down? kmaliszewski9.github.io/s... · Posted by u/kmaliszewski

Kwpolska · 2 months ago

The library that caused breakage for the OP is a good example: https://github.com/softwaremill/quicklens

still_grokking · 2 months ago

I still don't get what you want to say.

Linking some GitHub repo does not explain anything.

What is "abuse", what is "magic" in this context?

still_grokking commented on Scala 3 slowed us down? kmaliszewski9.github.io/s... · Posted by u/kmaliszewski

groundzeros2015 · 2 months ago

They absolutely do not. The problem is three-fold.

1. The rules for when an optimization works and doesn't is complex and implicit (as seen in this post).

2. The magnitude of performance between getting an optimization and not is significant.

3. When it does fail, you have almost no recourse because you can't express your intent.

Now do C. You have problem 1, but not to the same extent. In rare cases you can see problem 2. And you never have problem 3.

still_grokking · 2 months ago

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.

still_grokking commented on Scala 3 slowed us down? kmaliszewski9.github.io/s... · Posted by u/kmaliszewski

Rogach · 2 months ago

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 language isn't growing anymore, even slowly dwindling in userbase. And this became way worse after Scala 3 mess.

still_grokking · 2 months ago

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.

still_grokking commented on Scala 3 slowed us down? kmaliszewski9.github.io/s... · Posted by u/kmaliszewski

Rogach · 2 months ago

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 right from the start, and when that was finally added most of the damage was done, people already lost interest.

I understand that removing braces might feel harmless - but it really makes the code harder to read for people that use braces all the time.

If someone's brain is accustomed to seeing braces everywhere, reading code with them becomes almost automatic, handled by "low-level" parts of the brain. If the syntax is changed, then "low-level" brain areas have to pass work to "higher-level" areas, which increases energy requirements and processing latency. So reading unfamiliar syntax is literally harder.

Incidentally, that's also why many people are so picky about grammar - grammatical errors make the text noticeably harder to read.

Source: have a degree in neurophysiology.

still_grokking · 2 months ago

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.

still_grokking commented on Scala 3 slowed us down? kmaliszewski9.github.io/s... · Posted by u/kmaliszewski

gavinray · 2 months ago

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

still_grokking · 2 months ago

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

still_grokking commented on Scala 3 slowed us down? kmaliszewski9.github.io/s... · Posted by u/kmaliszewski

munchler · 2 months ago

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

still_grokking · 2 months ago

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.