5 ms·

> It was fine at what it did No need to talk in past tense. C is still the best language at what it is meant for: writing fast software. Not safe software, _fa

> It was fine at what it did No need to talk in past tense. C is still the best language at what it is meant for: writing fast software. Not safe software, _fast and portable_ software. > but the safety problems outweigh them Safety is to speed what security is to convenience. Frankly, most of the arguments I see today are just fear mongering. In my experience, there is no protecting users from developer mistakes that lead to software exploitation and 'unsafety', independent of the language being used. Memory issues are a common avenue, but if you take it away, the next issue will become the main avenue for exploitation, and you'll be back in the same spot, with the next generation of developers fearing that the new software safety level is insufficient to reach some ideal safety level, all while having traded off real world speed across the board to reach that point. > no new installations use it I'm writing a tool in C. It doesn't need to be perfectly secure. It does need to be fast. By using C we acknowledge that users want speed, more than they want safety, and that's our developer reality. That doesn't mean users don't want safety, it just means that outside of specialized domains, on average speed takes priority - people have been voting for decades that they want speed more than safety, and the process of deciding the priority is as you'd expect: users use money to buy a faster product and companies selling software invest in making their software fast first. The security argument is also weak. The whole point of cracking software is to find flaws in existing systems, regardless of the language they were coded in. One thing will always be true: anything that sends data can be cracked. You can only make the entry bar harder, but you will not create a language that is significantly safer and as fast as C because the optimizations that make software fast (like not checking array lengths, not checking for overflow, etc) are also the ones making it less secure. One can create a language that's safer than C and fast (in specific situations), but there will always be people cracking the core of whatever the 'safe' language du jour is, so you will have decreased security incidents on average, but have not eliminated them, while leaving room for a competitor to swoop in with a faster product that's safe enough, and it's your users who will decide who wins, not you. Just to emphasize this, so far, I have not seen any indication that the general population will shift to picking safety over speed, so you'd be betting against your users.

