Re:Reducing Rust Incremental Compilation Times on macOS
by mlindner on Sunday April 18, 2021 @10:07AM
(#26852595)
Except you can't build a lot of those same abstractions in C, at least not in a way that doesn't involve throwing void pointers everywhere. Also the compiler has no idea what it's looking at so it can't optimize it as well because of pointer aliasing rules. So no, you can't build the same abstractions in C as cheaply as you can in Rust.
Re:Reducing Rust Incremental Compilation Times on macOS
by flohofwoe on Sunday April 18, 2021 @10:15AM
(#26852656)
That assumes that "abstractions" are a good thing in the first place though. I haven't seen much evidence for this assumption in real world code so far (in the context of "understanding what this piece of code actually does"). I've mainly been exposed to C++ code though (where "over-abstraction" is quite common), but I also haven't seen much Rust code so far that I would consider particularly "straightforward" and/or "readable". YMMV of course.
Re:Reducing Rust Incremental Compilation Times on macOS
by steveklabnik on Sunday April 18, 2021 @10:27AM
(#26852749)
Rust heavily relies on such things for safety checks, without loss of speed. We could get the same safety with runtime checks, but that would compromise other goals.
Re:Reducing Rust Incremental Compilation Times on macOS
by gpderetta on Sunday April 18, 2021 @01:52PM
(#26854696)
C is an an abstraction over assembly that is an abstraction over microcode and so on and on.
So C programmers must agree that some abstraction is good and it is at least plausible that C is not the best abstraction layer for evry single application.
Re:Reducing Rust Incremental Compilation Times on macOS
by mlindner on Monday April 19, 2021 @03:52PM
(#26867195)
If abstractions were bad ideas we wouldn't have compilers and we'd handcode in assembly. We also wouldn't have the hardware continue to be pretending to be a PDP-8 machine even though it's completely reordering the instructions that it runs and predicting every branch taken.
Our world is full of abstractions in basically every single thing we use.
Also to be clear, I mean "abstractions" not "obfuscation" which many people (common in Java and C++) call "abstraction" even though it is nothing of the sort.
Re:Reducing Rust Incremental Compilation Times on macOS
by AaronFriel on Sunday April 18, 2021 @04:53PM
(#26856250)
It isn't "fancy speak" because those abstractions - language features - are intentionally so as not to have a non-zero cost implementation. It isn't an optimization pass and the programmer doesn't need to worry about a degenerate case causing it to fall through to a less optimized implementation.
You get the same "zero cost abstraction" effect in lower-level languages like C (but you need to feed it "dumb code" to see a similar effect). Nobody talks about "zero cost abstractions" in the context of C programming because C doesn't encourage to "obfuscate" source code with high level abstractions.
Not sure if optimizer passes are the main reason for Rust being slow though, I'd guess it's more the static code analysis, e.g. a C/C++ compiler with static code analysis enabled is also many times slower than regular compilation (but Rust should have an advantage there, because Rust doesn't allow as much freedom as "less correct" languages, so the static analysis can be more focused).