But really Rust seems to have the qualities I like about C and less problems. Also, all the reasons I used to have for wanting to be "close to the metal" are getting abstracted away in hardware. I think the only remaining reasons to use C is the huge existing code base.
> ...the complexity of C / C++
In this case, please don't throw C and C++ into the same bucket, C++ is vastly more complex than C.
> Rust seems to have the qualities I like about C
...a subset of Rust has those qualities, but the whole of Rust has the same problems as C++: overboarding complexity both in the language and stdlib.
To lure C users over to a memory-safe language, we need a programming language that just adds the comptime memory-safety features to a 'small language' like C, but none of the higher level features (which only serve to split the language community into different tribes - which is also the biggest problem of C++).
Finally: yes, C is not memory safe, but when 'language-level memory safety' is essential for security, then there's something fundamentally wrong with the sandbox the compiled C code runs in.
Doesn’t the problem then just become what do you write the sandbox in? If you have security-critical code that can’t be sandboxed, because it is the sandbox, then it seems that language-level safety is your only remaining defense?
You probably get accustomed to it, but I am not sure if I want to yet. Not deep enough into compilers to know why variables cannot be implicitly mutable or not. Probably a compiler necessity to enact its borrowing rules. But ultimately the compiler should make my life easier. Only ever using one thread or process does solve several common locking issues.
In that regard C string handling will probably let more people move away from it than its security flaws.
It will probably end up like always. There are some applications where some languages shine. And the simplicity of C has merits, otherwise another language would have taken its place. Of course C still has a lot of momentum and perhaps another language would do better in the specific use case.
i adore C, it was my first language and i still like its simplicity very much. Still, I have come to believe that only strictly vetted licensed people should be allowed to use it :)
A lot of memory safety CVEs come down to "we wrote a static analyzer and found a latent memory bug here."
Their use combines the proper use of C (low-level driver code) with the unsafe use (large-scale systems). They should absolutely stop using C. On the other hand, I think it's fine for my network driver.
Maybe that speaks to some of the driver problems they're having now, if their house just wasn't in order beforehand.
I am willing to bet that NVidia and AMD's GPU unit have floodgates of vulnerabilities along the lines of Spectre, which they simply never had to deal with before (not to mentions likely hundreds of more basic ones).
100%, I'm not anybody in particular but I've been saying this for years, as soon as I saw Spectre/Meltdown announced it's like "lol yeah I bet GPUs have zero hardening against that sort of thing". I hadn't thought of the connection between Meltdown and that person's comment but it's entirely possible the Intel team was deep in Meltdown at that moment when they got presented that lol.
Also Intel in particular seems to have uniquely tight ties between the iGPU and the CPU, since they come from a world where dGPUs didn't exist and the iGPU was only ever a ringbus away from memory or the CPU... it's apparently been a huge problem with the Xe/Arc drivers (there have been a couple patches where they produced 100x speedups by fixing operations that allocate memory in the wrong place, etc) since the GPU is suddenly no longer super close. It would not surprise me at all if AMD would be more secure because they're not working with an iGPU that's super tightly tied to the CPU like that.
https://www.pcworld.com/article/819397/intels-graphics-drive...
But yeah anyway I totally agree, multi-tenant or multi-privilege-level GPU is likely a shitshow, so in a way it's actually a blessing that heavy GPGPU compute never really took off. Because I bet you can totally do things like leak the desktop or your browser windows to malicious webGL or another tenant on a shared vGPU. We live in a world where clients are mostly running one GPGPU application at a time, plus the desktop.
(Although of course, it's always a little useless to speculate about the world going completely differently... if multi-tenant/multi-app GPGPU compute had taken off, more attention probably would have been paid to multi-user security/hardening.)
So this doesn't actually affect things built on top of C. E.g. transpiling Rust to C won't make it any less safe because C is "unsafe" - Rust has its own safety features, that work regardless of compile target.
Or think of it this way - assembly language is even more unsafe than C, yet everything (including C) is built on top of that.
C is safe if you are using a 1970s-style compilers that don't perform optimizations, or perform a limited and predictable subset. C that is passed through an optimizing compiler (which in the context of this comment is all modern compilers) can never be inherently safe unless you conform strictly to the "undefined behavior" spec which is impossible in practice.
In contrast transpiling (really this is just compiling) Rust to assembly should never be unsafe, because you know there is no additional transformation step. Or at least, unless the processor has an implementation flaw... which is, of course, the whole thing about Spectre/Meltdown.
C has far far too many things in the "unsafe behavior" categories that really should just be compiler errors. But like "implementation-dependent" behavior in general, this was seen as an advantage at the time, it makes it possible for low-power or esoteric hardware to be driven with C code. But in modern high-level software development contexts, this makes it a foot-howitzer to try and use.
Machine-emitted C can avoid most of the language, guarantee it won't incorrectly alias anything, and guarantee bounds are always checked.
Bugs are possible but you can make Rust->C bugs no more likely than Rust->assembly bugs.
But the message overall - that maybe we don’t need to instinctively reach for C for newbuild low-level programming anymore - is probably about right
It's also wrong. A lot of the time the people making these types of comments about C are just plain bitter that their favourite $NEW_LANGUAGE is mostly a rounding error in terms of usage.
That's true too; what's your point?
Like, everyone knows typescript catches more human mistake that JavaScript. But you won't know why if you don't know JavaScript at first place.
If there's a joke here I missed it, sorry.
We stopped using asbestos because of the link between its manufacture/installation and lung cancer. It’s a clear case where government regulation helps deal with a market failure: asbestos is cheap and effective, so consumers like it, but nobody involved in asbestos transactions bears the cost of the lung cancers the industry causes.
Writing C doesn’t make underpaid programmer die early deaths. The issues with C are borne directly by the customers who are using C software. It’s not really a market failure of any kind.
While I agree that equating a programming language to a carcinogenic substance is inherently wrong, your argument is partially false too.
The cost is born by the costumers of the software, not the developers. In that sense, it's actually directly opposed to your point.
with the language you've got
* the creators of C
* the developers writing software (tool/library/whatever) with C
* the users which use this software
That makes it (imo) directly opposed to your argument, as its technically the same as with the carcinogenic substance
* the creators of the substance dont get cancer
* the contractors using it to build the house dont get cancer
* the people that live in the house get cancerSo OP's point is correct. The two situations are not exactly analogous.
You're both a little bit wrong, and both want to be right, so seem to be ignoring the negative aspects of both your arguments.
C does not have a direct proven link to causing death or catastrophic disease like asbestos does, but any bugs due to language "allowing" the dev to shoot themselves in the foot is largely born by the users - at least initially.
I work with C and it kills me a little more each day, just like cigarettes. Its a pretty fair comparison.
And really, I think your argument bolsters my case. Federal and state governments are freaking out about cybersecurity and protecting infrastructure and voting systems, so why shouldn’t they ban the use of software written in C in their acquisition process?
Unfortunately, a lot more switching cost is involved in getting embedded and systems programmers and platforms over to a new programming language, than is involved in getting construction contractors and industrial engineers to choose a different material.
That's the exact problem with C. It's the tool, not the attitude, which is a problem.
Language-level memory safety is useful for eliminating an important class of bugs, but if those bugs can be exploited to escape the sandbox, then that's the problem of the sandbox, not of the buggy program running in that sandbox. So please, by all means, write the sandbox itself in a memory safe language like Rust, but requiring the same for all code running inside the sandbox is nothing more than an admission of failure.
You can have your app in perfect sandbox where nothing can escape then have a memory safety bug inside allowing user to get to the stuff of another user (because your sandboxed app talking with sandboxed database still have one set of credentials to do everything)
There is of course https://xkcd.com/1200/ for that.
And no "move that separation to DB" also isn't a solution.
Frankly getting your knickers in a knot is emotional - the people using C are doing so for pragmatic reasons, not emotion.
I do see comments like yours a lot - there's an emotional attachment and/or ego attached to the comment, so the argument against is very vociferous and, honestly, ugly[1].
[1] C and asbestos have almost nothing in common in terms of negative impact on the world. Maybe people are still using C because hyperbole is simply not a persuasive argument.
Could you explain how it's emotional? It comes across as a pretty logical analogy to me - the author isn't suggesting that they don't like C (which would be categorically emotional), they are comparing it to phasing out something unsafe in another industry.
Everyone would be better served by using and hearing it less. Focus on the actual argument.
Your reply doesn't point out the passionate component of it either, and doesn't answer my question.
In this particular case, the argument is that C should be replaced with something safer for similar reasons that asbestos is replaced with something safer. However, one can certainly challenge the validity of this comparison and whether there's something faulty in it.
I don't feel one way or the other because I don't work with C or other low-level languages, but it's a bit absurd to say that an analogy isn't an argument. It absolutely can be if the argument within is clear, even if fallacious.
More often than not I see analogies (ab)used as a tool to construct a straw man. This particular case demonstrates how analogy takes discussion away from merits and downsides of C to an emotionally charged subject of cancerogenic substances, as other commenters highlighted in this thread.
It seemed like just a simple, general, easily-mappable analogy that most people would get, even non-programmer laymen, that emphasizes that unsafe should be replaced with safe. Any analogy of something unsafe can be seen as "emotionally charged" if someone was personally impacted by it.
I’ve not personally been impacted by this, but this seems reasonable.
> The analogy is resting primarily on the appeal to that kind of emotion
This seems like projection. It struck me as a perfectly legitimate analogy without any emotional correlation.
EDIT: Because someone will probably make a note of it: Therac-25 wasn't written in C, but the flaws in that system and others helped lead to a massive change in the way critical systems are developed and treated. I referenced it because it's one of the most notable failures in safety-critical software systems.
What this entire thread is about, however, is this highly charged response to what seemed like a straightforward analogy.
> Frankly getting your knickers in a knot is emotional - the people using C are doing so for pragmatic reasons, not emotion. > I do see comments like yours a lot - there's an emotional attachment and/or ego attached to the comment, so the argument against is very vociferous and, honestly, ugly[1].
A failed experiment with the Socratic method on my part.
1 A culture that thinks API's need to always have a gotcha. See the inability to to field a safe string copy.
2 ISO commitee that thinks it's in charge of maintaining a historical artifact. Suggestions to change the language like Brights suggestions about passing arrays fail because the ISO committee thinks that's Heresy.
3 People that think C is hopeless. Usually these are people that had a bad time with it in school.
4 Idiots that think the only reason to use C is speed. Therefor any improved way of doing things that might be 10-20% slower than raw unsafe code is pointless.
Just for sake of clarity, formal analogy is a valid, non-fallacious argument because it's based on parity of reasoning.
The original comment made a pretty good, arguably formal analogy between asbestos and C. The only way to dismiss the conclusion is if there were no alternative to asbestos, then you're kinda forced to use asbestos. This is the case for C in some contexts, like some microcontrollers that only come with C compilers. It's not generally true that we need C for much else though.
"An analogical argument is an explicit representation of a form of analogical reasoning that cites accepted similarities between two systems to support the conclusion that some further similarity exists." [1]
Yes, you're missing the logic.
> Excluding the assumption that C is unsafe, it contains purely facts.
You think C is carcinogenic and mere exposure to it kills?
From a "purely facts" PoV, leaving all emotion aside, C runs, and has done so for a number of decades, life-critical systems, including munitions, weapons, life-support, industrial machinery and aviation.
It's only because you are married to your argument that you think comparing C to a fatal poison is "pure facts".
I don’t think there was any suggestion made that C is detrimental to human health.
> It's also logical to kill young children with autism so they don't become a financial or emotional burden on their family or society as a whole. It turns out claiming something is logical isn't, itself, enough of a reason to do something and those doing so should endeavor to give more convincing arguments.
That's an analogy, and we are talking about a programming language - not humans.
Again, where is the passion in the original comment? I have asked for nothing more than that.
Is it your supposition that asbestos was banned for non-human reasons?
Or does this "logic" only work when convenient for your own defenses?
You call it a logical analogy, how an analogy can be logical?
EDIT: and I hate analogies because, since they suck, someone will try to come up with a better analogy. And now we have a thread where people compare C to asbestos, then they compare C to a fire in kitchen. Not a kind of thread I would like to be in.
Vast quantities of language is built on analogy. Streaming, the internet, the World Wide Web, Starship. The word “cycle” comes from the Latin for “circle”. The list goes on.
I struggle to even comprehend how someone can hold this opinion. Have you ever tried instructing anyone in anything?
These are metaphors, not analogies. [1]
The GP is cautioning against argument by analogy, not the use of metaphorical language. Problems and conceptual traps engendered by argument from analogy have been raised for thousands of years, indeed probably ever since formal discussion of language and reasoning have been recorded.
And I’m firmly in the camp that it is fine to use analogy in debate. Rarely do people claim when they make a comparison that it is a one to one mapping. Just that there are possible insights to be gleaned from the comparison which could potentially mean that we may be able to solve problems in one domain using similar solutions to the existing domain.
Take this quote for example:
> I hate all analogies with physical world, because the person tends to pick up the most emotional one. It's emotional because they picked the thing that makes my lungs bleed. C, with all its flaws, doesn't damage my physical health.
Obviously interpretation is subjective but this seems a huge misinterpretation of what OP was saying. To me, OP is clearly arguing that C code is damaging to the long term health of computer programs the same way asbestos exposure is damaging to long term human health and that we should consider replacing or retiring C code with modern alternatives like Rust the same way asbestos has been replaced with modern building materials. Saying that you don’t like the argument because bad C programs are nowhere near as damaging to physical health as asbestos seems like a bad faith interpretation of what OP was trying to say. I also think the criticiser may feel differently if he was hooked up to a life support machine that was known to have buggy c code but that’s by the by.
Hacker News seems to have gone really hellbent on this pedantic ‘this is fallacy x’, this is fallacy y’ stuff recently as if every comment is some kind of formal scientific paper. It’s really weird and I’m sure it never used to be like this. It’s sucks the joy and fun out of everything, I don’t know why people can’t just express interesting viewpoints here anymore like a normal conversation without the fallacy police showing up,
At least it's not a "comparing Linux kernel to a car" situation I've also seen.
- 1: sometimes we have to learn simplified but faulty models in order to understand the more complex and more accurate models
- 2: Everyone sees the world in different ways. It is often through combining these different viewpoints (or analogies) that we arrive at something closer to the objective truth. This is eloquently illustrated in the [Blind men and an elephant parable](https://en.m.wikipedia.org/wiki/Blind_men_and_an_elephant). The moral of the parable isn’t that we should throw away all analogy because it can be misinterpreted. The moral is, as Wikipedia puts it:
> The parable has been used to illustrate a range of truths and fallacies; broadly, the parable implies that one's subjective experience can be true, but that such experience is inherently limited by its failure to account for other truths or a totality of truth. At various times the parable has provided insight into the relativism, opaqueness or inexpressible nature of truth, the behaviour of experts in fields of contradicting theories, the need for deeper understanding, and respect for different perspectives on the same object of observation.
1. "Don't rewrite code" a fundamental precept of software that has been "engineered"
- This is more about development lifecycles than something that contributes usefully to software quality in the long term. Corporations, and people haven't been treating these things like bridges or overpasses
- Again, paying low-wage junior SEs to patch uncovered bugs is obviously cheaper than proactively finding them all.
- If you have a good rewrite, sell it at a fat markup, and keep selling the old crap too, it's not your risk.
- Obviously don't rewrite unless your horrid monolithic source leaks, and you're certain that it's a problem, those disgruntled workers you wrongfully laid off know too much.
- Don't include pesky manuals where people can uncover issues with your development processes, outsource a minimum blackbox of guess work to Singapore and let that double as QA.
- It's not a manual, it's 'training' -- supporting education of hopeful workers! Wow!
I think a lot of us using C would like to move away, but for whatever reason can’t. One example is that we hotpatch our binaries, but that sort of infrastructure doesn’t exist for Rust.
Beyond tooling issues, that certainly can be fixed, it’s also non trivial to move a large codebase to a safer language. Maybe incremental use of languages like Rust is still better?
We still have software running in excel macros that control web browsers via COM. C is nothing compared to the attack surface of that.
Even the analogy holds up in this regard: using other materials instead of asbestos does not remove all the construction problems.
I think C has other things going for it (simplicity of the compiler), just wanted to point that out.
Getting rid of a class of errors (correctness) allows you to focus more on other errors (logical). It could be argued that it could slightly reduce the likelihood of the latter.
"It will solve memory leaks!"
...
"whoops, you can still leak memory in garbage collected languages, my bad everyone!".
which speaks how rare they are
I also suggest you say 5 years instead of "half-a-decade", most of us see through that and it's off-putting.
I have seen two instances of rooted memory:
- WPF. The implicit GC root path introduced by events. We were easily able to track this down due to the information that the GC holds in memory[1] (fixing it was not so easy).
- A leak in managed C++ (non-pure, i.e. native code). We had to use the normal tools to track this down, not a 5 minute diagnosis.
At the end of the day GC'd languages can have (and usually do) richer tooling surrounding memory usage. They are better in this regard even during a failure state.
[1]: https://learn.microsoft.com/en-us/dotnet/core/diagnostics/so...
Getting rid of C won't get rid of security problems anymore than moving to java and .net got rid of needing to think about memory leaks.
Those that think otherwise are ignorant of history, or choosing to ignore it.
And it gets worse when you consider resource exhaustion, not just memory. There are entire mechanisms in .net and java whose sole purpose in life is to try and deal with resource exhaustion because the GC only deals with 1 aspect of that resource exhaustion (memory leaks).
---
For those of us who watched that transition, it's obvious it won't work out the way people are claiming.
> it could slightly reduce
Had to wait on a patch for .net... not a problem anymore today, although I don't know the details how they solved the problem.
I think you mean "memory safety", not "correctness".
Correctness is a much harder target to hit and requires a good deal of time.
And that's all working as designed. Someone built it like that. There's no bug anywhere in that chain, just as extremely rickety system with no affordances for human intervention. No separation of what is trusted and what is not.
There's a good case to be made for using better languages than C and C++ for large classes of software. Don't weaken it by making absurd claims.
And this idea can be applied to so many things.
Seriously, very often things have enough downsides that you don't need to exaggerate things that are not downsides. You're actually weakening your side by doing so because if people cannot trust even that bit of honesty, why would they trust anything you say?
be trustworthy is the first rule in convincing others.
Moreover, almost no bugs are discovered in the actual reasonable software we have. That's not because we are the best engineers, or because we write it with the utmost care and attention to detail. It's because we're a total of 5 people (mostly a couple of years out of uni) looking at it. C, and other systems programming languages are greatly overrepresented in the corpus of software that is actually being combed through for bugs. Java and Cobol are heavily underrepresented.
I want to make this clear again. I work in banking. If 2008 showed us anything it's that banking underpins most of our modern society so these quality issues are not unimportant, they can be devastating.
According to studies done at Google and Microsoft, about 70% of their serious security issues are a result of memory safety errors.
>Around 70 percent of all the vulnerabilities in Microsoft products addressed through a security update each year are memory safety issues; a Microsoft engineer revealed last week at a security conference.
https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
and
>Nearly 70% of the high severity security bugs in Chrome's code are memory unsafety problems, Google's engineers have revealed.
https://tech.hindustantimes.com/tech/news/70-of-security-bug...
And in discussions like this, it's verging on the dishonest - leading with a large number makes readers think that a large difference to bug count will result.
> Around 70 percent of all the vulnerabilities in Microsoft products addressed through a security update each year are memory safety issues; a Microsoft engineer revealed last week at a security conference.
What's the total bug count?
A codebase with 10000 bugs logged against it might have maybe 10[1] that are CVEs, of which, according to that statistic, only 7 would be fixed by moving to a safer language (either GC or Rust or similar).
That's just not enough motivation for switching when the payoff for preventing "70% of CVEs" is so small it may never even happen.
[1] I've worked on C codebases that were developed over a decade, and 1000:1 of all-bugs:memory-safety-bugs is a very conservative ratio. IME, it's been closer to 10000:1.
Microsoft does not appear to agree.
>Mark Russinovich, the chief technology officer of Microsoft Azure, says developers should avoid using C or C++ programming languages in new projects and instead use Rust because of security and reliability concerns.
https://www.zdnet.com/article/programming-languages-its-time...
What people do believe is it would remove whole classes of security problems that affect everybody. Even if you have software running in excel macros. Maybe in your environment that is a minority of your problems. That is probably not a good thing, and we feel for you, and respect preferring to tackle that problem first. But it would be a good idea to not entrench C further while you are doing that. Once you shrink your attack surface, it would be great if the code being invoked doesn't have exploitable memory overflows to make all your hard work pointless.
Using nuclear power correctly takes a ton of engineering prowess, lots of additional construction. If done well, it works great. When it goes bad, it goes really bad.
So if it's 1982, maybe nuclear power or C is a good option. If it's 2022, new technology may provide a cheaper way of getting to the same end point, with less engineering and construction, and probably even less cost.
Why would your experience there make you think the good nuclear plants are any different?
Do they? The only “safe” comparable alternative is unsafe Rust which as the name suggests isn’t actually safe.
This guy is just doing the typical religious yelling about people doing their jobs (writing kernels, drivers, browsers, games, etc) with the most flexible tool for programming we've developed to date.
Maybe one day Rust will become dominant. Maybe someone will overhaul the aliasing rules of C, write some similar lifetime tracking tooling, and it will live on for another 50 years. Who knows. The reason people still use C and C++ isn't because they're good languages (or even that people like them, as the comment states), it's that until recently there have been very few viable alternatives, and for some domains literally none at all. They've largely been the only option for a long time.
It makes sense for nVidia to trade development time and prefer a language with formal verification for their firmware.
And for some applications, Rust isn't even an alternative. Not every chip is supported by LLVM.
For a lot of things, I just don't think this is true.
For example, here is sqlite's reasoning for choosing C: https://www.sqlite.org/whyc.html
I can't say I can really disagree with it.
“I don’t need seatbelts, I actually know how to drive unlike others”
Sure, but do they have certified compilers for Functional Safety (ISO26262) development for Automotive or Medical applications? Rust does not, although there's a company working on it.
C is not "unsafe" in the sense that little bits of it break off in installations and make people sick, but in the sense that the assurance of safety almost all rests on the programmer.
If code is safe, and not changed, it stays that way.
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.
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.
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.
But, it isn't used in products designed for the general public where strict oversight can't generally be provided.
We use incredibly dangerous materials in photolithography, nuclear weapons production, armor piercing projectiles, and aerospace... because there are no alternatives and/or the benefits outweigh the risks.
What changed is that we learned more about asbestos (it causes cancer) and phased it out of applications where alternatives existed, even more expensive ones.
In the C analogy, there may be places C continues to make sense... but it shouldn't be used anymore out of default, because it's the way things have always been done, or any other reason that doesn't end with "... and that's more important than an increased risk of security vulnerabilities."
Unlike asbestos insulation in houses, or flame in your personal kitchen, you actually can't avoid C in your software stack. Do you use Linux, FreeBSD, or OpenBSD, or macOS, or Windows? Do you use Postgres or MySql or sqlite, or maybe redis or memcached? How about a language like Python or JS or Java or Ruby or Lua? Do you use rust? guess what the business-end of that compiler is written in! so you dabble at the tippy-top of the stack in some language like rust or go, so what?
You know what, construction industry could have made the same argument - oh look, all insulation suppliers use asbestos, the factory is built out of it too, its everywhere in the supply chain, you can't actually avoid asbestos if you ate trying to build a house, so we should learn to live with it.
You can't avoid fossil fuels, you gave to use fossil fuels to produce a solar panel, so dreaming about clean energy is pointless.
The difference is that some i industries pull the finger out of their bum and clean up their act, and some i dustries, like our's, does not. Even thoigh perfectly serviceable alternatives exist.
Other languages make me depressive and steal my focus. They make me go to great lengths trying to get the simplest things done. In C, it's like memset(p, 0, sizeof *p), done. Other languages make it such that I always code on 3 layers of abstraction to not have to do the "hard" task, but now I don't know the implementation of those layers. They make it such that I'm constantly torn to come up with an even more clever thing to say the same things, with even more abstractions and moving parts. They pull so much attention to themselves, distracting from the task that I want get done. With C, this is not the case.
Maybe with a different personality, I could be similarly or even more productive in Rust, ignoring all the kitsch in its ecosystem. But I've started reading Rust projects dozens of times and have always turned away. They always use one more abstraction than I can be arsed to look up, always hide the most interesting and motivating parts behind a crate dependency.
This is not the case with C, where it is easy to find good (enough) code that is honest and direct, and rewarding. I know that C is not perfect. We're having an open relationship, and I don't have any attachments (besides knowing it well) that prevent me from jumping ship when I find a better one.
This will not be a quick change. C is interoperable, and the industry is moving slowly.
Having said that, I would never recommend C as the language of choice for new projects.
For whatever reason with C there’s this huge emotional component to it. Safer alternatives exist. You’d rightfully laugh at a contractor who suggested asbestos is fine, if you make sure to use only highly-skilled installers who patch up the drywall so that no fibers can escape. But with C we say that all the time, and the CVEs keep piling up.