Rust get’s a speed advantage over those languages from three things:
1. Being safer for writing concurrent programs and therefore having programs which are concurrent
2. (mostly) Type safe memory management which means most things are allocated on the stack and those things that are allocated in the heap don’t need to be gc’d (but note that gc doesn’t mean slow memory management but it is harder to have a shared heap in concurrent programs as some synchronisation is needed), and rust programs are typically written in a way that doesn’t allocate much on the heap.
3. Specialisation of generic code to specific data types
1 and 2 are hard for Java and c# as programs are not normally written in ways which would satisfy rust’s checks and so a compiler would just compile these to runtime checks like the c# or Java compilers would use. For number 3. C# already does this.
Note that actually if C# or Java program were translated into a rust program which does the same work then the Rust program would probably be slower because the Java and C# compilers are much better at optimising programs written in the Java/C# style. A fourth advantage rust gets (part of 3 and part of the type system) is a lack of subclassing and vtables which are typically fast at runtime but hard to inline.
One way to make a Java or C# program faster is to be conscious of the hidden work being done and trying to write programs in a way that safety checks can be eliminated and allocation can be made automatic.
> Would it be possible to write a compiler from Java to Rust? C# to rust?
It's possible to write a compiler from any Turing-complete language to any other Turing-complete language
> The goal then would be to get fast(er) execution times.
You'd improve startup times from not having to warm up the JIT, but otherwise it would very unlikely you'd get a noticeable performance improvement. The speed of a language is at least as dependent on its execution model and idioms as its compiler. Not to mention that the JVM already does plenty of optimizations
I'm not sure the statement "It's possible to write a compiler from any Turing-complete language to any other Turing-complete language" is really accurate, other than in a strict cs sense. If you have a language that only allows printing to the screen as output and reading from the keyboard as input then you can't write anything that requires low level hardware access in it.
Thats more a symptom of the environmemt/compiler, but not the language itself. Theres no reason printing to the screen would stop you from printing binary, and feeding that into your processor as normal. Theres also no reason why the language can't have another implementation that does allow more standard outputs.
Language-wise, theres nothing stopping you from parsing java, and producing equivalent semantics. There's nothing stopping you from producing equivalent jvm bytecode.
The interesting part of racket/perl6/this project is that this compilation step is being done without having to parsing "another language", by using macros. Parsing is still done ofc, but it could also be said that you're really just parsing the rust language, which happens to look like java, and producing rust code. The macro system itself is operating as the compiler, and since macros are "rust", then whats the difference?
Rust is a good base for many languages, but in these cases it would probably still imply implementing the JVM/the CLR, rather than "Java" or "C#".
There are probably research experiments that have involved ahead of time compilation, but if they had succeeded then I expect most people would have used them.
1. Being safer for writing concurrent programs and therefore having programs which are concurrent
2. (mostly) Type safe memory management which means most things are allocated on the stack and those things that are allocated in the heap don’t need to be gc’d (but note that gc doesn’t mean slow memory management but it is harder to have a shared heap in concurrent programs as some synchronisation is needed), and rust programs are typically written in a way that doesn’t allocate much on the heap.
3. Specialisation of generic code to specific data types
1 and 2 are hard for Java and c# as programs are not normally written in ways which would satisfy rust’s checks and so a compiler would just compile these to runtime checks like the c# or Java compilers would use. For number 3. C# already does this.
Note that actually if C# or Java program were translated into a rust program which does the same work then the Rust program would probably be slower because the Java and C# compilers are much better at optimising programs written in the Java/C# style. A fourth advantage rust gets (part of 3 and part of the type system) is a lack of subclassing and vtables which are typically fast at runtime but hard to inline.
One way to make a Java or C# program faster is to be conscious of the hidden work being done and trying to write programs in a way that safety checks can be eliminated and allocation can be made automatic.