jeswin

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

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.

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.