3 ms·

As much as I'd love the headline to be accurate (we use pylint and friends extensively) I think the comparision is pre-mature. The linters the author is compar

As much as I'd love the headline to be accurate (we use pylint and friends extensively) I think the comparision is pre-mature. The linters the author is comparing against have significantly more features an more overhead given they need to support many more complex rules/situations, also I'd argue this linter is far from well organized given it seems all checks appear to be implemented in a flat file [1]. I would not be surprised if a fully fledged linter written in rust outperforms any linter written in python by a factor of 20-25x though. I'd be curious to see functionality & performance comparisions if this project continues. [1] https://github.com/charliermarsh/ruff/blob/0b9e3f8b472dc3fd0ea22214d619e139c03eddb1/src/check_ast.rs https://github.com/charliermarsh/ruff/blob/0b9e3f8b472dc3fd0...

charliermarsh 4y ago
Thanks, it's a fair comment :) I've tried to be honest about ruff's limitations: it supports only a small set of rules, it's not extensible in any way, it's missing edge-case handling, it's significantly under-tested compared to existing tools, etc. I don't consider it production-ready -- it's a proof-of-concept. (I _did_ try to build conviction that there weren't inherent reasons for ruff to slow down significantly as the set of checks extended, but I could definitely be proven wrong as the project grows...) My goal with ruff was partly to build a fast linter, but that was really in service of testing a broader hypothesis I have about Python developer tools could evolve. If that's interesting to you, I wrote about it a bit more here: https://notes.crmarsh.com/python-tooling-could-be-much-much-faster https://notes.crmarsh.com/python-tooling-could-be-much-much-.... I'm certainly not here to say that the existing tools are bad or you shouldn't use them or that you should use ruff instead. I use those tools myself -- a lot! With regards to code organization: oh well, this doesn't bother me given the state of the project. The code will evolve as the project grows in scope, I didn't see a need to over-abstract. I'd written a small amount of Rust prior to ruff, but much of it was a learning experience for me. (Funnily enough: not that I want ruff to be organized as such, but pyflakes, pycodestyle, and autoflake are also effectively single-file projects :))

charliermarsh 4y ago

Thanks, it's a fair comment :) I've tried to be honest about ruff's limitations: it supports only a small set of rules, it's not extensible in any way, it's missing edge-case handling, it's significantly under-tested compared to existing tools, etc. I don't consider it production-ready -- it's a proof-of-concept. (I _did_ try to build conviction that there weren't inherent reasons for ruff to slow down significantly as the set of checks extended, but I could definitely be proven wrong as the project grows...) My goal with ruff was partly to build a fast linter, but that was really in service of testing a broader hypothesis I have about Python developer tools could evolve. If that's interesting to you, I wrote about it a bit more here: https://notes.crmarsh.com/python-tooling-could-be-much-much-faster https://notes.crmarsh.com/python-tooling-could-be-much-much-.... I'm certainly not here to say that the existing tools are bad or you shouldn't use them or that you should use ruff instead. I use those tools myself -- a lot! With regards to code organization: oh well, this doesn't bother me given the state of the project. The code will evolve as the project grows in scope, I didn't see a need to over-abstract. I'd written a small amount of Rust prior to ruff, but much of it was a learning experience for me. (Funnily enough: not that I want ruff to be organized as such, but pyflakes, pycodestyle, and autoflake are also effectively single-file projects :))