> 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`.
This week I was wondering whether using uv for managing Python versions is a good idea.
From their website [1]
> Python does not publish official distributable binaries. As such, uv uses distributions from the Astral python-build-standalone project. See the Python distributions documentation for more details.
I'm really not worried about `uv` and `cpython` -- their processes are robust, their response times fast, and (now) their funding significant
I'm worried about, say, `mdformat` (a widely used formatter mostly maintained by one person in their spare time), not to mention some super-specific dependency that hasn't been updated in years and is 3 levels deep in your dep tree. I really don't want to pin & manually approve every single update for an app that's under active development, but it's beginning to look like that's mandatory for any serious app.
In the meantime, I've gotta go get my API keys out of my unencrypted `.env` files! Getting burned on a large, consumer-facing webapp would be embarrasing but logical, but losing hundreds to thousands of dollars because of some indirect dependency of some silly one-off demo repo that just happens to be on the same host & system as my `.env`s... oof.
Anyone know if OAI or Anthropic will refund you if you get your keys stolen like this? Or is it user error?
i mean... uv is already a binary you run on your computer to manage python binaries, packages (and any binaries with those), systemwide tools etc; how much does it change whether they build the python binaries or someone else?
Kobayashi Maru: Win a no-win situation by rewriting the rules -- Harvey Specter
reply