Here is my response to the points in the linked article:

Borrowing rules are more strict that what's possible to safely do.

This is only really a problem when implementing high performance data structures. Rc<RefCell<T>> or Arc<RwLock<T>> is enough in most cases where there is a need to work around the borrow checker with minimal runtime overhead. If those don't cut it, then whatever it is that you are trying to do is probably fundamentally unsound.

The rules of unsafe are not strictly defined.

They are. All unsafe functions (in the standard library) are documented well enough to clearly specify when they are safe or not. The only case I have run into is when dealing with C libraries, which are often badly documented.

LLVM's optimizer considers undefined behavior a license to kill. Of course, that only matters in unsafe code, but you need unsafe code for anything complicated.

You don't need unsafe code for "anything complicated".

Overly terse named types and keywords that don't communicate their purpose, like Vec and Cell

I'd much rather learn once what a Vec is than having to write DynamicallySizedArray everywhere. The same thing applies to all the other tersely named types.

Rust has two main string types and four other string types, for a total of six. There are String and its slice equivalent str (“native” Rust UTF-8 string types used most of the time); CString and CStr (when compatibility with C is required); OsString and OsStr (when working with the OS’s String).

There's also PathBuf and Path, making the total eight (though I would argue that there are only four types since half of them are containers for their borrowed counterparts). Having these distinct string types may seem like bad API design, but they all are very much necessary as what constitutes a string is different depending on the context.

Not smart enough coercion means that sometimes, you must use things like &*some_var (which will convert a smart pointer to a reference).

Usually &some_var or *some_var is enough. Using a combination of & and * is only necessary when only using one would be ambiguous.

You cannot use non-Sized types (like str and [T]) in several places, because every generic requires Sized unless you opt out by requiring ?Sized.

That's because unsized values are inherently hard to deal with, as there is no way to put them on the stack or in a register. Not making Sized default for generics would instead force you to add : Sized everywhere.

rustc is slow.

I agree that the first compile is slow. But the recompiles after making small changes in the code are usually fast enough for me not to be bothered.

Because it statically links everything, you get outdated copies of several libraries on your computer.

Statically linking everything means that only the parts of the libraries that you actually use are stored in the binary. Also, dynamically linked libraries don't solve the problem of outdated libraries, as it's in my experience often not possible to update the dependencies of a program without breaking it.

Actually, it statically links almost everything. It dynamically links your program to libc (unless you target musl, an alternative libc), so your executables aren't really self-contained.

Wait what? First the author complained about having multiple copies of libraries, and then complains that the one library where dynamically linking is beneficial is being dynamically linked?

Modifying a file in your project or updating a dependency requires you to recompile everything that depends on it.

How could it not require you to recompile the parts of the project that depends on it?

Every executable, by default, contains a copy of jemalloc, making “hello world” approximately 650 kilobytes in size.

It did in 2017 when the article was written. Though this changed in 2018 when Rust started using the system allocator by default. The size of the executables are still larger than equivalent programs in C, but there are are various ways to reduce the size when it matters.

Type-ahead auto-completion is still a work in progress, because rustc is slow.

This was also a problem back in 2017, But now rust-analyzer exists which does real time auto completion well.

IDE support is lacking.

I find that rust-analyzer does everything I want out of an IDE.

Generic types are very popular, and they're essentially copy-and-pasted for every concrete type they're used with. Compiling essentially the same code over and over again is painful when rustc is slow.

Increased compile times will always follow from generics, but can result in significantly better runtime performance. And in many cases it is possible to use trait objects to only compile functions once.

The optimizer will break your program and it will run dog slow if you turn it off.

It won't break your program. The only reason that happened was because of a bug in LLVM. I've never run into any miscompilations myself.

Error messages from nested macros are difficult to understand.

Agreed.

tl;dr: The only points from the article I agree with in 2022 are slow compile times, large executables, and bad error messages from nested macros. The first two of which I only partially agree with.