5 ms·

If you want the outer language to be cross platform (e.g. x64, ARM64, etc), then you'd either need a parser for every potential platform (even ones you aren't c

If you want the outer language to be cross platform (e.g. x64, ARM64, etc), then you'd either need a parser for every potential platform (even ones you aren't currently using!) OR you just settle for strings. 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.

pjmlp 6y ago
Productivity of language users vs compiler developers.
- alharith 6y ago
  There are infinitely more language users. I'd rather throw a bone to the compiler developers.
  - AnIdiotOnTheNet 6y ago
    Then that means there is infinitely more productivity to be gained catering to the language users.
  - pjmlp 6y ago
    One more reason to actually care about the productivity of language users. They are free to go elsewhere more welcoming.
- Someone1234 6y ago
  Productivity of a niche area. 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.
  - pjmlp 6y ago
    Better not starting talking about niche in regards to Rust, unless adoption of a niche systems language isn't something to care about. Productivity matters everywhere, systems languages that care about happy programmers have better chances of long term adoption.
    - Someone1234 6y ago
      That's a pretty shallow argument, one that can literally be re-used verbatim to argue for any and every feature/philosophy. Particularly when "happy" is as subjective as this. 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."
    - yazaddaruvala 6y ago
      It seems reasonable, but we need to not conflate niche with lacking-popularity (i.e. low usage). 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.
zamalek 6y ago
I really don't like the strings (because Rust is so good at avoiding things like this), but your explanation makes tons of sense. That being said, it wouldn't be hard to create an asm_x86! macro that hides the string.

pjmlp 6y ago

Productivity of language users vs compiler developers.

alharith 6y ago
There are infinitely more language users. I'd rather throw a bone to the compiler developers.
- AnIdiotOnTheNet 6y ago
  Then that means there is infinitely more productivity to be gained catering to the language users.
- pjmlp 6y ago
  One more reason to actually care about the productivity of language users. They are free to go elsewhere more welcoming.
Someone1234 6y ago
Productivity of a niche area. 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.
- pjmlp 6y ago
  Better not starting talking about niche in regards to Rust, unless adoption of a niche systems language isn't something to care about. Productivity matters everywhere, systems languages that care about happy programmers have better chances of long term adoption.
  - Someone1234 6y ago
    That's a pretty shallow argument, one that can literally be re-used verbatim to argue for any and every feature/philosophy. Particularly when "happy" is as subjective as this. 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."
  - yazaddaruvala 6y ago
    It seems reasonable, but we need to not conflate niche with lacking-popularity (i.e. low usage). 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.

zamalek 6y ago

I really don't like the strings (because Rust is so good at avoiding things like this), but your explanation makes tons of sense. That being said, it wouldn't be hard to create an asm_x86! macro that hides the string.