giovannibonetti

Right, I didn't realize OCR is not used anymore when it comes to LLMs. Yeah, vision models, that's what I meant.

My security advice is: if you are feeding documents to your AI whose authors might have adversarial intent, transform them into photos and run OCR on them. Yes, it is wasteful and slow, but it is a guaranteed way to get rid of invisible (meta)data.

Granted, the OCR does not have a perfect 1:1 correlation to what the human eye sees, but IMHO as of November 2026 it is a fairly good approximation.

Have you heard about "default allow" and "default deny" in the domain of cyber security? Traditionally PCs, especially for home use, were built around the former idea, where the user supposedly trusts most of the stuff installed.

The problem is that malware may sneak in, and then the user needs a horrible piece of software called anti-virus that needs to apply complicated heuristics to try and separate one from the other. It kind of worked ok for many years, but as the world evolved and the dangers kept increasing, little by little we have been going towards the other idea – default deny – where apps are considered harmful until proved otherwise, and the honest app developers have to jump through multiple hoops to get their apps available to users. That's the app store model, which kind of works, but is cumbersome and expensive for the app developer.

Anyway, going back to the VM discussion, I think we may end up applying the default deny idea further into the OS Kernel to reduce those risks further. After all, a small kernel has a much smaller risk surface and perhaps it can be formally verified to be secure under some reasonable assumptions.

I think this will be the perfect motivation for the rise of pure functional programming, like in Roc [1]. With a clear separation of side effects from the rest of the codebase, you can sleep much better knowing that a library that is supposed to do some pure computations will not exfiltrate your data to a weird corner of the Internet.

[1] https://www.roc-lang.org/

I think advertising has soared in valuation over the last few decades because society and technology have evolved to a point where it is viable for many people to own small businesses with a handful of employees, if any. That has led to an explosion in the number of businesses, mostly concentrated in a few sectors (e.g. fast food), and to differentiate oneself in a crowded market you need ads.

Related to the topic of US law in Git, in another HN discussion on the front page someone posted a Git repository with the US tax model as code, including some Lean code for verifying the consistency of everything. It seems very useful to automate tax filing:

https://github.com/emmilco/us-tax-model

Temporal workflows are my main building block for supporting agents working in multiple steps.

In my company, we're pretty happy with Claude plus Metabase CLI (self-hosted). We quickly get any dashboard we want, regardless of the skill level of the person asking.

> Funnily enough, for coding, on many tasks, if you actually use one of their SOTA models and compare it to what you get from Anthropic, the actual speedup isn't all that large because of time spent on things like compiling Rust.

That's why I bet that fast compilers are the future. See this other thread that reached the front page a few hours ago about the Roc language [1]

[1] https://news.ycombinator.com/item?id=50218195

Funny thing, here in my company we're doing something similar, with CUE in a small Go library. You might be interested in it [1]. It generates a lot of boilerplate infrastructure code from the reference Cue files.

[1] https://github.com/bonisoft3/bayt

Many startups can now work in ways that were only fathomable in Big Tech before. Do you want a build system like Bazel for your monorepo? You can have it. Do you want to rewrite your app in a faster language? Sure, go ahead. Do you want to have native apps in all platforms? Yes, please.

> When the tools enable more creation at scale by tasteful creators, we'll start to get closer to content abundance. We're not there yet.

This reminds me of the comparison between Japanese manga and American comics/graphic novels. Some people say the former offer a much wider variety of content and ideas because it is often started by a single (often quirky) author, whereas the latter is usually designed by a committee, which ends up favoring more bland ideas. Anime usually starts of as manga, and that's why anime is so creative as well.

Perhaps AI will help single authors create more work by themselves, and we'll have a renaissance of comic books and other forms of (mostly digital) entertainment in the west. And we'll spend less time watching those TV shows on streaming platforms that follow the same few recipes.

Where does the language stand in the array-of-structs vs struct-of-arrays choices? Does it offer an annotation to choose that like in Zig?

What differentiation? Most work is bread-and-butter after you get a few years of experience. If you LLM's can automate 50% of that, it would transform society already.

I wonder if Roc will eventually have high-level abstraction to handle SIMD support. Perhaps by bringing some ideas from Futhark [1], a functional language focused on data parallelism. IIRC, the author has already been interviewed on Richard's podcast.

[1] https://futhark-lang.org/

Because LLMs make mistakes, and you want to prevent that? No wonder Rust is becoming the default language for high-performance LLM-written code. I hope Roc becomes a viable option soon, as it reaches stability.

