131–140 of 224 posts
On a small project, personally I use --release sometimes during development because the compile time doesn't matter that much and the resulting executable is much faster: if I don't use --release I can get a misleading sense of UX during development.
Earlier quoted context omitted.
I think the closest thing is enforced rustfmt. I don't hack on the compiler though, so maybe there's some stuff that the team does that they don't broadcast super widely.
I don't mean the code of the Rust compiler, I mean code written in Rust becomes unidiomatic as the idioms change. How fast does that happen, is it a problem, is it being addressed?
It is not a problem. A lot of processing steps go on before the meat of the work gets done; many new idioms end up boiling away entirely as part of this process. Like, the borrow checker doesn't even know about loops; by the time the code gets there, it's all been turned into plain old gotos. The further you get into the compiler, the simpler of a language it gets, and everything is defined in terms of sugar of the next IR down.
Earlier quoted context omitted.
That’s how C++ started out but as far as I know this had lots of limitations in terms of optimization so they started writing native C++ compilers.
I would be surprised if optimization was the actual goal. C++ is not faster than C.
This "C is faster than C++" is a bit dated by now.
Earlier quoted context omitted.
Devil's advocate: more diverse compiler tech will mean a more fragmented community and a larger probability of divergence across implementations. People think the C compiler community is dominated by GCC and Clang, and it is, but there are literally 1000s of implementations out there in the wild. Most are necessary, because we need code generated for some obscure processor architecture that's completely proprietary,…
Llvm is absolutely not the least effort for generating machine code. In many settings, it takes a fraction of the effort of integrating llvm to create a template compiler that goes straight to machine code. In many other cases, your best bet is to have your compiler emit C and then feed that to a C compiler of your choice. It’s good to have divergence. Competition is good. Otherwise people stop trying new things.
There wouldn't be any surprises, or cognitive dissonance, from using very different paths for debug versus release builds? On a small project, personally I use --release sometimes during development because the compile time doesn't matter that much and the resulting executable is much faster: if I don't use --release I can get a misleading sense of UX during development.
Earlier quoted context omitted.
I think the closest thing is enforced rustfmt. I don't hack on the compiler though, so maybe there's some stuff that the team does that they don't broadcast super widely.
I don't mean the code of the Rust compiler, I mean code written in Rust becomes unidiomatic as the idioms change. How fast does that happen, is it a problem, is it being addressed?
https://words.steveklabnik.com/how-often-does-rust-change
https://www.reddit.com/r/rust/comments/fz8mwm/how_often_does...
Earlier quoted context omitted.
I think the closest thing is enforced rustfmt. I don't hack on the compiler though, so maybe there's some stuff that the team does that they don't broadcast super widely.
I don't mean the code of the Rust compiler, I mean code written in Rust becomes unidiomatic as the idioms change. How fast does that happen, is it a problem, is it being addressed?
During my time in rust, the major changes in idiomatic code have been around Results/Errors, async/futures, and a few macros and syntactic sugar goodies have evolved. None of these evolutions were problematic to migrate to, and all of them were moving in the right direction, IMO.
One cool advantage of having multiple compilers for a language is that you can use one as a check on the other. For example, if you're worried that one of the compilers might be malicious, you can use the other compiler to check on it: https://dwheeler.com/trusting-trust Even if you're not worried about malicious compilers, you can generate code, compiled it against multiple compilers, and sending inputs and see when…
> For example, if you're worried that one of the compilers might be malicious, you can use the other compiler to check on it: https://dwheeler.com/trusting-trust This still requires the use of a use of trusted compiler though. Comparing two compilers arbitrarily shows if there is consensus , it does not give guarantees about correctness . From the link. In the DDC technique, source code is compiled twice: once with a…
As discussed in detail in that dissertation, if you are using diverse double compiling to look for malicious compilers, the trusted compiler does not have to be perfect or even non-malicious. The trusted compiler could be malicious itself. The only thing you're trusting is that the trusted compiler does not have the same triggers or payloads as the compiler it is testing. The diverse double compiling check merely determines whether or not the source code matches the executable given certain assumptions. The compiler could still be malicious, but at that point the maliciousness would be revealed in its source code, which makes the revelation of any malicious code much, much easier.
You're absolutely right about the general case merely showing consistency, not correctness. I completely agree. But that still is useful. If two compilers agree on something, there is a decent chance that their behavior is correct. If two computers disagree on something, perhaps that is an area where the spec allows disagreement, but if that is not the case then at least one of the compilers is wrong. The check by itself won't tell you whirch one is wrong, but at least it will tell you where to look. In a lot of compiler bugs, having some sample code that causes the problem is the key first step.
Earlier quoted context omitted.
I don't mean the code of the Rust compiler, I mean code written in Rust becomes unidiomatic as the idioms change. How fast does that happen, is it a problem, is it being addressed?
As it happens, Steve can provide some metrics for this: https://words.steveklabnik.com/how-often-does-rust-change https://www.reddit.com/r/rust/comments/fz8mwm/how_often_does...
Earlier quoted context omitted.
Why? Other than to prove it can be done what is the point. If rust was a huge community okay, but face it, they are not. It is better therefore to focus their efforts where they can make a difference. A new x where the existing ones are just fine (this includes well maintained) is a waste of resources. There are many possible good answers to the above question. However I'm not sure they apply, and worse I believe the…
Historically writing a compiler in the language that you’re promoting is a good way to really understand the limitations of your language. I think this works so well because language designers tend to understand compilers better than they understand other software.