A bug in the scriptlet I used to post it, which truncated the title as
“Silicon Valley sees AI as the solution – for everyone els...”, which I didn’t notice had dropped the third line of the title.
> In case you are curious about Fable: I intentionally did not test it because I was not sure if the classifiers they are running might downgrade me to Opus silently.
Is this still a thing? I thought Anthropic walked back the silent downgrades so now all the different domains downgrade non-silently.
It's slower. Wasm32 can just reserve 8 GiB (32-bit pointer + 32-bit offset) of the virtual address space from the OS for each memory, so checking for out-of-bounds memory accesses imposes no performance penalty. Wasm64 can't do that, so each memory access is a bit slower.
Oh that's interesting, never noticed it in my experience but I have never written anything in wasm where it would matter. Makes perfect sense now that I think about it though. Thanks!
Sometimes I wonder whether it's possible to run the wasm code in a separate sandboxed process to eliminate a lot of checks. I mean optionally, because normally JS calls wasm code synchronously in the same address space. The bridge will add more latency when there is a transition between JS and wasm. It's obviously complicated because some data structures can also be shared, such as SharedArrayBuffer.
> The bridge will add more latency when there is a transition between JS and wasm.
This would be similar to how NaCl/PNaCl communicated with the JS side (via message passing), and that really sucked and would also be prohibitively slow for talking to 'high frequency APIs' like WebGL2 or WebGPU (or the DOM heh).
I've seen various posts about Elixir's gradual type system pop up on HN, but haven't been following too closely. Does anyone know whether this particular gradual type system can change the asymptotics of programs vs untyped code? As far as I'm aware, most gradual type systems (e.g. Racket) can make programs run asymptotically slower, although there are some exceptions [1].
Elixir's gradual type system cannot change the asymptotic complexity of your programs. The design explicitly rules out mechanism that causes slowdowns in other gradual type systems (runtime casts at static/dynamic boundaries)
Most gradual type systems insert coercions when values cross the types/untyped boundary (checking every element of a list, wrapping values in typed proxies, etc) but Elixir's team published a "strong arrows" result specifically to achieve soundness without those runtime checks. The bytecode the compiler emits is semantically identical to untyped code.
That can be a concern indeed but it is worth noting that strong arrows compose/propagate. So if you have a function without guards that calls a function that guards on said types, the caller is also strong! We will likely have mechanisms to measure "strength" when we introduce type annotations.
Is it fair to think of this as the ability for type information to be propagated in both directions, e.g. both up and down the callstack? So callees down the callstack may receive any type information the caller might have, while callers up the stack may also receive any information callees further down the stack might have? Please correct me if my understanding of what you wrote is way off base!
I mean, sure, except that many large open-source projects (e.g. Linux [1], Nixpkgs [2], etc) require this as part of their AI policy. Omit attribution in your own projects if you want, but the maintainers of these projects are owed at least that level of transparency for contributions.
Notably though, Linux's requirement (Assisted-by) is different from what Claude Code actually does (Co-Authored-By). I'm not sure, but it might be intentional (to make the signaling explicit).
For sure, and in the PR description for the Nixpkgs AI policy, they explicitly mentioned this as a "brown M&M test" [1]. I read the blog post as being against including this information in commit messages at all, not just about tools adding it automatically.
My projects also require Assisted-by attribution as that's what the Fedora AI policy requires and that was the first major org with a coherent AI policy that I found when choosing it. Not sure which came first, that or Claude hijacking Co-Authored-By.
Personally, I prefer Assisted-By. Co-Authored-By implies a level of respect and self-direction I don't think LLM's deserve.
The triangular table view is fascinating. It looks like the periodic table. I wonder if there are number-theoretic lemmas (or at least conjectures?) about what "family" the optimal packing for a given number falls into (like diamond, diagonal strip, two blobs, etc). I didn't see anything when skimming the survey paper linked at the bottom of the site, but I'm sure there's a lot more literature here.
Another great tool, built on top of nix-locate, is comma. So for any program foo, if you have foo installed, you can run it like this:
foo
And if you don't have it installed, you can run it (without installing!) like this:
, foo
And if multiple different packages provide a program named bin/foo then comma lets you interactively choose the one you want, and remembers your choice so you don't have to specify again unless you choose to via the -d flag.
