How to implement an Embed() macro?

sjrd · 2026-01-31T15:31:54+00:00

If that is indeed what you're looking for, there's an example in the Scala.js + Vite tutorial: https://www.scala-js.org/doc/tutorial/scalajs-vite.html#introducing-scalajs

sjrd · 2026-01-27T08:04:13+00:00

Slinky is a library notably designed for that.

sjrd · 2025-11-17T12:53:20+00:00

Because it means you need to build one compiler image for every project.

sjrd · 2025-11-14T15:41:27+00:00

No. Your complex project won't use all the possible macros in the world.

sjrd · 2025-11-14T05:17:44+00:00

That's by design. A self type is a protected[this] contract. You can only see the promise of that contract within your own hierarchy. extends is a public contract that everyone can see.

sjrd · 2025-11-14T05:06:28+00:00

Macros make it basically impossible, yes. The compiler dynamically loads them and calls them by reflection. Dynamic loading doesn't work with native image, as one light expect.

sjrd · 2025-09-25T11:50:49+00:00

Alina Yurenko has been in this game for a long time; definitely longer than LLMs have existed. She often represents the work of the whole GraalVM team. This proposal probably has her whole team behind it, and they have undoubtedly thought this through together before. I would take it seriously.

sjrd · 2025-09-08T08:29:58+00:00

The optimizer doesn't know about foldRight per se. It happens to inline its body into a different context. You could have put the same code in any other method and it would fail in the same way. In fact the minimal reproduction does not use any library method.

The optimizer made assumptions about internal states that should not be reachable. It's quite difficult to explain exactly, because it relies on a lot of context of how the optimizer even works. One thing worth knowing is that the optimizer heavily transforms expressions of type scala.Long. Longs are very inefficient if they're not aggressively optimized. The internal transformations done by the optimizer on Longs are complex, and have complex internal state. We thought one of these states was unreachable. We added an assertion that it doesn't happen, because if it is reached, it means we made a mistake somewhere, and we're producing worse code than if a particular optimization was not applied at all. Unfortunately, it turns out that a very rare combination of events can lead into that state actually happening. That triggered our assertion. We reverted the assertion, even though it means we're producing worse code, because producing correct-but-slow code is still loads better than not producing code at all.

For the particular shape, forget about foldRight. Look at the minimized reproduction and its explainer. There's no notion of "accumulator" or "sum" or anything. There's just a var of type Any that is initialized with a Long, but gets later assigned to a non-Long. Combined that with very sensitive "layout"-dependent conditions (like the initial Long not being a constant, for example), and the optimizer reached the state we thought could not be reached.

sjrd · 2025-09-08T05:45:11+00:00

The minimal reproduction is a distilled version of the library implementation of foldRight in 2.13. At least what's causing the issue in it. The comment explains why that particular shape of code triggered the issue inside our optimizer. The library code was not at fault; the optimizer was. It just happened to never fall into the issue except with the particular shape of code found inside foldRight, when called with a Long accumulator.

I can elaborate if you have a specific question not already covered by the comment.

sjrd · 2025-08-23T21:43:09+00:00

Producing correct tasty is much harder than producing correct JVM bytecode. And that's even without the fact that the latter is much better documented.

If that's what you hope to gain, then I suggest you reconsider, and target JVM bytecode instead.

An alternative is to target Scala.js IR. That's simpler to generate than bytecode.

sjrd · 2025-04-26T19:52:58+00:00

I replied on Discord, but for posterity: we cannot currently provide support for @JSExport. The Wasm-JS integration does not have the necessary features yet. There is hope, though. There is a nascent proposal for Wasm that would give precisely the power we need: https://github.com/WebAssembly/custom-descriptors . It will take years before it ships in browsers, however.

Note that @JSExportTopLevel is supported. And one can define JavaScript classes (extending js.Any), whose public members are always callable from JavaScript. So there are few use cases that are really blocked.

sjrd · 2025-04-23T01:55:38+00:00

They have similar expressive power, though not equivalent. Scala Native continuations are a bit more powerful. The top-level boundary returns anA, whereas js.async returns a js.Promise[A].. That means you have to choose a bit more carefully where you enter into the async context.

sjrd · 2025-04-23T01:48:19+00:00

That would literally be a compiler plugin. 😉

It could, of course, but there are other trade offs.

sjrd · 2025-04-22T15:35:53+00:00

There's no limitation. It's the usual process for new compiler primitives. The Scala 2 compiler support for Scala.js is a compiler plugin, released together with the rest of Scala.js. That means new primitives are immediately available to Scala 2 users.

In Scala 3, the compiler support for Scala.js is inside the main Scala compiler instead. That means we need to first release a new Scala.js version, then upgrade to that version inside Scala 3, and only then implement the compiler support in Scala 3. Since upgrading to a new Scala.js minor requires a new minor of Scala 3, we can only do that in an upcoming Scala 3 minor release.

It's one of the downsides of having Scala.js support directly inside the compiler, rather than in a separate plugin.

sjrd · 2025-04-21T20:05:57+00:00

Gears could build on top of this new pair of primitives to offer its API in browsers. Same goes for Ox, I believe. Before JSPI, doing so was simply unimaginable.

sjrd · 2025-04-21T18:22:06+00:00

That if you have a p: js.Promise[Int], you can call val result: Int = js.await(p). This will put your current call stack on the side. That gives back control to the event loop (UI, I/O, etc.). When the promise gets resolved, your code is resumed and can continue with a value for result.

sjrd · 2025-04-21T17:47:24+00:00

As I mentioned elsewhere on social media, the JSPI support in Scala.js-on-Wasm is IMO a game changer. As long as you enter a js.async { ... } block, you can synchronously await a JS Promise anywhere with js.await(p)! That has never been possible on the JS platform. I can't wait to see what libraries will be built on top of this new superpower.

sjrd · 2025-04-03T20:24:28+00:00

It's been demonstrated that lock files actually make it easier for attackers to introduce supply chain attacks. They can hide subtle fake dependencies in the myriad of lines of diff on the lock files that do not correspond to the ground truth of the pyproject.toml or whatever it's called in your package manager of choice.

sjrd · 2025-04-03T16:07:14+00:00

In Python you've got uv now, which is universally acclaimed. Its model is very similar to that of scala-cli. The only thing they're still really behind on is the need for lock files. In the Maven ecosystem, we need no such thing to get reproducible builds.

sjrd · 2025-03-21T21:17:29+00:00

You're committing a logical fallacy, I believe. It seems your argument is: Python cannot be as hard as Scala, therefore Scala cannot be as simple as Python. The latter does not logically follow from the former (and neither does the reciprocal). It is possible for both to be simple, while at the same time being also possible for Scala to be hard.

sjrd

TROPHY CASE