Lines of code is not the measure of productivity
I didn't say lines of code is good way to measure productivity. Using it as such a measure is counter productive because programmers find ways to bloat the code. Not only doesn't it increase real productivity, it creates a maintenance nightmare.
What I said was programmers produce the similar lines of code per day, regardless of language. If you are doubt this, you need to go study some more. It's been demonstrated over and over again. There are many things that do effect lines of code delivered of course - the biggest one being project size. Most programmers can deliver a 200 line debugged, working program in a day. Put the same programmer in a large project, and that can drop to 10 lines of code per day, which is far larger effect than language.
You are right in that lines produced per day by a programmer is effected by language - but It's nothing like 20 to 1. This page shows 4 to 1 at the extreme; Smalltalk vs Assembler, with the assembler programmer producing 4 times as many lines of code as the smalltalk programmer. I guess that's to be expected give how much a meaning a smalltalk programmer can put into one line vs an assembler programmer. If you look at languages that are more similar - eg curly brace languages, you see a difference of only 2 to 1.
If you look closely, you notice another odd thing. The less lines the programmers write, the more productive they are in delivering function points in general. Now if I had of said because the C programmer writes code faster than Rust productive, he will be less productive I'm sure you would have jumped on me from an even greater height and you would have managed to be more wrong than you are now. I don't know whether it's true for C and Rust, but "the more code a language lets you write in a day, the less productive you will be in it" is definitely a good rule of thumb. In the smalltalk vs assembler case, the smalltalk programmer delivers 3 times as many function points as the assembler program per unit time, while writing 1/4 of the amount of code! If it is true for C and Rust, it annihilates your suggestion that over the life of a project C would be more productive that a Rust.
Lines of code is not the measure of productivity when two thirds of them require debugging or rewriting because the idiot didn't know what they were doing and used a hammer to drive a screw.
True. Which is why it isn't measured that way. The usual measure is the total non comment lines delivered over the total time it took to deliver the project, divided by the number of people employed to do it - and that doesn't just include programmers. Here "delivered" means debugged and in production. Which is how a large project ends with with abysmal figures like 10 lines per day. If a language encourages buggy code, which is thrown away that counts against it, not for it.