The ribbon that was introduced around... 2007, I think? Or is there a substantially different one now?

Eh, he also said "While not my favourite language it's definitively one of the best new ones and I encourage people to use it for new projects where it fits."

Huh. I had forgotten that git does actually create a file with the branch name. But it doesn't actually screw up the .git folder or lose your data when you try to do a rename like this; it just rejects the rename unless you also use the "force" option. This has been the case since at least January of 2020. But apparently it actually doesn't always use a local file for branch names, so sometimes there's a problem and sometimes there isn't, which I guess is arguably worse than just having consistently-surprising behavior.

There is indeed a caveat in the introduction to the Reference that there may be statements in it that are specific to rustc. However, the authors strive to keep statements about the implementation separate from statements about the language.

The main reason there's not yet an "official" spec is that creating one takes enormous time and money, which are always limited resources. (Note that both C and C++ had no formal standard for over a decade after their initial release.) The Reference is "good enough" to make a formal spec not strictly necessary, and the existence of Ferrocene makes it even less necessary, since anyone who absolutely needs a spec can use Ferrocene.

Creation is easy, assuming the many-worlds interpretation of quantum mechanics!

Or Stockholm Syndrome

Every technology that gets used frequently enough facilitates maladaptation to its faults. 😑

The thing about Rust's type inference that seems wild to anyone who hasn't seen Hindley-Milner/ML style type systems before is that it's "bidirectional" (in quotes because that's not a proper type theory term as far as I know). The type of the left-side of an assignment can determine the type (and behavior!) of the right side. For instance, this is ambiguous:

let foo = [("a", 1), ("b", 2)].into_iter().collect();

The expression creates an iterator over the (letter, number) pairs, and collect() stores the elements in a newly created container. But which container type? Here are two valid variants:

let foo: Vec<_> = [("a", 1), ("b", 2)].into_iter().collect();

This creates a vector with items ("a", 1) and ("b", 2).

let foo: HashMap<_, _> = [("a", 1), ("b", 2)].into_iter().collect();

This creates a mapping where "a" and "b" are keys, and 1 and 2 are the corresponding values.

Playground link in case you'd like to mess with this concept: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=76f999f4db600415643b0c58c19c69b7

That's not a download button for the program. But there is indeed a link to the release page right on the home page of the project, so you're still correct.

Critical hit! It worked on the first try and you fixed some tech debt!

Who benefits from C being suppressed and attempts being made to replace him? I think there is only one answer - companies. Not developers.

You've missed the group that is most affected by software quality: end-users. Almost everyone in the world relies on computers in some way now, and bugs, especially security vulnerabilities, affect people who have no say in what languages people use to develop software.

But you as a programmer are (and must be) responsible for the code you write, not a language. And the one way not to do bugs - not doing them.

Sounds good. How do I, the end-user of software, hold developers accountable for bugs? I guess I can switch from one buggy operating system to another, or from one buggy browser to another.

But also, do you honestly think that the choice of language does not impact software quality at all? Surely if you were forced to write software in a raw assembly, you'd find it more difficult to write a large and complex system correctly; right? But assembly is just another language; what makes C easier to use correctly? And if C is easier to write correctly than assembly, why would it be surprising that there are languages that are even easier to write correctly, especially after five decades of development in the extremely young field of computer science? Tools are important; your programming language (and compiler) is your first, most important, and most impactful tool as a developer.

[C] remains the fastest among high-level languages.

How are you determining that? C, C++, Rust, Fortran, Ada, and D all compile down to machine code, with no garbage collector (D's is optional). So there's not really any theoretical reason why they shouldn't all perform roughly the same. And, in fact, this is largely supported by evidence:

• There's a fair amount of competition among grep type tools. grep itself is written in C and heavily optimized. I think it's fairly well known by now that ripgrep, written in Rust, is probably the fastest of these tools.
• The TechEmpower web framework benchmarks maintains a ranking of the fastest web frameworks, updated each year. It doesn't look like the current version of the site shows what language each framework is written in, but the top three (may-minihttp, xitca-web, and ntex) are all Rust projects. The fourth (h2o) is in C.
• The Benchmarks Game lets people submit programs in a wide variety of languages to solve a variety of problems, and these submissions are benchmarked and compared. Rust and C are effectively neck-and-neck (note that Rust currently does actually beat C in several of the challenges). See the second graph here for an overall visual comparison among languages.

[Side-note: no one is "suppressing" C. I'm also not convinced anyone thinks C is "useless".]

I'm sympathetic to the desire for an "install and forget" drop-in Vim replacement, but...don't you think that this runs contrary to the purpose of Vim/NeoVim as a flexible, customizable editor? If you're an advanced enough user to have a nontrivial vimrc, then it's entirely possible that you'd also want different configurations for vim vs nvim, and that you'd want to be able to switch between them easily if you discover something doesn't work in nvim (especially since nvim is not yet at version 1.0). It's also probable that a lot of Vim users wish that more classic Unix/POSIX tools followed XDG, rather than requiring rc files in your home directory. As for Bash, not everyone uses it, there's no reliable way to automatically insert content into a bashrc file without potentially screwing things up, and Windows doesn't even have a reliable way to run a Bash script (assuming some version of Bash is even installed).

I do think it would be reasonable for the neovim installer (on all systems) to have an option to create an init.vim file that reads your vimrc, and possibly even to create a shell alias as you describe. But these should definitely be opt-in, not opt-out.