pornel

> But the major players do seem to be happy to replace their C++ code with Rust.

Because incremental improvements don't provide enough value. A stable C++ codebase is best left untouched. It's not worth to rewrite C++ into C++++ to get a couple of features that are flawed retrofits backported from modern languages. In the end you still have C++.

> Aliexpress

There are even cheaper ways of starting a fire.

Instead of prompting "Summarize: $SESSION" you submit "$SESSION Summarize what has been done so far".

This way you have a prefix cache hit on the session and don't pay any more than for a regular prompt.

There is a solution that Mozilla uses in prod for legacy C codecs:

https://rlbox.dev/

It's not a replacement for Fil-C's role as a precise ASAN/Valgrind, but it works great if you want to call a C library without letting it freely spray caller's memory.

I don't like that it throws away the whole KV cache when compacting. It costs a cache miss of the whole conversation length, and that's a waste of time and money.

LLMs are perfectly capable of summarising the conversation without a new system prompt.

Language models were supposed to be more flexible than Siri.

Otherwise why bother with an LM? 14MB can fit a lot of regexes for fixed sentences.

Dictionary-based compression is based on prediction that recently seen words will be used again. That happens to be generally true for lots of datasets, including human languages (zipf distribution).

JPEG's zig-zag is a primitive for quantization, throwing data away based on rough approximation of human perception and biology. That isn't compression itself. However, the rounded and zeroed-out data is then compressed using a combination of RLE and Huffman, set up to predict the data will have lots of zeroes and few other distinct values (which the earlier step forces to be true). Or if you think about the system as a whole, you could say that JPEG predicts images will be blocky low-frequency patterns of DCT.

Another example is encrypted data. Statistically, encrypted data is indistinguishable from random. Truly random data is impossible to compress losslessly.

But if you had a predictor so smart that it could crack the encryption key, it could start predicting the rest of the encrypted stream, and therefore compress it.

You're just assuming a flawed implementation of a predictor and complain that it's flawed. That doesn't invalidate the general premise that predictors are compressors.

Predictors don't have to give you some corpus-average probability. They can give probabilities adjusted per symbol. The probability could even be exactly 1 for some symbol when the predictor is absolutely certain (and then it costs 0 bits to encode).

If you had a magic oracle predictor that already knew all the data you wanted to send, you'd have perfect compression.

Technical solutions may be seen as kindly as handcuffing yourself to something when told to leave. "I can't, I've made it impossible for myself to obey the law".

They might not be able to break your private keys, but they can fine you or jail you for not complying.

Induction is the good one - it has instant response like gas.

Resistive electric stoves suck and deserve their reputation, but induction is the best of both worlds: high power, accurate control, and you don't waste half of the energy due to the flame's heat going around the pot.

But the touch-sensitive controls are infuriating indeed. Nothing about induction requires them, it's just a dumb design fad.

I have some wind turbines near my town. I can walk right up to the pole, and I can't hear any noise from the turbine.

Light car traffic is ~50dB.

They're silent.

I don't know where Trump got the idea from. Perhaps he thinks they work like fans?

I'm not happy about the drop in quality either, and I'm not advocating for just making software shittier.

However, look at history of DSLR cameras vs mobile phone cameras. Mobile phones were always worse than large format cameras, and we've got a massive quantity-over-quality explosion in photos taken. It didn't replace professional photography, but let people upload photos of their lunch to social media.

I think in programming we're getting frustrated because we're trying to naively use high-volume low-quality code generators in our previous low-volume high-quality workflows. We're still discovering what's the programming equivalent of bathroom selfies, photos of receipts and QR codes.

They're here, because even "bad" code has uses. We can have quantity over quality. We can generate throw-away programs (where the lack of maintainability doesn't matter). We can solve some problems by brute force (keep trying until tests pass). For people who can't program, even bad code can do more than no code.

LLMs are also useful as a natural language interface. They're pretty useful for search (as RAG and autoresearch, not the glue-on-pizza Google search crap). They're good for filtering and classification against rules that can be specified in natural language instead of special syntax or by training dedicated models.

This is the hard-won load-bearing quote.

I'm enjoying the maximal version: https://omp.sh

I don't think so. A basic consumer-oriented harness is a commodity (zero moat: you can ask one harness to write you another).

State-of-the-art models have more of the workflow sensibilities built in, and don't need as much help from the harness.

Where harness helps the most is very customised personal workflows (not a textbox for a prompt, but an end-to-end IDE for how you develop software) But then it's best to have your own, rather than some closed-source rigid product.

Harnesses help smaller models, and very tightly hand-holding harnesses are needed for models runnable locally. I think that is very valuable to users, but avoiding paying for the biggest models is the opposite of what the frontier labs want.

Before LLMs the barrier to modifying software was much higher - in skill and time investment required.

Now we're getting to the point where any user can say "Claude, I don't like that. Please fix" and have it fixed. Configurability/extensibility can work in some cases, but having source code makes it much more powerful.

CVEs sucked even before LLMs. CVSS is an ass-covering exercise, not an importance signal. Everything is "critical" all the time.

Things you'd expect to work already.

It doesn't really add anything new and flashy, but removes some annoying warts.

Sync code has scoped threads that enable multi-threaded execution within a function, without having to ensure the data outlives the function call. Async can't do that while guaranteeing safety. This makes tokio::spawn awkward and annoying, and is a major source why people dislike Rust's async.

Low-level async code that polls Futures requires using the Pin wrapper type, which is unergonomic, and doesn't really guarantee safety, but it's more like a "be careful here" sign. Proposed changes would make that code look more like normal Rust and work without unsafe escape hatches.

omp.sh lets you enable "advisor" model that watches the session. Works very well for keeping DS on track.

yes

This mitigates problems with LLMs' low quality code. For a single user, the bar is much lower. The app doesn't have to have all the features that work for everyone's edge cases, implemented in a way that other devs can maintain. It only needs to be good enough for one user, and can be discarded and recreated when it gets too messy.

App Store will be the place to download apps you can't avoid, like your bank's client.

For personal apps, the locked down stores are making themselves irrelevant. When you have software for one person, you don't want to publish it there. You want to bypass the gatekeepers.

"we"? Looking at electricitymaps, everyone except maybe Nebraska and Mongolia is making progress.

The supply chain already exists, available worldwide as long as you don't bomb your suppliers.

I agree that removing human from the loop is the next stage, but we're not there yet beyond small programs.

Agents left alone tend to create so much tech debt, that once the program becomes so messy that they can't fix one bug without creating two new bugs, it's too late to even clean that up.

The program will be super tidy in superficial aspects that linters catch (everything neatly formatted and verbosely commented), and roughly appear to do what it's supposed to do, but everything in between will be "I can't even".

We need something else than formal methods, because the problem is usually in lack of simplicity - you get four versions of the problem solved in four times in four in different ways, each uniquely flawed and just incompatible enough with the others that unifying them is too big and hairy for the agent, and will result in eight different glue adapters written in the process.

The intelligence scores are absolute, not per $.

DeepSeek Pro is more capable than Luna regardless of the cost.

We've ran out of time. Even if political will shifted immediately, getting new nuclear plants on the grid is going to take a decade or more.

In the meantime batteries + solar or wind can be built quickly and hooked up pretty much anywhere.

Even if we had nuclear fusion, solar+batteries could still win on cost and time to deploy!

which is why they charge extra for an option to hold >256K tokens.

The cost may be smoothly variable, but likely there's a bimodal distribution of users who barely use any context and users who push it to the max. Average price across both extremes fits nobody, but averages per kind of workload can be close enough.

Having it as a separate model makes it easier to load-balance the traffic.