I think the point of the question is what a hypothetical ideal language for CI/CD pipelines would look like.

Actually, it's pretty surprising to me that a small university lab is forcing a specific version of a specific OS on you.

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."

The education system (universities, colleges, courses) uses the "modern" development stack.

Hahahahahaha!

Only a very few colleges and courses specializing in a very narrow field, such as embedded devices, can teach you the C language.

snort BWAHAHAHAHA!

the “dying C”

[wheezing]

And by doing this they are trying to hide the C language.

[incredulous snort]

And the community is kind

[wistful sigh] I truly wonder what it would be like not to know anything about Linus Torvalds. I sometimes wish I didn't know about Richard Stallman!

And that it is unlikely that C will be able to replace anything in the near future.

I'm sure you wrote this backwards.

WASM has no native ability to access most web APIs, including the DOM. JavaScript is literally unavoidable on the front end.

What custom implementation? The escaping logic?

Edit: to be clear, there is no "custom implementation" of cmd itself, nor is the problem exclusive to Rust. This is a problem with the Windows cmd itself.

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.

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.

Yes, it's largely for SPAs, but you said "requires killing the web app", and most web apps are SPAs.

...arguably you're better off using Rust anyway, if you have a choice.

"used to"?