jeswin

I've tried Chinese models extensively over the last 1 year I've been working full-time on this project [1]. They're borderline useless. 90%+ of my code is written by Codex, and perhaps <10% by Claude and myself.

> Can you share any example prompts where Chinese models aren't good enough?

Nobody is prompting any more, it's more planning, automation, guardrails and reviews. For example, if your tests report that there's a 40% slow down in a particular type of analysis, you have to review possible causes, and approve a plan involving multiple agents to find solutions that won't break 50k tests. And that solution itself is a small part of the work that gets planned in a day.

Codex and Claude are the only tools that work for me, inspite of testing almost everything out there to save costs.

[1]: https://github.com/orgs/tsoniclang/repositories

I know, but looking at how quickly people got it running on a few other phones (I've seen pixel 1, 4 and 6, a samsung, and another), I'm thinking that codex or claude code is exceptionally good at this class of work.

I'm saying the hobbyist community for phones is massive - this is not for regular phone users. And they all have older (but fast enough) phones lying around to try something like this on.

Looking at the comments, I get the feeling that HN has no idea how big this is going to get.

Agents are going to move this project into acceptable usability and performance in 6-12 months, across a broad set of Android phones. You're going to see people loading iOS on $299 phones, with grey zone marketplaces for app packages (like Android has had for ever).

Hackintosh was a small hobbyist community. Phones will be 100x that. There's going to be very little money in it, but I'll be surprised if this doesn't explode.

This is incredible work. Thanks for letting us know. The really cool thing about this is that it actually works on phones.

TrungNguyen1909's reverse engineering of A13 bionic booted up modern iOS on non apple hardware for the first time. This opened up a viable path to Apple Silicon hackintoshes as well (eventually), and is just inspiring work. That itself was supported by by the work of Martijn de Vos (devos50) on emulating the 1st-gen iPod Touch, winocm on the early 2010s iEmu project for the Apple A4, and the alephsecurity team on the xnu-qemu-arm64 project for virtualizing 64-bit XNU kernels.

I think it continues as Chefkiss inferno and they seem to be close to getting recent iOS to work [3]. I suppose they could make rapid progress with AI now.

[1]: https://www.youtube.com/watch?v=PBeIW2PDFVk&t=286s

[2]: https://github.com/TrungNguyen1909/qemu-t8030

[3] https://github.com/ChefKissInc/Inferno

You're on a website called "hacker" news. Inclined to downvote so that this doesn't take up conversation space.

> Separately would say it is a bad assumption to make that a product is vibe coded without trying it out.

You've put it behind a very typical AI-generated UI; like the many that come up every day. In your case, it's an auth product and it matters more. Besides, It's difficult to try your product without handing you the keys to the kingdom.

> We are currently in the process being fully SOC2 compliant

You're getting a Type I attestation first, I presume? That is of limited value in itself, and is mostly about getting to Type II. If you already have Type I complted, you could mention that on the website. "Regulated industries" have long sales cycles and evaluations, and you'll find it difficult to start those conversations without a more reassuring website.

This might seem like an aggressive question. But it's one to be asked of products dealing with auth.

For a security-centric product, how would I trust your fully vibe-coded product if I can't see the source code?

> You can't run C# without the .NET runtime

With NativeAOT, same a golang then. NativeAOT has worked wonderfully for us, and in some specific situations faster than Rust.

I'll take a shot at this even though I have no connection to vercel or scriptc. I have been working on tsonic.org for a year - which is a transpiler which will let you transpile typescript to rust, c# and mojo instead of javascript.

First, you can't get very far without self-hosting. You'll need many extensions and hooks into the compiler, and those are probably all in TypeScript. You can't use the mainline tsc v6 compiler because it's slow and runs Javascript. scriptc will not be able to compile the v6 compiler into native code either, because that code is too dynamic. And you can't use v7 because it's written in golang.

So the only option is to rewrite it in typescript, and compile it into native code via scriptc itself.

We did exactly the same thing, and it's here: https://github.com/tsoniclang/tsts-legacy

We decided to move away from it, by writing a golang-to-typescript transpiler - https://github.com/tsoniclang/gotots. That produces a working typescript version automatically from Microsoft's v7 compiler, but we just decided to not proceed with that because (a) LLMs have gotten so much better at doing these rewrites, that it's not expensive to maintain a port and (b) looking at signals from Microsoft, they don't seem to be so sure of golang anymore. I suspect it's going to get rewritten in rust.

> That's because there's no such thing as a "performant language".

That's not true. Many languages make tradeoffs for performance. There are many things in JS (or Python) which make optimizations difficult and sometimes impossible. For example - obj[key] = "haha".

Not a lawyer, but what if someone did this:

- Find examples of content that will constitute infringement. Then send Meta legal a notice saying here are examples where the publisher does not own the content, and their scraping is not legal. Our current/future clients will be damaged by Meta's planned actions.

This might elevate it to willful infringement.

I've seen prion disease up close with someone dear. I couldn't sleep thinking about what could have been going through their minds. It was 6 months of torture, and if I were in the same situation I'd have preferred someone switch me off.

I remember reading about Sonia Vallabh (and their race against time) - I'm so glad they're getting somewhere. Kudos.

Dynamic memory hot-plugging is still not as efficient. So if you don't want strict isolation between containers or individual sandboxes around each one of them, avoid VMs to achieve the highest density per box.

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.