I don’t care about what’s popular or what feels most familiar. What I want is a dispassionate discussion of how different language features impact code quality, and I think you can only find that in more abstract discussions. The kind that turns people off with its talk of monads and applicatives.
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.
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.
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.
Not in my experience: only in the usual ramp-up period in the first few months.
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"
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.
(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.
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.