c-cube 4y ago
At this point there isn't strong evidence that C is going to deliver better performance than C++ or Rust, especially for a given amount of work. One could argue that better code reuse (templates, generics, crates, etc.) allow programmers to write faster code in C++ or rust. For example you need barely any work to use a really good hash table in rust, one that's really tricky to rewrite by hand because it involves simd and whatnot.
- optymizer 4y ago
  The language that for the past 50 years has: 1. consistently had much faster compilation times than C++ or Rust 2. consistently generated some the smallest binaries 3. consistently ended up in #1 on programming language benchmarks 4. consistently been used to write the worlds OS kernels, where speed is critical does not have _strong evidence_ that is going to continue to deliver better performance than C++ or Rust? On the contrary, there is no evidence that Rust will ever be as fast as C. The burden on proof is on you and Rust to support your bold claims. C++ is in a different boat - it already tried to displace C in the 90s and it has been successful only in the environments where its other properties are a much more needed advantage, not for being faster than C. That's where Rust will end up - in between Java and C++. It will never displace C, because you pay for runtime safety with CPU cycles. Static analysis can only get you so far. Even Java's JIT, which got everyone excited about beating C in the early 2000s, failed miraculously at being faster than C, even if it could generate better assembly code at runtime, precisely because extra features cost cycles which necessarily slow down execution speed, so you're not the first group of people with starry eyes and bold claims about performance and C. As far as the generic simd hashmap goes, it will always be slower than a specialized custom built hashmap in C, even if it takes longer to code it and has more bugs.
  - c-cube 4y ago
    C has existed for a longer time, and for historical reasons it's used for some of the biggest and most popular kernels. That makes sense. However, newer kernels don't necessarily stick to C (e.g. Fuschia's kernel is in C++); there is also no evidence that kernels in C++ would be slower than the C equivalent. Regarding your other points: 1. compilation time is not related to runtime performance. 2. smaller binaries can mean better perf sometimes, but it's not always a win. It's a deep tradeoff between inlining/specialization/code size. 3. benchmarks are fun, but I think it's misleading to claim they're absolute truth. In particular, a popular benchmark will be tuned endlessly till it yields what you want. For real code you get a tradeoff between the effort put in optimization, and the total time to deliver features. I think this is where C++ (and rust) shine over C. 4. see above For the rest: "continue to deliver better performance than C++ or Rust" that makes no sense since C++ and rust are more recent. And C++ can be just as performant as C already, or better (for a given amount of programmer effort). Code reuse is a big deal. The runtime impact of safety features is real, but (for non-elided bound checking) it's pretty low. Rust is also known for compile-time safety features which can help writing better code because you need to spend less time on debugging; the classic examples are string handling (keeping slices of the input is easier to do safely in Rust) and threading. Some features of C++ and Rust are also better optimizable than the equivalent C idiom (e.g. to represent objects/dynamic dispatch). Comparing C++ and Rust with java is a red herring. Java is JIT compiled and garbage collected, with little control over memory layout. People might have overhyped it in the 1990s and 2000s, sure. Rust and C++ give you as much control as C if you need it, and they go throught the same static code generator (LLVM) than one of the leading C compilers. Rust also will optimize the memory layout of structs for you by rearranging fields unless you explicitly use `#[repr(C)]`, which means that it'll be smaller than C's equivalent on average. > As far as the generic simd hashmap goes, it will always be slower than a specialized custom built hashmap in C, even if it takes longer to code it and has more bugs. Maybe if you spend as much time to write your C hashmap as was spent on the generic Rust hashmap. That's really a long time. If you just need a hashmap somewhere, pulling the standard Rust hashmap (or, in C++, abseil, from which the Rust version took inspiration) will deliver great performance for little effort, so you can move on with your life and spend more time on the profiling phase. I think we talk too often about "absolute" performance without accounting for the total time it takes to achieve it, including debugging, profiling, etc.

c-cube 4y ago

At this point there isn't strong evidence that C is going to deliver better performance than C++ or Rust, especially for a given amount of work. One could argue that better code reuse (templates, generics, crates, etc.) allow programmers to write faster code in C++ or rust. For example you need barely any work to use a really good hash table in rust, one that's really tricky to rewrite by hand because it involves simd and whatnot.

optymizer 4y ago
The language that for the past 50 years has: 1. consistently had much faster compilation times than C++ or Rust 2. consistently generated some the smallest binaries 3. consistently ended up in #1 on programming language benchmarks 4. consistently been used to write the worlds OS kernels, where speed is critical does not have _strong evidence_ that is going to continue to deliver better performance than C++ or Rust? On the contrary, there is no evidence that Rust will ever be as fast as C. The burden on proof is on you and Rust to support your bold claims. C++ is in a different boat - it already tried to displace C in the 90s and it has been successful only in the environments where its other properties are a much more needed advantage, not for being faster than C. That's where Rust will end up - in between Java and C++. It will never displace C, because you pay for runtime safety with CPU cycles. Static analysis can only get you so far. Even Java's JIT, which got everyone excited about beating C in the early 2000s, failed miraculously at being faster than C, even if it could generate better assembly code at runtime, precisely because extra features cost cycles which necessarily slow down execution speed, so you're not the first group of people with starry eyes and bold claims about performance and C. As far as the generic simd hashmap goes, it will always be slower than a specialized custom built hashmap in C, even if it takes longer to code it and has more bugs.
- c-cube 4y ago
  C has existed for a longer time, and for historical reasons it's used for some of the biggest and most popular kernels. That makes sense. However, newer kernels don't necessarily stick to C (e.g. Fuschia's kernel is in C++); there is also no evidence that kernels in C++ would be slower than the C equivalent. Regarding your other points: 1. compilation time is not related to runtime performance. 2. smaller binaries can mean better perf sometimes, but it's not always a win. It's a deep tradeoff between inlining/specialization/code size. 3. benchmarks are fun, but I think it's misleading to claim they're absolute truth. In particular, a popular benchmark will be tuned endlessly till it yields what you want. For real code you get a tradeoff between the effort put in optimization, and the total time to deliver features. I think this is where C++ (and rust) shine over C. 4. see above For the rest: "continue to deliver better performance than C++ or Rust" that makes no sense since C++ and rust are more recent. And C++ can be just as performant as C already, or better (for a given amount of programmer effort). Code reuse is a big deal. The runtime impact of safety features is real, but (for non-elided bound checking) it's pretty low. Rust is also known for compile-time safety features which can help writing better code because you need to spend less time on debugging; the classic examples are string handling (keeping slices of the input is easier to do safely in Rust) and threading. Some features of C++ and Rust are also better optimizable than the equivalent C idiom (e.g. to represent objects/dynamic dispatch). Comparing C++ and Rust with java is a red herring. Java is JIT compiled and garbage collected, with little control over memory layout. People might have overhyped it in the 1990s and 2000s, sure. Rust and C++ give you as much control as C if you need it, and they go throught the same static code generator (LLVM) than one of the leading C compilers. Rust also will optimize the memory layout of structs for you by rearranging fields unless you explicitly use `#[repr(C)]`, which means that it'll be smaller than C's equivalent on average. > As far as the generic simd hashmap goes, it will always be slower than a specialized custom built hashmap in C, even if it takes longer to code it and has more bugs. Maybe if you spend as much time to write your C hashmap as was spent on the generic Rust hashmap. That's really a long time. If you just need a hashmap somewhere, pulling the standard Rust hashmap (or, in C++, abseil, from which the Rust version took inspiration) will deliver great performance for little effort, so you can move on with your life and spend more time on the profiling phase. I think we talk too often about "absolute" performance without accounting for the total time it takes to achieve it, including debugging, profiling, etc.