I've been enjoying using the new, native, VS Code integration with local models. I can use LM Studio on my Mac with LM Link to start an OpenAI-compatible server running on my DGX Spark, and plug it in to VS Code for offline/private inference.
Typst also has native scripting! For fun, I've been working on a small statistical distributions library in Typst, distro[^1] that uses plain Typst.
It's really nice having a decently powerful scripting component, it makes for some fun literate-style programming. You can package things up pretty easily for others to use, too[^2]. It even supports WASM plugins, if you want to go wild.
This package, conch[^3], renders a mini OS and terminal, based on Typst:
> A shell simulator that renders interactive terminal sessions in Typst, powered by a Rust WASM plugin.
> Type shell commands in your Typst document. Conch executes them against a virtual filesystem and renders a realistic terminal window — complete with colored output, syntax highlighting, and animation support.
Possibly controversial, but I think short commands should be disallowed. This is the stance the AWS CLI takes, and it 1) vastly improves readability, especially for those learning the syntax 2) makes it less easy to shoot yourself in the foot with a typo.
(Disclaimer: I am not a cryptographer and this is a heavily simplified explanation). Homomorphic encryption is built on the foundation of 'hard problems' (e.g. the Learning with Errors Problem) - loosely, computational problems that are thought to be impossible to reverse without being in the possession of a secret key.
The crux of HE is that it provides a _homomorphism_: you map from the space of plaintext to the space of cipher texts, but the mapping preserves arithmetic properties such as addition and multiplication. To be clear - this means that the server can add and multiply the cipher texts, but the plaintext result of that operation is still irreversible without the private key. To the server, it looks like random noise.
I don't think it's helpful to think about this as connected to deep learning or embedding spaces. An excellent resource I'd recommend is Jeremy Kun's guide: https://www.jeremykun.com/2024/05/04/fhe-overview/
I had good fun transliterating it to Rust as a learning experience (https://github.com/stochastical/microgpt-rs). The trickiest part was working out how to represent the autograd graph data structure with Rust types. I'm finalising some small tweaks to make it run in the browser via WebAssmebly and then compile it up for my blog :) Andrej's code is really quite poetic, I love how much it packs into such a concise program
Handwritten! (aka no LLM assistance :) It wasn't transpiled or anything like that. I've been meaning to post a little about it on my blog; just been caught up with other stuff atm.
One thing that was a _little_ frustrating coming from Python, though, was the need to rely on crates for basic things like random number generation and network requests. It pulls in a lot, even if you only need a little. I understand the Rust community prefers it that way as it's easier to evolve rather than be stuck with backwards-compatability requirements. But I still missed "batteries included" Python.
I recently wrote an eigenvalue solver for an interactive component on my blog with Rust compiled to WebAssembly. Being able to write-once and compile for the web and desktop felt like the future. But then, I'm no fan of JavaScript and wouldn't have attempted it if WASM didn't exist.
I've just recently done the same, turned Rust into WASM and it does feel great. Being able to compile mature and well-tested libraries into WASM instead of trying to find a JS equivalent is incredible value.
Thanks for writing this game! I came across it after seeing your Checkers written in Rust for WASM game[0], and thought it deserved an HN submission of its own.
reply