1. Terrible performance.

2. Terrible installation UX.

The number of issues we've had with pre-commit because it's written in Python and Python tooling breaks constantly...

In fairness, the latter point may be finally solved by using `uv` and `uv tool install`. Performance is still a major issue though. Yamllint is easily the slowest linter we use.

(I'm tempted to try rewriting it in Rust with AI.)

▲

turtlebits 10 minutes ago | parent | next [-]

Then remove it? There's always tradeoffs adding tooling - I'm assuming you have it in your workflow to catch downstream issues because it saves more time in the long run.

▲

viraptor 5 hours ago | parent | prev [-]

It definitely is a problem when the tool you're going to use a few times a week takes an extra hundred milliseconds compared to a native solution. Especially when you need to process huge data files like hand crafted makefiles. I can totally feel your pain - extra effort would've been made to avoid that at the cost of development speed. /s

	▲	justinrubek 3 hours ago \| parent \| next [-]
		I find that writing anything substantially complex in python sacrifices the development speed. That isn't its strong suit. It's that a lot of people want to write their code in it by preference.
	▲	IshKebab 3 hours ago \| parent \| prev [-]
		Yeah if only it was an extra 100 milliseconds a few times a week. We have yamllint (also written in Python) in our pre-commit (also written in Python) and it definitely adds a second or two. Also format-on-save is a common workflow.