jeswin

Unrelated to the particular code above. There's a difference between writing code about or adjacent to a proven idea vs writing code in uncharted territory. I suspect that is what happened here. It's the same thing with say music and art. A lot of people today can play Chuck Berry.

Not the same. HttpOnly/Secure cookies were added much later and was not the default. They should have been inaccessible to JS by default from the beginning, and this policy has been a source of countless attacks.

> utility is of a standard that creates affordances for the insecure defaults

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.

Sorry to say this, but it reads promotional. Especially with a model which was on Show HN a couple of months back, and is not a comparable product.

Lenses are only tested on bodies which are available at the time of manufacture. They might focus hunt on newer bodies, because of tweaks to AF algorithms (for example, the speed at which instructions are transmitted). Sometimes in ways that can potentially cause damage long term.

> at this point a lens for a mirrorless camera will have a USB-C port

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.

Agree that the intermediary is not very useful when you can just use a directory watcher, but driving Claude via another app incurs api level costs starting this month, according to the new ToS.

> I’m always amazed by human’s capacity to devalue conscious in things they don’t fully understand

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.

Docker must always be installed rootless on Linux - https://docs.docker.com/engine/security/rootless/

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.

tsonic uses NativeAOT by default, and DLR/System.Dynamic isn't supported in NativeAOT. There are switches in tsonic to give you MSIL, but that's used mostly for testing or for compat reasons.

> strict, deterministic subset of TypeScript

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

Yes. :) With the goal of compiling it to native code.

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

Hmm yeah good point. I didn't think of it. It might even be cheaper to do this when the list of possible types are closed and few.

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

> Another option is to define your own integer types

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

Yep. The MS compiler written in TypeScript has a lot of dynamic behavior which tsonic cannot support. Those were not easy to port either, and tsgo seemed like a much easier target.

> such as this project which is converting tsgo to Rust

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

> Traditional OOP runtimes use vtables for method resolution, adding a layer of indirection on every call. Perry resolves all method calls statically during compilation, turning interface method calls into direct jumps.

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();
  }

First of all, congrats.

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

> I've been able to refactor one of the most complicated parts of our code base with similar results. Mechanical refactors are relatively straight forward for agents.

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'm out of credits codex pro credits (200 plan) in 4-5 days, and then I switch to claude (another large plan) mostly or just go out more and get Vitamin D. :)

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.

It's a highly successful language because (1) it was backed by Google, and (2) created by Robert Griesemer, Rob Pike, and Ken Thompson.

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

Docker has not required root for a long time, at least on Linux. There's even a convenience script for it: https://get.docker.com/rootless

Almost everyone I know installs docker rootless.

Installing docker doesn't require root.

"Rootless mode lets you run the Docker daemon and containers as a non-root user."

https://docs.docker.com/engine/security/rootless/

This is how docker is best installed on Linux, and there's a convenience script for it as well (https://get.docker.com/rootless). I am surprised that's not how people are using docker.

> Make sure you're running a rootless VM engine (e.g. podman instead of docker) !

Aren't most people running docker rootless (at least on Linux)? Does podman do more?

Since we can't reliably detect AI generated crap, I think it makes sense to penalize their submission. I say this as a generally pro-AI person.

A few decades back, a lot of computer use was emails. And it was stored on someone else's servers - with everyone from server operators along the route, to the government potentially having access to it. Even HTTPS is a relatively recent thing.

I guess what I'm saying is - we've always had this problem.

Built something like this, but mostly just read-only. Handling writes seemed harder (and a maintenance issue), so we didn't.

There's no way to know if a new maintainer will live up to whatever standards they've kept to date. Archiving should be the default decision, unless there's formal and elaborate handover.

> this is why Anthropic wants to ban open weight models

Do you have a source?

Notion, as any other thin-AI product out there, is now in Anthropic/OpenAI/Google's crosshairs. Unless one has a moat the size of SharePoint or Google Docs or OneDrive, it's just a feature away.