…and anyone who wants to do different things (even just *more* things) has to build their own compiler that *targets* TS.

So the thing I’ve been mulling on is: What if JSX/TSX were powered by a first-class extension point instead? (The web ecosystem tradeoffs around React would sure be different!)

It’s not a *given* to me that if the language itself had differently-shaped first-class extension points then the tooling would follow, but it does some *plausible* to me that it could. Put very concretely in the: you get JSX/TSX “for free” from TS-powered tooling, because it’s baked into TS itself…

AFAIK the only approaches with significant real-world adoption are macros: Rust and Swift in mainstream languages, and of course Lisp; and compile-to-target-language: the approach in the JS ecosystem, inclusive of JSX, Svelte, etc.

Both approaches are pretty hard on tooling (LSP, formatters, etc.).

My observation/hypothesis is that it’s a very interesting underdeveloped intersection of HCI and PL research—not because there isn’t a bunch of interesting research there, but because taking the interesting stuff and making it effective in real-world PLs hasn’t *really* happened.

The research from @ltratt.bsky.social’s group is not coterminous with that, but has some interesting overlap. Relevant papers: “Parsing Composed Grammars with Language Boxes”, “Eco: A Language Composition Editor”, and “Fine-grained Language Composition: A Case Study” from tratt.net/laurie/resea...

So the thing that got *me* interested in it was the space that JSX, Svelte, Vue, Glimmer, etc. play in—it would be great if there were a natural extension point (even “just” macros! But Rust shows the limits I think) for syntax extension/integration for those kinds of templating languages.

I started the project that will eventually launch (post-yak-shave) in 2016 and have had the good sense to keep it decoupled from my ability to actually publish things as it extremely slowly developed. Longest project with the most fits and starts ever. But it’s getting there. 😁

I think about it surprisingly often 😆😮‍💨 because of how much time folks in the JS ecosystem (myself included) have collectively spent on the problem at this point and looking at the Rust ecosystem options—all varieties of macros—, which are much better than nothing but still leave a lot to be desired.

(I’m not, to be clear, making any claim about what *you* value, only that claims about “cost effectiveness” have relatively little purchase on my thinking about what we ought to do industry-wide in this space!)

I’m also not at all persuaded by “cost effectiveness” arguments. We know empirically that plenty of folks are plenty productive in both FP and Rust contexts.

But even beyond that: I care deeply about the performance, reliability, correctness, and maintainability of software—not merely profit ratio.

The assertion that they’re relatively rare is simply wrong. We have just collectively decided very literally to pay for it with a higher memory footprint everywhere all the time. That may be an acceptable choice, but it’s a *choice*.

(And yes, I would absolutely pivot code structure to FP or Rust!)

Yep. The most challenging bits of “keep the system up” work I’ve done in my career involved (implicit!) retention of GC roots in a Node.js environment. 😭

If it’s not for you, because you don’t prefer to embrace the set of tradeoffs it offers, that’s fine! I’m not trying to argue you into liking Rust or preferring its tradeoffs. I am simply making the point that that isn’t a matter of “it’s good/bad for X”, but “I prefer/don’t these tradeoffs”.

That works right until it doesn’t. Cycles that include a root are far from rare! I have spent two separate 3–4-month periods of my life dealing with showstopper bugs in very large web applications that came down to “GC makes cycles invisible, good luck have fun getting to the bottom of it.” 😅

(Watching subsets of the Swift ecosystem be very. mad. about Swift Concurrency—“this doesn’t solve any real-world problems!” a recurring refrain—sometimes makes our async scuffles look tame. 🥴)

Yeah. We may get some interesting data from the parallel-world experiment that is Swift’s opt-in low-level data structures and memory safety now that that’s landing in the Swift 6.x series. Esp. b/c the Swift ecosystem has a lot of devs who are skeptical of *any* attempt at more rigor than ObjC. 😂

I personally *strongly* prefer the set of tradeoffs that Rust enforces, including for “business app” logic, even with the places that Rust makes me work harder than a “perfect” borrow checker implementation would. So it‘s not a matter of “bad at it”; it’s a matter of “can I embrace this approach?”

Yeah, this is a classic case of “I prefer to write my app code in a style that isn’t amenable to single ownership”—there *are* real limits to the borrow checker’s smarts, though they’re improving all the time, but there are also different tradeoffs to system design that GC’d languages afford.

That kind of implicit ownership chain where you end up with multiple ‘owners’ pointing to the same piece of data is often quite unhelpful in GC’d languages; you just get to ignore it for longer, usually till it’s causing hard-to-untangle problems at runtime. I’ve spent inordinate debugging those!