"Eschew flamebait. Don't introduce flamewar topics unless you have something genuinely new to say. Avoid unrelated controversies and generic tangents."
What Rust needs is an alternative, gcc-based implementation similar to gccgo.
This will solve the problem immediately and allow Rust to be used on a much greater variety of targets, including obscure targets such as Tricore which are used in the automotive sector.
Only if Rust code runs everywhere, it will also be deployed everywhere.
Rust is on LLVM for a reason: implementing new languages on top of GCC is hard. It seems much more reasonable for unusual architectures to contribute to LLVM. If companies want to sell their own architecture, they should provide the support themselves, rather completely relying on free contributions from the OSS community.
The original person said "evangelists" and then slid into "zealotry." And I find a lot of anti-Rust folks seem to think anyone who likes Rust is a "zealot." YMMV.
I think that this is just a hard conversation to have, with a ton of different groups who all want different things, and have different incentives.
But it is. Unlike C/C++, Rust does not have undefined signed integer overflow or strict aliasing rules. Furthermore, you can do a few more things with pointers that are undefined in C/C++ (e.g., implementing offsetof the naïve way in C/C++ is undefined behavior, but would not be in Rust [assuming you use raw references, which are still in the process of being added]).
In general, there's a slice of behavior that's undefined behavior in C/C++ that isn't undefined behavior in Rust, and for people who want C to really be "portable assembly," Rust is arguably a slightly better choice as a result of being less likely to accidentally trip up on undefined behavior.
Unsafe Rust is harder to predict the behaviour of than C – at least, when you're doing completely off the wall stuff like re-using the stack in two threads. You can keep it contained, though, and so long as your unsafe Rust is keeping the language's invariants, the code is safe; therefore, you know where to start looking when there's trouble to be found.
> It’s almost getting to the point that I’m rooting for rust to fail and for C++ to just continue to get better, just so that these people who claim to take memory safety so seriously might shut the fuck up about it.
lol idk kiiiinda sounds like you might be the one taking things too seriously?
I feel like the author is not being that zealous! More to the point, he is not really focusing on memory safety so much as his frustration with the nature of the complaints RE: Rust. Perhaps he is being pithy and snarky enough to hurt people’s feelings, but his points about C being “organizationally” unsafe are well-established and not controversial.
And his broader point is one that C evangelists should take seriously - the fact that C can be compiled on all sorts of esoteric architecture does not mean that every open-source C program is supported on those architectures. There is a serious risk with using a crypto library on instruction sets the author isn’t supporting, and the responsibility is on the package distributor or consumer (depending), not the maintainer.
The point is: If Rust is supposed to replace as _the_ systems programming language, it needs to be as portable as C.
There is no point in arguing what architectures are considered obscure and which are not since there a lot of fields of applications in industry and research which use architectures most people never heard of such as Elbrus 2000 or Sunway.
C is more portable than Rust when you define portable as "it compiles". If you define portable to mean "works correctly" I expect C is about as portable as Rust in the context of most applications.
> C is more portable than Rust when you define portable as "it compiles". If you define portable to mean "works correctly" I expect C is about as portable as Rust in the context of most applications.
I suspect you have a more narrow definition of “works correctly” than the C advocates do.
I do suspect that a lot of "our CI says this compiles on platform X" situations, for quite a few programs, are targeting arch/os combos that genuinely aren't getting tested, with only the occasional hobbyist poking at it every few months.
It wouldn't surprise me at all of most of those just crash-on-launch - or crash when you try to do anything, even though the CI builds them just fine and they pass the automated tests.
For an awful lot of boutique platforms, it's usually "literally one person" that drove the work to port it to that thing, and when that person's no longer actively doing the work, bitrot goes wild.
Please don't take HN threads further into flamewar. The perpetuation/escalation actually does more harm than the original post, which is why the site guidelines ask you not specifically not to do this.
A great deal of this article is about C being a "cancer", "a perpetually unsafe development ecosystem", whose cancerous properties are enabled by the absolute horror of it being portable.
> A great deal of this article is about C being a "cancer", "a perpetually unsafe development ecosystem", whose cancerous properties are enabled by the absolute horror of it being portable.
Author here: my sibling already explained the language, but I specifically chose "cancer" because I remember seeing the UNIX-haters handbook use that phrase (I'm not exactly a UNIX hater, but it's always stuck with me). I write C and C++ professionally (and I like it that way!), and I think it's perfectly fair and accurate to refer to their spread as cancerous.
> The implied replacement is Rust.
No. Rust was an example. The replacement is any memory-safe language; Rust just happens to have done a great job getting much of the tooling right from the get-go.
That is not a good reason for choosing such charged language. You can get your point across without comparing a venerable (if flawed) programming language to one of the most feared class of diseases that kills millions each year.
I think there are good points you make that people should hear, but less people will listen if you turn them away by making grotesque comparisons.
> You can get your point across without comparing a venerable (if flawed) programming language to one of the most feared class of diseases that kills millions each year.
I'm going to be pedantic with this: calling something "a cancer" is not comparing it to cancer. The phrase "X is a cancer" is bombastic and inflammatory, which is intentional. It's neither a simile nor grotesque, at least in my dialect of English.
As for the actual point: I see no reason to venerate C. Nobody should labor under the false pretense that we, as an industry, are brilliant enough to reliably write safe, cross-platform C. We haven't managed to do it for the last 50 years and, given the current state of static analysis on C, I don't have any particular hope for the next 50. I'm going to keep on writing it, but I don't intend to venerate it or convey that expectation on anyone else.
> As for the actual point: I see no reason to venerate C. Nobody should labor under the false pretense that we, as an industry, are brilliant enough to reliably write safe, cross-platform C. We haven't managed to do it for the last 50 years and, given the current state of static analysis on C, I don't have any particular hope for the next 50. I'm going to keep on writing it, but I don't intend to venerate it or convey that expectation on anyone else.
This absolutely hits the nail on the head. This is masterfully put.
The problem with a great many successful things in the world is there's a very human tendency to "saint" them and attribute a sort of mystical infallibility/ineffability to them. As though they weren't just "fit for the purpose and in the right place at the right time", but rather "a work of genius - the right solution for all time, now and forever." (C.f "end-of-history-fallacy").
That's how technology stagnates - if we, as a community, can't admit something's got room for improvement, it simply won't.
At least part of the point was that C only appears to be portable. The abstract machine concept itself is leaky, lesser used compilers have serious bugs, build scripts aren’t portable across architectures, dependency management is poor, etc.
C programs would be a lot more safely portable if there was a pervasive testing culture, preferably with some new language features, so eg you could see a program doesn't actually work without 64-bit pointers.
(Without language features it's annoying to write tests because you end up exporting things that don't otherwise need exporting.)
It's a "cancer" in the sense that it spreads everywhere and people use C software even in environments where it was never intended to work, and get hurt by it.
