Big-name crates that do IO often use async by default, but I haven't seen one so far that doesn't provide a sync/blocking api as well. Usually this is done by enabling a feature for the crate.
Having a standard is overrated. What you usually want is clearly defined behavior and a good backwards compat story.
Standards only make sense to me in the presence of multiple compilers or formal verification. There is ongoing work on supporting the second use case. I don't understand why people want multiple compilers.
> Maybe there needs to be a tiny (incomplete?) rust compiler. Or maybe there should be an interpreter.
In which case the issue is "Rust doesn't have a small compiler" or "Rust doesn't have an interpreter". Having multiple compilers won't necessarily mean that those issues are resolved. A more generic argument would be something like "the existing compiler doesn't cover my use cases".
That's the way it's resolved in languages with a standard, multiple compilers and no preference towards any of the compilers. This doesn't mean it has to be done this way in Rust.
It seems like Rust is leaning towards doing that like it's done in python. One reference implementation, a language reference and a bunch of design documents (PEP, RFC). There are some areas where the language reference is lacking right now but that can be, and is being, fixed over time.
Those qualifications are going to hold for any advice about technology.
You can even justify using malbolge for your hobby project with "I like it" or "It's just for fun".
If your company is only going to pay you for producing malbolge code, then you write malbolge or quit. If you decide to stay, then trying to change their mind might be a good idea if you can spare the effort.
