> On the other hand, Rust is a complex language prone to refactoring avalanches, where a small change in a component forces refactoring distant code.
Are you saying this out of personal experience or just hypothesizing? I am working on a large, complex rust project with Claude Code and do not experience this at all.
- write sleek operator-overloading-based code for simple mathematical operations on your custom pet algebra
- decide that you want to turn it into an autograd library [0]
- realise that you now need either `RefCell` for interior mutability, or arenas to save the computation graph and local gradients
- realise that `RefCell` puts borrow checks on the runtime path and can panic if you get aliasing wrong
- realise that plain arenas cannot use your sleek operator-overloaded expressions, since `a + b` has no access to the arena, so you need to rewrite them as `tape.sum(node_a, node_b)`
- cry
This was my introduction to why you kinda need to know what you will end up building with Rust, or suffer the cascade refactors. In Python, for example, this issue mostly wouldn't happen, since objects are already reference-like, so the tape/graph can stay implicit and you just chug along.
I still prefer Rust, just that these refactor cascades will happen. But they are mechanically doable, because you just need to 'break' one type, and let an LLM correct the fallout errors surfaced by the compiler till you reach a consistent new ownership model, and I suppose this is common enough that LLM saw it being done hundreds of times, haha.
Yeah, totally unrelated to LLMs, this has definitely happened to me when changing core types or interfaces in our large rust codebase.
However, a) I think the compiler telling me everywhere I need to fix it is great, and b) even before LLMs, using compile mode with emacs and setting up a macro to jump to next clippy warning, jump to code, fix, and then repeating in batches of like 20-50 could often make it go quite fast.
You can still use the fancy operators for readability, just use a macro to translate them into the actual code. Very common pattern in non-trivial Rust libraries.
That link reads like an autobiography about his love affair with Rust and subsequent breaking up after pushing the relationship a step too far: into gaming. He has been using Rust much, much longer than me, but I rekcon I already hit most of the pain points he mentions. (And I notice he left some things out, like async.)
I've come away feeling that most it looks fixable - but it won't be fixed in Rust. Some of the language choices (like favouring monomorphization to the point of making dll's near impossible) are near impossible to undo now, and in other cases where it might conceivably be fixed (like async) it won't be because the community is too invested with their current solution.
So we are stuck with the Rust we have; warts and all. That blog post convinced me those warts mean the language should be avoided for game development. Similarly sqlite developers convinced me the current state of Rust tooling meant it wasn't a good fit for their style of high reliability coding, so they are sticking with C. Which is a downright perverse outcome.
But for most of us C programmers who aren't willing to put in the huge effort Sqlite does to get the reliability up, Rust is the only game in town right now. It's the first and currently only language to implement a usable formal proof checker that eliminates most of the serious footguns in C and C++. But I am now hoping it becomes a victim of the old engineering adage: plan to throw the first one away, because you will anyway.
I also work on a large complex rust project (>1M LOC) with extensive use of Claude Code. It is very consistent with my experience. Claude frequently subverts the obvious intent of the system - whether that's expressed in comments or types - in the pursuit of "making the build green", as it so often puts it. It, like many junior engineers, has completely failed to internalize the lesson that type errors are useful information and not a bad thing to make go away as soon as possible. It is remarkably capable, but you cannot trust it to have good taste.
The most common reason is that a quick manual step is needed before publishing. Nothing malicious. Often it is just removing paths used during dev from Cargo.toml. Should it be automated? Sure, but that is extra work.
I agree that position is nonesense. I mean, the single best defense against supply chain attacks is to bring everything in house. Is that reasonable? No…
Help normalize saying no? As an OSS maintainer, the sense of entitlement many have is quite frustrating. After years in OSS, I have built up a thick skin and am fine saying no, but many aren't.
You are very confidently incorrect. So incorrect, it is hard to even start correcting you.
* Inflation is not caused by "putting your money somewhere" What on earth.
* At a high level, inflation is caused by either "too much money chasing too few goods" and/or the cost of producing the goods rising. Money supply can increase without causing inflation if the supply of goods can also increase. In short, the supply of money can increase without causing inflation if productivity rises to match it.
* Most people do not "put money" in loans what are you even talking about there?
* Bank loans do not automatically increase the supply of money. When a loan is taken out, it is (mostly) deposited to another bank, resulting in a net-zero change in money. Increasing the supply of money requires the federal reserve to take steps.
> In short, the supply of money can increase without causing inflation if productivity rises to match it.
You're actually agreeing with me. Money supply must be backed up by real wealth and production.
That's not how things work in current times. We have nearly zero interest rates, and currencies are backed up by literally nothing.
> Most people do not "put money" in loans what are you even talking about there?
Fractional reserve banking. Banks loan out the cash you deposit. They "efficiently allocate" the money in their custody.
> Inflation is not caused by "putting your money somewhere" What on earth.
It absolutely is. Banks can easily turn thousands of dollars into hundreds of thousands of dollars by repeatedly loaning out the exact same dollars numerous times.
It's some kind of society wide financial call stack. Too many defaults and everything starts unwinding.
> Bank loans do not automatically increase the supply of money.
Obviously they do.
Imagine you deposit $100 at your bank. It takes your $100 and loans out $90 of it to someone else. There are now $190 dollars in circulation.
Whoever took the loan goes off and spends it. Eventually it gets deposited back into a bank. Then the bank loans out $81 out of that $90. There are now $271 dollars in circulation.
And it keeps going.
You can inflate bitcoin via this algorithm.
> When a loan is taken out, it is (mostly) deposited to another bank
Irrelevant. Banks form interconnected systems. They all settle debts and accounts with each other.
> Increasing the supply of money requires the federal reserve to take steps.
The physical supply of money is irrelevant. It contributes only a small fraction of the circulating money supply. Money is numbers in bank databases now. They could run the money printers 24/7 and they'd never even come close to catching up to the inflation caused by banks.
I doubt it. Eating healthy is already cheap and easy (rice & legumes as a base, fresh or frozen veggies based on what is cheapest at the time). It just doesn’t taste as good and gets boring fast.
I respect that some prefer just to use SQL, but that isn't where most stand.
Also, instead of a reactionary "all ORMs are trash," where ORM probably means different things to different people, maybe you could provide some value to the conversation by providing specific points and/or arguments supporting your feelings about ORMs. At the very least, you could provide some citation to an article that does the summarization.
Canada and the UK (among others) have toyed with these kind of "use it or lose it" penalties for unnecessary empty premises. I think they're a great idea, but they don't seem popular, maybe because the benefits are spread widely while the costs are paid by relatively few, but politically powerful, landowners.
Are you saying this out of personal experience or just hypothesizing? I am working on a large, complex rust project with Claude Code and do not experience this at all.
reply