Of course, culture and technical design are both important for any language, but be specific. Despite the prevalence of tools that improve C's safety, writing C safely generally requires a culture of using those tools and other techniques. For better or worse, Rust's borrow checker is a clear demonstration of where Rust lies on the safety-freedom spectrum.

Before getting to research, I think a more honest attitude towards admitting motivated cognition in oneself and others is appropriate. I may give a spur-of-the-moment remark on a political situation, but at least if someone presses me, I will readily provide more insight on my biases and values. When I take the time to contemplate, I usually try to modify my eventual response to avoid undue bias altogether. Being reminded that motivated cognition is pervasive in all of us should reduce the unintentional-but-convenient faults in our cognition.

Rust's async is reminiscent of state machines, which are universal. The issues with the experience come from accidental complexity, in the language or the library ecosystem.

You are correct in the abstract, but concretely I contest how useful LLMs are for producing software. I don't doubt their usefulness in prototyping or, say, writing web apps, but I truly do not think they are revolutionary for me, or for software development as a whole.

You're naming and lambasting multiple different technologies and their communities without justifying why they are so bad. Few people use C without knowing about the threat of buffer overflows or invalid pointer dereferences, and C can be used productively in spite of these obvious flaws. Instead of trying to drive people away from what they do, if you seek understanding then you should allow others to justify their reasons. If you only test your understanding against your understanding, you're not making an assessment at all. You can find and talk to many smart people here and elsewhere, if you so desire.

Not to make a point of it either way, but judging a book by its cover can be useful if the credibility of the book's content alone is difficult to evaluate. That's why people care about degrees and other qualifications.

There are plenty of other ways. Book reviews for example. If the cover is the only way than so be it, but this is rarely case. Additionally the cover of a book, like capitalization is one of the most inaccurate metrics to judge a book by.

My point is that a questionable cover can indicate problems. I agree that one should be as holistic as possible.

I was going to disagree, along the lines of the people bringing up Bret Victor or other modes of communication and learning, but I have long accepted that the written word has been one of the largest boons for learning in human history, so I guess I agree. Still, it'll be an interesting and worthwhile challenge to make a better medium with modern technology.

I like to be flexible with policies, so while I think "capabilities" should be the core model, using ACL mechanisms under the hood is valid. If the capability mechanism is very minimal, people can build mechanisms and policies on top that are specialized for different use cases. It's not about "capabilities vs. ACLs"; it's "use the right tool for the job".

So while resource revocation in general is a hard problem, anyone can come up and implement their clever scheme in my imagined world.

Lifetimes and types are different, but the part where they are generic is the same. I think of it as "who controls/decides the value of this parameter". It's a crucial part of understanding lifetimes, not just a misconception.

Exactly, so it seems like a category error to say (as the article does) “generics and lifetimes are tightly intertwined in Rust”. I mean, would you say “generics and types are tightly intertwined in Rust”? If anything, types and lifetimes are intertwined — by generics!

Rust tutorials introduce lifetimes and stick them into the brackets, but I don’t remember one that explains genericity in a general way first, then applies it to both types and lifetimes. Lifetimes come across as a special thing that happens to be in the same brackets. (Or maybe that was just me!)

I believe the model in the compiler isn’t quite so pure in reality (IIRC, struct lifetimes can affect type unification), but most of the time this is the easiest way to understand it.

> The problem is that no-one can easily understand how their brain works compared to other people. People on both sides don't talk about it enough or openly enough. If you look at the science it quickly descends in to endless confusing/impenetrable psychiatric terminology.

It's not just how the "science" is conducted, or limited to a fixed number of sides. Everyone doesn't quite know what anyone else experiences. We all just throw around symbols, hoping someone gets what we mean by what we say, and assuming that we know what others mean by what they say. The meat of what we know and experience never gets transmitted faithfully to anyone.

To be certain, many people do have conditions that, say, I will never have. But that doesn't make me "normal" or those people "abnormal". The definition of a disorder by showing harm to living one's life is a good start, but fraught with the complexity of analyzing things in an implicit social context. If it seems that someone has a problem, I'll consider it a problem, not only if it seems sufficiently and officially abnormal.