You could make the same argument about Cookies.

> as opposed to just designing it right from the beginning

And generally, it's quite difficult to design it right from the beginning because one would often start with the wrong assumptions. Most standards evolve, and it should be acceptable.

Ideally, camera bodies should support firmware updates via the body in a non-discriminatory way, but until then I wish manufacturers support firmware updates via USB-C.

Looking at you Samyang Lens Station. I think users have been sufficiently upset, and they're adding USB-C to newer lenses.

What?

We devalue things we fully understand too. For example, veal = take a baby cow away from the mother, and fry it into cutlets. Or turn the mother into steak. We are well aware that animals have emotions; happiness, sadness and the full range.

Humans are just inhumane.

There's even an install script for it: curl -fsSL https://get.docker.com/rootless | sh

This has been there for a while. The root install option should be removed.

I'll add that page, thanks. Today, almost all of idiomatic TS is supported including most of its utility classes. Dynamic JS-style code is not supported, for example adding a function or a field into an object, prototype-based class modifications etc. I'll compile a list, and include it along with the large docs cleanup planned before v1.

> Also, what's an "ambient surface" in this context?

The idea is that when JS gets transpiled into C# (or Rust, upcoming), JS globals and built-ins are invalid. The native "surface" is C#, meaning the string is .Net's string type and the methods that you expect on JS strings would be missing. But when you opt in to a surface, such as the "JS surface", the compiler applies surface defined translations such as substring becoming SubString, either directly or via a companion helper class. This allows you to write against standard JS and Node APIs, instead of relying on the stdlib/builtins of the target framework (currently CLR). And you get the JS "stdlib" - console, JSON, Date, Map, Set etc.

For example, all the projects you see under this use the JS surface: https://github.com/tsoniclang/proof-is-in-the-pudding/tree/m...

It's mostly a mechanical port. Hoping to do a Show HN maybe in a month.

I am still inclined to believe AI just made up the documentation though, because this has its own tradeoffs.

This is what I did. Most int usage is inferred, but if they had to define it explicitly, I make them import { int } from "@tsonic/core/types.js";

If you'd like to follow, here's my attempt at converting tsgo to typescript (called tsts [1]). Admittedly there's AI involved, but it's a very mechanical job. Going from golang to ts is not a very difficult problem, the other way around would have been way harder. The plan is to then compile tsts to binary via tsonic.

[1]: https://github.com/tsoniclang/tsts

What? How is this possible, even with something as simple as:

  interface Animal {
    speak(): string;
  }
  
  class Cat implements Animal {}  
  class Dog implements Animal {}

  function makeSound(animal: Animal) {
    return animal.speak();
  }

The website doesn't explain how it works in a lot of detail. I am the author of tsonic [1], a TS compiler that produces binaries via Clr NativeAOT (on Linux/Mac). The hardest parts were numbers (TS has no ints or shorts), Generics, and TS Utility Types. I've been on it for the last 6 months (almost every day); getting to near complete TS compatibility is a very long journey because of its expressiveness.

Add: A request is to explain how it works on the website. I did take a look at https://www.perryts.com/en/internals/ but are those techniques described really sufficient to express TS? Based on my experience, I must say I'm surprised. But the proof is in the pudding, and if it's compiling those examples it must be working somehow!

[1]: https://tsonic.org

A rewrite of bun in Rust is unlikely to be a trivial mechanical refactor. And if you are not sharing what the complicated parts were, or how big it is, how do we assess that the task was similar?

Unless you are intimately familiar with the bun codebase and you've already made that assessment.

I spend most of my time designing and tweaking tests suites, and improving test performance. These commits are almost entirely Codex: https://github.com/tsoniclang/tsonic/commits/main/ - but it's possible only because there's a very large test suite attached to it.

All of that is very token intensive. If OpenAI gave me 3x my limits, I'd find ways to eat it up in a week.

What do these tokens give me? Well, I think in a week or two, I hope to port the TypeScript-Go compiler back into TypeScript, but compiled to native code. It's probably not particularly useful for most ppl, but it's a hobby project that I've spent the last 7 months on.

If it came out of anywhere else, it might have struggled even to hit the homepage here.