> idk why Arch doesn't invest in whats standard in every other major distro
Simplicity, among other reasons. Installers force the users hand and need maintenance. Having no installer but rather a detailed installation guide offers unlimited freedom to users. Installation isn't difficult either, you just pacstrap a root filesystem and configure the bootloader, mounts and locale.
ArchLinux does now have an installer called archinstall, but it's described more as a library than a tool. It allows you to automate the installation using profiles.
Just to paint an example, if I am installing Arch I like to have:
* A user configured through systemd-homed with luks encryption
* The limine bootloader
* snapperd from OpenSUSE with pacman hooks
* systemd-networkd and systemd-resolved
* sway with my custom ruby based bar
* A root filesystem in a btrfs subvolume, often shared across multiple disks in raid0
If you were to follow the installation guide it will tell you to consider these networking/bootloader/encryption options just fine. But trying to create an installer which supports all these bleeding edge features is futile.
Also if you want 'Arch with sensible defaults' CachyOS is basically that, people think of it as a 'gaming distro' but that's not an accurate characterisation. I use it as a daily driver on my personal machine mostly for non-gaming work and it's an excellent distro.
There is though the TUI installer, not like it used to be where the commands were typed in following the wiki. Not that there was anything wrong with the 'manual' mode, it gave you insight into the basic building blocks/configurations right from the start.
It's been a very long time since I moved to Arch, but I swear that something like 12 years ago it did have some form of menu-driven installer.
Nowadays, there are so many ways to partition the drive (lvm, luks, either one on top of the other; zfs with native encryption or through dm-crypt), having the efi boot directly a unified kernel image or fiddle with some bootloader (among a plethora of options)...
One of the principal reasons why I love Arch is being able to have a say in some of these base matters, and would hate to have to fight the installer to attain my goals. I remember when Ubuntu supported root on zfs but the installer didn't it was rather involved to get the install going. All it takes with Arch is to spend a few minutes reading the wiki and you're off to the races. The actual installation part is trivial.
But then again, if you have no idea what you want to do, staring at the freshly-booted install disk prompt can be daunting. Bonus points for it requiring internet for installation. I would have to look up the correct incantation to get the wifi connected on a newer PC with no wired ethernet, and I've been using the thing for a very long time.
That's assuming you do system upgrades through paru/yay. However, you may not want to upgrade the packages you've obtained from the AUR and so you upgrade using pacman. That may cause the updated libalpm to become incompatible with the installed yay/paru.
Iirc it was to force the extra step necessary for the user to acknowledge that the AUR can bootstrap malware if used blindly.
This seems to be a relatively consistent discussion surrounding AUR helper development; for example, adding UX to incentivise users to read PKGBUILDs, lest the AUR becomes an attractive vector for skids.
No one wants the AUR to become NPM, and the thing that will incentivise that is uneducated users. Having the small barrier of not having helpers in the main repos is an effective way of accomplishing that.
The problem I see with low-type[1] is that it lacks static analysis to evaulate type usage before runtime and, I don't think, it has any support for tooling so you can't get method usage information in the editor.
I think that static analysis could be done with an extension to rubocop via Prism though. Same for documention features via Ruby-LSP tooling.
I think if they worked on those they would very quickly pick up support as the syntax is quite nice.
Until then I think that Sorbet, possibly using RBS-Inline, is probably the best solution. I'd give a notable second to YARD annotations and Solargraph. Solargraph is a much underated project IMHO.
Simplicity, among other reasons. Installers force the users hand and need maintenance. Having no installer but rather a detailed installation guide offers unlimited freedom to users. Installation isn't difficult either, you just pacstrap a root filesystem and configure the bootloader, mounts and locale.
ArchLinux does now have an installer called archinstall, but it's described more as a library than a tool. It allows you to automate the installation using profiles.