[0] https://www.theonion.com/no-way-to-prevent-this-says-only-na...
https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
Generated by exactly 69 lines of Go every time: https://github.com/Xe/site/blob/main/cmd/no-way-to-prevent-t...
Truth is, these people are simply afraid for their cozy jobs, that's all there is to it. Derivative states of mind like Stockholm Syndrome and Sunk Cost Fallacy are quite normal to appear in these conditions.
On OP: I could not agree more. People always downplay their fuck-ups, that's sadly part of being a Homo Sapiens, but the lack of awareness is still both despairing and hilarious to watch.
And finally, C/C++'s niches have decreased but these people will not adapt, of course. Almost anything I've done with those languages 15-20 years can today be done with Rust. Or if you are on a tight time budget -- Golang, and you still won't lose too much speed.
But sure, "nothing can be done, these things sometimes happen". Sigh.
In my world, using C++ is the modern language, because most project are stuck with Fortran.
My broader point was that C/C++ are still kings in some areas but people insist on using them where a bunch of languages do better today.
I am not evangelizing for Rust, Golang or anything in particular. I am evangelizing for periodically asking yourself "Am I still using the best tool for the job?" which most people never do.
Oh don't even get me started on this but I agree sooooo much.
> No, more people should be using memory managed languages like Java and Golang.
Well, I use both Golang and Rust depending on the need. We can have both, it's not an either-or.
...same with "struct", "record" or "tuple" vs "product type". Nobody calls them that except functional programmers and mathematicians, both quite rare specimen in the wider programming world, but nevertheless they are ancient and widely known concepts even among us "peasant coders" ;)
Unfortunately you can't just have Rust's safety checks, without opting into restrictions that Rust designers force onto You that aren't inherent to safety checks, but more because 'that's a better practice (according to us)'.
And also, easy and fast iteration just isn't there, both because of borrow checker restrictions and compile times
Let's face it, it felt good to be a lone cowboy carrying a lot of responsibility and knowing what you are doing. I was there myself and I'll admit the ego trip was awesome.
These times are long past and naturally, people refuse to adapt.
> Unfortunately you can't just have Rust's safety checks, without opting into restrictions that Rust designers force onto You that aren't inherent to safety checks, but more because 'that's a better practice (according to us)'.
Show me something that does better and I'll switch tomorrow. But don't tell me C/C++ are better -- they are not. Too much freedom leads to CVEs literally every month somewhere and that's only because we don't have better vetting and checking tools, otherwise I'm sure we'd be getting one every day for a while.
> And also, easy and fast iteration just isn't there, both because of borrow checker restrictions and compile times
I agree on that, that's why I mentioned Golang. Most of the C/C++ systems I worked on around 15-20 years ago didn't need the close-to-the-metal speed because at least 90% of their time was spent on I/O... frak, even Python would have done well there. And Golang is times faster. It's a very nice compromise if you want to be productive and don't care super much about CPU speed efficiency.
- Lack of restrictions
- Safety
- Performance
If you choose safety and no restriction, you pay the price in performance (for GC etc.)
If you want fast iteration, use python and then hand transpile your code into rust.
Not every tool has to be used at once ... but Python for the idea and rust for the implementation can be the best of both worlds ... :)
It's a value oriented language. Variables mean something completely different than in any other common language. Everything is about the values and where they are kept at the moment.
Hence why you choose to interpret things as everyone (except you) is defective. Everyone (except you) is laughable, completely lacking in self-awareness, refusing to adapt and be and do as they should (according to you of course).
Because they're all lesser than you! That's why. You write Rust. So obviously, you're so far above them. Like a God looking down at monkeys.
Couldn't be reasons like inertia, or lacking the time, or not having the budget to change, or being too tired to learn, or any other such thing that'd let them be equal to you but just with differing priorities.
No, because then you wouldn't get your narcissistic supply, allowing your delusion you're better than others, rather than a man distracting himself from his own failings?
Just an alternative theory. What do you think?
This is already included in the "almost anything" expression and you are the 4th person deliberately (or accidentally?) not noticing it.
There are valid cases for C/C++ both on technical merits and business specifics. I have not denied that.
---
The rest of your comment is just projection borne out of your faulty assumptions about my comment and it's thus not interesting at all.
> "No way to prevent $THIS" say users of only language where $THIS regularly happens
A weird psychological quirk I've noticed (of myself, and others) is we'll often exhibit a sort of 'programming language xenophobia', where we apathetically accept (or don't even notice) unpleasantries of our language of choice, yet be quite averse to the unpleasantries of other languages.
Maybe it's due to sunk cost; time/effort has already been spent finding work arounds for or adapting to the warts of our native tongue, whereas doing so for unfamiliar languages would require additional effort.
Me: "If it can't happen then it would be fine to just crash on those situations, right? Because such a crash would never be reached. Can we get that?"
C compilers: "No. Would you want to crash on signed integer overflow, for example?"
Me: "Yes? Would be safer than the current situation at least."
C compilers: "What, no, that would make your programs imperceptibly slower. Would you even like that?"
Me: "Yes, I'll be able to live with that."
C compilers: "Well, the answer is still no."
There is a place for C, where there's no alternative. But that place is where 99% of programmers never work, because they are not doing kernel nor firmware development (which, in the meantime, also has a lot of support by and for memory safe VMs and languages).
The issue I have with this narcisstic fatigue (similar to the author's point I assume) is that there is no reflection when they fuck up a codebase.
The best code is the code that is safe and easy to read, and doesn't need to use "clever tricks" that beginners cannot understand.
If you are using some tricks for type casting to implement your ideas into code, you probably should not write code.
Code should be dumb and easily maintainable. If it is not, you made the wrong choice for the programming language.
I suppose incidents like this actually do give a reason to "rewrite it in Rust", when "it" is "widely deployed infrastructure written in C". OTOH, I'm sure there were plenty of non-memory-safety bugs introduced and later fixed over the years, and rewriting in Rust will recapitulate that subset of bugs.
[0] https://github.com/fluent/fluent-bit/commit/49269c5ec3c74411...
In decades of writing C (sometimes as a hobby, often for a lot of money) I'd guess I thought "These errors when I wrote bugs in my program are crap, somebody should fix it" maybe once per month on average. But a C compiler is very intimidating code, subtle and hard to even build from scratch let alone contribute to, so I never attempted to make such changes.
In only a few years of writing Rust (none of that paid) exactly twice I've thought "Man this compiler error diagnostic isn't very good, somebody should fix it". The first time I asked on Reddit, and I was informed that I wasn't the first to notice, the fixed diagnostic was in nightly Rust already. The second time I found the diagnostic and I just fixed it, compiled first time, wrote a new unit test, checked that passed, wrote a pull request. Landed it. Then I wrote a HN comment, a reader found a bug in my diagnostic, so I fixed the original code, and wrote a new PR which also landed. If Rust has told you that instead of 'X' when you needed a byte, you should write b'X' because just 'X' is a char not a byte - that's me, that's my small fix. [Before the fix 'X' wasn't legal here, of course, but the diagnostic wouldn't suggest what to write instead]
[1] https://qz.com/646467/how-one-programmer-broke-the-internet-...
[2] https://www.bleepingcomputer.com/news/security/dev-corrupts-...
[3] https://www.sonatype.com/blog/everything-matters-why-the-npm...
Write a new userspace program? Use anything else, all language shave flaws so pick one which supports the features you need. Want to quickly write something because you are not allowed to rewrite the entire ecosystem you need into a new language since the project will go massively over budged: Use what you can and what's available and accept the risks, which is the 99th percentile of software.
You mean a buffer overflow? Why write so technical then dumb down something that's pretty obvious.
B) It's a spin on The Onion headline about school shootings.
B) I know, it still sounds smug and condescending
"It's a shame, but what can we do? There really isn't anything we can do to prevent memory safety vulnerabilities from happening if the programmer doesn't want to write their code in a robust manner." -- Some (uncredited?) C programmer.
Does C have more footguns as a low level language? Of course. That's part of the freedom of bringing only the baggage a project needs. Sadly, like many dangerous or sharp tools, incorrect use will lead to harms.
If someone has a choice, a safer more modern language can accommodate less skilled practitioners.
Which is extra visible when one looks at original UNIX sources and its many short assembly bits in separate files to handle bits of direct hw manipulation.
Alternatives to C have started appearing for a long while, and they are quite mature now.
> because they are not doing kernel development
FluentBit, where this error occurred, is a userspace application.
> there is no reflection when they fuck up a codebase
C does not support runtime reflection, that is correct. It's one of the reasons why it's a programming and debugging nightmare.
> If you are using some tricks for type casting to implement your ideas into code
There seem to be no casting issues involved in https://www.tenable.com/security/research/tra-2024-17.
> The best code is the code that is safe and easy to read, and doesn't need to use "clever tricks" that beginners cannot understand.
It's just a pile of truisms.
Is your whole post even related to this article?
I think they were just reiterating TFA message in another way: Don't expose yourself to the pitfalls of C when the actual power of C is not really needed.
Maybe go to http://osv.dev/list and search for OOB or Out of Boundary errors instead to make a study on whether this regularly happens or not? Especially when parsing arbitrary strings into a struct?
I'm not sure whether or not you got my message to prefer any programming language over C/C++ or whether you're trying to ignore that on purpose?
Certain embedded targets are also legitimate use cases for C. For example, I am currently working on a project using an 8051 microcontroller. Aside from using assembly – which obviously isn't safe either – there is no practical alternative to using C. Rust may be making inroads for 32-bit targets, but will likely never be able to target an 8051.
We now have enough resources to do this. When C was created, we had to do those tricks to have good performance. Currently C is best used for constrained devices, where sometimes you need those tricks.
> If it is not, you, yes ... you, made the wrong choice for the programming language.
Or your project manager or CTO, or some other stakeholder.
Well ... that rules out everyone's pet favourite here to replace c.
C is portable assembly. Don't use it unless you really must.
Yes I know people want to replace C with Rust, no it won't work because Rust is not assembly, yes it can be used to replace anywhere between 90% to 99% of C and it shouldn't even be too hard. (Unless your embedded device manufacturer doesn't care, which of course they don't.)
Forgive my bluntness, but do you even know any C programmers? The ones I know are not at all a homogenous group (there isn't even anything resembling a "C community" - and IMHO that's a good thing btw).
> The best code is the code that is safe and easy to read.
These two things are not really related.
- Rust code is safe, but typically not easy to read
- C code is unsafe, but typically easy to read
...as a counter example though, C++ code is unsafe, and typically not easy to read.
Of course "readability" is entirely subjective too. Seasoned programmers are typically blind to the problems of their language of choice (and that includes C's sloppiness, and Rust's readability). Language beginners typically stumble over problems that experienced users of that language wouldn't even think of.
> Code should be dumb and easily maintainable.
Well, obviously, but see above, one programmers 'dumb and maintainable' is another programmers 'unmaintainable complicated mess'. IME it's harder to write code that's 'dumb and maintenable' in languages that nudge the programmers towards sugarcoating the program logic in high level abstractions than in "simple" languages like C, Go or Zig, because you don't just need to know the language, but also understand the high level abstractions the original author came up with (and which might have been a good fit at the start of the project, but not 3 years later when requirements have changed and the original programmers have long left for greener pastures).
IME it's not 'narcissism' that makes programmers pick C, but the incredible flexibility of the language, combined with being quite predictable what code will be generated (yes, optimizer passes do complex things, but after a while you'll develop an intuition for what the compiler will do, verifiable via godbolt).
Also for instance, look at the hoops other languages are willing to jump through just to get close - but never fully match - what's possible with simple text replacement in the C preprocessor (an incredible hot take, I know).
Are you joking?
https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
> If someone has a choice, a safer more modern language can accommodate less skilled practitioners.
This is the usual mistake. It's not a "skill issue". Footguns are a design mistake, they're much more dangerous than necessary hence the name. As a result the practitioners accomodated by a better language are all those capable of mistake ie all humans.
(edit: someone was helpful to provide an example in this thread; https://news.ycombinator.com/item?id=40438716 )
In the case of shootings, one must talk about what may have caused shootings to start noticeably increasing in around the 1970s, to the point where a single year started having as many shootings as all the shootings prior to the 20th century combined.
Fun fact; the first documented school shooting was perpetrated by some Lenape indigenous people, in Pennsylvania in 1764, during which attack they also beat to death all of the students and scalped everyone.
The implication here is thoroughly debunked. We’ve seen over and over again that memory safety bugs will happen in every C codebase(ignoring toy or small codebases). Even for the mythical and infallible “skilled practitioner” spending time re-solving the solved issues inherent to C just isn’t a good use of developer time.
That’s really what it’s all about. SV is absolutely obsessed with hiring bad programmers, treating them like crap, so they don’t stick around, and somehow, magically, forcing them to write good code.
We have this belief that if we just use the “right” tool (in this case, a particular programming language), all of our products will be good. Couple that, with the belief that we should be able to build our stuff on someone else’s code, for free, and you have a recipe for disaster.
People like Linus Torvalds are living proof that it is quite possible to write amazing stuff, in old languages (he is a C guy), but people like that, are rare as hen’s teeth, and may be difficult for today’s tech managers to handle.
There really is no substitute for running a good shop, hiring good people, training them well, treating them well, paying them well, and keeping them around for significant lengths of time.
Also, we need to be able to hold ourselves accountable for the Quality of our own work -regardless of the tools we use. Torvalds is notorious for being a tough taskmaster, because he’s serious about the Quality of his work, and casts that onto others.
“Treating people well” does not mean using kid gloves. It can mean expecting people to act like grown-ups, produce grown-up work, and not accepting less. I worked in an environment like that for decades. It was often quite stressful, but was also personally rewarding.
It isn’t the tools that are broken; it’s the management culture, and no one wants to fix that.
We should not be developing new projects in C, and we should make it politically hard to make new projects written in C in distribution repositories. C is going to stay around for a long time and that's okay, but there are so many inherent problems of its design and implementation that make it unsuited for unsupervised use. I wish that we didn't have to make such hard-line stances about this, but people have continuously proven that this tool is unsuitable for modern development and it's only going to get worse as time goes on.
I would give at least embedded development a pass, since you rarely do have a choice there
Nobody writes flawless code.
I might try it out if these two requirements were met. I have a mental model between what I write in C and what I can expect the assembly to be.
Or maybe the problem is that we have the same stack for code and data? could that be it?.
What projects need manual memory management? Those where the hardware costs are comparable to development/maintenance costs. That is much rarer than people think.
RAM is cheap, and few applications really need bespoke allocation. And it's not just a question of skill; even the most disciplined make mistakes. It's one of how much brainpower you want to allocate to... memory allocation.
Games.
Big/specialiased games to be precise, as for smaller projects managed language offer good enough performance.
No compiler gives you that memory safety flag (aside from very specific security features, ex. -fstack-protector) because it's not possible in C.
I am sorry but my observarion is that Nim and LLVM and dare I say even GC-less Java all achieve the same performance as C without the footgun baggage. Sometimes it is good to find a way to move on.
This is just false. Sure, they probably are 'close enough', but you can't claim the performance is 'the same' simply because those languages inherently do more to achieve the same results.
Because at this point, where can we find programmers who aren't 'less skilled practitioners'? Because it's clear Microsoft, Google, Apple, and major open source projects, have failed to find them based on memory corruption issues in the Linux, Windows and Mac kernels, chrome, and firefox.
There's a huge difference between C and C++. There's a big difference between 2001 version of C++ and 2021 version of C++.
The languages are so different that, in general, something that happens to one of them doesn't apply to the other.
Nah, this is a false dichotomy. If a language doesn't have product types but instead resort to declaring variables separately, you don't call that "structs". Similarly, calling tagged unions a sum type is kind of misleading. They are both programming languages, I am sure I can do whatever I can do in A using B.
Why is a "struct" such a powerful concept? Because it is correct by construction. When I declare struct A, I have everything that A should contain. It is impossible to say, oops, I forgot about A::b. Similarly, a sum type as a concept is only useful when the abstraction is very, very solid.
Tagged unions or variants (in C and C++ respectively) is nothing like that. I have a variant A, I checked that that it is B, but oops, I casted it as C. Its your typical TOCTOU (or LOCLOU for line of check, line of use, I guess). std::optional is also like, same with pointers. Proper sum types, like Rust, it is literally impossible for me to get C by mistake.
Obviously, all of this minus some underlying implementation details, unsafe code yadda yadda.
Sorry if I sound aggressive, but I am just tired of "we have A at home, A at home (the most cursed shit)".
Does go have enums? Yea... just declare some global constants like so bro.
SomeEnum_A = 0
SomeEnum_B = 1
SomeEnum_C = 2
Yea..."enums"..
Edit: Oh how can I forget, we had this kind of issue just TODAY in production. No wonder I am so pissed off.
Unless ofc you're contractually obligated to use vendors half-arsed kludget together patchy version of GCC of unknown provenance that they compiled with barely half C support, let alone other GCC languages.
The fact that a lot of C/C++ fans do not properly profile those areas of their programs does not mean they do not pay for them.
Or that defensive coding (assuming they do not want to introduce a happy little accident of CVE into the world) is free compared to having compiler lift necessary asserts outside of hot loop.
Some memory-safe languages even provide a faster feedback loop on exact instructions that will be executed for all code you write (probably most famous example is Common Lisp, which mandates that DISASSEMBLE is accessible to developer at all times)
In C++, you can not not type "this", at least if you don't, "this" will be looked up anyway.
Unfortunately, it isn't quite this, and many of the instances which people use it for this are actually undefined behavior; there's a hinterland of "things C compilers do" which are used as portable asm but are not part of C because they are UB.
I sometimes wonder if it would be feasible to define an actually portable typesafe macro assembler.
The Lions book is a good example of what that C used to be like.
That would probably count under modern definitions of "terrorism". I would also say that most school shootings should also be counted as "terrorism", except there's a very strong ideological push to not look at them this way. Don't look at the radicalisation. Don't read the (suspiciously similar) manifestoes. Don't look at who they cite for inspiration.
"The Pervert's Guide to Computer Programming Languages" https://www.youtube.com/watch?v=mZyvIHYn2zk
It's pretty out there, but I thought also interesting.
Is it acceptable to risk buffer overruns on the HTTP server running on an insulin pump?
Not because there's no other options (and long before Rust had its name coined)
And while you can technically prototype in a other language, speed of iteration is always a bottleneck.
The only way to escape it is if You are an about master of language, the project you are working on and even the feature you are adding.
But that's a verry rare case scenario
Rust's slower iteration only disappears when you become a pro as you said and that's my main problem with it. I simply can't invest as much time and effort for free.
This is in contrast to C++, where one organization creates a set of guidelines, another organization creates another set of guidelines. Valid arguments of critique in one organization are not seen in the other.
Single source of truth is also beneficial to compiler authors as well, because they get more feedback how the language is used and why.
Last time I checked ubsan was a few years ago for a small program, and I've read stuff about it not being suitable for anything outside development (more like a valgrind complement than a release option) because of how it messed with environment variables and linked libraries or something, so I might not have the full picture.
Totally agree with you: use the best tool for the job.
Are you talking about enums?
A sum type is an idea from type arithmetic. Suppose we have two types A and B, and we want to produce a new type from those, the most common provision in languages is to let you make a product type, it has all the values of A multiplied by all the values of B, this may be available to you as a named tuple, perhaps named a "struct" or "class" in your preferred language.
But what if instead we added these types instead of multiplying them? The new type has the values of A plus the values of B ? That's a sum type.
Suppose I have three types which resemble booleans: mood (it's either happy or sad), size (huge or tiny) and activity (either sleeping or eating)
A sum type of these three would allow me to make a "brief" of a cat as one of the six values, either as its mood, its size or its activity. The cat brief can be sad, or sleeping, or tiny, but it cannot be sleeping and sad [in this model] any more than a cat's size could be both huge and tiny. There are 2 + 2 + 2 = six values of the brief type.
In contrast a product type, maybe lets call that "state" of the cat consists of separate values of each of the three constituents, so the state of a cat might be (sad, tiny, sleeping) or (happy, huge, eating) or any other combination. There are 2 * 2 * 2 = eight values of this state type.
Just as an arithmetic is kinda crap if it only has multiply but not add, a type system is kinda crap if it can't make sum types. Where complicated hard-to-get-right hacks are used (e.g. C++ std::variant) these are often unsatisfying both ergonomically and in terms of delivered functionality, so hence the desire to have actual sum types in the language.
Crucially that's not necessarily what's going on in Rust and (assuming it lands) won't be the actual implementation of C++ std::optional<T&> specialisation.
Instead the language can decide from the value which type it has. This is where Rust's Guaranteed Niche Optimisation kicks in. If we've promised the compiler that type T's values don't occupy the space needed fully, the GNO promises that sum types consisting of T plus one other value are the same size as T was. There is no "tag field".
In practice, the compiler can provide optimisations beyond the Guarantee. For example the compiler can see that OwnedFd (a file descriptor) has a niche so Option<OwnedFd> is the same size as OwnedFd (ie the same size as a C integer, typically 4 bytes), but it can also see that char has a huge niche. Many of the 32 bits aren't needed to store a 21-bit Unicode scalar value, so (although the guarantee doesn't apply) a sum type of a char and six hundred other named possibilities is the same size as just the char was.
Ah, I see you mention this at the end, I think it's worth highlighting much earlier, that the "tag" isn't actually a mechanically necessary part of such a type.
But that still doesn't do C/C++ any favors. None of my Rust contracting work ever resulted in a buffer overflow.
Back in the days we were arguing for Ada, Modula-2, Object Pascal on Usenet, we were straitjacket programming advocates apparently.
And yeah I am gradually giving up on arguing with people who are extremely biased but point at me and blame me for being biased. Seems there's no win.
I actually regret engaging so thoroughly in this thread but once started I figured I'll not budge and will hold my ground. I am anti-group-think that way.
I haven't engaged in such threads in a while and I think the next time around is going to be months in the future. We'll see.
We’re mostly adopting rust to replace our C, to protect us from ourselves. It’s just so much easier to hand off these sort of projects to developers who mainly work with things like Java or C#. Partly because of the memory “safety” but also because things like enums work the way they expect them to being sum types, and so on. It’s also very clear when something is intended not to be mutable. The borrow checker is probably the biggest struggle, where with C, everything is a struggle.
Rust still has a long way to come though, and maybe it’ll never get there. I do think we’ll see an uptake as performance increasingly matters due to cloud costs and ESG. Right now though, I’d argue that unless you know why you “want” to use Rust then maybe you shouldn’t.
If you could theoretically swap out the entire back-end of a programming language, and hypothetically you did that to C# by allowing developers to write C# styling and syntax that could be compiled to Rust, it would probably not be a big loss. The type primitives would be an apples-apples comparison at best, or "Rust is just better" if you really scrutinized the types closely. Where does that leave the rest of the language? A better regex implementation? Rust would probably win. A better GUI experience? Rust is speedily approaching usable APIs there at the same time Microsoft is trying to sunset the best they had.
I wonder if F# could be rebased on top of Rust...
As you said, it's a pragmatic but also kinda niche language. I don't reach for it unless I can't do the job with others, easier and quicker to work with languages.
Maybe it's normal for people to praise something that legitimately solved their problems. I know that happened with me.
I genuinely think that :
1/ this field is dominated by a disproportionate amount of people with autistic traits
2/ their ability to reason only functions in the narrowest sense and their grasp of language (takes everything in the most literal sense, thinks in extremes, prone to putting things in boxes, have a very, very strong attachment to their routine and are unable to ever leave the comfort zone they constructed) makes any attempt at communication beyond painful.
I have come to not even bother replying to people who are unable to understand human words such as when they interpret "most" as meaning "all" or "rarely" as "never" as it's one of the telltale signs that it is going to be extremely unproductive.
This phenomenon is the cause of most pains and drama. Once you start to see how this pattern develops you understand the true cause of the endless bikeshedding, of why even the idea of having a code of conduct can raise endless anger and storms and so on. You're touching a comfort zone so the temper tantrums are thrown. The routine has been built and it must continue until the end of times.
If there's any field in this world that is in need of more neurotypical, emotionally stable adults, this is it.
But it's nice to add words like "autistic", "thinking in extremes", "painful", etc. to terminally bash on those people who are wrong and just can't learn...
But, by all means, go on, I can only presume you are bored.
As I said in multiple other comments, I know there are valid cases for C/C++ where various factors prevent migration. I am not playing a little rebel revolutionary here, I am addressing the people who can migrate away but refuse to do so based on hand-wavy philosophy clashes (or my favorite petty rebellious take: "people praise Rust, I must resist using it!"). Petty stuff and I am pretty disappointed that people who bill themselves as "engineers" refuse to see objective evidence and hold on to only what they know.
Those are the people I address with my comment. Not the people who will be never allowed to migrate away a 2 million lines worth of C codebase. They have my deepest sympathies.
I think it is widely accepted that Rust is more safe. (There comes the NPM factor too so it's not entirely clear). The thing is just, you are excited about this technology, and you are equating "engineering" with "security". You are willing to pretend that other merits and factors don't exist, including ergonomics of iteration, or inertia. I tried writing my usual explorative Win32 code in Rust for an evening. Well, it was painful and I went back to do it the way that works for me, that is supported by all the official tooling, and that the official documentation is written in. I also can't see myself reading reasonable Rust code quicker than I can read and write reasonable C code in a year down the line. It's just too intricate, too clever, too condensed / abstracted and at the same time too verbose. Another time I went to download a couple simple projects (e.g. text editor) to dabble a bit with. But the stuff was too opaque and had _hundreds_ of third-party dependencies, and I couldn't understand it well. So I lost interest.
Choice of language and ecosystem is an economic matter. They get chosen based on what one knows and what one wants and how one evaluates the possibilities. "Security" quite frankly is not the most important of concerns in most situations, and for a good reason. I frankly am not getting paid in finding the nicest or "most secure" way to write a piece of code, but to get it done. I am not interested in following the development of the hundreds of dependencies of my Rust project, and to change my data structures when they learned a better way to design the API to those "safe" data structures.
But you are seeing only "security". Well, it's most secure to just shut your computer off. So much for "objectivity". Maybe you _are_ the zealot!
And you have JavaScript were all functions have an implicit this ...
But regardless, the "rewrite in rust" advocacy has created a significant opportunity for projects created by single people, without outside review and often without significant domain expertise (at least where they are slavish re-implementations of existing code), to be proposed as replacements for longstanding stable tools. Whatever the merits of that chance it's also dream for someone looking to introduce new vulnerabilities. Even where the replacement itself is reviewed it will usually come with a massively expanded dependency footprint which isn't.
I used Turbo C++ (not C) back in the day, and recall near pointers, far pointers, based pointers, but I don't recall bounds-checked pointers. Do you remember any details?
>However, why bother trying
Because it would immediately make the large amounts of C code still in the wild safer for the users, who do care?
You can also run with ASan on, or compile into WebAssembly and run that… obviously not perfect though.
What do you mean by this? Like writing to a specific integer address?
*((volatile unsigned *)(0x20001000)) = 0x12345678;
It is, however, not the only way to write to memmapped registers.
The original C way of doing so was to use an assembly function wrapping the actual act of reading/writing (honestly, better than doing the above, as it helps making it very explicit how the write will happen as well as abstracting any details like needing to add a barrier or whatsoever), the other way was to specify the symbol with address of the memmapped register in assembly, and link resulting object with C code.
A C implementation is, AFAIK, free to refuse the literal addresses used as pointers and pass as ISO C.
At least they don't without LTO.
Please cite chapter and verse of the C standard which defines this behavior. Any edition.
Edit: Looks like the result in this case is implementation defined: https://stackoverflow.com/a/24212940
I don't hold with the "I'm not going to open a link on HN from Xe at work" bollocks, because I know its going to be a gem, moreover, I'm not a fucking prude.
If one can, at work, open the daily mail, "listen" to music videos, or read celeb gossip sites at work, then you can 100% look at computer using anthropomorphic animals.
Plus ever since I read your article about abusing S3 into a message queue, I've started using 18th century engravings of gargoyles, statues and classic sculpture to aid my presentations.
In summary, I love you work, I wish you to continue making it, and please don't take my comment as sarcastic. As I said before many months ago, this is what the internet was designed for, long may it continue.
High end games programming sometimes knocks the love of malloc()/free() (and naive RAII) out of them.
Note also that with (tracing) GC, you not only pay for the cost of allocation, but also pay for the time your allocated objects live.
A more nuanced take is that I can, in practice, map considerable chunk of developers I met and their understanding of memory as:
"it's magic" > "manual memory management rulz! my C/C++/Rust will be always better than GC" >>> people who actually studied automatic memory management a bit >> people who adjust memory management techniques to specific use cases
The fall off is pretty much exponential in amount of people, which I will admit does make some people defensive thanks to second group being both numerically big and undying because programmers suck at educating new generations. Same can be seen in various other areas, not just GC (though GC links with general trope of "opinions formed from people repeating things learnt from xeroxed half dog eaten copies of notes somewhat relevant on 256kB IBM 5150 PC and Turbo Pascal")
A lot of the time I do encounter people who essentially parrot claims about GC without any understanding of what's happening underneath, and indeed sometimes going about "crazy awesome non-GC solution!" that turns out to call out to whatever malloc()/free() happens to live in libc when I pull the cover and with just as much unpredictability as you can get.
As for paying - allocations in GC systems tend to be blindingly fast, but yes, collection does involve other costs.
A funny story related to all that from one of my previous jobs includes a high performance C++ code base that used forking to utilize preloaded code and data and to easily clean up after itself.
Turned out that naive-ish (even with jemalloc dropped in) memory management in C++ code resulted in latency spikes not because of allocation/freeing, but because they put no control over where things got allocated which resulted in huge TLB and pagetable thrashing as copy-on-write got engaged after forking.
To the point that using something like Ravenbrook's Memory Pool System (a GC) with threads quite possible would let them hit performance targets better.
I do no such thing. I am not at all excited about Rust in fact anymore, I just learned where it excels at and I know when to reach for it.
> You are willing to pretend that other merits and factors don't exist, including ergonomics of iteration, or inertia
I have literally just responded to you before this comment where I made it clear that I stopped actively using Rust due to slower speed of iteration -- and that is said in another comment as well (including the inertia or lack-of-choice factor).
Can you please not misrepresent what I said? It's clearly written in at least two places.
> Choice of language and ecosystem is an economic matter. They get chosen based on what one knows and what one wants and how one evaluates the possibilities.
Which agrees with my "right tool for the job" take elsewhere in the thread. We're aligned.
> I frankly am not getting paid in finding the nicest or "most secure" way to write a piece of code, but to get it done.
Yes, and that explains why the programming at large is always teetering on the verge of ruin and stuff is barely working and is kept together by goodwill and spit. Though obviously worker bees like you and me can't change that reality for now. I have partially made my peace with that fact but not entirely; hence I reach for Rust every now and then.
> But you are seeing only "security". Well, it's most secure to just shut your computer off. Maybe you _are_ the zealot!
You seem to have gotten quite worked up and I'll ask you to stop. When I told you that I am open to discussion in a previous comment I was genuine.
Both Microsoft and Google said that from 60% to 75% of all C bugs are memory safety problems -- not my words, not my research, but that of two of the largest IT corporations out there.
That is proof. That is objective info. We can bikeshed and throw feces at each other until the end of time but there are people who got out there and gathered the info.
I refuse to be viewed as a zealot simply because I want to attack the lowest hanging fruit in terms of bugs and security vulnerabilities. No, that makes me both a pragmatic and a guy who is no longer willing to live with the broken status quo.
And I'll not agree with your polarizing take that "the only security is shutting your computer down". That's nonsense. You are simply not motivated to advance anything but your career. That's your right, surely, but at the same time it makes you dismiss any well-intended discussion about the current state of our profession and how can it be advanced further. You dismiss stuff off-hand and then you blame me for being a zealot. Not acceptable to me and I'll not take it.
So try and calm down and read better. We in fact agree on much more than you think but you are not seeing it because you seem to have formed an opinion of me before you even started writing.
It's not "2 out of 3", it's a triangle where a language can pick a sweet spot anywhere within the triangle (and ideally, it's not a "sweet spot" either, but more like a "sweet area" where the programmer can pick an actual spot within that area defined by the language).
fn setData(comptime pins: anytype, bus: anytype, data: u8) @TypeOf(bus)
The borrow checker works on "struct granularity", but it would be much more flexible and convenient if borrowing would work on memory location granularity (for instance passing a struct reference into a function "taints" the entire struct as borrowed, even if that function only accesses a single item in the borrowed struct - this 'coarse borrowing' restriction then may lead to all sorts of workarounds to appease the compiler, from 'restructuring' your structs into smaller pieces (which then however may fit one borrowing situation, but not another), or using 'semantic crutches' like Rc, Cell or Box.
There are also related restrictions about function call barriers. AFAIK the Rust compiler cannot "peek into" called function bodies to figure out what's actually going on inside those functions (and that information would be very valuable for fine-grained borrow checking), it can only work with the information in the function signature.
Again, disclaimer: take this with a grain of salt since I'm not a daily Rust user, but this is how I understood why Rust feels so restrictive.
Your imagery is part of who you are as a writer, and it's part of your work. People need to take it or leave it.
What I mean is, most compilers won't generate a function call or an additional indirect memory access for *(111) = 222;, unlike your spec-compliant alternatives.
This is, IMO, the problem. Sometimes we just want a more ergonomic way than inline assembly in a hot loop (and also we'd like to to pretend its portable). The spec does not have an answer to this.
So, unless all C compilers in the world actively sabotage this usage (like how Go did to map traversal orders), your spec saying this is "implementation defined" have no impact at all. All C compilers are bound to implement the same intuitive but completely-not-enforced-by-spec behavior. Because if they don't, people just use something else.
That's valid, thanks for pointing it out. I seem to recall the team lately mentioning they are starting to consider fixing that. And yes that's a real productivity killer, happened to me as well in the past.
I don't think it's so much "can not" as it is "will not". Allowing the function signature to be determined by the body can lead to accidentally breaking callers by changing the body.
That, at least, is consistent with other parts of the signature: the input/output types and how the lifetimes of input/output references are related.
Anime is not inherently sexual as a medium but has a well-deserved reputation for being associated with creeps and perverts.
Don’t talk about either in professional settings.
I mean you could argue that about Emos, or Goths. Its not really true.
I'm sure sex is a large motivator, but you can't be doing sex all the time. When a Goth is dressed up all Goth-y its not because they are horny right now. They are just wanting to look good.
I imagine its the same with the furries, but the difference is, the furries are the butt of most jokes
Both being a goth and being a furry are about way more than clothing and appearance. Goths don’t really have anything to do with furries. I don’t know why you’re bringing them up.
Every furry I have met in real life thought it was a sex thing. Every normal person from the outside looking in thinks it’s a sex thing. Just look at the history of furry magazines and subculture and it is mind-numbingly obvious that it is a sex thing.
Even if it wasn’t a sex thing, would you want to discuss it at work knowing 99% of people will think of it that way?
Its basically clifford using a computer.
Because they're the ones that we keep hearing from right now. When it was the Haskell zealots showing up every few days, they were annoying. When it was the Lisp zealots, they were annoying.
The "religious zeal" was also an important reason why I switched back to C from C++ and why I don't have much interest in Rust. I can't quite stand the "holier than thou" attitude in.parts of those communities.
This is 100% baffling to me. Let me explain.
1. Every single area has zealots. Yours included. And we're not talking only work. Every hobby area as well.
2. What the attitude of the most toxic 0.1% of the users of a thing is has exactly ZERO correlation with whether the thing is good and worth using.
3. By resisting only those 0.1% toxic zealots you are only demonstrating meaningless rebelliousness. As a supposed adult you should be immune to what are people hyping up and form your own opinion. INFORMED opinion. Not one based on the "many people praise it hence I, the intellectual, will stay far away from that obvious nonsense" stance.
4. Have you considered that maybe, just maybe, Rust is praised because it's actually good? Have you considered that the Rust community is not trying to cheat its way into your heart, and that the love Rust gets is justified by the people who need its features? Seems like you did not, and that's disappointing.
In other words, I have zero clue of your thought process here, maybe you can help me understand?
Back in my home town the VW Golf had an ardent fan base, yet one of my friends still bought one after he graduated. He didn't call the people who loved VW Golf zealots. He did his research and concluded that with his budget and mechanic skills the VW Golf is the ideal option.
Food for thought?
And it's such endless circular discussion where the extremists show up (I guess the equivalent in Rust is shaming projects that use unsafe, IIRC there have been quite a few dramas in the past). Shit like this is simply mentally exhausting, and in now 7 years of C as my main language I did not encounter this even once). In general C coders seems to be a quite relaxed, happy and tolerant bunch.
I don’t use rust because I don’t have enough time in my life right now for discovering a new language just for the pleasure of it and even if I had, my real alternatives would be functional languages, not rust vs C++ which I use daily in a big project that has incentives stacked into C++ favor
The VWs you can just dump on the fans.
I know, I live in a similar country.
But even if it was true (I'd contest it's not) can't you ignore it and judge the language on its merits? We are not teenagers for a long, long time now, we should be making up our own mind about things.
But you denied my right to make up my own mind about Rust based on what its proponents say.
I believe you even attempted to insult me, too bad I don't know what curmudgeon means :)
I have not denied you anything, I implored you to ignore the zealots that exist IN EVERY ECOSYSTEM and judge the thing based on what it can actually do.
Please don't misrepresent what I said, that's not arguing in good faith.
Am I supposed to use a tool just because of what it's made of, or because it solves a problem for me?
No embarrassing buffer overflow CVEs is a very good start.
To me that's an actual selling point and I've migrated from almost all UNIX coreutils to Rust alternatives for that reason alone.
> Am I supposed to use a tool just because of what it's made of, or because it solves a problem for me?
No, as an adult you are supposed to not frame the discussion unfairly and ask the right questions.
Are your coreutils replacements 100% drop-in?
That's why I claimed that no such language exists.
Rust is quite the opposite, more primitives that carry semantics (most of those in the stdlib though), a stronger but also more rigid type system, but those are pretty much needed for the compiler to guarantee safety.
The million dollar question is of course, can there be a more relaxed Rust with the same safety and performance guarantees, maybe by "squeezing the type inference engine" even more (and letting Rust look or somehow extract information across crate boundaries)? And do Rust programmers even see this as desirable, or are they mostly comfortable in their current sweet spot of the triangle?
Rust absolutely is not the end state of programming languages but I feel in many ways it's quite ahead than most of everything else. But yes, we still need something a tad better than it.
in rust, the P and B are resolved at compile time, not at runtime. If you wanted dynamic dispatch the types would be Box<dyn B>
Diving into the ruins of Usenet, or UNIX/C literature, will provide enough examples.
This. "Undefined behavior" is such a terrible way of thinking. As is the "we can assume in the optimizer that UB does not happen and then eliminate code on that basis", which allows the compiler to introduce bugs that only appear at certain -O levels.
It took decades to get them to define arithmetic as twos-complement.
I'm not sure this is right? IIRC C++20/C23 require two's complement representation for signed integers but generally leave other behaviors (including signed overflow) the same.
[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p09...
Golang I hear is doing much better btw. But you still have to be wary of its footguns i.e. leaking goroutines.
Again, the former are fine, it's the latter I have a problem with.
Which isn't really a good aproach to structuring codebase, it's just to appeal to borrow checker inflexibility.
Lack of global scope. Lack of function overloading.
Then eventually C++ got invaded by C expatriates, and writing C with C++ compiler idioms increased instead of going away.
It is like giving Typescript to groups of folks that insist on using any all over the place.
There's no limit to perfection, but if you merely don't write C of opportunistic kind, logical errors quickly start to outweigh other types of errors.
Frankly this is a very bad decision. Because now you have C code, Rust code, and yet another language's code, and you're left with a mess that you have to integrate too.
Okay, let me try this then: https://soatok.blog/2021/04/02/the-furry-sexuality-blog-post...
Key argument: What isn't a sex thing?
My point is, there is an entire culture, just like emos, just like goths, and to me, that is fascinating.
So yeah, we do discuss it at work, and no I don't care overly much, because I don't work with 14 year olds.
Edit: from what I hear from my peers (translation: other programmers that I have coffee or drinks with), if I started a new server application today and I needed the performance of a compiled language, I should use Go not Rust.
I believe servers are where the propensity of C like languages to allow you to shoot yourself in the foot is the problem, isn't it?
Golang, Rust, Nim, Zig, and a few others are a much better fit nowadays.
However, if you reduce the language surface it is possible to have something safe and simple enough (IMHO).
For instance, you can say no async, no custom traits and only {Debug, Display, Eq, PartialEq, ...} are allowed for your structs and generics. From limited personal experience that takes away more than half of the complexity of navigating rust code.
You might be able to outsource some complexity to external libraries, but integrating libraries is itself a major headache, and it can lead to security issues too.
However, I believe the being "opt-in" by explicitly marking sections unsafe is the way to go instead of having unsafe by default (which is the only way using C).
You don’t need to outsource complexity anywhere. Rust is fully capable.
I think Rust’s reputation for being hard to learn is overblown. Yes it is probably a little more esoteric than what you’re familiar with but any decent dev should be able to pick it up
This is from my favourite book: In the beginning was the command line.
[0] https://web.stanford.edu/class/cs81n/command.txt , search "HOLE HAWG".
But, people aren't writing K&R C. These days most of them are writing something closer to C99 or C11 and some may be using something newer (e.g. C17) or proprietary (GNU's C dialect) either deliberately or just because it compiled and nobody told them not to.
At that point you've actually given away much of the simplicity, and yet what you get for your trouble is largely more footguns. Trade up for a sound type system and fewer footguns instead.
They were far less homogenous in the early years. Today you have a octet addressed little endian integer machine, with ieee float hardware and a small vector unit. Maybe you have two different instances of that on the same address space, but probably just one.
I think reasonable argument could be made that the complexity in modern computing is primarily self inflicted by software engineers.
You also addressed almost zero of what I said and asked you.
What's quite obvious when watching from the outside is that it's almost always people with a crab emoji in their profile who are more likely to talk shit about C programmers (myself included in a couple of cases via subtweeting).
I usually just shrug it off and move on, because what else is there to do?
FYI I did the same because the kind of work that I do does not desperately need Rust's benefits.
But I'll always call out biased and prejudiced people and I don't care about what the HN group-think believes.
> I usually just shrug it off and move on, because what else is there to do?
1. Stop thinking that the zealots are representative of... anything at all, really. (I don't include myself in that group of zealots. I get ticked off by bias and firmly held preconceived notions. That's why I commented as much in the entire sub-thread started by me.)
2. Do your own research like you did.
3. Refuse to think about trolls and zealots. Which is what all of us as healthy adults in this attention-predatory age of the internet should do.
This makes simple application code slightly faster. That's kind of a reasonable domain for C++ but on dubious ground for C. Where C is superb is talking to hardware and language implementation, exactly the areas the ISO group has chosen to cripple the language for.
Thankfully compilers know about this and provide fno-strict-aliasing et al. Maybe there should be a std= style flag to change to the language subset that doesn't actively try to miscompile your program chasing benchmark numbers.
Next one is what, the C11 memory model? Doesn't take away any simplicity, just defines things better.
In both those cases the K&R C model was very simple. You could decide you love how simple this model is, and when smarter compilers optimise it into a pretzel or other languages are faster that's OK. This code used to drive the serial port, now it does nothing, OK, don't use C to write such drivers. This code used to go real fast, now everybody else is faster, OK, don't use C if you need the best performance.
C89 and C99 choose different, making the language more complicated to keep addressing performance and compatibility. In C99 I can write the fast serial port driver, but it's significantly more complicated as a result. The beginner will definitely get it wrong and explaining why is pretty subtle.
Then C11 says actually you're not writing sequential programs, which was a crucial simplification in K&R C - the programs you can write do one thing at a time, in order, and then maybe stop. The memory model in C11 is needed because it says actually your programs might do more or different things at once.
Now, in reality by 2011 lots of people were writing C that's not actually sequential - after all SMP Linux long pre-dates C11. But those weren't legal C programs, they're GNU's dialect and so all bets are off. Nobody is claiming Linux is simple.
So C11 definitely isn't the simple language for a 1970s computer any more. C11 is a competitor with C++ or today Rust. And it doesn't fare so well by that comparison.
C11 atomics would have been much better if they'd standardised existing practice instead of inventing something based around the application centric design C++ was inventing. It's nice that there's an acquire/release scheme one can reason with but a real shame that they conflated it with type annotations.
I've already made my points several times. If you don't engage on the concrete arguments and are trying to be vaguely argumentative without substance then you're kind of polluting the replies.
Here's what should be a food for thought for you.
Also, you behaved quite rudely as well as counterproductively - to the point that, if I felt any investment in the Rust community, I would now be asking you please to stop trying to represent it, at least until you can do so competently enough not to embarrass those you purport to defend.
If I found I'd erred as you have, it would bother me a lot. How you handle it is, happily for me, not my problem. But now at least you can't say you've never been told.
You're the perfect example of biased and tunnel-visioned. Textbook example even.
Think what you will. Unfortunately for you, future readers will make up their own mind and not all will land at your defective conclusion.
Wink wink.
I am assuming that you did your own research, formed your own informed opinion, and ignored the feedback nevertheless because you know who is right :-)
I don't even use Rust for a while now, by the way, because its lower speed of iteration was an ill fit for my contracting work. I love what it's doing but it is not a silver bullet (but then again, what is?).
...and by the way, mental exhaustion is pretty much a given if you are a pro. That's one of the reasons we are paid gobs of money.
As for the "feedback" you are alluding to, it's more like people throwing feces at me but feel free to disagree. None of them have addressed my questions except maybe one. They all rushed into snark just like you did. Even 1000 such comments are not interesting or informed feedback and can't advance any discussion.
I am still here and still open to discuss... with the people who bother to discuss.
You're mistaking "idomatic because it's the only way" with "idomatic because we say say so". There is currently no way in Rust to specify the granularity of a borrow, so we're stuck with splitting your structs to get around it.
Part of the problem is that it's a hard problem to design around. It can not be done automatically by the compiler, because it would result in changes in the implementation being changes in the type signature. For example, say we have this function:
pub fn foo(&self) -> i32 {
self.a + 5
}
pub fn foo(&self) -> i32 {
self.a + self.b
}
You could, of course, say that we can allow the programmer to specify it manually:
pub fn foo<'borrow>(&'borrow self) -> i32
where 'borrow: 'self.a + 'self.b
{
self.a + self.b
}
The question is whether or not the fact of it not being implemented comes from problem difficulty, or designers explicit refusal to do so
Isn't there at least some technical basis for this (less-than-ideal interactions with type inference IIRC)?
Ask people if they used all flags of `sort` and report back results as a test of my hypothesis.
> The right questions according to who?
This is tiring. I told you twice that I'd prefer you engaging in technical merits. You keep drawing attention to what is annoying you but you'll have to talk to your friends and family about that because I am not interested.
Bye.
> This is tiring.
Hey, you're the one keeping the argument going...
I am getting tired of being misinterpreted, not of the argument itself because the argument ended several comments ago and the person focused on being a little rebel ("who gets the determine the right questions" is his favorite pet peeve apparently).
There is no argument currently, just people trying really hard to miss the point that was stated very clearly.
This “sometimes you need a knife" argument just doesn’t make sense. You can have the power and the safety. Stop cutting off your fingers.
> This “sometimes you need a knife" argument just doesn’t make sense. You can have the power and the safety. Stop cutting off your fingers.
Sometimes you need a scalpel.
I'm not against Rust. I still want to start a project where Rust will be worth learning for me, but I'm currently busy writing erlang and java for big systems and C for microcontrollers. This is of course only my local situation, I don't advocate for those languages (I love erlang though and I'm wishing for advertised easy concurrency in Rust, maybe someday).
I don’t think Rust should be used everywhere, but I’m firm that it could be used anywhere that C can (short of an unsupported architecture).
That code doesn't appear to be sequential from other threads is not the language's fault. It's just a fact of reality.
If you don't want to do SMP / lock-free programming, you don't have to pay for the complexity. You can still write "sequential programs" like it's K&R. Don't do multiple threads, and you don't have to care. You can also do multiple threads but use mutexes for synchronisation, everything will be fine.
Pretty much nobody uses restrict or volatile. There is some fringe stuff that is obsolete and maybe badly designed, but by and large you don't have to use it or interact with it. Compare this to other languages / ecosystems which have this amount of cruft times 100.
It's still this language where you can define a struct, then define a function that receives a pointer to the struct, and it does as you say, and you can actually read and understand the code a month later.
If you need to go fancy for a reason or another (most likely a bad reason), you can do that too, and of course you'll have to pay for it. But most likely, the complexity is not "cancerous" -- define a simple function interface with the most basic assumptions you require, and the complexity is pretty much isolated behind a simple pointer to an opaque structure.
> So C11 definitely isn't the simple language for a 1970s computer any more. C11 is a competitor with C++ or today Rust. And it doesn't fare so well by that comparison.
That's ridiculous and you know it.
"Faster but wrong" isn't really faster it's just wrong.
> That code doesn't appear to be sequential from other threads is not the language's fault. It's just a fact of reality.
What other threads? In a sequential programming language we certainly can't have "other threads".
> You can still write "sequential programs" like it's K&R.
"You can just not use the bits you don't like" is how we got C++ dialects that C++ proponents love to pretend don't exist. If the language is "simple" except for all the new bits that are complicated it's not simple.
(Or, I suppose, whether we're just talking past each other.)
Mine was that some people needlessly -- and very immaturely -- rebel against using Rust because of something they saw on HN 5 years ago. There's no Rust zealotry here for a long time.
I chased after a few people asking them if they really tried it or they simply resist something because it's gaining popularity.
How dare I? :D
I tried Rust and downloaded some projects that should be comparatively simple (e.g. text editor). "cargo build" downloaded and built about 500 dependencies. The Rust ecosystem had a chance to convince me, and it sure has some convincing results. But it wasn't my cup of tea.
If you included hundreds of dependencies to do what you can't easily do yourself within the "safe" framework, that may or may not be the language's or the ecosystem's failure. But the attribute "secure" for such a project is questionable. As NPM history or a certain guy or the recent events around the xz project illustrate well.
Number of dependencies is a bad signal for JS projects, I am not so sure the same applies for Rust however.