bakkoting

You can set up paths that route to different local ports. As long as your apps don't need to live at the root path you can have as many as you like. And you can still have something on the root path as long as it doesn't need the subpath.

Here's `tailscale funnel status` on my machine:

    $ tailscale funnel status
    
    # Funnel on:
    #     - https://my-machine.tailXXXX.ts.net
    
    https://my-machine.tailXXXX.ts.net (Funnel on)
    |-- /            proxy http://localhost:3000
    |-- /foo         proxy http://localhost:3001
    |-- /bar         proxy http://localhost:3002
    |-- /baz         proxy http://localhost:4004

A while back I ported htdemucs (the same thing this uses) to onnx/wasm/webgpu so you can do it in browser (though I only bothered with the 4-stem version): https://bakkot.github.io/demucs-js/

I dunno, lots of companies seem pretty happy to build large portions of their business on top of unvetted single-maintainer open source projects. Don't see why they'd stop doing so now.

(Anyway, I don't care so much about what companies go for, as opposed to what I can do on my own devices.)

Depends on exactly where you draw the line at "breakthrough", but there's been at least a few novel and interesting results coming from outside mathematicians. Recently for example there were https://old.reddit.com/r/math/comments/1uxj3cy/after_openais... from Phillip Kerger at Berkeley, and https://www.erdosproblems.com/forum/thread/119/proof-claims from Samuel Korsky at Two Sigma (the latter of which was more of a collaboration between the human and machine, not a one-shot like several of the other results we've discussed).

They didn't open a PR against zig either, the compiler concurrency work they did was also only ever in their own fork.

In case anyone missed it, this PR is based on that:

> This is an implementation of the design Filip Pizlo published in 2017: "Concurrent JavaScript: It Can Work!".

