MySQL was generally (pre 8) optimized for point queries on primary keys. So rows are stored in the PK index, the PK index is a clustered index. Everything more or less falls out of this.
Sure, I'm only taking about innodb. The join strategies supported before 8.0 (5.7 and lower) were basically nested loop and that's it. Which only really works well for a couple of query patterns: point queries with a handful of joined tables all using indexed FKs, or a big sorted scan over one single table and everything joined to it, with pagination through where clause and sorting all on the primary key, and possibly a straight_join to make sure it doesn't start the execution plan anywhere other than the spine table.
> only really works well for a couple of query patterns
To be fair this probably covered probably 9x% of production queries, like high-selectivity index-covered filters and sorts (with a limit). Even today most planners will still use an inner loop.
It's been interesting to watch how different planners have evolved over the years. SQL Server 7 in 1998 launched with features that MySQL and Postgres wouldn't catch up to until the late 2010s, but they had other features and quality-of-life improvements that made these edge-case optimizations hardly noticable.
10 litres alcohol is about 100 bottles of wine a year (exactly 100 at 13.33% alcohol content).
I drink a lot of wine, but 1 full bottle is too much to have regularly. A half bottle - two generous glasses - is more reasonable, but you'll still feel it the next day. And 10 litres of alcohol puts you at 8 generous glasses a week.
Neither nuclear nor gas or coal will matter any more in a few years. It took California only six years to install 41% of the battery capacity goal it has for 2045[1]. As batteries are becoming part for new solar and wind installations, they will push nuclear and gas out simply by being cheaper and more predictable as an investment.
> they will push nuclear and gas out simply by being cheaper and more predictable as an investment.
Unfortunately, this probably won't work everywhere. Particularly in Northern Europe winter is tough as there's very little sunlight (manageable) and often very little wind (not manageable,as it lasts longer).
Nuclear is an expensive way of solving this problem, but it's carbon neutral which is super important.
Even that would be manageable with enough solar panels and batteries, no? Or is it certain that too much surface area would have to be covered with panels?
Batteries work for 1-2 days right now. These wind breaks can be 1-2 weeks.
Like, to be fair, batteries have improved so much in the last decade that this may be solved, but I'm generally sceptical of one thing that will save us, as I reckon we'll need multiple things to ensure resilience (which is really, really, really important when it comes to core needs like electricity and heating).
Is the need for "pretty large breakthroughs" based on realistic calculations, or are you just guessing? I know that most people subscribe to your position, but I can't say I've really seen convincing analyses that show the numbers:
- What thresholds of $/kWh, charge speed, power density etc. do we need to reach before scaling becomes viable? What are those thresholds based on?
- Where are we now on those metrics, and how did they evolve over the last 2-3 decades?
Still, everyone seems very confident that scaling is non-viable now. But IMO it should be possible to demonstrate the non-viability using the approach above - even if the exact numbers are wrong, the orders of magnitude should be good enough, right?
> Is the need for "pretty large breakthroughs" based on realistic calculations, or are you just guessing?
I'm just guessing. But absent some kind of path to get there, I'd prefer to plan for needing to cover this situation with nuclear or other storage (I feel like pumped storage may make sense, but again haven't done the numbers).
Like, if you're correct then we'll end up with lots of power we don't really need. That's great, as we can use it to decarbonise other parts of the economy, however, if I'm correct and we dont build some kind of baseload/storage solution then we'll be in trouble in the winters, which I really want to avoid.
If you're correct, we'll end up with tons of extra power, since the nuclear plants would have to cover everything on their own anyway! But it would also take unbelievable amounts of money, and thus delay the energy transition by decades. We don't have that much time left.
Instead of guessing, maybe it's worth looking into the numbers?
Nuclear power plants need to be taken offline for multiple weeks to months at a time for refueling and maintenance over their lifespans making them a poor fit for base load without extremely costly redundancy in a small country.
A couple points. No, entire plants aren't taken offline at once typically, individual reactor cores are, and modern designs work to minimize that. They still maintain extremely good uptime, especially if you're comparing them to intermittent renewables. Secondly, Italy isn't super tiny, and you need redundancy for outages and such in any grid regardless of its components.
Cutting out the “and maintenance” bit is misleading.
It’s commonplace for maintenance issues at non CANDU reactors to extend the “refelling” downtime. So no, CANDU can’t stay online for decades without maintenance and instead have similar downtime issues. The major benefit is when manufacturing plutonium due to shorter fuel cycles, but overall CANDU reactors are less cost effective which is why adoption fizzled out.
> So no, CANDU can’t stay online for decades without maintenance and instead have similar downtime issues.
There are several situations:
* refuelling occurs
* maintenance and/or inspection needs to happen
* refurbishment may be desired
Some of these things take downtime, some do not, depending on the design of the reactor and other factors. A blanket statement of "refuelling forces a downtime" is incorrect in many situations. Depending on the maintenance (or inspections) needed, this may or may not need downtime. Refurbishment generally means tearing things apart, so usually means downtime, but if a site has multiple reactors they can be done one at a time, e.g.:
Eh, again, I disagree. As an example: Many CANDU reactors have insanely high availability. Example: Qinshan CANDU Unit 1 only had a planned outage of less than 27 days in 2023. There are many other examples. That is crazy uptime in the world of electricity production. And to be clear, if you come at me with "Oh, what about the major maintenance required every 10+ years?". Thermal (coal/gas) has the same issue.
I had a discussion with ChatGPT about this concern. When comparing a modern EPR (European Pressurized Reactor) to a modern coal or natural gas thermal power plant, the required maintenance cycles look fairly similar. For the nitpickers/tomato throwers (I see you!): I am using EPR because it is state-of-the art for nuclear power, and I am specifically using the term "modern" for thermal power plant because the newest ones (China, Japan) are nearly at the frontier of efficiency possible for that type of electricty production.
Roughly: EPR runs for 18 months, then requires 1-2 months of maintenance (which includes refuelling about one third of its fuel assemblies). A modern coal or natural gas thermal power plant runs 12-18 months, then requires 1 month of maintenance.
Next, I could not resist as other commenters already mentioned it. You wrote: "small country". As the Aussies say: Yeah, no. Italy is 300,000 sq km. That is not small. If compared to the United States, it would be the fifth largest state.
Finally, why does it seem that all discussions about electricity production on HN always devolve into the "Base Load Wars"? For me, it is starting to feel like a meme. (Are there LLM troll bots trained to enter HN discussions and make a bunch of "base load" arguments?) Seriously, can someone please create a text-based role playing game that revolves around a future society locked into eternal "Base Load Wars"? (See: PhD Simulator[1])
But is this the intended maintenance duration, or the actual one? Because the construction of every EPR project has been a disaster. Construction took 20 years in Europe and 9 years in China.
Well, there are only four EPRs in the world. It is too early to say. Frankly, as a non-expert "armchair observer", Finland was dumb for starting the EPR project before the design was finalised.
From what I read no further EPRs are planned and they fully want to go ahead with a streamlined EPR2 design.
I think the problem of the Finns was that they really wanted energy independence and tge inly ones that were on the market were the french. No doubt the frenched used much diplomatic muscle to attract them as a first experiment.
What if I don't want my agent to have terminal access though? I get the feeling many people here simply never worked with smaller models, those will confuse cli args really quickly once context expands, and then you have no idea what damage they might do. With MCP's, they get just the access they actually need. Is the Principle of least privilege just not something we want to apply anymore?
CLIs, run in a sandbox as tight as your preferred choosing, live in an ecosystem, where, via pipes and redirection, input and output can be easily manipulated. An agent can do similar things but more laboriously (and less token efficiently) via Python or similar but it would still live in a sandbox somewhere.
Going without the sandbox means hobbling the LLM. It can do things directly but is less able to construct ad-hoc programs to deal with looping, conditionality, tame verbosity, connect tools together, and so on.
It's a choice to not give the LLM an environment. As you say, it can be necessary if you're using dumb models. I don't find it particularly worth the trade most of the time.
If not even OpenAI can properly box in their models I definitely won't trust myself to do so with the very limited time available to me, and instead just use a standard that's already defined, and proven to work.
You hobble the expressiveness of the LLM and reduce its capability.
Think of an agentic harness as like a kind of body for the LLM. It gives it primitive inputs (read_file, web_search or whatever) and primitive outputs (edit file, respond to user, etc). Give it a command line environment (in a locked down sandbox, with as few or as many tools as you prefer), and you've given it a toolbox. It can do a whole lot more, faster and more efficiently. It can compose tools together. It makes fewer transcription errors manually shifting data around. It can tame verbosity with good protections in the harness and access to grep, sed and awk.
It's really up to you how useful you want your agent to be.
If you don't have something running somewhere, you don't have an agent, you don't have a harness. You've got a token generator, an LLM from the 2024 era.
That's where you are completely wrong. The point of MCP is that you can have an agent and a harness without running raw CLI or Python commands. Very common for relatively lightweight loads that involve shuffling data around between APIs, often run in a tiny serverless task.
Sure, you have an LLM which can invoke functions. I will say that without storage and composition, you're asking for hallucination. LLMs are not deterministic and while they're good at regurgitating text - you can see how replies in an instruct model are structurally keyed off the question - they will rephrase, adjust, "correct" data they're schlepping from one call result to another call input. And one noisy MCP call and there goes your context.
You could build something with storage and composition out of MCP functions, but come on, have you seen how LLMs - particularly budget LLMs - try and invoke functions reliably? The amount of retries you have to hide, feedback you need to send back to the LLM about what it did wrong. Parameters get replaced with synonyms, arrays are passed for singular arguments and vice versa, structured inputs are flattened, etc.
So maybe you fine tune on interactions with your subset of MCPs, to improve reliability. But all you end up doing is reinventing a Unix-like command line, poorly.
Firecracker micro-VMs, gVisor, wasm sandboxes. There are ways to make this work that aren't heavyweight. Giving LLMs tools that they've seen how to use millions of times in training corpora just works better.
Mutability vs immutability describe the relationship between identity and state. Mutable values retain identity when their state changes. For immutable values, getting a new state requires a new identity, and importantly, existing identities never have their states changed.
Variables can be described by types. That is, a mutable slot referencing a value can be a value itself (a reference to a reference) and we can use subtype relationships to describe it. Variables are covariant when used as inputs (i.e code reads from the variable) and contravariant when used as outputs, and invariant when used as both. You can logically supply a Box<Cat> to a vet(in Box<Animal>) routine, and supply Box<Animal> to catchAndStore(out Box<Cat>). Substitute `ref X` for `Box<X>` when using a language that can pass variables by reference.
Instead of thinking through all the places in the code the AI is going to have to touch, why not kick off three parallel agents implementing the thing and finding out what they did and the tradeoffs they found?
Planning is essential but it doesn't survive contact with reality. However, AI makes contact with reality cheap! Why not use it to improve designs, by writing the design after a few implementations have already been made?
I'm looking for the places that need to be touched, but that wouldn't occur to me (and maybe not to an AI either) while I'm knee-deep in the code. Seeing where the AI touched isn't going to solve that.
If the feature works, and passes AI auditor agents with various hats (thinking of auth and security in particular), did that code you're not thinking of need to be touched? What effect did it have that cannot be captured in side effects, tests or audits?
If what you said doesn't make the AI think of changing that code, why is it going to make the AI auditor think of testing that code? That's what a gap looks like: Nobody changed it, nobody tested it, but some business constraint is now left in an inconsistent state because some piece got updated and another piece did not.
Here's an example. You updated the code that interfaced with the database. But you forgot to update the stored procedures within the database. As a result, the database is now being put in an inconsistent state with every transaction that uses your new code. That is the kind of thing that a software design doc can help you remember, because it is supposed to make you think through all the stuff.
And if you're going to say "Your business stuff shouldn't be able to get into an inconsistent state", well, there's a lot of businesses that have potential landmines laying around. You can say they shouldn't. You're right, in an ideal world. But in this world, they do, and you have to live and work in the world that we have.
Now, in fairness, a good AI check might turn up that the database was left in an inconsistent state... if it understood the constraints well enough. If. I wouldn't want to gamble my production database on the AI's understanding and testing of all the constraints, though.
When I've worked with systems that had these kinds of characteristics, we had checklists. A long list of "have you thought of X". You can't rely on someone writing a design to think of these things either! You need to have a process, and the process applies whether you dive into the code, dive into the spec, or have an AI dive into either.
It's orthogonal.
To be clear, I'm not suggesting blindly deploying an AI-written spike implementation to production, but rather using it to elicit information for better designs.
The fact that a probe that goes off and modifies tables X, Y and Z to achieve the feature gives information for an AI auditor to look for other uses of X, Y and Z, and discover things humans may miss, because with good guidance and a proper harness, AI is usually more persistent and thorough than people. It can turn search results into a checklist and the harness can track completion, and so on. I am far from convinced that your example would not be found via this route.
Well, yes, I'd expect a checklist to be used as part of creating the design document. If there's a separate auditing tool that also knows about the checklist, yes, that's useful.
But if you're doing a spike, no, don't do a design document for it. How can you? You don't know what the design needs to be yet!
That means you could choose to try three (or more) genuine implementations and explore their tradeoffs, instead of making three proposals in a document with one recommended (and the other two usually only provided for contrast).
I do think the design is important to keep around - in particular, the constraints, the communication points, schema, tacit things that might not be clear in code. I am not certain that the design should precede the implementation for features below a certain size though.
Larger efforts need milestones and collaboration and will have multiple people doing implementation, so there's more need to agree schemas, APIs etc up front there.
Agree, but in my experience that doesn't change much about the design doc.
I think it's helpful to the author to be able to say to an AI agent, "Hey, put together this quick prototype," and that informs the design doc. But if the goal is to review the design decisions with the team, I don't see how you get around the design doc. I don't want a teammate to send me 10 KLOC of AI-generated code and ask me to review the design. Even if you told AI to try 10 different ideas and pick the best, I don't trust AI to make the same decisions as my human teammates.
I'm not suggesting using AI generated code as a proposed design.
I would try and get an understanding of design space by giving a good agent a high level goal and seeing what it does, then getting a summary of the approach.
When you do this several times, especially if you give it a steer on some non-functional requirement, you can compare and contrast different approaches.
The idea isn't to prototype so much as to gather information by doing. Prototype, to my mind, suggests other things; shortcuts, stubs, incompleteness. I would actually ask agents to do the whole thing, and find out the full scope. It can be particularly useful revealing side effects.
Pair it with code auditors wearing different hats, of course.
I find that LLMs are still worse than humans at limiting complexity, which is one of the most important outcomes of a design review.
If I tell a senior SWE that I'm creating a Discourse-like discussion forum, and I want users to have three options for selecting an avatar: (1) import from Gravatar, (2) upload a JPG or SVG or PNG or GIF, or (3) let the user draw their avatar on a canvas, the LLM will happily go and design that and write a 5 KLOC implementation, whereas a good SWE would push back and say, "That's like 10x the complexity of just allowing JPGs. How about we simplify it to say that in v1, the only option is to upload a JPG."
I've tried working with Fable/Sol and saying, "Look for features that we can simplify to reduce complexity," and they don't understand. They'll guess at features we can cut entirely, but they fail to see how to capture the essence of the feature without the complexity.
I've noticed this a lot with Fable recently. Like I'll say, "Show an error message in the web UI if X fails," and Fable comes back with this like 800 LOC error message generator that has switch-cases and combines inputs from three different sources when all I wanted was something like, "Update failed: database is locked."
I do agree with you put I would push a little further - is it that complexity itself is the enemy? Or is it that the secondary outcomes of complexity (bugs, more effort to make changes, confusing code) are the enemy? If it is the secondary outcomes that are the enemy, and AI actually effectively allows you to mitigate those outcomes (debatable! I debate this with myself all the time!), then maybe we should embrace the complexity (or the agent should on our behalf)
> I do agree with you put I would push a little further - is it that complexity itself is the enemy? Or is it that the secondary outcomes of complexity (bugs, more effort to make changes, confusing code) are the enemy?
I agree, but I think we're still a long way away from being able to trust AI to manage all software complexity for us. For one, LLMs frequently get tripped up by their own complexity. But even if the complexity didn't make LLMs more error prone or expensive to run, you still often need a human in the loop to understand what the system does.
I think of it kind of like compilers. Compilers do a good enough job that 99% of developers don't understand code at the bytecode or machine instruction level, but if we lost that last 1% of programmers who understand CPU instructions, we'd be in serious trouble.
Even if it's cheap, 3 implementations are more expensive than one and then you add the additional task(s) of evaluting them and selecting one to move forward with.
reply