I have not looked at the source for 80-90% of the python packages I’ve used. if a tool is well-maintained, I don’t care about its language if implementation. while I agree with the caveats you suddenly introduced in your last sentence, none of them apply to any of the tools you initially mentioned (uv, ruff, pyright) so I think you’re actually arguing two different things and don’t want to be convinced otherwise.

I think there’s two perspectives here: one as a potential contributor, and one as a “simple” user.

as a potential contributor, sure, the language of the tool matters. something breaks and you go investigate the source files to figure out why and maybe open a PR. In that case, a different tech stack is no good - you’ll have to learn a totally new language!

however as just an end user, I see no problem with something being written in whatever language. regardless of the implementation, all I do is open GitHub and file a new issue (if that). I don’t care about whatever stack is being used, I never even look at it.

so it depends on your approach to your own usage pattern. aside from those options, I would expect any sufficiently well-designed tool to not require me to understand language of implementation to know why some particular invocation didn’t work. and of course in the ideal world, if you use it and it works perfectly, then the question is immaterial anyway.

just to add to the other answers - no need to have them in your home dir (that sounds like it would suck). use a tool like uv tool or pipx , or just manually create any venv you need under a path you choose, say $HOME/.cache/venvs/

uv actually does have a reimplementation of pipx, via uv tool or uvx: https://docs.astral.sh/uv/concepts/tools/#tools

the concept in the OP is different; it’s an implementation of pep722 https://peps.python.org/pep-0722/

It definitely would be. Next time someone posts a kernel written in Perl I hope they specify that.

might switch from alacritty to kitty almost just for this (although I’ve been meaning to for a while). the “immediately get scroll back into an nvim buffer to edit as a command” is pretty sweet

another way to start is to only do small configurations at first. as you code maybe you realize you want a tool that shows git diffs, install a plug-in that does that. over time, you gradually build your config. maybe you want to start using leader for custom key maps. a couple days later maybe you think you want a file picker so you add telescope. this 100% will take longer, but you’ll intimately understand why every line in your config is there.

neat write up, I’ve also run into some of the errors that ruff throws (eg don’t use f strings in logging) but didn’t really know why.

thought it was cool the author said feel free to implement in ruff in the foot notes

Great article. there was a even a response a year later https://medium.com/front-end-weekly/how-it-feels-to-learn-javascript-in-2017-a934b801fbe

without more information, the most straightforward way is to disable your plugins one at a time and test if things are working (could go the other direction: start from no plugins, and install them one at a time). do this by commenting/uncommenting lines in your config and rerunning sync/clean/install or whatever with your plugin manager.

ideally youd have some idea about what specifically is breaking for you. since you say completion maybe start with whatever you use for that (cmp, mason setup, coc, deoplete, ycm)?

edit: forgot to say, but if you post your config that could be helpful in case there’s an obvious err somewhere. is it all macros that fail or only some with specific motions?

this was the first lua plugin I migrated to back when lua support was merged! efficiency difference was noticable, great plugin.

there can also ne inertia for existing projects though. for example it can be tough to get more research-y work (eg grad students) to switch over from r/python/Matlab for data processing in favor of c/rust