Fucking degenerates.

There is nothing wrong in bullying and humiliating incompetence and arrogant stupidity and impostorism. We all went through all this in our childhood and it did us good – made us think twice.

When some fucking degenerate do shit without proper understanding, just low-effort quick “solution” (the proverbial “getting shit done”) and then almost everyone pick it as a dependency (because it is getting shit done somehow) everyone (as a society) gets properly fucked.

Look here, idiots. Here is the rust-analyzer. It usually comes (being installed) within the toolchain, either via rust-up or from a proper build from the sources, and that is for a reason.

lngnmn2@localhost ~ $ ldd `which rust-analyzer`
	linux-vdso.so.1 (0x00007f43bed2d000)
	librustc_driver-a3dbdc2b2b352eab.so => /usr/lib/rust/1.92.0/bin/../lib/librustc_driver-a3dbdc2b2b352eab.so (0x00007f43b6800000)
	libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/15/libgcc_s.so.1 (0x00007f43becb6000)
	libm.so.6 => /usr/lib64/libm.so.6 (0x00007f43b6708000)
	libc.so.6 => /usr/lib64/libc.so.6 (0x00007f43b6400000)
	libLLVM.so.21.1 => /usr/lib/llvm/21/lib64/libLLVM.so.21.1 (0x00007f43abe00000)
	libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/15/libstdc++.so.6 (0x00007f43aba00000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f43bed2f000)
	libffi.so.8 => /usr/lib64/libffi.so.8 (0x00007f43beca3000)
	libz3.so.4.15 => /usr/lib64/libz3.so.4.15 (0x00007f43a9800000)
	libz.so.1 => /usr/lib64/libz.so.1 (0x00007f43bec84000)
	libzstd.so.1 => /usr/lib64/libzstd.so.1 (0x00007f43a96d8000)

The reason that it uses the the librustc_driver is that it is tightly coupled with the compiler internals, and it must be in sync with the compiler version. This is why rust-analyzer is not distributed as a standalone binary with all dependencies statically linked (unless you are a fucking idiot).

One more time – it uses the compiler as a library. This is not a standalone tool that can be used independently of the compiler version.

Now look at what the fuckers from mason-nvim did: if you are trying to use rust-analyzer from mason-nvim, it will download some random prebuilt binary from the internet. If you are trying to disable that and use your system rust-analyzer, it will still download that random prebuilt binary and use it instead of your system one. If you completely exclude it, it will break the LSP configuration, because it won’t automaically_enable it and prevent the rest of the system to configure the LSP for you.

Why the fuck can’t they just have a variable, like use-system-wide or something like that, which lists the servers to be just used from the $PATH, or, even better, scan /usr/bin:/usr/local/bin:/home/$USER/.local/bin:/home/$USER/cargo/bin for existing binaries, and just use them via full path (fully qualified name ) when found.

And no, there is no adequate solution (allowing it to download and install that shit and then remove and symlink the correct binary until it decides to update).

This is just Rust.

Do you fucking know what haskell-language-server (hls) is? It carries the whole compiler and a half of Hackage as a dependency (yes yes, they are fucking idiots too). The installation is a couple of Gigabytes for each version of the compiler.

In general, it is not the editor’s responsibility to try to manage system packages. It will fuck up for obvious reasons. It shall use the system-wide packages a priority, bacause system packages resolved the complex dependencies in the right way (until they don’t).

Yes, modern neovim is moving away from such a lame bloatware, and a modern bare minimum config works perfectly without mason-lspconfig by just looking what is in the $PATH, which is the right way. BTW, people who “invented” paths way back then were way smarter and better educated that you. Not only the concept of a paths do perfect “shadowing” while uses fully-qualified names to resolve any ambiguity, it also roughly correspond to the notion of a nested frames of environment and the proper lexical scooping rules.

Shadowing of names is a proper way.