No matter how many optimizations can be ported from tsrs to ts-go, Rust will be more efficient and enable the WASM use case.

The premise of porting the compiler from TS to GO was ease of migration due to Go's garbage collector. That doesn't hold anymore? AI doesn't care how hard or easy a migration is if a test suite exists.

Comments URL: https://news.ycombinator.com/item?id=49635328

Points: 2

# Comments: 2

- opens local markdown files

- Claude/Codex natively integrated (with my existing subscription!)

- in-line diffing to quickly accept/reject changes

- WYSIWYG (!)

The in-line diffs are a big step up to other apps static previews, and, in theory, just the first collaborative primitive.

But, I am getting feedback that "editing" might become a thing of the past. Why do I need to see diffs from Codex/Claude if the models are getting so good to the point that they need no correction?

Which makes me wonder, how did your writing setup with AI change over the past months? Are you still iterating on posts or are agents one shotting them?

Comments URL: https://news.ycombinator.com/item?id=48764289

Points: 5

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48362673

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48187727

Points: 17

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47943447

Points: 4

# Comments: 0

The appeal or structured file formats like .docx, .json, etc. Images are unstructured and simple "do you want to keep the left or right image" is good enough.

Take a docx, write the file, parse it into entities e.g. paragraph, table, etc. and track changes on those entities instead of the binary blob. You can apply the same logic to files used in game development.

The hard part is making this fast enough. But I am working on this with lix [0].

[0] https://github.com/opral/lix

I built lix [0] which stores AST’s instead of blobs.

Direct AST writing works for apps that are “ast aware”. And I can confirm, it works great.

But, the all software just writes bytes atm.

The binary -> parse -> diff is too slow.

The parse and diff step need to get out of the hot path. That semi defeats the idea of a VCS that stores ASTs though.

[0] https://github.com/opral/lix

Comments URL: https://news.ycombinator.com/item?id=47237949

Points: 1

# Comments: 0

We were coming from a an application perspective where blocking the users intent is a no-go.

Do you have a link to a discussion where the JJ community is discussing checks?

[1] https://github.com/opral/lix/issues/239

Begs the question if Anthropic will follow up with a first-class Claude Code "multi agent" (git worktree) app themselves.

Write an SSIS plugin (essentially just parse the XML) and lix can track the xml props in the SSIS package. Opposed to line by line stuff that git does.

Hm that is what lix provides?

SQL is just the interface to query the deltas.

Anyhow, lesson learned. The primary use case for lix is embedding. Positioning lix for binary files leading to existing systems. None of those support the embedded use case. Thus, don't position lix for binary files :)

> How often are binary files being diffed? How long does it take to materialize? How long to run a diff algorithm?

If version control is embedded in an app, constantly.

Imagine a cell in a spreadsheet. An application wants to display a "blame" for a cell C43 i.e. how did the cell change over time?

The lix way is this SQL query

SELECT * from state_history WHERE file_id AND schema_key "excel_cell" AND entity_id C43;

Diffing on the fly is not possible. The information on what changed needs to be available without diffing. Otherwise, diffing an entire spreadsheet file for every commit on how cell C43 changed takes ages.