rictic

Yeah, another fun one is string enums. Could tread "DeleteIfEmpty" as "Delete".

Numbers, booleans, and nulls are atomic with jsonriver, you get them all at once only when they're complete.

For my use case I wanted streaming parse of strings, I was rendering JSON produced by an LLM, for incrementally rendering a UI, and some of the strings were long enough (descriptions) that it was nice to see them render incrementally.

If you send a task off to a work queue in another thread, and then do some local processing on it, you can't usually use a single Arena, unless the work queue itself is short lived.

Nope. `(() => {let bar; return bar})()` is `undefined`

I love spreadsheets for casual stuff, but my concerns with using them for anything heavy duty are twofold: change management and correctness testing.

Other software that I use and write is version controlled and has tests to catch errors, mistakes, typos. Those tests regularly find and prevent problems! Likewise version control.

Could we get the same with spreadsheets? Seems difficult but not conceptually impossible, particularly with LLM assistance.

Yeah, that's vanilla syntax. The semantics are fairly magic though. The component function that calls useState though isn't a normal function, it's a function that must be called in a special way by the React runtime in order to line up all of the hidden state that React maintains so that it can magically infer the data that your `useState` call maps to and then there's more magic to maintain the lifetime of that data.

CPU production is centralized, but email is decentralized. Email changed a lot about the distribution of information without necessarily changing the distribution of industrial manufacturing. Likewise solar will change the distribution of energy without necessarily changing the distribution of industrial manufacturing.

Once the panel arrives at your home it keeps making electricity for decades, without asking anyone's permission.

How is security looking with io_uring these days? I've been wary of it since https://security.googleblog.com/2023/06/learnings-from-kctf-...

