I was surviving with Ubuntu, I had my complaints but I figured 'that's just how it is' on Linux, that it was the same everywhere. I didn't even realise what I was missing until I switched.
I got a hardware upgrade at one point, so in order to get those new drivers ASAP I tried an Arch-based distro, with plans to switch back once drivers became available. I never moved back.
The two big reasons I stayed was ironically enough the lack of good Ubuntu documentation, and the PPA system. Ubuntu is used a lot, but there's not really formal documentation anywhere, only random tutorials online (most likely out of date and never updated) and people on forums talking about their problems. By contrast the Arch wiki is the gold standard of Linux documentation, there's just no comparison. Even on Ubuntu I found myself using it as a reference from time to time.
Regarding PPAs, the official Ubuntu package list is strangely small so if you're like me and find yourself needing other software, even mainstream software like Docker, you'll be faffing about with PPAs. So if you want to install Docker, instead of typing
sudo apt install docker
You instead have to type:
# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
# Add the repository to Apt sources:
echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt-get update
These are the official install instructions, by the way. This is intended behaviour. The end user shouldn't have to deal with all this. This feels right out of the 90's to me.
Instead of PPAs, Arch has the Arch User Repository (AUR). Holy moly is the AUR way nicer to work with. Granted, we're not quite comparing apples to apples here since the AUR (typically) builds packages from source, but bear with me. You install an AUR package manager like yay
(which comes preinstalled on my flavour of Arch, EndeavourOS). yay
can manage both your system and AUR packages. Installing a package (either official or AUR) looks like yay packageNameHere
. That's it. A full system upgrade like sudo apt update; sudo apt upgrade
is a single command: yay -Syu
, a bit cryptic but much shorter. The AUR is fantastic not just for the ease of use, but for sheer breadth of packages. If you find some random project on github there's probably an AUR package for it too. Because it builds from source an AUR package is essentially just a fancy build script based on the project's own build instructions, so they're super easy to make, which means there's a lot of them.
You might argue 'but building from source might fail! Packages are more reliable!', which is somewhat true. Sometimes AUR builds can fail (very rarely in my experience), but so can PPAs. Because PPAs are often made to share one random package they can become out of date easily if their maintainer forgets or simply stops updating it. By contrast AUR packages can be marked out of date by users to notify the maintainer, and/or the maintainer role can be moved to someone else if they go silent. If a PPA goes silent there's nothing you can do. Also, since an AUR package is just a fancy build script you can edit the build script yourself and get it working until the package gets an update, too. PPAs by comparison are just a black box - it's broken until it gets updated.
Moral of the story? Don't be afraid to just give something a go. Mint will always be waiting for you if you don't like it.
Firstly, I'm not sure where you got the impression that Rust is designed to replace C. It's definitely targetted at the C++ crowd.
The string comparison with Rust actually points out one of my problems with C: All those Rust types exist for a reason - they should behave differently. That means that in C these differences are hidden, implicit and up to the programmer to remember. Guess who is responsible for every bug ever? The programmer. Let's go through the list:
&str - a reference to a UTF-8 string on the stack, hence fixed size.
String - a handle to a UTF-8 string on the heap. As a result, it's growable.
&[u8] - a reference to a dynamically sized slice of u8s. They're not even ASCII characters, just u8s.
&[u8;N] - a reference to an array of u8s. Unlike above they have a fixed size.
Vec - a handle to a heap-allocated array of u8s.
&u8 - a reference to a u8. This isn't a string type at all.
OsStr - a compatibility layer for stack-allocated operating system strings. No-one can agree on what these should look like - Windows is special, as usual.
OsString - a compatibility layer for heap-allocated OS strings. Same as above.
Path - a compatibility layer for file paths, on the stack. Again, Windows being the special child demands special treatment.
PathBuf - a heap-allocated version of Path.
CStr - null-terminated stack-allocated string.
CString - null-terminated heap-allocated string.
&'static str - a string stored in the data segment of the executable.
If you really think all of these things ahould be treated the same then I don't know what to tell you. Half of these are compatibility layers that C doesn't even distinguish between, others are for UTF-8 which C also doesn't support, and the others also exist in C, but C's weaker type system can't distinguish between them, leaving it up to the programmer to remember. You know what I would do as a C dev if I had to deal with all these different use cases? I would make a bunch of typedefs, so the compiler could help me with types. Oh, wait...
I dislike C because it plays loosey-goosey with a lot of rules, and not in an opt-in 'void*' kind of way. You have to keep in your head that C is barely more than a user-friendly abstraction over assembly in a lot of cases. 90% of the bugs I see on a day to day basis are integer type mismatches that result in implicit casts that silently screw up logic. I see for loops that don't loop over all the elements they should. I see sentinel values going unchecked. I see absolutely horrible preprocessor macros that have no type safety, often resulting in unexpected behaviour that can take hours or days to track down.
These are all problems that have been solved in other, newer languages. I have nothing personal against C, but we've had 40+ years to come up with great features that not only make the programmer's life easier, but make for more robust programs too. And at this point the list is getting uncomfortably long: We have errors as types, iterators, type-safe macro systems, compile-time code, etc.. C is falling behind, not just in safety, but in terms of ease of use as well.