7 ms·

Why not Python? I primarily program in C++ but I see it as a decent choice as Python is available in almost all recent machines. Of course Windows is a notabl

Why not Python? I primarily program in C++ but I see it as a decent choice as Python is available in almost all recent machines. Of course Windows is a notable exception but given it's a tool for developers I guess Python should be present.

IshKebab 1y ago
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.)
- viraptor 1y ago
  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 1y ago
    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 1y ago
    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.
- turtlebits 1y ago
  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.
- mcswell 1y ago
  > 1. Terrible performance Performance only matters if you're doing something compute- or disk-intensive, and then only if the libraries you're using are Python all the way down. (AI programming, at least the kind that most of us do--I don't know about places like OpenAI) is generally done with Python using libraries that use some compiled language under the hood. And in this case--a linter--performance is almost certainly never an issue.
  - IshKebab 1y ago
    The only thing computers do is compute and disk. Performance only matters if you care about performance, and I do care about performance. If you don't, fine I guess.
    - mcswell 1y ago
      What do you care if a program takes one second or half a second, or even 1/10 of a second?
smusamashah 1y ago
Terrible portability across platforms specially with dependencies.
kiitos 1y ago
`pip install ...` is not a reliable or appropriate mechanism for distribution of any kind of tool like this one. Table stakes is pre-compiled architecture-specific binaries.

IshKebab 1y ago

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.)

viraptor 1y ago
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 1y ago
  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 1y ago
  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.
turtlebits 1y ago
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.
mcswell 1y ago
> 1. Terrible performance Performance only matters if you're doing something compute- or disk-intensive, and then only if the libraries you're using are Python all the way down. (AI programming, at least the kind that most of us do--I don't know about places like OpenAI) is generally done with Python using libraries that use some compiled language under the hood. And in this case--a linter--performance is almost certainly never an issue.
- IshKebab 1y ago
  The only thing computers do is compute and disk. Performance only matters if you care about performance, and I do care about performance. If you don't, fine I guess.
  - mcswell 1y ago
    What do you care if a program takes one second or half a second, or even 1/10 of a second?

smusamashah 1y ago

Terrible portability across platforms specially with dependencies.

kiitos 1y ago

`pip install ...` is not a reliable or appropriate mechanism for distribution of any kind of tool like this one. Table stakes is pre-compiled architecture-specific binaries.