amw-zero

If you had to pick a default, an arena allocator would definitely be it. Although even better would be a fixed-size arena that can never grow, like Tigerbeetle does.

I don't think the footguns you're talking about are real by the way.

Why is that baffling? You usually have to diagnose what's going on before summarizing it into a status update.

Or do you mean you want to see: "Something is wrong, we're looking into it."

I totally agree. I have this nagging feeling that LLMs push things like this past the breaking point. Effects and contracts are _obviously_ useful to humans as well, we've just gotten by without them for a long time. But when you have intelligence on demand, context building is a huge bottleneck, and local reasoning becomes way more useful from an efficiency perspective.

I'd love to see some actual experiments with LLMs in this area. There are a fair number of languages with effect implementations at this point.

You can use them for dev environments.

You just have to finish development in 8 hours.

It would not, and you would know that if you actually evaluated the results.

It's not weird, since 99% of rentals are apartments, right?

I agree in principle, but I think the 2-5% estimate is extremely low. I could be sold on most developers spending ~25%, up to 40% of their time on code. But very few people are spending 2% of their time on it. Unless you're some sort of super senior staff / advisor to the CTO at a gigantic company, which has already placed you on rare terrain.

This is a really, really, really bad comparison. I used to say the same thing. But the semantic distance between compiling a for loop to equivalent assembly instructions is much smaller than the distance between "I'd like a web application that can store and retrieve todo items." The space of the latter is practically infinite in what can be "compiled."

Yes you're missing something: the snake oil.

I think so, yea.

Give it a shot

It 100% implies that it's looking for locally installed binaries.

So is human coding.

To say "Rob Pike wrote Unix" is completely inaccurate. He joined after v7, in 1980.

TLA+ is around 30 years old.

There is no such thing as a robust helm chart. Null was not the billion dollar mistake: templating languages were.

That’s literally what the post is about. I don’t see your point. The post is saying that formal tools currently do not handle performance and reliability problems. No one said otherwise.

I’m starting to think this take is legitimately insane.

As said in the article, a conservative estimate is that Gen AI can currently do 2.5% of all jobs in the entire economy. A technology that is really only a couple of years old. This is supposed to be _disappointing_? That’s millions of jobs _today_, in a totally nascent form.

I mean I understand skepticism, I’m not exactly in love with AI myself, but the world has literally been transformed.

Super interesting, but I think this will be very difficult in practice due to the gigantic effect of nondeterminism at the hardware level (caches, branch prediction, out of order execution, etc.)

Who brought up static analysis?

I think simulation is definitely a promising direction.

I think this is less about guarantees and more about understanding behavioral characteristics in response to different loads.

I personally could care less about proving that an endpoint always responds in less than 100ms say, but I care very much about understanding where various saturation points are in my systems, or what values I should set for limits like database connections, or how what the effect of sporadic timeouts are, etc. I think that's more the point of this post (which you see him talk about in other posts on his blog).

This is the single most impactful blog post I've read in the last 2-3 years. It's so obvious in retrospect, but it really drove the point home for me that functional correctness is only the beginning. I personally had been over-indexing on functional correctness, which is understandable since a reliable but incorrect system isn't valuable.

But, in practice, I've spent just as much time on issues introduced by perf / scalability limitations. And the post thesis is correct: we don't have great tools for reasoning about this. This has been pretty much all I've been thinking about recently.

So... a specification.

So... a specification.

Let's say a new feature. Do you just type random letters, or do you have some kind of plan ahead of time?

When you go to write a line of code, how do you decide what to write?

How do you or the client know that the software is doing what they want?

Compare the spec with the application here: https://concerningquality.com/model-based-testing/

I think we've become used to the complexity in typical web applications, but there's a difference between familiar and simple (simple vs. easy, as it were). The behavior of most business software can be very simply expressed using simple data structures (sets, lists, maps) and simple logic.

No matter how much we simply it, via frameworks and libraries or whatever have you, things like serialization, persistence, asynchrony, concurrency, and performance end up complicating the implementation. Comparing this against a simpler spec is quite nice in practice - and a huge benefit is now you can consult a simple in-memory spec vs. worrying about distributed system deployments.

Half of the world uses Apple products, how is that not the maximum possible impact?

that's a fantastic point.