Don't get me wrong: Parsed assembly is superior because you can have certain parser guarantees/checks. But it will definitely limit the scope of your language or at least slow its adoption to new platforms.
Don't get me wrong: Parsed assembly is superior because you can have certain parser guarantees/checks. But it will definitely limit the scope of your language or at least slow its adoption to new platforms.
That being said, it wouldn't be hard to create an asm_x86! macro that hides the string.
They are free to go elsewhere more welcoming.
But related: There's no reason parsers cannot be externalized and inject the resultant assembly strings into the Rust solution. If that's really what people want. The nice thing about external parsers is that they become optional in every sense.
If the Rust team builds them in, then every supported platform needs support, every development environment needs every parser, and tooling also has to support it (e.g. IDEs, code checkers, etc).
It isn't simply just adding it once and leaving it forever, the work is repeated several times over and the maintenance will be time-consuming for what is: A niche feature.
Productivity matters everywhere, systems languages that care about happy programmers have better chances of long term adoption.
It also ignores the reality that the Rust team's time is finite, and if they invest it into three or more assembly parsers then they aren't investing it into other areas of the language that could also be productivity multipliers. Areas that more programmers actually use.
Ultimately how much is unsafe assembly in Rust going to be used? And how large are those code sections? And are you better off creating Assembly in existing dedicated tooling and importing it, even if Rust had native parsers (e.g. due to better debugging/visualization elsewhere)?
Honestly if Rust code outside of standard libraries ends up with a ton of assembly anyway then that's a weakness of Rust. You should be using as little as possible. Even unsafe Rust is superior to assembly because it is platform agnostic. I'd go as far as to call it a "last resort."
Niche is about the environment, i.e. the problem domain.
Analogy to biology/ecology, grazing on mountain tops is a niche that is also unpopular (i.e. low usage), meanwhile pollination is a niche that is popular.
The problem domain for Rust to be useful is very large, across the programming ecosystem and across the programming ecosystem effort is put into increase accessibility for the less and less experienced (e.g. embedded, wasm, webservers, clis, etc). However, Rust might currently lack popularity (i.e. low usage).
The problem domain for Inline Asm to be useful is very small, typically by experts in narrow domains and across the programming ecosystem effort is put into decrease the need for inline asm (e.g. crypto, firmware, drivers, etc). It also happens to be unpopular, and is avoided as much as possible.
Summary, Rust is pragmatically niche, rather than theoretically niche, Inline Asm is theoretically niche, and also pragmatically niche.