> What I want is a dispassionate discussion of how different language features impact code quality

This can be difficult because code quality, productivity, safety are hard to objectively define and measure, so we always fall back to differences in interpretation and experience.

I would be interested in serious attempts to argue for this, even if they can't reasonably be backed up by data.

For example, I think there's a pretty strong argument that immutability makes it easier to write multithreaded code (perhaps at some performance cost), because it entirely prevents common types of bugs.

Similarly there's a good argument that making methods open to extension (like Kotlin or Julia) makes it easier for an ecosystem to adopt unified APIs without explicit coordination.

There's obviously a very strong argument that Garbage Collection prevents a lot of memory safety bugs, at costs to interoperability and performance.

> dispassionate discussion of how different language features impact code quality

I think we can start disagreeing here.

The metrics shouldn't be solely code quality, but also simplicity, readability, and how fast you can express yourself in it.

Code quality will go up the more language friction you add: types, "one way" of doing things, and function-oriented programming. Same code in a language with heavy types and strict functions will be of course "more solid". However, it will take 10x the time to write, be less flexible, and harder to understand.

> However, it will take 10x the time to write, be less flexible, and harder to understand.

Not in my experience: only in the usual ramp-up period in the first few months.

Do you know of any articles/papers that try to do in-depth analyses of which features are helpful for building big systems?

Most posts I can think of basically say "X language is good" or "Y language is bad", but I'd really be interested in arguments like "feature A is better at accomplishing goal Z than feature B"

That's a very good point. My experience is that for large project the architecture also becomes important.

Large project have much code but if you can split out responsibility because your architecture allows this, then you keep your code concise.

One feature Ruby has that helps here is creating Domain Specific Language without yacc or lex. This allows for concise code where its needed.

Not quite the same, but I find "data-oriented programming" to be a very strong method for managing large codebases. By that I mean having data structures that designate the end state that you want, having another set of code that gets you to those end states, and maintaining a pretty clear boundary between the two.

(If you like with "Functional Core, Imperative Shell", this is a way to further divide the Functional Core.)

It works well because it narrows the surface area of a lot of possible bugs: either your configuration is wrong, or your code doing the transformations is wrong.

You kind of describe flow based programming (FBP) whereby data is passed to stateless functionality.

Things like Unix pipes, Node-Red and n8n are inspired by FBP.

I agree with what you describe, also reuse is simpler because code tends to be stateless.

There are languages much better suited for DSLs though.

There are some programming language journals that people like to dismiss as “academic”. But “academic” is what I value here.

There are a lot of programming language journals – are there ones you'd recommend specifically for discussions of tradeoffs between features?

You're looking for a copy of Eloquent Ruby: http://eloquentruby.com/