You can have great abstractions on the upper levels that lower to fast primitives. See the articles [1] Push your "ifs" up and "fors' down and [2] Vectorized interpreters for more details.

[1] https://debasishg.github.io/blog/push-ifs-up-fors-down/ [2] https://venge.net/graydon/talks/VectorizedInterpretersTalk-2...

> A new reversible algorithm > > Designing a quantum circuit involves two constraints that ordinary programming doesn’t have. The first is that a quantum circuit can’t make “if-then” decisions the way an ordinary program can. An ordinary program can check a value and then run only one of two pieces of code. But a quantum computer runs on a superposition of many inputs at once, some of which would run the first piece of code and some of which would run the second, so the circuit has to include the operations for both every time it runs.

If you squint, this looks like SIMD programming (for a quick introductory reference, see [1]) where there is no branching logic in the lowest level. Looking from far away, it seems like high-performance programming is converging from these two points, isn't it? One with the current classical hardware, the other with the new quantum one.

[1] https://mitchellh.com/writing/everyone-should-know-simd

Great point. Perhaps when we have AI robots interacting in the real world doing experiments we'll have that.

> Real progress happens by expanding the area of the envelope, not by coloring in the blanks.

Respectfully disagree. What one person may classify as expanding the envelope, another one with broader knowledge may classify as coloring in the blanks. Much knowledge in one field comes from cross-pollination from other fields.

Let me give you an example I just learned about. The database community spent decades trying (to some extent) to solve the implementation of materialized views to arbitrary complex SQL queries. Then, a few years ago, someone with experience in digital signal processing brought their expertise to the DB field and completed the puzzle. [1]

Someone with DB expertise but no signal processing expertise might say that is expanding the envelope, but another person with experience in both may say it is coloring in the blanks.

AI work now may seem like coloring in the blanks, but given it's vast expertise in multiple fields, my bet is that for most people it will look like pushing the envelope very soon.

[1] https://arxiv.org/abs/2203.16684

> Frontier models couldn't change or add a feature without breaking something else.

Have you tried working with Rust (e.g. Bevy) and all of its compile-time guarantees to prevent that? I imagine it must help a lot.

I wonder if nowadays we should be focusing less on scalar data structures and more on languages that facilitate vectorized/SIMD instructions. Languages like Vx lang, Mojo, and Futhark that work both in the CPU or the GPU, although each one works in a different level of abstraction and control.

I remember listening to Jane Street’s Ron Minsky on their podcast talking about this a few months ago, how TCP becomes the bottleneck in AI clusters. As an electrical engineer, I remember that circuit switching gave away to packet switching due to very sparse usage of the network when there are many actors going through it. It is not very efficient, but that wide variety of traffic makes it hard to optimize it since the flow patterns are too dynamic. A good analogy with car traffic is that downtown there are so many cars going to a large variety of places, that traffic lights – as inefficient as they are – are a solution that at least works good enough.

On the other hand, if the traffic follows a very predictable pattern, a custom implementation can be much more efficient. Specially nowadays machine learning can find much better solutions through reinforcement learning. And AI cluster data flow is much more predictable than what goes over the internet as a whole.

> Most software that requires hiring and paying software engineers has low risk tolerance:

I think a few of the industries listed like defense and aviation have low risk tolerance. However, from my (somewhat brief) experience of working in two health techs for a couple of years, I strongly disagree that healthcare has low risk tolerance for tech. Granted, they make run-of-the-mill CRMs, but I was baffled at how tolerable it is to have egregious user experience that makes users waste multiple hours per month with clerical work that is very painful because the UIs are very slow and buggy.

There is a huge amount of pending work in health research that is nowadays ignored because smart people have better paying jobs available.

Once many of those jobs get automated, I bet there will be many more people working in health research, which hopefully should lead to better health outcomes for society as a whole.

For frontend web development, Elm enforces a pure core (pure > deterministic).

I have been trying to tell the folks at work the same thing. Ideally, using a language that goes in that direction. For frontend web development, for example, there is Elm, which is pure and functional.

Maybe learn Rust as a middle ground between ML and C, then? It has sum types like ML and teaches you memory management like C.

Shotout to PowerSync for enabling companies to go in the opposite direction and build offline-first apps. My company is a (production) customer, and we recommend it.

> Companies want everything to be push instead of pull.

This reminds me of Instagram's search page, which is full of animated videos jumping at you to dissuade you from completing the search you wanted and just click on what they want you to see.