This makes sense in the abstract - in practice, what compiler-specific features or biases do you think might not be suited for any given general-purpose language?
Compilers are biased, among other things, towards:
- Having a rich, complicated internal model (and having minimal contact with external data; mostly just the code being ingested)
- Recursion
- Being stateless (at the top level anyway; code goes in code comes out)
- Having an enormous amount of semi-regular code (favoring macros and related features)
- Dispatch/polymorphism among very broad type groups (favoring enums and ways of discriminating enums)
Not that any of these things are bad to support in any given language, but every language is a big bag of trade-offs, and focusing on compilers might cause you to choose certain tradeoffs that aren’t as relevant to the way the language will typically be used later on
No specific judgements on Rust (in fact, Rust has ended up seeing a lot of use for compilers and compiler-adjacent projects), just something I’ve been thinking about in general
The most common criticism in practice tends to be a strong aversion to mutability. Compilers can be thought of as a series of pure functions transforming a large immutable data structure, and given the practical issues of mutability (reasoning about it is legitimately hard), this can give a lot of languages a strong aversion to mutability. However, there are some domains where you can't transform the problem space into consume-and-produce-immutable data structures and expect anything close to performant--databases are a good example here.