One thing to take care with in cases like this, it probably needs to handle code with syntax errors. It's not uncommon for developers to work with code that doesn't parse (e.g. while you're typing, to resolve merge conflicts, etc).

In general, a drum I beat regularly is that during development the code spends most of its time incorrect in one way or another. Syntax errors, doesn't type check, missing function implementations, still working out the types and their relationships, etc. Any developer tooling that only works on valid code immediately loses a lot of its value.

Lit 2 to Lit 3 was really minimal: https://lit.dev/docs/releases/upgrade/

As I recall inside Google it was maybe one in a thousand elements that needed any changes at all. I updated the entire internal codebase of many tens of thousands of elements in a couple weeks of part time work.

But more importantly Lit 2 and Lit 3 are interoperable, so there's not the same pressure to update. When an element or library updates from Lit 2 to Lit 3, it can do that as a point release, because its public API is the same. This really reduces the amount of upgrade toil you have to deal with.

A person might have mistyped a price, a barcode may have been misread, the unit prices might be correct but the quantity could be mistaken. Modeling uncertainty well isn't just about measurement error from sensors.

I wonder what it'd look like to propagate this kind of uncertainty around. You might want to check the user's input against a representative distribution to see if it's unusual and, depending on the cost of an error vs the friction of asking, double-check the input.

nix manages the environment too, all direnv is doing in my setup is automatically entering and leaving environments based on my current working directory. Looks like mise does that automatically, which is neat.

mise looks nice, uses PATH manipulation rather than asdf's slow wrappers, and it supports Windows, which is a point over nix. nix only supports unixy environments like Linux, Mac, and WSL.

What might tempt a mise user to try nix are its just truly stupendous collection of packages, so more tools are available. You can also easily add your own packages, either upstream or privately. nix is bigger, more ambitious, more principled, but more complicated. You can build an entire fully-reproducible operating system from a short nix config. It's really cool! But also a lot more to learn, more surface area, more places to get confused or to spend time fiddling with configs rather than solving the actual problem.

A flake.nix file plus a direnv `.envrc` file with `use flake` has solved this for me.

When I cd into a project directory I get all of the tools that project needs, at the exact versions they were tested with. When I cd out of the directory, they go away. If the dependencies are well behaved (e.g. they don't do any self-modification, which is annoyingly common in the npm world) then it's often pretty easy to track all of your deps this way, imported from your npm package-lock.json or similar.

Ask your favorite LLM to write your flake.nix file for you, they're pretty good at it. I've been able to drop all of the bespoke language-specific tool versioning stuff `nvm`, `uv`, `rvm`, etc for all my personal projects, and it makes it easy to add deps from outside the language-specific package managers, like ffmpeg and lame.

Instead of using a dodgy package manager, install `nix` and use `nix run`. Get access to the largest collection of packages, and lean on a highly principled and secure baseline rather than… whatever this is. Easy to install on Mac, Linux, or WSL: https://github.com/DeterminateSystems/nix-installer?tab=read...

You're speaking out of ignorance here. Steam has a long-term relationship with its customers. They can and will remove a title from a user's library if the payment is charged back, as well as placing restrictions on the account.

> like the Document APIs?

Yeah, the DOM in the browser, node APIs in nodejs, etc.

> especially if it was faster

Well, that's the thing. Initially it'll be slower, 'cause the code you call, and that calls you will be mostly unsound.

Unless you can run the sound code without the soundness checks at boundaries, at which point it becomes harder to reason about, and you'll be tempted to add some additional runtime checks to your code that the type system should catch.

Tricky thing there is that the VM would still need to do checks at all the boundary points, including all of the language-level and runtime-level APIs. At what point along such a migration would it become net faster?

It'd need a ton of buy-in from the whole community and all VM implementors to have a chance at pencilling out in any reasonable time span. Not saying I'm against it, just noting.

What's Omit refer to in this context?

Private fields, unique symbols, there's many ways to do nominal typing in TypeScript, depending on what you want.

Discussion on the previous post in this series: https://news.ycombinator.com/item?id=44390452

The system described in the article is very React-like, and could be used by future versions of React. In both, functions return a description of HTML to render, which can be applied either to create new HTML or to update previously rendered HTML.

Yes, MCP adds no new fundamental capabilities. What it does is solve an N x M problem, where to hook up a given tool to a given LLM scaffold you have to write specific integration code for that combination of scaffold and tool.

With MCP that's decoupled, the tool and the software speak a common protocol, and it's one line of configuration to hook the tool up to the LLM. Makes it easy to mix and match, reuse code, etc.

Models are deterministic, they're a mathematical function from sequences of tokens to probability distributions over the next token.

Then a system samples from that distribution, typically with randomness, and there are some optimizations in running them that introduce randomness, but it's important to understand that the models themselves are not random.

I agree with your general point, but C++ isn't a great example, as it is so underspecified. Imagine as part of our calculator we wrote the function:

    int add(int a, int b) {
      return a + b;
    }

What is the result of add(32767, 1)? C++ does not presume to define just one meaning for such an expression. Or even any meaning at all. What to do when the program tries to add ints that large is left to the personal conscience of compiler authors.

Good question. jsonriver is well optimized, exhaustively tested (tens of thousands of test cases), and provides a number of potentially useful invariants[0] about its parsing.

jsonriver's performance comes primarily from simplicity, and doing as little work per character as we can. Repeatedly reparsing from scratch on the other hand gets expensive quick, your parse time is quadratic in the length of the string to parse.

[0] https://github.com/rictic/jsonriver?tab=readme-ov-file#invar...

If you've got some client side code and want to parse and render JSON progressively, try out jsonriver: https://github.com/rictic/jsonriver

Very simple API, takes a stream of string chunks and returns a stream of increasingly complete values. Helpful for parsing large JSON, and JSON being emitted by LLMs.

Extensively tested and performance optimized. Guaranteed that the final value emitted is identical to passing the entire string through JSON.parse.

Is this your reaction when someone climbs a mountain? "Bipedal locomotion was shown sufficient for climbing mountains centuries ago, given reasonable assumptions about the terrain, why should I be impressed?"

Doing things can be difficult and admirable, even if it was confidently believed possible beforehand.

Can the reality of hardware be modeled with complexity analysis? Yes.

Is it, in practice? I haven't seen it.

Hm? They have 128GB of RAM. Macbook Pros cap out at 128GB as well. Will be interesting to see how a Project Digits machine performs in terms of inference speed.

The json-schema-to-ts npm package has a FromSchema type operator that converts the type of a json schema directly to the type of the values it describes. Zod and TypeBox are good options for users, but for the reference implementation I think a pure type solution would be better.