jeswin

There are many ways people solve this. I use spec directories, and the agents just keeps updating it as I make decisions. It isn't a single file, it's a directory; sometimes nested based on the size of the project. I'll have the directory open in my editor of choice. It being a directory allows me to use an arsenal of text tools, and also optionally commit it for history/tracking.

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

This account exists only to submit links from this specific website, and has zero comment history.

Zen3 is 7nm, Zen4 is 5nm and Zen5 is n4p. That's also why Apple is ahead; TSMC is a big factor.

Also curious - how do you handle "number"? i32, i64, doubles, floats, i16 etc have very different performance characteristics. Also, things like sparse arrays, Error.stack etc. I haven't documented them in my project yet, but it's quite high up in the list of things people actually care about.

I've been working on this full-time since late 2025. Happy to share what I've learned - feel free to email me as well if you wish to.

> 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.

Author of tsonic.org here (which is very similar, but for Rust, C# and Mojo - WIP).

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....");

or even:

  a: unknown, or a: any.

The rest of it is largely doable. But people want to see what's not supported. Otherwise it's not clear to them what to avoid.

Contrarian opinion, but being open here.

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.

> They probably also knew that the paper was trash

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.

All of these accusations could be true. But there's also no way for a company to casually claim "No, we did not train on your data", without verifying all the knobs the user might have turned to enable or disable data sharing.

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 programmers, there's very little incremental gain by going from 4k/32" to 6k/32". I've tried both and there's a limit to how small the text can be, but then I'm kinda middle aged.

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.

It was useful for paper because it helped save time in cutting, folding, printing etc. None of that matters for a phone.

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

For Desktop use, 100% of electron and python slowness will be gone in a couple of years, at least for new projects. If you're using Rust (or Mojo or C/C++), you'll have to try hard (almost a deliberate effort) to make software slow.

In my search, I found that they spend almost an equal number of hours in air like you said - 75-100 hours per month. If that's the case, after adjusting for sex, these numbers holding would throw some uncertainty into the radiation hypothesis.

Well, Clinton took over when the Soviet Union had just dissolved. Of all US Presidents, he had the least to worry about on the defense front. Reagan's spending was a reason why the Soviet Union collapsed when it did. So it's not that black-and-white.

These cards are forwarded manually (by handlers manning post offices), and it takes a while to travel. Bogota to Tokyo will take days to arrive.

Sure.

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.

That's not been my experience. My prompting methods haven't changed much between recent GPT releases. I do put a lot of effort into building tooling and tests around a project, so the LLM output is converging around it.

* association I mean, not correlation.

It depends on what effort you're using etc. As an example [1] of what codex is capable of, here's hugo (written in golang) ported to TypeScript - and then a TypeScript to Rust transpiler which converts arbitrary TypeScript into Rust.

The TypeScript code which was transpiled into Rust (and is compatible with most hugo templates) runs faster than the original hugo.

[1]: https://github.com/tsoniclang/tsonic-examples/tree/main/rust...

The transpiler is still WIP, but the fact that it can do this says a lot of about how far LLMs have come.

Agree. Antiquated Indian farm subsidies are the biggest impediment to sustained growth. Nothing can be done, because it'd be electoral suicide to touch them. India's holding more than 100 million tons (!) of grain due to the mandatory procurement policy. It is not merely wastage, but also an environmental disaster to keep doing this.

$1B or even $5B is nothing, given the impact UPI has had across the country.

> One of the reasons why the fee is being considered is under the pressure of other payment providers who are loosing to UPI in Indian market.

Correlation is not causation. Banks have demanded this (getting rid of Zero MDR) for many years, even prior to Trump assuming office. However, it may have momemtum now due to the impending trade deal. But that's speculation either way, and the burden of proof rests with whoever is making that assertion.

What the government conceded (or gained, which could be a boring topic relatively) would make an impactful story. Unfortunately, newpapers today mostly rely on correlation rather than doing the hard work of finding someone who'll spill the beans. There's very little of Tehelka-style "Operation West End" (or "All the President's Men" for a movie equivalent) going on these days.

Software developers still need to think. Models can't do everything. That's it.

For a while now, I've found pelican rendering to be an unreliable metric for LLM ability - and most people know it. Yet, somehow it gets upvoted to the very top of every new model discussion.

No. I mean synthetic drug addiction. I know where you're going with this, and I once supported what you're saying; but there's enough evidence now (with addictive substances) to say that accessibility is going to make things worse.

The underlying problem in most cases (of youth violence across the world) is drug addiction. I recently spoke to someone who had to quit an overseas job and return home because his teenage son had started engaging in criminality, after a drug addiction problem at school. He was telling me how widespread the problem is, and how accessible drugs are to kids via online channels.

Just randomly:

1. TS only has a "number" type. But what type of number is it? This is doable safely via keywords (or known markers), or sometimes via analysis, but I couldn't find it in the README.

2. A compiler that works only on macOS?

All you saw on that page was the revenue?

For a potential customer deciding whether to trust a relatively small app (compared to Google and Apple) with their memories, these are useful numbers. 50% increase in paying customers this year. Nearly half a million registered users, with a 40% growth in the last 6 months. 5% of their users are paying customers. Revenue topping a million. That's stuff I want to know if I'm subscribing and uploading all my pics to their servers. I want to know if they'll be around, and my stuff is safe.

> So for folks that don’t know better, this is a very cool thing ente is doing. For folks that run businesses and know better...

Oh please. Perhaps work on not jumping to conclusions too quickly.

* autoregressive

The transformer architecture is fundamentally unsuitable for local inference, while being efficient at scale. It's a fun experiment to try, but that's about it.

I have no connection with the team.

They seem to be making good progress, starting out from Trung Nguyễn's effort. This would be a massively impactful project, and could revive the Hackintosh.