C isn't a hangover and Rust isn't a cure
scribe.rip
C isn't a hangover and Rust isn't a cure
1–10 of 20 posts
Re: C isn't a hangover and Rust isn't a cure
#2Re: C isn't a hangover and Rust isn't a cure
#3Re: C isn't a hangover and Rust isn't a cure
#4Re: C isn't a hangover and Rust isn't a cure
#5Re: C isn't a hangover and Rust isn't a cure
#6Bounds checks themselves aren’t that expensive, if you already have the length to check against in a register or some other convenient spot.
And - if the bounds are convenient to find and known to be immutable then it does make it easier for the compiler to eliminate those checks using the same techniques it would use to eliminate all kinds of redundancies. C has many redundancies that we don’t have to think about because they’re straightforward for the compiler to reason about.
Re: C isn't a hangover and Rust isn't a cure
#7The reason why Rust and other languages have bounds checking that approaches C’s speed is less to do with the compiler being able to prove away bounds checks and more to do with those languages making the bounds easy to carry around. Bounds checks themselves aren’t that expensive, if you already have the length to check against in a register or some other convenient spot. And - if the bounds are convenient to find an…
Re: C isn't a hangover and Rust isn't a cure
#8Re: C isn't a hangover and Rust isn't a cure
#9Go in particular has a lot of the advantages of C/C++ and Rust--fully-compiled binary, easy access to system calls, high performance--without the overhead of needing to constantly think about memory management.
Re: C isn't a hangover and Rust isn't a cure
#10There are a lot more practical and lucrative skills for a young programmer to focus on than C or C++. Many will be able to have good careers without going that low level.
What impact will that have on the economics of legacy C/C++ code bases in the 15-30 year time frame?