19 ms·

> Linter taking multiple seconds is not a problem which occurs in any other popular language. It doesn't happen in Python either. So that's good. > barely e

> Linter taking multiple seconds is not a problem which occurs in any other popular language. It doesn't happen in Python either. So that's good. > barely ever needing to touch the terminal Not really a good sign, point-click developers are not usually the strongest. That said I like things to work easily and don't have many quarrels with Python. Certainly fewer than most other languages. Sounds like you're not very familiar with it and got used to C#. I don't have a problem with anything you list.

throwaway2137 4y ago
> Not really a good sign, point-click developers are not usually the strongest. In principle I agree, but my point is - it was possible to be fully productive being just a point-click developer. > It doesn't happen in Python either. So that's good. pyright + black + isort hook in the project I'm working on takes 1-5 seconds on an M1 mac on save. We're moving to ruff for this reason. Never saw this anywhere else. > I don't have a problem with anything you list. To give better examples: - poetry takes ~900 seconds to resolve dependencies during update/lock - I had to use multiprocessing where in any other language I would use threads because GIL, inter-process communication is needlessly complex - I can't dot+tab+enter autocomplete while using boto or many other libraries - due to weak typing discoverability suffers and I need to have documentation always open in another window to do anything. This is not a problem in strongly typed languages. - wsgi - concept of running separate interpreters for each incoming request is a bit wasteful - I never had any problem with broken / incompatibile environment like I had on python. I just install recent version of .net / rust / node (to a lesser extent) and things generally tend to work. Here I have to worry about specific subversions and conflicts in PATH with another envs and OS-packaged python. Avoidable, but noobs are certain to hit this at some point. - I didn't talk about general speed as it's beating a dead horse, but Python basically nullifies the last 20 years of hardware improvements > Sounds like you're not very familiar with it and got used to C#. I also used Rust and Go and was super happy with the experience for similar reasons.
- mixmastamyk 4y ago
  I mentioned elsewhere but might as well here again. These tools should only be run on the files that changed, not every single one in the repo. I run my tools with the script equivalent of: git status | grep \.py | tools And it should exit in a split second. We have a pretty large codebase, though not gigantic.
  - brenns10 4y ago
    You might be interested in pre-commit which does exactly that! https://pre-commit.com/ https://pre-commit.com/ It probably will also support Ruff if it doesn't already.
    - mixmastamyk 4y ago
      Yup, I know it, thanks. Think of the above as pseudo code. Still, I want some things to run more often than commit, such as pyflakes.
  - globular-toast 4y ago
    People seem to forget the three ways to make things faster in computers: 1. Micro-optimisation, 2. Better algorithms, 3. Change the problem. The potential impact of each of these increases as you go down. Choosing Rust over Python is micro-optimisation. All things being equal, the impact isn't going to be that great. People are like "let me squeeze out every ounce of power from my CPU so I can run a linter on the entire codebase every time I save". Python folk are like "why on earth would you do that?" We simply changed the problem.

throwaway2137 4y ago

> Not really a good sign, point-click developers are not usually the strongest. In principle I agree, but my point is - it was possible to be fully productive being just a point-click developer. > It doesn't happen in Python either. So that's good. pyright + black + isort hook in the project I'm working on takes 1-5 seconds on an M1 mac on save. We're moving to ruff for this reason. Never saw this anywhere else. > I don't have a problem with anything you list. To give better examples: - poetry takes ~900 seconds to resolve dependencies during update/lock - I had to use multiprocessing where in any other language I would use threads because GIL, inter-process communication is needlessly complex - I can't dot+tab+enter autocomplete while using boto or many other libraries - due to weak typing discoverability suffers and I need to have documentation always open in another window to do anything. This is not a problem in strongly typed languages. - wsgi - concept of running separate interpreters for each incoming request is a bit wasteful - I never had any problem with broken / incompatibile environment like I had on python. I just install recent version of .net / rust / node (to a lesser extent) and things generally tend to work. Here I have to worry about specific subversions and conflicts in PATH with another envs and OS-packaged python. Avoidable, but noobs are certain to hit this at some point. - I didn't talk about general speed as it's beating a dead horse, but Python basically nullifies the last 20 years of hardware improvements > Sounds like you're not very familiar with it and got used to C#. I also used Rust and Go and was super happy with the experience for similar reasons.

mixmastamyk 4y ago
I mentioned elsewhere but might as well here again. These tools should only be run on the files that changed, not every single one in the repo. I run my tools with the script equivalent of: git status | grep \.py | tools And it should exit in a split second. We have a pretty large codebase, though not gigantic.
- brenns10 4y ago
  You might be interested in pre-commit which does exactly that! https://pre-commit.com/ https://pre-commit.com/ It probably will also support Ruff if it doesn't already.
  - mixmastamyk 4y ago
    Yup, I know it, thanks. Think of the above as pseudo code. Still, I want some things to run more often than commit, such as pyflakes.
- globular-toast 4y ago
  People seem to forget the three ways to make things faster in computers: 1. Micro-optimisation, 2. Better algorithms, 3. Change the problem. The potential impact of each of these increases as you go down. Choosing Rust over Python is micro-optimisation. All things being equal, the impact isn't going to be that great. People are like "let me squeeze out every ounce of power from my CPU so I can run a linter on the entire codebase every time I save". Python folk are like "why on earth would you do that?" We simply changed the problem.