Why do you think other languages will optimize as well as Rust? Specifically, how do you propose to get the same level of memory alias analysis with unrestricted aliasing and mutation? How do you propose to deal with escape analysis for higher-order functions without a region/lifetime system?
Years of effort put into their compiler optimizers.
For example, without any benchmarks I wonder how Rust current code generation relates to optimizing Ada compilers, specially the commercial ones like Atego.
It is hard to believe a language with an 8 year old compiler already generates better code than a 20 year old compiler battle tested in many production systems, even with the help of LLVM as backend.
Perhaps you're discounting the importance of LLVM and at the same time overestimating performance of some of the languages you mentioned.
.NET: type system has some performance oriented features, but JIT compiler isn't all that great (currently).
Java: java has terrible performance model but JVM does heavy lifting to recover a good amount. However, there are still problems once your perf targets get tighter and tighter (ergonomics also degrade the more you push performance).
I am not overestimating the othe languages, because unlike many HNers I differentiate between languages and implementations.
Just to pick on your example, for Java there is OpenJDK, Oracle's commercial JDK, IBM J9, Excelsior JET, HP-UX JDK and many many other compilers.
The new .NET compiler makes use of the Visual C++ backend, as another example.
Ada compilers have around 20 years history of production code.
Same goes for some of the other languages.
So when one bluntly states that Rust 1.2 compiler already generates faster code than any of the compilers for the other languages, including commercial ones, it is a bit hard to believe.
Of course Rust's compiler will improve code generation.
Language vs implementation is Sufficiently Smart Compiler phrased differently. The main difference between Rust (and say C++) and .NET/Java is the former has a stronger performance model baked into the language which makes it easier to make an implementation fast.
I'm aware of PackedObjects. Note it's not a value type in the sense it doesn't get allocated on the stack (if used as a local), it's a flattened object graph on heap with a shared header.
More to the point, implementations are interesting to compare when they're for the same language, but not so much across languages as languages have different semantics and features that dictate how amenable they are to optimization with today's compilation techniques.
Maybe I didn't make myself clear. If you want to compare speed cross lang, take fastest impl of each and compare that; so long as we're talking about real compilers existing today.
Also, fundamentally C# and java aren't designed on zero-cost abstractions as core principle, which is fine in and of itself. Implementations try to recover performance but it's an uphill battle as compilers will always be limited by various constraints.
> Maybe I didn't make myself clear. If you want to compare speed cross lang, take fastest impl of each and compare that; so long as we're talking about real compilers existing today.
I agree.
> Also, fundamentally C# and java aren't designed on zero-cost abstractions as core principle,....
Sure, but then again Ada, Delphi and D are also on my language list.
True, but having a good motor is not enough for having a good car.
For example, apparently SIMD is only getting done on 1.3.
Again, my whole argument goes against someone stating that Rust 1.2 compiler already generates better code than all the existing compilers for my language list, some of them with 20 years of production code.
It is quite clear to me that Rust compiler will improve and take better advantage of LLVM. I just don't believe that 1.2 is already there.
I think there's no way we're going to know either way in terms of the current state of the art. I do think, however, that Rust has language advantages that will enable better optimization going forward than languages with unrestricted (or less restricted) aliasing and mutation.
