> In Zig, every file can be parsed completely in isolation...every name needs to be explicitly declared (there’s no use *)...

> In contrast, you can’t really parse a file in Rust...Expanding macros requires name resolution, which, in Rust, is a crate-wide, rather than a file-wide operation...Similarly, the nature of the trait system is such that impl blocks relevant to a particular method call can be found almost anywhere...

matklad doesn't even mention dynamic languages, where perfect name resolution is undecidable. "Fast static analysis, easy static analysis, language designed for static analysis - pick two".

Rust's IDE integration is fast and deep, and I've heard TypeScript's is too, so "easy static analysis" may not be important today. I believe it will as coding evolves due to LLMs, albeit without evidence and I'm not quite sure how.

▲

rendaw 6 hours ago | parent | next [-]

> "Fast static analysis, easy static analysis, language designed for static analysis - pick two"

Where does this come from and what's the explanation?

	▲	armchairhacker 2 hours ago \| parent [-]
		I made it up, although maybe I’m not the first? The third should actually be “language not designed around static analysis” - You can write a static analysis that is fast and straightforward if you design the language around it (fast + easy + !language) - Otherwise, you’ll run into features that prevent that. Ex (stolen from an above comment): name resolution within unqualified imports - For many such features, you can write a brute-force solution. Ex: scan all possible definitions within the unqualified import until you find the target name (!fast + easy + language) - Or you can optimize this solution, using incremental cached lookup tables (fast + !easy + language) Of course, there are languages with features that make most static analyses for them neither fast nor easy (ex: for name resolution, eval or macros). But it holds in many cases, ex: - Parsing: basic syntax (!language), GLR parser or LL parser with big alternatives (!fast), IELR parser or LL parser with smart alternatives (!easy) - Type inference: many type annotations (!language), brute-force enumerate candidates (!fast), Hindley-Milner or bidirectional, possibly extended for features like trait resolution (!easy) - Allocation: manual (!language), put everything on the heap (!fast), heuristics, implicit boxing and unboxing (!easy) There’s a trend (I also don’t know where it originates) that most “data processing” problems can be solved with an easier slower or trickier faster algorithm (hence, competitive programming). Static analyses are this class of problem, but for them (sometimes) there is a third option: simplify the problem by putting hints in the language.

▲

foolswisdom 7 hours ago | parent | prev | next [-]

I would really appreciate if rust analyzer was faster, actually. It feels even worse with the fact that you need to save the file before it updates the type checking (though I assume it's because it's too slow to feel smooth if you do it while typing?).

	▲	Rusky 6 hours ago \| parent [-]
		The reason rust-analyzer doesn't update diagnostics until you save is historical. Originally, people tried to build IDE support by reusing rustc itself, but this proved too slow and cumbersome at the time. Rust-analyzer reimplemented the frontend in a more IDE-friendly architecture, but focused more on name resolution than on type checking. So it delegated diagnostics to literally just running `cargo check`. As parts of rustc get rewritten over time (the trait solver, borrow checker) they have also been made more IDE-friendly and reusable, so rust-analyzer is slowly gaining the ability to surface more type checking diagnostics as you edit, without delegating to `cargo check`.

▲

6 hours ago | parent | prev [-]

[deleted]