jeswin

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.

Anything that can be written in Rust will be written in Rust.

I'm using Rust as a placeholder for a language with excellent performance and safety characteristics. It may not be a good thing, but there's no way around it.

Thanks. The idea is that many projects (including tsts itself) can be run unmodified on a JS runtime, or as a native binary via NativeAOT/C# or Rust.

Congrats on launch. The code is beautiful, and the test suite is quite solid.

Over the past year, I've been working on porting the v7 tsgo compiler back into TypeScript - https://github.com/tsoniclang/tsts

It's fully functional now, but 2x slower than the original tsc and 10x slower than tsgo. But hopefully in a month or so, we'll get to C# and Rust targets and it should be able to compile itself to become nearly as fast as tsgo.

They're everywhere. But if you're short on time, buying the postcard is often easier than getting stamps and dropping it in a postbox.

One petty complaint - generally across the world, stamp design has nosedived. Compared to old postage stamps, they have terrible typography and gaudy colours. I've generally been disappointed when buying stamps to put on postcards. Old stamps were truly works of art.

> Thoughts[^0] from Theo, who had early access:

I looked at his YouTube, and found a stream of industry gossip and beginner content like "web dev tutorials". I have nothing against such content and it may be useful and good fun to watch.

But does that say anything about this particular model? People have been using models effectively for web code since Gpt 3.x.

Misha and Soviet Woman were quite common in the 80s. I remember that the paper and print was much better than what we were used to.

The problem with ORMs is that they look kludgy without language support - which is why Hibernate in Java looks painful, while DotNet's EF looks like magic. I wrote something similar called TinqerJS - https://tinqerjs.org, which is like Entity Framework but for TypeScript.

There's immense value in everything being typed from the API down to the DB queries.

  // EF-inspired type-safe API in TypeScript
  const query = (q) =>
    q
      .from("users")
      .where((u) => u.age >= 18 && u.email.includes("@company.com"))
      .orderBy((u) => u.name)
      .select((u) => ({ id: u.id, name: u.name, email: u.email }));

Of course, ORMs are not for all queries in your project, and may not be a good fit for some projects. That goes without saying. The problem with the article is that it's dismissing ORMs by looking at specific implementations.

I would not trust AI on images. But I once had ChatGPT tell me that an MRI report was very likely to be incorrect based on the text, and offered a different diagnosis. Since it was semi insisting, I visited another doctor who made me do a retest. Long story short, ChatGPT was correct.

Again, this is just one single person's experience. So not worth much.

I was an avid reader during the web 2.0 days. Quite sad that his kind of tech journalism vanished; one could feel the decline of independent blogs month over month, while Facebook and Google were taking over the entirety of the web's traffic control.

But the old internet still exists in pockets. I found this via Om - glass.photo. https://glass.photo/cm/LCGjX2IqUWtK288zq5dSt

At thousands of tokens per second, LLMs (harnesses) can start to do a broader tree search of possibilities even in inefficient token space. This unlocks capabilities outside programming.

Would prefer not to offend the author, but I do believe this article has very little for the HN audience. No new insight, and no numbers or new information.