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

Points: 3

# Comments: 0

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

Points: 1

# Comments: 0

This tool is a difficult sell. Users _might_ consider an Open Source version, but switching people away from familiar tools is not easy.

> so it doesn't support classes, asynchronous, destructuring

For users, this general category of problems (not knowing these edges) is the hardest. It's amplified if you pull libs from npm. One of the best ways to test compatibility is to test with non-trivial projects, or existing codebases. For example, one which has helped me a lot is trying to compile Microsoft's typescript-go compiler, after translating it from golang to TypeScript via a separately written tool. Large projects surface a ton of issues.

One of the biggest complaints I get is about missing documentation on what TypeScript is not supported.

For example, the following is obviously impossible:

  const a = eval("...something....");

  a: unknown, or a: any.

While there are exceptions, there's usually very little you'd get from in-person talks. And quite often, the people who are giving these talks are serial presenters - as a lifestyle, or sometimes career building.

But then like I said, there are exceptions. Especially when it's about something interesting being demoed for the first time, or a deeply technical conversation. Those are not the norm.

Doesn't matter. This forum used to celebrate "because you can" with no riders. And solving a Millennium Prize problem is among the biggest stages for Because We Can.

Now we're saying there are some qualifiers attached to it, such as (1) only if not done by companies with a lot of money, (2) only if it is inconsequential.

I agree with some of what you're saying, but like everything else it isn't black and white. Maybe some day, someone will improve some particular treatment because we can.

I just don't understand getting the pitchforks out because a company did not give an answer immediately. And the effect such data entering training would have affected the output is even less clear.

For graphics work, of course the answer might be different and I'm no expert. Personally I think screen size does matter, and I've noticed a fair improvment going from 28 to 32.

This is such a non issue given that iOS developers already have so many resolutions to test.

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

Points: 1

# Comments: 1

This is the csharp target for tsonic (a TypeScript to C#/Rust/Python/Triton transpiler). It has a bunch of tests here: https://github.com/tsoniclang/tsonic-csharp/tree/main/test

More comprehensive e2e proving grounds are at

1: https://github.com/tsoniclang/proof-is-in-the-pudding

2: https://github.com/tsoniclang/tsumo/

They were built specifically for testing the C# target. There are several other large projects we built specifically for e2e testing.

But more interesting would be the tooling built to support this. For example, our current TypeScript parser [1] is a file-by-file port of Microsoft's TypeScript V7 compiler written in golang. The challenge here is that every time Microsoft changes code, we'll have to fix our code and tests. It's doable, but a fair amount of work.

So we decided to write tooling to transpile Microsoft's v7 compiler from golang, and autogenerate our compiler. That tool is called gotots [2] - and it already produces a fully working TypeScript compiler. It's 3x slower than TypeScript v6 compiler, but we hope to get to rough performance parity in a week or so. Everytime Microsoft makes an update, we run gotots and our parser gets updated as well.

[1]: The old parser - https://github.com/tsoniclang/tsts-legacy

[2]: Golang to TypeScript transpiler - https://github.com/tsoniclang/gotots

My general point is that tests and tooling is tremendous value, and they are guardrails for LLMs to converge. I could have, for example, chosen not to write the go-to-ts transpiler, and live with porting Microsoft's parser line by line. But making such tools is something LLMs are good at, so it's a tradeoff well worth making. And the upside is that you don't have to use LLMs to port Microsoft's parser/compiler (a large and complex project) line by line.