JSIR is optimizing for round-trips back to JavaScript source. But since in language to language conversion teh consumer is a backend emitter (C# in my case), instead of preserving source structure perfectly, my IR preserves resolved semantic facts: types, generic substitutions, overload decisions, package/binding resolution, and other lowering-critical decisions.

I could be wrong, but I suspect transpilers are easier to build if it's lowering oriented (for specific targets).

Meanwhile, there are half a dozen other projects (business apps, web apps etc) where it works well.

Show us the code, or an obfuscated snippet. A common challenge with coding-agent related posts is that the described experiences have no associated context, and readers have no way of knowing whether it's the model, the task, the company or even the developer.

Nobody learns anything without context, including the poster.

It took them more than 2 decades to finally support pure native binaries (via NativeAOT). And it's fantastic for servers on Linux.

What I don't get however is who'd use their custom accelerators for AI inference.

However "Telling" has made it better, and generally the model itself has become better. Also, I've never faced a similar issue in Codex.

1) claude will stash (despite clear instructions never to do so).

2) claude will use sed to bulk replace (despite clear instructions never to do so). sed replacements make a mess and replaces far too many files.

3) claude restores the stash. Finds a lot of conflicts. Nothing runs.

4) claude decides it can't fix the problem and does a reset hard.

I have this right at the top of my CLAUDE.md and it makes things better, but unlike codex, claude doesn't follow it to the letter. However, it has become a lot better now.

NEVER USE sed TO BULK REPLACE.

*NEVER USE FORCE PUSH OR DESTRUCTIVE GIT OPERATIONS*: `git push --force`, `git push --force-with-lease`, `git reset --hard`, `git clean -fd`, or any other destructive git operations are ABSOLUTELY FORBIDDEN. Use `git revert` to undo changes instead.

I've been an Ubuntu user for 20 years, and RedHat and Suse prior to that. Ubuntu just worked. Debian had packages for everything, including from 3rd party vendors. It lets me focus on my work, and not worry about the OS, or compiling packages, or finding installers. When I had issues (rare), the large user base meant that someone had already figured out a solution to the problem.

The flavor of Linux doesn't matter so much in my opinion.

I'd like to mention sport again, but with an addition: find a sports coach you can afford. This changes sport from being a destination to a path, and you'll avoid injuries - which is something you'll need to be careful about as your grow older. Im in my mid 40s, for context.

Never mind, found this in the docs: https://fna-xna.github.io/docs/appendix/Appendix-A%3A-Native...

> If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident.

This is what I was responding to.

I'm saying that if you care about performance, data structures should be designed with approach specific tradeoffs in mind. And like I've said above, in typical business apps, it's ok to start with data structures because (a) performance is usually not a problem, (b) staying close to the domain is cleaner.

If anything it's the other way round, if you're not talking about business domain modeling (where data structures first is a valid approach).

Currently it uses .Net and NativeAOT, but adding support for the Rust backend/ecosystem over the next couple of months. TypeScript for GPU kernels, soon. :)