This used to be more common but the pattern these days is to have the binaries split into optionalDependencies which declare their supported CPU etc, one per supported platform. Then npm will install just the matching one (optionalDependencies that require a different platform aren't installed).

The fact that most of the ecosystem has moved to this pattern is a big part of why this change is now feasible.

I have; you specify one optional dependency per platform and set the requirements in each package. It works fine. A bunch of packages do this (e.g. esbuild). I don't know what your complaint is or what you're asking for.

They have taken action as of very recently. The latest version [1] of npm warns when there are install scripts and tells you they will be disabled by default in a future version, with a per-dependency opt in mechanism [2].

[1] https://github.com/npm/cli/releases/tag/v11.16.0

[2] https://github.com/npm/rfcs/pull/868

The proposal used to do more thing and we didn't change the URL after we ultimately arrived at this set of APIs.

There's an RFC for this: https://github.com/npm/rfcs/pull/868

> most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages

Technically true, but wheels can include a `.pth` which will run arbitrary code as soon as Python is started, which is only marginally less dangerous. Recently exploited in the LiteLLM attack.

These things are usually caught by tools specifically scanning npm or by the maintainers noticing their account is compromised, not by people auditing their own installed packages.

2fa being enabled for people on the team is different from 2fa being required for publishing. It is not current possible to enforce (or use) 2fa for publishing with trusted publishing.

> type safety without having to transpile code from another language (so no build processes that rival C++ in complexity just to still have interpreted code at the end)

All major server-side JS runtimes are capable of executing TypeScript without transpilation these days. Complex build processes are only really a thing for client-side JS. The normal state of affairs these days is to run server-side code with no build step whatsoever.

Ehhhhh basically none of those exploits generalize beyond one very specific engine and set of conditions, and half of them are things to do with interactions between JIT tiers and can't be reliably triggered.

I agree that the original cancellation discussion was bad. I don't agree that these threads reflect the same disfunction. They're a new effort (from me). No one was working on it previously because browsers have said that they were unwilling to add any other form of cancellation given that AbortSignal already exists, so there was never a chance to add a separate CancelToken once it shipped. The work to be done now is basically administrative: moving a subset from the WHATWG spec to TC39. This has ~no relevance to user's lives unless they're using a JS runtime which does not implement the WinterTC spec, which is approximately no one. The delay has nothing to do with SES (which has no bearing on this), and Governors are a _use case_ which motivates bringing it into the language, not a thing with which it needs to be reconciled.

Browsers have said that they are unwilling to ship any new cancelation mechanisms given that AbortSignal already exists, so we can't ship a different CancelToken. But I think there's a path to standardizing a subset of the existing AbortSignal machinery [1].

(I am on TC39 and while this isn't my highest priority I did bring the topic for discussion at the last meeting [2], and there was support from the rest of committee.)

[1] https://github.com/tc39/proposal-concurrency-control/issues/...

[2] https://github.com/bakkot/structured-concurrency-for-js

We haven't refused, it just takes time! There was an update at the meeting two weeks ago [1]. There's a lot of other machinery which needs to be specified and implemented before module declarations will work but it's coming along.

[1] https://docs.google.com/presentation/d/1inTcnb4hugyAvKrjFX_X...

Python and Rust have such a thing, but not e.g. Java, Go, C#. And I can't find any libraries on npm which do this. That seems like a very niche need, not actually the sort of thing whose absence causes people to have lots of npm dependencies.

Observables has moved to WHATWG [1] and been implemented in Chrome, although I don't know if the other browsers have expressed any interest (and there's still some issues [2] to be worked through).

But Observables really do not solve the problems being talked about in this post.

[1] https://github.com/WICG/observable [2] https://github.com/WICG/observable/issues/216

Neat! I wonder how slow this would be running in wasm. In my dream world it would also use WebGPU but that's a much bigger lift.

You're thinking of a previous report from a month ago, #897 or #481, or the one from two weeks ago, #728. There's a new one from a week ago, #205, which is genuinely novel, although it is still a relatively "shallow" result.

Terence Tao maintains a list [1] of AI attempts (successful and otherwise). #205 is currently the only success in section 1, the "full solution for which subsequent literature review did not find new relevant prior partial or full solutions" section - but it is in that section.

As to speed, as far as I know the recent results are all due to GPT 5.2, which is barely a month old, or Aristotle, which is a system built on top of some frontier LLMs and which has only been accessible to the public for a month or two. I have seen multiple mathematicians report that GPT-5.2 is a major improvement in proof-writing, e.g. [2]

[1] https://github.com/teorth/erdosproblems/wiki/AI-contribution...

[2] https://x.com/AcerFur/status/1999314476320063546

Formally JavaScript is specified as having TCO as of ES6, although for unfortunate and painful reasons this is spec fiction - Safari implements it, but Firefox and Chrome do not. Neither did QuickJS last I checked and I don't think this does either.

Have you seen the YoWASP toolchain for VSCode [1]? It sounds pretty similar.

[1] https://github.com/YoWASP/vscode

And there's an open issue for that already: https://github.com/bearcove/arborium/issues/62

Yes. I'm on TC39 as well, and I've talked to Jordan about this topic.

It's true that there are a few people who publish packages on npm including polyfills, Jordan among them. But these are a very small fraction of all packages on npm, and none of the compromised packages were polyfills. Also, he cares about backwards compatibility _with old versions of node_; the fact that JavaScript was originally a web language, as the grandparent comment says, is completely irrelevant to the inclusion of those specific polyfills.

Polyfills are just completely irrelevant to this discussion.

This hasn't been true since version 5.4.2, released in 2017.

`npm install` will always use the versions listed in package-lock.json unless your package.json has been edited to list newer versions than are present in package-lock.json.

The only difference with `npm ci` is that `npm ci` fails if the two are out of sync (and it deletes `node_modules` first).

Very few packages published on npm include polyfills, especially packages you'd use when doing local scripting.

If you look at the list of compromised packages, very few of them could reasonably be included in a standard library. It's mostly project-specific stuff like `@asyncapi/specs` or `@zapier/zapier-sdk`. The most popular generic one I see is `get-them-args`, which is a CLI argument parser - which is something Node has in the form of `util.parseArgs` since v16.17.0.