I did the same. I got "Build Your Own LLM From Scratch" last christmas and it is a great resource for learning how LLMs work, from tokenization to generating text. The author makes a great job explaining each new concept. If you know PyTorch (or at least know about tensors), the material will be approachable for you.
Sebastian, if you are reading this, this is an idea for another book: how to orchestrate agents for adversarial code review. I've been looking for learning resources to make something similar to this [1] at a smaller scale. I am aware of codex subagents, though. However, given that Sebastian already has a book for LLMs and another book on planning, I think adversarial code review is an interesting next step.
I think this is basically a compiler that turns arbitrary JS code into weights of a neural net that then behaves exactly like the JS program. And the stuff at the bottom are demo projects that are now running as a neural net.
> the agents didn't hack to find the answer to the problem; they hacked to try and figure out how the exploit gym evaluator worked so they could convince it they had solved the problem without doing so
Kobayashi Maru: Win a no-win situation by rewriting the rules -- Harvey Specter
I've been learning about React, Vue, and HTMX these days. As I understand, these tools aim to bring some level of interaction in a web application:
- Both React and Vue are all about reactivity: you have a variable, make it reactive by using something like ref() or useEffect(), and the framework will patch the DOM whenever that reactive variable changes. The idea is easy to understand but hard to implement. I agree with this podcast [1], where the author mentions that writing good React code is hard. I like Vue, but it is a bit overwhelming since it has many functions for creating reactive variables, like ref(), refs(), isRef(), unRef(), reactive(), toRefs(), computed(), etc [2].
- HTMX follows a similar idea: patching the DOM when an event occurs. Unlike React and Vue, HTMX does not rely on reactivity. Instead, it uses attributes like hx-get for requesting HTML fragments to the backend, patching the UI using those fragments. No watchers, no reactivity, just plain requests. This is (to some extend) suitable for dashboards, pagination, sorting tables, autocompletion. But if your application requires a higher level of interactivity, then React and Vue are a better option [2].
Then we have LiveView and Elixir, which I think is a better alternative/trade-off to these three tools:
- Similarly to React and Vue, LiveView has reactive variables (called assigns, you can think of it as a hashmap that holds the state of your application): every time the assigns changes, LiveView reloads the corresponding HTML fragment. This operation is efficient because LiveView knows which parts of the HTML fragment are static and which parts are dynamic. So when some variable changes, LiveView sends a tiny payload to the UI for updating the DOM.
- Also, LiveView follows an arguably simpler approach for reactivity, you only need to implement three functions: mount() to setup the initial state of the assigns, render() to prepare the HTML content, and handle_event() to handle events like button clicks or form submissions.
I think LiveView is so much easier to follow: if the assigns change, then the framework will update all the relevant HTML fragments. That's it. Also, we do not need to worry about adding third-party libraries for routing, state management, forms. Those are likely included in Phoenix.
I have the same feeling about Zig. In this interview [1], Andrew Kelley, creator of Zig, explains a lot of the features of the language; compares it against c, rust, go; and explains why he created the language. According to him, the killer feature of zig is the tool chain (compiler, linker, build system) since it has no dependencies. So, it will work in any OS/target you choose.
It is a really interesting interview. However, Zig code is a bit hard for me to read.
Can you give more details about using zig along with elixir?
> microscope is mounted on a elixir nerves deployment!
What do you mean? I imagine that there is an Elixir application running on an embedded system and maybe it relies on an external binary application (compiled using zig). If so, how do you manage the communication between them?
no, it mounts a .so file using dlload, and itself is a NIF.
Incidentally there is a second proprietary industrial camera on there that I have running as a different NIF built in zig, but truth be told I probably could have had claude do that one in pure elixir. However, claude did write a harness that I used to inspect the usbpcap dumps (and create the camera interface), that was done in zig for simplicity and turning it into a nif using zigler was a trivial transformation for claude to do.
For Linux, it was an ABI nightmare, the Steam sandbox is based on Debian 11, and glibc/GTK/webkit can't be reliably static-linked to a modern version that Tauri wants. We also ship a stand-alone version in itch.io that doesn't have the limitations of the sandbox but it was a friction point for many players having to figure out how to meet the dependencies.
For Windows, it was a bit less dramatic, but WebView2 is controlled by Windows Update in Windows 10, Some players have it, some players don't. And requiring windows 11 and up is a very unpopular choice. Maybe could have been solved by vendoring it but also not super clean.
I look forward to give it a try again, when Steamworks Linux runtime 4.0 comes around, and less people are still using Windows 10.
- We can embed an existing application using a sidecar [1].
- Now, we can also use Elixir in the backend, embed the BEAM, and deliver a single binary, see ElixirKit [2].
As far as I know, LiveBook Desktop [3] is using Tauri for building binaries for MacOS and Windows. If Tauri works for the Elixir team, I think it works for me too.
Also, I know that Tauri is not bullet proof. WebView can be limited for some use cases, see [4]. There is some effort to use CEF to mitigate those problems, though [5].
I'd like to know how Deno Desktop compares with Tauri in this context. I know it is a new product, not sure if we could bundle an existing binary in Deno Desktop, like in ElixirKit.
I gave it a try today using Linux Mint 22.3 with 16 GB of memory. Writing experience is OK, the UI is beautiful. However, when I load a medium markdown file (less than 200 lines), the UI is a bit slow. Scrolling and switching between two tabs take a lot of time. I tested after compiling it using `cargo tauri build`.
Sebastian, if you are reading this, this is an idea for another book: how to orchestrate agents for adversarial code review. I've been looking for learning resources to make something similar to this [1] at a smaller scale. I am aware of codex subagents, though. However, given that Sebastian already has a book for LLMs and another book on planning, I think adversarial code review is an interesting next step.
[1] https://bun.com/blog/bun-in-rust
[2] https://learn.chatgpt.com/docs/agent-configuration/subagents...
reply