I don't think this will be a very big issue for the majority of the cases though. As long as it's configurable and not a (very) controversial change. Especially, since I don't think that feature requests on a programming focused community will be that much controversial...
What I have observed so far: I think the maintainers are relatively open to changes (compared to a few other open source repos).
I just default to recursive descent parsers (with pratt parsing), simple, efficient, great error messages and almighty (CFGs). For quick prototyping I really like to use https://github.com/zesterer/chumsky currently (pratt parsing was just added, need to try that out again).
But writing a parser generator is certainly an interesting academic task.
Hmm yeah it probably helps to be able to program functionally (it's basically lambda calculus with lazy sets and a little bit of syntax sugar). NixOS has a little bit of a steeper learning curve. When understanding Nix itself and having a little bit dived into the the nixpkgs repo you'll quickly get a grip for it (and understand some of the IMHO quirky design decisions).
But then I feel it's only going to get better, as the system can be perfectly configured to your liking and it stays like that across different machines etc. I think the initial investment has paid off for me so far. It's really hackable and you can quickly try ideas without having to fear to break your system. Also something like nix flakes for good reproducible dependency management across different OS is really nice (at least if not much if any GUI is involved, then the different worlds (impure vs pure) sometimes clash together).
You might want to checkout NixOS (or home-manager if you don't want a cold deep dive into a rabbit-hole).
Depends on what you mean exactly with "file format".
If declarative functional programming falls under that, I think something like Nickel, the already mentioned Dhall or Nix. Though Nix more so for packaging and some kind of system management (NixOS?), it's not easily embeddable into a runtime (your app?). Nickel or Dhall is better for that, as they are built from ground up with that in mind, Nickel is maybe the successor of Nix as it is inspired by Dhall and Nix (one goal is to use Nickel as frontend).
The reason why I recommend a simple declarative language, is that they are IMHO much better composable as it lets the user hide boilerplate via functions. I almost always feel limited by static configuration formats like yaml, json etc..
Is this a hard error? Like it doesn't compile at all?
Isn't there something like #[allow(unused)] in Rust you can put over the declaration?
Is it good technically though? Or is it just really popular because it's so well maintained and extensible?
I think the main reason vscode is so popular is, because there aren't really good native alternatives (e.g. I wouldn't compare e.g. vim because it's kind of a different target audience).
So maybe something like zed or so will take the reign of this class of editors, but we'll see, I just hope it's not yet another electron or DOM based editor, DOM is bad enough in the web already...
So cancer + a different form of cancer = ...?
I really don't get why you want an editor to be based on DOM, it feels just like sluggish ... cancer...
When it's ready...
Hmm pretty sure, it's not vim, as that would be u and C-r
Pretty sure, that there's already a github issue on lemmy itself (too lazy currently to search it though)