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

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.

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

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

Sure. All successful languages go into decades still stand.

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

/s

What's so bad about it?

Why not try to learn it for good?

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.

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

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.

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.

> Especially when the libraries abuse magic language features (and far too many Scala libraries do)

Would you mind to explain what you mean?

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

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?

Just for context, a lot of people in the community think that this syntax change was the best thing that happened to Scala since its inception.

Also the silent majority thinks that the people who still lament over that change are just a very vocal minority.

Almost all Scala 3 code uses the new syntax, no matter how loud a few people cry. Similar situation to systemd on Linux…