News for hackers. Stuff that matters.
Re:What Challenges and Trade-Offs Do Optimising Compilers Face? by steveklabnik on Thursday June 22, 2017 @01:43PM (#14613944)
This is true in many cases, but there's subtleties.

Rust was designed to be optimized; this means unoptimized Rust code can easily be 2x-100x slower than optimized code. Given that speed is one of Rust's goals, yeah, you could implement a Rust compiler with no optimization, and that's fine. But it won't be usable to a significant chunk of users who rely on the speed.

Another way this can affect language design: Rust supports enums, which are a sum type. The memory layout of the enum is undefined at the language level. This is specifically so that compilers can do optimizations to make layout more compact than a naive implementation. In some sense, this is leaking optimization concerns out into language design.

Re:What Challenges and Trade-Offs Do Optimising Compilers Face? by mhh__ on Thursday June 22, 2017 @02:24PM (#14614237)
I was imagining direct language ties to (say) LLVM passes, and things like that.

Designing the language around optimizability is a good thing, e.g. C++'s "as if" rule (in [intro.execution] in standards after C++11 (or near there)). Some of these options, which may or may not be used for optimization, can also be very useful for code quality/correctness: e.g. Language enforced purity (of functions) (in D) can be very useful for optimization (It's inferred in most compilers, but it can at least save a trip) and being able to trust (even a D function pointer) to be pure.

Re:What Challenges and Trade-Offs Do Optimising Compilers Face? by pcvarmint on Wednesday June 28, 2017 @03:51AM (#14652405)
Fortran is better in this regard.