Another hint on all this, is that the most "loved" languages and special here, Rust, Go, Zig, ... are HOLISTIC. C, C++, JS are badly designed languages and tha

Another hint on all this, is that the most "loved" languages and special here, Rust, Go, Zig, ... are HOLISTIC. C, C++, JS are badly designed languages and that is something that will never, ever, for all eternity ( :) ), allows to make great tooling. "Badly designed" here is related, but not the same, to "bad languages". All this tooling is a circle that start from the syntax, paradigms, tastes and feedbacks that reinforce the whole thing. A good example is Rust clipply. Is amazing how great is (past week it help me turn a mess of logic with 2-3 steps of refactoring that turn like 10/15 lines of code on 5!). But you CAN'T have that good without a) GOOD design or b) TOO MUCH effort. For a great linter, Rust design has: - Cargo and sub-commands, so `cargo clippy` - A formatter, so it exist some guidance in how "good code" *look like (try guessing a lint that show a compressed line of code: Not helpful!) - A idea of what are "idiomatic looking apis" - That is based in traits and some enforced idioms - That is based in the Rust type-system and checks (so it knows when you are cloning a copy value) - That is based in a explicit syntax - That is based in extensive annotations of code - That has a GREAT error reporting machinery - That DEMAND a sophisticate parser that is resilient to errors and has full access to the source code - That run alongside the whole chain so you can start again in each cycle. And more importantly: - That is made by the same guys that made Rust, not somewhere else guessing what to do with that! Too much things to align, and that show how a "well designed" language is a holistic endeavor.