If you use Arch Linux or one of its derivatives (EndeavourOS, Manjaro, Artix, etc.), sooner or later you'll run into the AUR repositories and the famous yay and paru assistantsEveryone talks about them, they're recommended in forums, they appear in almost every guide, but when you try to decide which one to use, the differences aren't always so clear.
In the following lines we will calmly break down what each one offers, what real opinions the community has, what myths surround it “Yay is dead” or “Paru is much faster”and in what cases it's worth switching from one to the other. The idea is that, by the end, you'll have solid arguments for choosing an assistant without overthinking it.
What are yay and paru and why does everyone use them?
Broadly speaking, both yay and paru are AUR assistants that automate the work of searching for, compiling, and installing packages from the AUR, in addition to managing packages from the official repositories using pacman behind the scenes. That is, instead of manually going to the AUR website, downloading the PKGBUILD, and running makepkg and then install the package; they do all that in one go.
In Arch and derivative environments, it is very common to want to access the A vast catalog of software is available in AURThere you'll find applications that aren't in the official repositories, Git versions, experimental patches, or simply programs that no one has officially packaged; for example, guides for Installing Visual Studio Code on ArchTo manage all of that with some ease, most people end up using an assistant, and that's where yay and paru come in as two of the most popular options.
Yay has been one of the leading names for many years now: It is well-known, documented, and has a huge community. and appears by default in distros like EndeavourOS. Paru, on the other hand, is more recent, but has gained considerable traction because it offers a somewhat stricter and safer approach to the AUR workflow, and because its author was involved in the development of yay in the past.
Technical differences: Go vs Rust, design and philosophy
One point that usually comes up in all the debates is that yay is written in Go and paru is written in RustTechnically, this matters less to the end user than is sometimes suggested, but it does say something about the approach of each project.
Yay, developed in Go, is inspired by old assistants like yaourt, apacman and pacaurIts code is relatively easy to read and extend for anyone proficient in Go, and one of its historical virtues has been precisely that The compilation is quick and painless.That foundation has allowed it to remain alive even after changes in the development team.
Paru, on the other hand, is implemented in Rust and draws directly from yay's experience, both in functionality and command-line interface design. Thanks to this, Migrating from yay to paru is very simpleMany commands and options feel almost the same, so you don't have to relearn everything from scratch.
At a philosophical level, Paru places somewhat more emphasis on security and review of PKGBUILDsWhile yay has historically tended to prioritize a faster and more convenient workflow by default. This difference is clearly seen in how each presents the files before building the packages.
Speed: Is paru really faster than yay?
One of the most repeated arguments in forums and social networks is that paru is “faster” than yayIt's worth clarifying this point. Several users with powerful hardware and a good connection (for example, 1 Gbps fiber) report that, in practice, The sensation of speed between the two is very similarIn systems like this, the bottleneck is often the download or compilation of the software itself, not so much the wizard.
Even so, some have compared both on more modest machines and claim that Paru performs certain operations somewhat fasterThis is especially noticeable when performing searches, synchronizations, or global updates that involve both official repositories and the AUR. The difference isn't usually huge, but on systems with limited resources or slow disks, you might see a few seconds of improvement here and there.
The other side of the coin is that paru forces you to check PKGBUILDs by default before compilingThis adds an interactive step that obviously consumes human time (albeit a little). Some users perceive this as a "slowdown," while others consider it a reasonable compromise because it provides security and transparency.
In short, if you have a modern computer and a good internet connection, The speed differences between yay and paru will be very smallWhere it might really be worthwhile to opt for Paru is in limited systems where every second counts, or if you want an assistant that is optimized down to the last detail and you notice that slight advantage.
Syntax and user experience: what it feels like to type
Beyond benchmarks and technical discussions, many users are left with "yay" for a rather mundane reason: It's very comfortable to writeSome people say they literally "mash both keys at the same time" to type yay because it's short, easy to remember, and autocompletes in the terminal.
Paru isn't exactly a horrible name, but some people say that Their syntax seems a little more "rough" to them when using it daily. It's not that the commands are very different, but habit prevails, and those who have been using yay for years feel that the workflow is more natural and faster, both mentally and when typing.
In any case, both assistants provide shortcuts, interactive options, and very similar flagsFor example, features like displaying a combined menu of repository and AUR updates with version details are available in both. In yay, there is an option --combinedupgradewhich displays a color-coded list of what will be updated and from which version to which. In Paru, something comparable is achieved through the option --upgrademenu, which offers a detailed menu of updates.
One curious detail that appears in some threads is that Some users even create aliases like yaya yaybecause they find it even more convenient and fun to summon it that way. This clearly illustrates the extent to which ergonomics and habit play a very real role when choosing an assistant.
Where does each compiled package store?
Another interesting aspect that often goes unnoticed is the management of the pre-built packages (the .pkg.tar.zst files)Here, yay and paru behave slightly differently, and that affects how they integrate with typical Arch paths.
Default, makepkg places the built packages in the build directoryThat route can be adjusted using the variable PKGDEST en /etc/makepkg.confSo you could, for example, send them to /var/cache/pacman/pkg/ to centralize the packaged binaries.
In the case of paru, it respects the usual behavior of makepkg: The packages end up in the compilation directory associated with paru, usually something like ~/.cache/paru/clone/$pkgname/If you want to modify that path globally, you can use the option BuildDir en /etc/paru.confforwarding the compilations to another site.
Yay behaves somewhat differently. Several users point out that yay copy the built packages to /var/cache/pacman/pkg/ After compiling them, this effectively puts your AUR packages in the same place as the official packages managed by pacman. This is convenient, but it means that, in a way, "yay is..." stepping on what you have defined in PKGDEST en /etc/makepkg.conf, something that some consider disrespectful to the overall configuration of the system.
For the average user this is usually not a big deal, but if you're very particular about how binaries are organized on your machine, This could be a reason to prefer the "cleaner" behavior of paruor at least to be aware of what each assistant is doing with your packages.
Maintenance level and activity of each project
In various debates, the idea has spread that yay is abandoned or outdated and paru is its natural replacementThis statement stems in part from the fact that one of the developers associated with yay moved on to focus on paru, and in some videos and posts this was interpreted as the yay project dying or being left unmaintained.
Several users and developers have categorically refuted that narrative: Yay, it still has active maintenance.With frequent commits to its repository and a fairly large community behind it. In fact, part of the frustration of some maintainers stems precisely from seeing the mantra "yay it's dead" repeated over and over without people bothering to check the project's actual state.
At the same time, it is true that Paru shows very high and constant activity.Sometimes even slightly higher than yay's at certain times. This is logical, since it's a relatively new project, eager to iterate and refine details, and with a very involved author who responds quickly to issues and requests from the community.
In practice, for the person who simply wants to install packages, these differences in activity rarely translate into problems. Both projects are alive, receiving bug fixes and new featuresAnd there's nothing forcing you to abandon yay for fear of it breaking in the short term.
Security, PKGBUILD review and AUR usage philosophy
One key point where clear differences in approach are perceived is how each attendee approaches the PKGBUILDs reviewRemember that AUR is not an official repository: these are recipes submitted by users, and the final responsibility for reviewing them is yours.
The Arch community has always insisted that You need to read the PKGBUILDs before installing themTo avoid unpleasant surprises (malicious scripts, downloads from untrusted sources, dangerous commands, etc.), Paru, aligned with this philosophy, is configured by default to show you this review and "force" you to pay attention to it before building the package.
Yay, although it also allows you to check PKGBUILDs, facilitates a "faster and more carefree" flow If you want a straightforward solution. This is very appealing to those who prioritize convenience and trust the AUR maintainers, but it has also created the perception that "yay" encourages a bit more "install without looking," something that doesn't quite fit with Arch's purist mentality.
In any case, it's important to remember that, whichever assistant you use, Everything ends up going through Makepack and PacmanIn other words, both help automate the heavy lifting, but the basic model remains the same: PKGBUILDs that become packages that pacman manages and installs. The responsibility for understanding what you're installing remains yours.
Using the AUR without assistants and the role of Pac-Man
A recurring question also appears in several threads: "How do you update AUR packages without using a wizard?"The orthodox answer, which aligns directly with Arch's official philosophy, is clear: using makepkg by hand with the corresponding PKGBUILDs.
PKGBUILDs are recipes that define How to build the package from source code or from precompiled binariesOnce that package is generated, pacman handles the installation and logging, just as it does with packages from the official repositories. There's no special treatment for being an "AUR": for pacman, once packaged, it's simply another package.
Assistants like yay and paru are nothing more than layers of comfort on top of that classic flow of “download PKGBUILD → makepkg → pacman”They perform searches, resolve dependencies, automate downloads and compilations, and add useful menus and options, but they do not replace or modify pacman's role as the central system manager.
That's why some veteran users boast about never using assistants and defend the manual method as the most transparent and controllable. Others, the majority, prefer to save time and rely on manual tools, trusting that automation simplifies their lives without completely losing sight of what they're doing.
Paru and yay in derivative distros: EndeavorOS, Manjaro, Artix…
In distros like EndeavourOS, yay usually comes pre-installed or recommended as the main assistantThis significantly impacts the experience of newcomers, who adopt yay without much thought because that's what the system and official documentation provide. Later, they may discover paru and consider whether the change is worthwhile.
In some discussions within the EndeavourOS community itself, the following has been raised They should start including Paru by default.Many users and team members have responded that they don't see a real need to do so, as yay remains a solid, well-maintained, and well-known tool. Consequently, in the short and medium term, it doesn't appear that there will be a mass replacement of yay with paru in this distro.
In other Arch derivatives (Artix, Manjaro, etc.), the situation is similar: The important thing is to have access to the AUR and the ability to use an assistantBut which one you end up using usually depends on what the documentation recommends, what the community says, or simply what you tried first and it worked well for you.
It is also common to suggest activating external repositories such as Chaotic-AUR To facilitate the installation of these assistants without having to compile from the AUR itself, some tutorials explain how to prepare the system, add these repositories, and then install yay or paru directly as binary packages, avoiding the initial manual build step.
Install and live with both assistants
One option favored by many users, especially those who are testing things out, is install both yay and paru and live with both for a while. This way you can use yay for what you already do routinely and experiment with paru for specific tasks, comparing the feel and features on your own hardware.
Since these tools rely on pacman and makepkg, They don't step on each other's toes or break the system by coexistingYou can install packages with one, list updates with another, and keep working without major issues, as long as you know what you're doing. Once you're clear on your preferences, if you want to simplify things, you can keep only the one you like best and uninstall the other.
In some specific cases, it is recommended to install paru using yay (since yay comes pre-installed on the distro), try it out, and if you like it, switch your scripts, aliases, and habits to paru and then do without yay. But, to reiterate, There is no technical obligation to make this changeIt's more a matter of taste and philosophy.
On the other hand, there are those who prefer to always follow the "vanilla" method: Install the assistants from the AUR itself using makepkgTo maintain consistency with the pure and simple Arch philosophy. In either case, the end result is the same: you have a functional assistant that simplifies the use of the AUR.
Looking at all these nuances together, what is clear is that Both assistants cover the needs of the average Arch user very well.Paru automates AUR interactions, keeps the system up-to-date, and offers certain conveniences that Pacman, by design, doesn't provide. Paru focuses more on revisions and slightly more refined performance, while Yay offers an extremely familiar, fast-paced typing experience with years of proven reliability, which explains why so many people remain loyal to it despite the arrival of newer alternatives.
