| ▲ | einpoklum 16 hours ago |
| tl;dr: Rust officially allows you to write inline assembly so it's fast, but in C it's not officially specified as part of the language. Plus more points which do not actually indicate Rust is faster than C. ... well, that's what I get for reading an article with a silly title. |
|
| ▲ | steveklabnik 16 hours ago | parent | next [-] |
| That’s not how I would summarize what I wrote, for what it’s worth. My summary would be “the question is malformed, you need to first state what the boundaries are for comparison before you can make any conclusions.” I think this is an interesting thing to discuss because many people assume that the answer to “is x faster than C?” to be “no” for all values of X. |
| |
| ▲ | bigfishrunning 16 hours ago | parent | next [-] | | > many people assume that the answer to “is x faster than C?” to be “no” for all values of X. This is because C does so little for you -- bounds checking must be done explicitly for instance, like you mention in the article, so C is "faster" unless you work around rust's bounds checking. It reminds me of some West Virginia residents I know who are very proud of how low their taxes are -- the roads are falling apart, but the taxes are very low! C is this way too. C is pretty optimally fast in the trivial case, but once you add bounds checking and error handling and memory management its edge is much much smaller (for Rust and Zig and other lowish-level languages) | | |
| ▲ | bluGill 15 hours ago | parent [-] | | In the real world the difference is rarely significant assuming great programmings implement great algorithms. However those two assumptions are rarely true. |
| |
| ▲ | sevensor 16 hours ago | parent | prev [-] | | I read the post to see how you would answer, not because I was unclear about what the answer would be, because the only possible answer here is “sometimes.” I especially like the point that Rust can be faster because it enables you to write different things. As I never tire of getting downvoted for saying, I’ve improved the speed of a program by replacing C with Python, because nobody could figure out how to write the right thing in C. If even Python can do this, it must apply to just about every pair of languages. |
|
|
| ▲ | anonnon 16 hours ago | parent | prev [-] |
| The article felt fairly dispassionate and even-handed to me, and I say this as someone who dislikes Klabnik very much and also dislikes the Rust community (especially its insidious, forced MIT rewrites of popular GPL software, with which they also break backwards compatibility). It is worth mentioning that there are certain things about Rust that conceivably could make it faster, e.g., const by default (theoretically facilitating certain optimizations), but in practice, thus far, do not. |
| |
| ▲ | avadodin 3 hours ago | parent [-] | | > especially its insidious, forced MIT rewrites of popular GPL software Is this some sort of movement? I was aware that some Rust software had been released under permissive licenses but I didn't know it was activism besides the obvious C-is-obsolete angle. | | |
| ▲ | steveklabnik 2 hours ago | parent [-] | | It’s not deliberate activism. It’s two things: Monomorphizarion makes the GPL weird. Rust is dual licensed under Apache/MIT, and so most people choose the same as a default if they don’t feel strongly about licensing. |
|
|