luckystarr

Tried it on Android and got "!!!!!!!!!!!!!" for answers.

Fair take if the user is the same person as the implementer.

If I sell software to my customers that reduces their operational complexity by me investing some code, then I don't consider it a loss.

Can be that I remembered it incorrectly, as it was in 2008, but here it is:

https://se-radio.net/2008/03/episode-88-the-singularity-rese...

There is a difference between easy to set up and not having to set up anything. It's an improvement in operational UX.

It only changes behaviour if the risk of having to pay outweighs the benefit. And Google won't tell what they earned through that I guess.

I listened to an interview with one of the researchers. They had a component to verify "this binary will never allocate mem outside it's allowed area" and by statically verifying that they could enable high performance IPC. Also, that was the source for the decision to allow it to run on Ring 0. That's what stuck in my mind.

Sounds a bit like Microsoft's Singularity project, though I don't know if they even used a proof system to ensure a program couldn't do bad stuff(TM). After verification they just let the program run in Ring 0 (kernel space) of the CPU to skip even the performance hit of the cpu's isolation.

[int overflows, etc.] No runtime cost when Z3 can prove it. Otherwise, the compiler emits a safe runtime check as fallback.

Super interesting approach. I see this eventually be integrated into future mainstream languages, though that may take a while. I suspect that the game programming crowd will try to use it first, due to the possibility to prove certain edge cases at compile time and skip the runtime cost. But perhaps this optimization drive is no longer the case because we've got bazillions of cores nowadays. I may be too old for these predictions. Cool nonetheless.

How I see this:

Refactoring code to reduce the number of lines is _compression_, akin to RLE coding.

Refactoring the code to lift conceptually coherent parts is _abstraction_.

Less compression, more abstraction. Then you're fine.

Over the last year or so I arrived at a (sort of) MQTT semantic broker that facilitates an actor architecture. It supports federation (including transitive, so proxies "just work"(TM)), transparent outbound buffering with disk overflow and encryption with the noise protocol. Building apps on top of it is a joy. Rust.

edit: ah, yes also a broker controlled component manager that can start, stop, monitor services over the mentioned broker. This is the carpet that brings the room together.

Then the workers wouldn't spend 20 trillion and the economy as a whole would tank.

In most of Germany neither is required (Baden Württemberg requires non-EU citizens to pay 1.5k€ per semester). Commonly though you have to pay from 200 to 300€ administrative fees.

The harder problem is to enter Germany, but as you have EU citizenship, that's not a problem for you.

I tried coding "ownership strictly" in Rust myself for a while and I've given up for the most part. In a lot of cases I painted myself into corners that I couldn't get out from without changing everything. That is probably a signal I should use, but Arc and clone also work. So I use them.

So what does that mean? Claude within ACP within my editor is billed differently than Claude via CLI?

You have to make performance part of the spec. It will then create benchmarks and plan differently. If you omit this, you get what you get.

And you can spend your effort on features and architectural issues rather than smaller scope bugs. My experience is that Rust enables me to focus on features as long as I don't give the AI free reign. Architecture matters for correctness bugs, because some solutions are inherently more prone to the AI becoming confused along the way than others.

The more effort I spend on planning architecture with the AI, the less runtime bugs I need to investigate after it did the implementation.

Discovery of the best solution in a problem space is not generative but only verificative. Meaning: the LLM can see if a solution is better than another, but it can't generate the best one from the start. If you trust it, you'll get sub-par solutions.

This is definitely an agent problem instead of an LLM problem. Anybody got something explorative like this working?

For the love of god, don't do blank textiles anymore. In the end you have a software that has 20 (or more) individual files for each programs section, which works fine until you want the files to be consistent. Boom. And then you add a lock to fix it and suddenly your whole program can only run sequentially. And then your customers ask why it's so slow in ingress. I won't name any names here, but this is a real commercial product.

That's why I use Rust and an Actor architecture. :)

The problem is not the LLM deviating from the plan (though that rarely also happens when it thinks it has a better idea) but rather if the plan is not strict enough and the LLM decides on the fly HOW it is going to build your plan.

When the end result has problems and needs to be reworked.

You can't figure this out instantly except when you'd review everything the LLM produces, which I am not. So the round trip time is pretty long, but I can trace it back to the intent now because I commit every architecture decision in an ADRs, which I pour most of my energy into. These are part of the repo.

Using these ADRs helped a lot because most of the assumptions of the LLM get surfaced early on, and you restrict the implementation leeway.

Its the "unsettling little ways", right. So you can't skip whole paragraphs, you literally have to read everything. And sometimes its worded in ways I don't understand at all (due to missing implications that the LLM conveniently omitted), so I have to re-ask it about that point as well. For every major feature or work-unit it takes up to 2 or 3 hours.

I figured out some patterns in the way it behaves and could put more guard-rails in place so they hopefully won't bite me in the future (spelled out decision trees with specific triggers, standing orders, etc.), but some I can't categorize right now.

The way I use AI now feels more exhausting than the programming I did for the last 20 years. I pose a problem, then evaluate proposals, then pick the one I think is the "right one"(tm), then see the AI propose a bunch of weird shit, then call it out, refine the proposal until it feels just about right (this is the exhausting part), then let it code the proposal. The coding will then run for 1-5 hours and produce something that would have taken me at least 2 or 3 weeks (in that quality).

After 5 hours or so of doing this planning, I'm EXHAUSTED. I never was exhausted in this manner from programming alone. Am I learning something new? Feels like management. :)

The original plan was to only shut the reactors down when enough renewable energy sources would be available to replace them. The Merkel government wanted to prolong the initially planned phase outs. Then Fukushima happened. Bad optics. So after pressure from the populace they instead of prolonging their runtime (as they wanted initially), they shut them down, but earlier than planned.

Get the facts straight.

I tried the way they used "oracles" to verify their implementation against known good ones, and I must say: this works.

Not all implementations are re-implementations, so this approach won't work for everything. But for a new implementation in a new programming language than the original implementation, it works great. Built myself a MIB compiler, checked against smidump. Now it is more correct than the original, because smidump still crashes on some inputs, while mine does not.

So the news is not so much that Anthropic built a C compiler, but HOW.

While they are not as efficient or flexible, they are many times more efficient than resistive electric water heaters. I've installed one with in house air intake (due to construction reasons) in my house and it cooled down the basement by a few degrees (and removed air moisture as an added bonus). In summer the thermal capacity of the ground heats up the basement again, in winter it's a bit cooler, but it still works efficiently.

Not sure how to take this. While your statements are objectively true, there are a lot of reasons the US won't attack the EU, even if the reasons are mainly economic.

Russia on the other hand is shit at waging their war in Ukraine but they achieved their objectives (land bridge to Sevastopol, etc.).

So the worry is not that Russia will wage a well fought war, but some war at all, even if they are shit at it, because it will do extensive damage either way. And we know for a fact that they don't shy away from it.

Now make an algebra out of the CAP theorem. It's not already one, isn't it? Didn't read the paper.

Newer wind turbines don't have a gearbox and are almost completely silent. When standing next to one, the loudest components are the electrical inverters/transformers.

The API is great. Will definitely try it out. I have a use case already. How difficult would it be to extend this to support timed flushes? Like, every 200ms or so, regardless the fill of the buffer?