News for hackers. Stuff that matters.

auraham

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.

[1] https://bun.com/blog/bun-in-rust

[2] https://learn.chatgpt.com/docs/agent-configuration/subagents...

Re:Show HN: Turn regular JavaScript into a neural net on Thursday October 22, 2026 @04:10PM (#50200337)
It seems interesting but I am confused. What is the purpose of that landing page? It is not clear since it showcases several (not related) ideas:

- turning js code into something else, arguably high-level code for training neural networks

- a mini OS inside the browser

- a gallery

- document search

Re:Why are AI agents lying, cheating and coordinating? on Sunday September 13, 2026 @03:47AM (#49681137)
> 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

Re:How I use HTMX with Go on Wednesday July 15, 2026 @05:10AM (#48918158)
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.

[1] https://www.youtube.com/live/pMwTR2KeuaU?si=AU7sqxVwTv4lRhV6...

[2] https://youtu.be/k1TrnzZaygo?si=kCpMvOgB0Egk5mDg&t=380

Re:Zig – SPIR-V Backend Progress on Tuesday June 30, 2026 @02:07AM (#48729039)
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.

[1] https://www.youtube.com/watch?v=iqddnwKF8HQ&t=10s

Re:Zig – SPIR-V Backend Progress on Tuesday June 30, 2026 @01:58AM (#48728982)
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?

Re:Deno 2.9 on Thursday June 25, 2026 @04:33PM (#48678847)
> Tauri proved to be quite problematic except when in macOS

Can you elaborate?

Older »