It uses twice as much tokens to achieve the same but the results are significantly better and because it's so much cheaper it's the most economical choice too.

[1] https://blog.bosun.ai/software-maintenance-with-open-weight-...

Comments URL: https://news.ycombinator.com/item?id=49271848

Points: 4

# Comments: 0

One argument I could bring is that despite all its claims, OpenAI still had to switch from containers to MicroVMs because its agents under test still managed to break out from their containers. Is the security model of a Sandstorm grain so much better that agents wouldn't figure out how to break out of it?

We have so many programming languages because it's a fun and relatively easy thing to start, and lots of people have differing opinions of how it should be done. Also making a programming language seems like a difficult thing from the outside so it has a certain allure.

Swift exists because objective c has archaic language design that modern developers reject. Objective C exists because as far as I know at the time smalltalk style object oriented programming was hip and C++ made the wrong decisions in their eyes. It could also be that C++ wasn't popular enough yet at that point for Apple to commit to it. In that period basically all major operating systems went different ways. The Unix derivatives went all in on plain C, Microsoft went C++ and Apple objective c, though I think OSX itself is plain C for the most part.

And you are right, that charge on the drain can then be used both to drive some logic and to activate the recharging of the capacitor that was just discharged.

By the way I am being handwavy about "charge" moving about, if you really want to learn the electronics it is more correct to call it a voltage relative to some ground that the charge always moves towards.

> This isn't how computers work and it's not even how math works.

What are you disagreeing with? There's some baseline amount of I/O that the kernel does for you, that's what I'm assuming is 50ms, and everything else like runtime degrading is overhead due to the language/platform choice. I'm saying Rust is upwards of 100x faster in that regard thanks to its zero cost abstraction philosophy. You can't just include the I/O baseline in a claim about Rust's performance advantage. You'll be really disappointed when Rust doesn't download your files 100x as fast as the Python file downloader.

Anyway, I'm sorry I provoked your antagonism with my terse messages, I wasn't trying to be blase. I believe uv is the sort of tool that wouldn't suffer much from the downsides of Python and that in most situations the reduced runtime overhead of Rust would have a negligible impact on the user experience. I'm not arguing that they shouldn't build uv in Rust. Most situations is not all situations, and when a tool is used so widely you'll hit all edge cases, from the point where the 10s of milliseconds of startup time matters to the point where Pythons I/O overhead matters at scale.

That is assuming Rust is 100x faster than Python btw, 49ms of I/O, 1ms of Rust, 100ms of Python.

Also, languages made up of tokens are still languages, in fact most academics would argue all languages are made up of tokens.

Anyway, it's not LLM's that achieve AGI, it's systems built around LLM's that achieved AGI quite some time ago.